mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-08-20 08:52:32 +00:00
Vincent Fiduccia
@@ -1,3 +1,7 @@
|
||||
--ignore-dir=public
|
||||
--ignore-dir=static
|
||||
--ignore-dir=src/img
|
||||
--ignore-dir=src/img
|
||||
--type-add=svg:ext:svg
|
||||
--no-xml
|
||||
--no-svg
|
||||
|
||||
+1
-1
@@ -59,7 +59,7 @@ layout: blank
|
||||
<p>Rancher Kubernetes Engine (RKE) is an extremely simple, lightning fast Kubernetes installer that works everywhere.</p>
|
||||
</div>
|
||||
<div class="border-top p-t-xs m-t-sm">
|
||||
<a href="{{< baseurl >}}/rke/v0.1.x/en" class="btn bg-link">Read the Docs</a>
|
||||
<a href="{{< baseurl >}}/rke/latest/en" class="btn bg-link">Read the Docs</a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -23,7 +23,7 @@ This procedure describes how to use RKE to restore a snapshot of the Rancher Kub
|
||||
|
||||
### 1. Preparation
|
||||
|
||||
You will need [RKE]({{< baseurl >}}/rke/v0.1.x/en/installation/) and [kubectl]({{< baseurl >}}/rancher/v2.x/en/faq/kubectl/) CLI utilities installed.
|
||||
You will need [RKE]({{< baseurl >}}/rke/latest/en/installation/) and [kubectl]({{< baseurl >}}/rancher/v2.x/en/faq/kubectl/) CLI utilities installed.
|
||||
|
||||
Prepare by creating 3 new nodes to be the target for the restored Rancher instance. See [HA Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/) for node requirements.
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@ When a node is unreachable and removed from the cluster, the automatic cleaning
|
||||
|
||||
## Imported Cluster Nodes
|
||||
|
||||
For imported clusters, the process for removing Rancher from its nodes is a little different. You can the option of simply deleting the cluster in the Rancher UI, or your can run a script that removes Rancher components from the nodes. Both options make the same deletions.
|
||||
For imported clusters, the process for removing Rancher from its nodes is a little different. You have the option of simply deleting the cluster in the Rancher UI, or your can run a script that removes Rancher components from the nodes. Both options make the same deletions.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "By UI / API" %}}
|
||||
@@ -82,9 +82,9 @@ Rather than cleaning imported cluster nodes using the Rancher UI, you can run a
|
||||
chmod +x user-cluster.sh
|
||||
```
|
||||
|
||||
1. **Air Gap Users Only:** Open `user-cluster.sh` and replace `yaml_url` with the URL in `user-cluster.yml`.
|
||||
1. **Air Gap Environments Only:** Open `user-cluster.sh` and replace `yaml_url` with the URL in `user-cluster.yml`.
|
||||
|
||||
If you aren't an air gap user, skip this step.
|
||||
If you don't have an air gap environment, skip this step.
|
||||
|
||||
1. From the same directory, run the script and provide the `rancher/rancher-agent` image version which should be equal to the version of Rancher used to manage the cluster. (`<RANCHER_VERSION>`):
|
||||
|
||||
@@ -103,7 +103,7 @@ Rather than cleaning imported cluster nodes using the Rancher UI, you can run a
|
||||
|
||||
### Docker Containers, Images, and Volumes
|
||||
|
||||
Based on what role you assigned to the node, Kubernetes components in containers, containers belonging to overlay networking, DNS, ingress controller and Rancher agent. (and pods you created that have been scheduled to this node)
|
||||
Based on what role you assigned to the node, there are Kubernetes components in containers, containers belonging to overlay networking, DNS, ingress controller and Rancher agent. (and pods you created that have been scheduled to this node)
|
||||
|
||||
**To clean all Docker containers, images and volumes:**
|
||||
|
||||
@@ -177,9 +177,7 @@ rm -rf /etc/ceph \
|
||||
|
||||
### Network Interfaces and Iptables
|
||||
|
||||
The remaining two components that are changed/configured are (virtual) network interfaces and iptables rules. Both are non-persistent to the node, meaning that they will be cleared after a restart of the node.
|
||||
|
||||
This is the recommended method.
|
||||
The remaining two components that are changed/configured are (virtual) network interfaces and iptables rules. Both are non-persistent to the node, meaning that they will be cleared after a restart of the node. To remove these components, a restart is recommended.
|
||||
|
||||
**To restart a node:**
|
||||
|
||||
|
||||
@@ -128,14 +128,14 @@ Option | Description |
|
||||
|
||||
>**Note:** In Rancher v2.0.5 and v2.0.6, the names of services in the Config File (YAML) should contain underscores only: `kube_api` and `kube_controller`.
|
||||
|
||||
Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/v0.1.x/en/config-options/) in an RKE installation.
|
||||
Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/latest/en/config-options/) in an RKE installation.
|
||||
|
||||
- To edit an RKE config file directly from the Rancher UI, click **Edit as YAML**.
|
||||
- To read from an existing RKE file, click **Read from File**.
|
||||
|
||||
|
||||
|
||||
For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/).
|
||||
For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/latest/en/example-yamls/).
|
||||
|
||||
## Managing Node Pools
|
||||
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ To provide stateful workloads with vSphere storage, we recommend creating a vSph
|
||||
|
||||
### Prerequisites
|
||||
|
||||
In order to provision vSphere volumes in a cluster created with the [Rancher Kubernetes Engine (RKE)]({{< baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the [vSphere cloud provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere) must be explicitly enabled in the [cluster options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/).
|
||||
In order to provision vSphere volumes in a cluster created with the [Rancher Kubernetes Engine (RKE)]({{< baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the [vSphere cloud provider]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere) must be explicitly enabled in the [cluster options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/).
|
||||
|
||||
### Creating A Storage Class
|
||||
|
||||
|
||||
@@ -69,7 +69,7 @@ If you use a Kubernetes provider such as Google GKE, Rancher integrates with its
|
||||
|
||||
### Rancher Launched Kubernetes
|
||||
|
||||
Alternatively, you can use Rancher to create a cluster on your own nodes, using [Rancher Kubernetes Engine (RKE)]({{< baseurl >}}/rke/v0.1.x/en/). RKE is Rancher’s own lightweight Kubernetes installer. In RKE clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform. These nodes can either:
|
||||
Alternatively, you can use Rancher to create a cluster on your own nodes, using [Rancher Kubernetes Engine (RKE)]({{< baseurl >}}/rke/latest/en/). RKE is Rancher’s own lightweight Kubernetes installer. In RKE clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform. These nodes can either:
|
||||
|
||||
- Be provisioned through Rancher's UI, which calls [Docker Machine](https://docs.docker.com/machine/) to launch nodes on various cloud providers.
|
||||
- Be a prior existing node that's brought into the cluster by running a Rancher agent container on it.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Rancher Launched Kubernetes
|
||||
weight: 2200
|
||||
---
|
||||
|
||||
If you don't want to use a hosted Kubernetes provider, you can have Rancher launch a Kubernetes cluster using any nodes you want. When Rancher deploys Kubernetes onto these nodes, it uses [Rancher Kubernetes Engine]({{< baseurl >}}/rke/v0.1.x/en/) (RKE), which is Rancher's own lightweight Kubernetes installer. It can launch Kubernetes on any computers, including:
|
||||
If you don't want to use a hosted Kubernetes provider, you can have Rancher launch a Kubernetes cluster using any nodes you want. When Rancher deploys Kubernetes onto these nodes, it uses [Rancher Kubernetes Engine]({{< baseurl >}}/rke/latest/en/) (RKE), which is Rancher's own lightweight Kubernetes installer. It can launch Kubernetes on any computers, including:
|
||||
|
||||
- Bare-metal servers
|
||||
- On-premise virtual machines
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ When creating a vSphere cluster, Rancher first provisions the specified amount o
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before proceeding to create a cluster, you must ensure that you have a vSphere user with sufficient permissions. If you are planning to make use of vSphere volumes for persistent storage in the cluster, there are [additional requirements]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere/) that must be met.
|
||||
Before proceeding to create a cluster, you must ensure that you have a vSphere user with sufficient permissions. If you are planning to make use of vSphere volumes for persistent storage in the cluster, there are [additional requirements]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere/) that must be met.
|
||||
|
||||
## Provisioning a vSphere Cluster
|
||||
|
||||
|
||||
@@ -3,12 +3,12 @@ title: Cluster Options
|
||||
weight: 2250
|
||||
---
|
||||
|
||||
As you configure a new cluster that's provisioned using [RKE]({{< baseurl >}}/rke/v0.1.x/en/), you can choose custom Kubernetes options.
|
||||
As you configure a new cluster that's provisioned using [RKE]({{< baseurl >}}/rke/latest/en/), you can choose custom Kubernetes options.
|
||||
|
||||
You can configure Kubernetes options one of two ways:
|
||||
|
||||
- [Rancher UI](#rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster.
|
||||
- [Config File](#config-file): Alternatively, you can create a [RKE config file]({{< baseurl >}}/rke/v0.1.x/en/config-options/) to customize any option offered by Kubernetes.
|
||||
- [Config File](#config-file): Alternatively, you can create a [RKE config file]({{< baseurl >}}/rke/latest/en/config-options/) to customize any option offered by Kubernetes.
|
||||
|
||||
## Rancher UI
|
||||
|
||||
@@ -43,14 +43,14 @@ From this section you can choose:
|
||||
- [Calico](https://docs.projectcalico.org/)
|
||||
- [Weave](https://github.com/weaveworks/weave) (_Available as of v2.2.0_)
|
||||
|
||||
When Weave is selected as network provider, Rancher will automatically enable encryption by generating a random password. If you want to specify the password manually, please see how to configure your cluster using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) and the [Weave Network Plug-in Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/#weave-network-plug-in-options).
|
||||
When Weave is selected as network provider, Rancher will automatically enable encryption by generating a random password. If you want to specify the password manually, please see how to configure your cluster using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) and the [Weave Network Plug-in Options]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/#weave-network-plug-in-options).
|
||||
|
||||
|
||||
<br/>
|
||||
|
||||
- If you want to configure a [Kubernetes cloud provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers). If you want to use [volumes and storage]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider.
|
||||
|
||||
>**Note:** If the cloud provider you want to use is not listed as an option, you will need to use the [config file option](#config-file) to configure the cloud provider. Please reference the [RKE cloud provider documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) on how to configure the cloud provider.
|
||||
>**Note:** If the cloud provider you want to use is not listed as an option, you will need to use the [config file option](#config-file) to configure the cloud provider. Please reference the [RKE cloud provider documentation]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/) on how to configure the cloud provider.
|
||||
|
||||
If you want to see all the configuration options for a cluster, please click **Show advanced options** on the bottom right. The advanced options are described below:
|
||||
|
||||
@@ -58,7 +58,7 @@ If you want to see all the configuration options for a cluster, please click **S
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
If you are using a private registry with authentication for your Docker images, please configure the registry in this section to allow the nodes to pull images from this registry. See [Private Registries]({{< baseurl >}}/rke/v0.1.x/en/config-options/private-registries/) for more information.
|
||||
If you are using a private registry with authentication for your Docker images, please configure the registry in this section to allow the nodes to pull images from this registry. See [Private Registries]({{< baseurl >}}/rke/latest/en/config-options/private-registries/) for more information.
|
||||
|
||||
### Authorized Cluster Endpoint
|
||||
|
||||
@@ -70,7 +70,7 @@ Authorized Cluster Endpoint can be used to directly access the Kubernetes API se
|
||||
|
||||
#### Nginx Ingress
|
||||
|
||||
Option to enable or disable the [NGINX ingress controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/).
|
||||
Option to enable or disable the [NGINX ingress controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/).
|
||||
|
||||
#### Node Port Range
|
||||
|
||||
@@ -78,7 +78,7 @@ Option to change the range of ports that can be used for [NodePort services](htt
|
||||
|
||||
#### Metrics Server Monitoring
|
||||
|
||||
Option to enable or disable [Metrics Server]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/metrics-server/).
|
||||
Option to enable or disable [Metrics Server]({{< baseurl >}}/rke/latest/en/config-options/add-ons/metrics-server/).
|
||||
|
||||
#### Pod Security Policy Support
|
||||
|
||||
@@ -94,20 +94,20 @@ If the nodes you are adding to the cluster have Docker configured with a non-def
|
||||
|
||||
#### Recurring etcd Snapshots
|
||||
|
||||
Option to enable or disable [recurring etcd snaphots]({{< baseurl >}}/rke/v0.1.x/en/etcd-snapshots/#etcd-recurring-snapshots).
|
||||
Option to enable or disable [recurring etcd snaphots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots).
|
||||
|
||||
## Config File
|
||||
|
||||
>**Note:** In Rancher v2.0.5 and v2.0.6, the names of services in the Config File (YAML) should contain underscores only: `kube_api` and `kube_controller`.
|
||||
|
||||
Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/v0.1.x/en/config-options/) in an RKE installation.
|
||||
Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/latest/en/config-options/) in an RKE installation.
|
||||
|
||||
- To edit an RKE config file directly from the Rancher UI, click **Edit as YAML**.
|
||||
- To read from an existing RKE file, click **Read from a file**.
|
||||
|
||||
|
||||
|
||||
For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/).
|
||||
For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/latest/en/example-yamls/).
|
||||
|
||||
### Rancher specific parameters
|
||||
|
||||
|
||||
+3
-3
@@ -13,10 +13,10 @@ By default, the **Cloud Provider** option is set to `None`. Supported cloud prov
|
||||
|
||||
The `Custom` cloud provider is available if you want to configure any [Kubernetes cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/).
|
||||
|
||||
For the custom cloud provider option, you can refer to the [RKE docs]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) on how to edit the yaml file for your specific cloud provider. There are specific cloud providers that have more detailed configuration :
|
||||
For the custom cloud provider option, you can refer to the [RKE docs]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/) on how to edit the yaml file for your specific cloud provider. There are specific cloud providers that have more detailed configuration :
|
||||
|
||||
* [vSphere]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere/)
|
||||
* [Openstack]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/openstack/)
|
||||
* [vSphere]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere/)
|
||||
* [Openstack]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/openstack/)
|
||||
|
||||
> **Warning:** Your cluster will not provision correctly if you configure a cloud provider cluster of nodes that do not meet the prerequisites. Prerequisites for supported cloud providers are listed below.
|
||||
|
||||
|
||||
@@ -150,4 +150,4 @@ As of Rancher v2.0.7, Canal is the default CNI network provider. We recommend it
|
||||
|
||||
### How can I configure a CNI network provider?
|
||||
|
||||
Please see [Cluster Options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/) on how to configure a network provider for your cluster. For more advanced configuration options, please see how to configure your cluster using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) and the options for [Network Plug-ins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/).
|
||||
Please see [Cluster Options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/) on how to configure a network provider for your cluster. For more advanced configuration options, please see how to configure your cluster using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) and the options for [Network Plug-ins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/).
|
||||
|
||||
@@ -156,7 +156,7 @@ When the node is removed from the cluster, and the node is cleaned, you can read
|
||||
|
||||
### How can I add additional arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
|
||||
|
||||
You can add additional arguments/binds/environment variables via the [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/).
|
||||
You can add additional arguments/binds/environment variables via the [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables]({{< baseurl >}}/rke/latest/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls]({{< baseurl >}}/rke/latest/en/example-yamls/).
|
||||
|
||||
### How do I check if my certificate chain is valid?
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Rancher supports air gap installs using a private registry. You must have your o
|
||||
The following CLI tools are required for this install. Make sure these tools are installed on your workstation and available in your `$PATH`.
|
||||
|
||||
* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
|
||||
* [rke]({{< baseurl >}}/rke/v0.1.x/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
|
||||
* [rke]({{< baseurl >}}/rke/latest/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
|
||||
* [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes.
|
||||
|
||||
>**Note:** If you install Rancher in an HA configuration in an air gap environment, you cannot transition to a single-node setup during future upgrades.
|
||||
|
||||
+12
-3
@@ -11,7 +11,7 @@ From a system that can access ports 22/tcp and 6443/tcp on your host nodes, use
|
||||
|
||||
Replace values in the code sample below with help of the _RKE Options_ table. Use the IP address or DNS names of the [3 nodes]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/provision-hosts) you created.
|
||||
|
||||
>**Tip:** For more details on the options available, see the RKE [Config Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/).
|
||||
>**Tip:** For more details on the options available, see the RKE [Config Options]({{< baseurl >}}/rke/latest/en/config-options/).
|
||||
|
||||
<figcaption>RKE Options</figcaption>
|
||||
|
||||
@@ -51,8 +51,6 @@ private_registries:
|
||||
is_default: true
|
||||
```
|
||||
|
||||
|
||||
|
||||
## B. Run RKE
|
||||
|
||||
After configuring `rancher-cluster.yml`, open Terminal and change directories to the RKE binary. Then enter the command below to stand up your high availability cluster.
|
||||
@@ -61,4 +59,15 @@ After configuring `rancher-cluster.yml`, open Terminal and change directories to
|
||||
rke up --config ./rancher-cluster.yml
|
||||
```
|
||||
|
||||
## C. Save Your Files
|
||||
|
||||
> **Important**
|
||||
> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
|
||||
|
||||
Save a copy of the following files in a secure location:
|
||||
|
||||
- `rancher-cluster.yml`: The RKE cluster configuration file.
|
||||
- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
|
||||
- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
|
||||
|
||||
### [Next: Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher)
|
||||
|
||||
+2
-2
@@ -55,13 +55,13 @@ By default, Rancher generates a CA and uses cert manger to issue the certificate
|
||||
1. From a system connected to the internet, fetch the latest cert-manager chart available from the [official Helm chart repository](https://github.com/helm/charts/tree/master/stable).
|
||||
|
||||
```plain
|
||||
helm fetch stable/cert-manager
|
||||
helm fetch stable/cert-manager --version 0.5.2
|
||||
```
|
||||
|
||||
1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.
|
||||
|
||||
```plain
|
||||
helm template ./cert-manager-<version>.tgz --output-dir . \
|
||||
helm template ./cert-manager-v0.5.2.tgz --output-dir . \
|
||||
--name cert-manager --namespace kube-system \
|
||||
--set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller
|
||||
```
|
||||
|
||||
@@ -25,7 +25,7 @@ This procedure walks you through setting up a 3-node cluster with RKE and instal
|
||||
The following CLI tools are required for this install. Please make sure these tools are installed and available in your `$PATH`
|
||||
|
||||
* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
|
||||
* [rke]({{< baseurl >}}/rke/v0.1.x/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
|
||||
* [rke]({{< baseurl >}}/rke/latest/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
|
||||
* [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes.
|
||||
|
||||
> **Important:** Due to an issue with Helm v2.12.0 and cert-manager, please use Helm v2.12.1 or higher.
|
||||
|
||||
@@ -11,7 +11,7 @@ Use your provider of choice to provision 3 nodes and a Load Balancer endpoint fo
|
||||
|
||||
View the supported operating systems and hardware/software/networking requirements for nodes running Rancher at [Node Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements).
|
||||
|
||||
View the OS requirements for RKE at [RKE Requirements]({{< baseurl >}}/rke/v0.1.x/en/os/)
|
||||
View the OS requirements for RKE at [RKE Requirements]({{< baseurl >}}/rke/latest/en/os/)
|
||||
|
||||
### Load Balancer
|
||||
|
||||
|
||||
@@ -15,6 +15,8 @@ kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
--key=tls.key
|
||||
```
|
||||
|
||||
> **Note:** If you want to replace the certificate, you can delete the `tls-rancher-ingress` secret using `kubectl -n cattle-system delete secret tls-rancher-ingress` and add a new one using the command shown above. Replacing the certificate is only supported if the new certificate is signed by the same CA as the certificate currently in use.
|
||||
|
||||
### Using a Private CA Signed Certificate
|
||||
|
||||
If you are using a private CA, Rancher requires a copy of the CA certificate which is used by the Rancher Agent to validate the connection to the server.
|
||||
|
||||
@@ -50,7 +50,7 @@ services:
|
||||
|
||||
RKE has many configuration options for customizing the install to suit your specific environment.
|
||||
|
||||
Please see the [RKE Documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/) for the full list of options and capabilities.
|
||||
Please see the [RKE Documentation]({{< baseurl >}}/rke/latest/en/config-options/) for the full list of options and capabilities.
|
||||
|
||||
### Run RKE
|
||||
|
||||
@@ -112,7 +112,14 @@ kube-system rke-network-plugin-deploy-job-6pbgj 0/1 Completed
|
||||
|
||||
### Save Your Files
|
||||
|
||||
Save a copy of the `kube_config_rancher-cluster.yml` and `rancher-cluster.yml` files. You will need these files to maintain and upgrade your Rancher instance.
|
||||
> **Important**
|
||||
> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
|
||||
|
||||
Save a copy of the following files in a secure location:
|
||||
|
||||
- `rancher-cluster.yml`: The RKE cluster configuration file.
|
||||
- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
|
||||
- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
|
||||
|
||||
### Issues or errors?
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Enable API Auditing
|
||||
weight: 300
|
||||
aliases:
|
||||
- /rke/v0.1.x/en/config-options/add-ons/api-auditing/
|
||||
- /rke/latest/en/config-options/add-ons/api-auditing/
|
||||
---
|
||||
|
||||
>**Important: RKE add-on install is only supported up to Rancher v2.0.8**
|
||||
|
||||
@@ -150,7 +150,7 @@ Choose a fully qualified domain name (FQDN) that you want to use to access Ranch
|
||||
|
||||
RKE (Rancher Kubernetes Engine) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. We will use RKE to setup our cluster and run Rancher.
|
||||
|
||||
1. Follow the [RKE Install]({{< baseurl >}}/rke/v0.1.x/en/installation) instructions.
|
||||
1. Follow the [RKE Install]({{< baseurl >}}/rke/latest/en/installation) instructions.
|
||||
|
||||
2. Confirm that RKE is now executable by running the following command:
|
||||
|
||||
@@ -170,7 +170,7 @@ RKE uses a `.yml` config file to install and configure your Kubernetes cluster.
|
||||
>**Advanced Config Options:**
|
||||
>
|
||||
>- Want records of all transactions with the Rancher API? Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/).
|
||||
>- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/).
|
||||
>- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/latest/en/config-options/).
|
||||
|
||||
|
||||
2. Rename the file to `rancher-cluster.yml`.
|
||||
@@ -186,7 +186,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec
|
||||
For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`.
|
||||
|
||||
>**Note:**
|
||||
> When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) >for RHEL/CentOS specific requirements.
|
||||
> When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) >for RHEL/CentOS specific requirements.
|
||||
|
||||
nodes:
|
||||
# The IP address or hostname of the node
|
||||
|
||||
@@ -98,7 +98,7 @@ Choose a fully qualified domain name (FQDN) that you want to use to access Ranch
|
||||
|
||||
RKE (Rancher Kubernetes Engine) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. We will use RKE to setup our cluster and run Rancher.
|
||||
|
||||
1. Follow the [RKE Install]({{< baseurl >}}/rke/v0.1.x/en/installation) instructions.
|
||||
1. Follow the [RKE Install]({{< baseurl >}}/rke/latest/en/installation) instructions.
|
||||
|
||||
2. Confirm that RKE is now executable by running the following command:
|
||||
|
||||
@@ -118,7 +118,7 @@ RKE uses a YAML config file to install and configure your Kubernetes cluster. Th
|
||||
>**Advanced Config Options:**
|
||||
>
|
||||
>- Want records of all transactions with the Rancher API? Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/).
|
||||
>- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/).
|
||||
>- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/latest/en/config-options/).
|
||||
|
||||
|
||||
2. Rename the file to `rancher-cluster.yml`.
|
||||
@@ -135,7 +135,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
|
||||
>When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
|
||||
|
||||
nodes:
|
||||
# The IP address or hostname of the node
|
||||
|
||||
@@ -3,12 +3,12 @@ title: Project Administration
|
||||
weight: 2500
|
||||
---
|
||||
|
||||
_Projects_ are objects introduced in Rancher that help organize namespaces in your Kubernetes cluster. You can use projects to create multi-tenant clusters, which allows a group of users to share the same underlying resources without interacting with each other's applications. Typically, any
|
||||
_Projects_ are objects introduced in Rancher that help organize namespaces in your Kubernetes cluster. You can use projects to create multi-tenant clusters, which allows a group of users to share the same underlying resources without interacting with each other's applications.
|
||||
|
||||
In terms of hierarchy:
|
||||
|
||||
- Clusters contain projects.
|
||||
- Projects contain namespaces.
|
||||
- Clusters contain projects
|
||||
- Projects contain namespaces
|
||||
|
||||
Within Rancher, projects allow you to manage multiple namespaces as a single entity. In native Kubernetes, which does not include projects, features like role-based access rights or cluster resources are assigned to individual namespaces. In clusters where multiple namespaces require the same set of access rights, assigning these rights to each individual namespace can become tedious. Even though all namespaces require the same rights, there's no way to apply those rights to all of your namespaces in a single action. You'd have to repetitively assign these rights to each namespace!
|
||||
|
||||
@@ -16,12 +16,12 @@ Rancher projects resolve this issue by allowing you to apply resources and acces
|
||||
|
||||
You can use projects to perform actions like:
|
||||
|
||||
- [Assign users access to a group of namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/project-members).
|
||||
- Assign users [specific roles in a project]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/).
|
||||
- [Assign users access to a group of namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/project-members)
|
||||
- Assign users [specific roles in a project]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/)
|
||||
- [Edit project settings]({{< baseurl >}}/rancher/v2.x/en/project-admin/editing-projects/)
|
||||
- [Set Resource Quotas]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/)
|
||||
- [Manage Namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/)
|
||||
- [Configure Tools]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/)
|
||||
- [Set resource quotas]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/)
|
||||
- [Manage namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/)
|
||||
- [Configure tools]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/)
|
||||
|
||||
### Authorization
|
||||
|
||||
@@ -33,7 +33,7 @@ Whoever creates the project automatically becomes a [project owner]({{< baseurl
|
||||
|
||||
To switch between projects, use the drop-down available in the navigation bar. Alternatively, you can switch between projects directly in the navigation bar.
|
||||
|
||||
1. From the **Global** view, navigate to the project that you want to configure pipelines.
|
||||
1. From the **Global** view, navigate to the project that you want to configure.
|
||||
|
||||
1. Select **Projects/Namespaces** from the navigation bar.
|
||||
|
||||
|
||||
@@ -77,6 +77,16 @@ NODE1 cannot reach NODE3
|
||||
|
||||
Cleanup the alpine DaemonSet by running `kubectl delete ds/overlaytest`.
|
||||
|
||||
### Check if MTU is correctly configured on hosts and on peering/tunnel appliances/devices
|
||||
|
||||
When the MTU is incorrectly configured (either on hosts running Rancher, nodes in created/imported clusters or on appliances/devices in between), error messages will be logged in Rancher and in the agents, similar to:
|
||||
|
||||
* `websocket: bad handshake`
|
||||
* `Failed to connect to proxy`
|
||||
* `read tcp: i/o timeout`
|
||||
|
||||
See [Google Cloud VPN: MTU Considerations](https://cloud.google.com/vpn/docs/concepts/mtu-considerations#gateway_mtu_vs_system_mtu) for an example how to configure MTU correctly when using Google Cloud VPN between Rancher and cluster nodes.
|
||||
|
||||
### Resolved issues
|
||||
|
||||
#### Overlay network broken when using Canal/Flannel due to missing node annotations
|
||||
|
||||
@@ -7,10 +7,6 @@ Service discovery is one of the core functionalities of any container-based envi
|
||||
|
||||
This document will also show you how to link the workloads and services that you migrated into Rancher v2.x. When you parsed your services from v1.6 using migration-tools CLI, it output two files for each service: one deployment manifest and one service manifest. You'll have to link these two files together before the deployment works correctly in v2.x.
|
||||
|
||||
<figcaption>Resolve the <code>output.txt</code> Link Directive</figcaption>
|
||||
|
||||
|
||||
|
||||
## In This Document
|
||||
|
||||
<!-- TOC -->
|
||||
@@ -62,11 +58,6 @@ When you migrate v1.6 services to v2.x, Rancher does not automatically create a
|
||||
|
||||
In the image below, the `web-deployment.yml` and `web-service.yml` files [created after parsing]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/run-migration-tool/#migration-example-file-output) our [migration example services]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/#migration-example-files) are linked together.
|
||||
|
||||
<figcaption>Linked Workload and Kubernetes Service</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
### Service Name Alias Creation
|
||||
|
||||
Just as you can create an alias for Rancher v1.6 services, you can do the same for Rancher v2.x workloads. Similarly, you can also create DNS records pointing to services running externally, using either their hostname or IP address. These DNS records are Kubernetes service objects.
|
||||
@@ -75,9 +66,6 @@ Using the v2.x UI, use the context menu to navigate to the `Project` view and ch
|
||||
|
||||
Click **Add Record** to create new DNS records. Then view the various options supported to link to external services or to create aliases for another workload, DNS record, or set of pods.
|
||||
|
||||
<figcaption>Add Service Discovery Record</figcaption>
|
||||
|
||||
|
||||
The following table indicates which alias options are implemented natively by Kubernetes and which options are implemented by Rancher leveraging Kubernetes.
|
||||
|
||||
Option | Kubernetes-implemented? | Rancher-implemented?
|
||||
|
||||
@@ -40,10 +40,6 @@ After provisioning your node(s), install Rancher:
|
||||
|
||||
After your Rancher v2.x Server is installed, we recommend configuring external authentication (like Active Directory or GitHub) so that users can log into Rancher using their single sign-on. For a full list of supported authentication providers and instructions on how to configure them, see [Authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication).
|
||||
|
||||
<figcaption>Rancher v2.x Authentication</figcaption>
|
||||
|
||||
|
||||
|
||||
### Local Users
|
||||
|
||||
Although we recommend using an external authentication provider, Rancher v1.6 and v2.x both offer support for users local to Rancher. However, these users cannot be migrated from Rancher v1.6 to v2.x. If you used local users in Rancher v1.6 and want to continue this practice in v2.x, you'll need to [manually recreate these user accounts]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) and assign them access rights.
|
||||
@@ -82,7 +78,7 @@ When you create a cluster, two projects are automatically created:
|
||||
- The `System` project, which includes system namespaces where important Kubernetes resources are running (like ingress controllers and cluster dns services)
|
||||
- The `Default` project.
|
||||
|
||||
However, for production environments, we recommend [creating your own project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#creating-projects) and giving it a descriptive name.
|
||||
However, for production environments, we recommend [creating your own project]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/#creating-projects) and giving it a descriptive name.
|
||||
|
||||
After provisioning a new cluster and project, you can authorize your users to access and use project resources. Similarly to Rancher v1.6 environments, Rancher v2.x allows you to [assign users to projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/). By assigning users to projects, you can limit what applications and resources a user can access.
|
||||
|
||||
|
||||
@@ -9,10 +9,6 @@ As outlined in [its documentation]({{< baseurl >}}/rancher/v1.6/en/cattle/adding
|
||||
|
||||
If you encounter the `output.txt` text below after parsing your v1.6 Compose files to Kubernetes manifests, you'll have to resolve it by manually creating a load balancer in v2.x.
|
||||
|
||||
<figcaption><code>output.txt</code> Load Balancer Directive</figcaption>
|
||||
|
||||
|
||||
|
||||
## In This Document
|
||||
|
||||
<!-- TOC -->
|
||||
@@ -43,7 +39,7 @@ By default, Rancher v2.x deploys NGINX Ingress Controller on clusters provisione
|
||||
|
||||
RKE deploys NGINX Ingress Controller as a [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), meaning that an NGINX instance is deployed on every node in the cluster. NGINX acts like an Ingress Controller listening to Ingress creation within your entire cluster, and it also configures itself as the load balancer to satisfy the Ingress rules. The DaemonSet is configured with hostNetwork to expose two ports: 80 and 443.
|
||||
|
||||
For more information NGINX Ingress Controller, their deployment as DaemonSets, deployment configuration options, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/).
|
||||
For more information NGINX Ingress Controller, their deployment as DaemonSets, deployment configuration options, see the [RKE documentation]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/).
|
||||
|
||||
## Load Balancing Architecture
|
||||
|
||||
@@ -53,17 +49,8 @@ In Rancher v1.6 you could deploy a scalable load balancer service within your st
|
||||
|
||||
<!-- add comparison table-->
|
||||
|
||||
<figcaption>Rancher v1.6 Load Balancing Architecture</figcaption>
|
||||
|
||||
|
||||
|
||||
The Rancher v2.x Ingress Controller is a DaemonSet, it is globally deployed on all schedulable nodes to serve your entire Kubernetes Cluster. Therefore, when you program the Ingress rules, you must use a unique hostname and path to point to your workloads, as the load balancer node IP addresses and ports 80 and 443 are common access points for all workloads.
|
||||
|
||||
<figcaption>Rancher v2.x Load Balancing Architecture</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
## Ingress Caveats
|
||||
|
||||
Although Rancher v2.x supports HTTP and HTTPS hostname and path-based load balancing, you must use unique host names and paths when configuring your workloads. This limitation derives from:
|
||||
@@ -79,14 +66,9 @@ You can launch a new load balancer to replace your load balancer from v1.6. Usin
|
||||
|
||||
>**Prerequisite:** Before deploying Ingress, you must have a workload deployed that's running a scale of two or more pods.
|
||||
>
|
||||
>
|
||||
|
||||
For balancing between these two pods, you must create a Kubernetes Ingress rule. To create this rule, navigate to your cluster and project, and then select the **Load Balancing** tab. Then click **Add Ingress**. This GIF below depicts how to add Ingress to one of your projects.
|
||||
|
||||
<figcaption>Browsing to Load Balancer Tab and Adding Ingress</figcaption>
|
||||
|
||||
|
||||
|
||||
Similar to a service/port rules in Rancher v1.6, here you can specify rules targeting your workload's container port. The sections below demonstrate how to create Ingress rules.
|
||||
|
||||
### Configuring Host- and Path-Based Routing
|
||||
@@ -95,18 +77,8 @@ Using Rancher v2.x, you can add Ingress rules that are based on host names or a
|
||||
|
||||
For example, let's say you have multiple workloads deployed to a single namespace. You can add an Ingress to route traffic to these two workloads using the same hostname but different paths, as depicted in the image below. URL requests to `foo.com/name.html` will direct users to the `web` workload, and URL requests to `foo.com/login` will direct users to the `chat` workload.
|
||||
|
||||
<figcaption>Ingress: Path-Based Routing Configuration</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
Rancher v2.x also places a convenient link to the workloads on the Ingress record. If you configure an external DNS to program the DNS records, this hostname can be mapped to the Kubernetes Ingress address.
|
||||
|
||||
<figcaption>Workload Links</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
The Ingress address is the IP address in your cluster that the Ingress Controller allocates for your workload. You can reach your workload by browsing to this IP address. Use `kubectl` command below to see the Ingress address assigned by the controller:
|
||||
|
||||
```
|
||||
@@ -118,11 +90,7 @@ kubectl get ingress
|
||||
Rancher v2.x Ingress functionality supports the HTTPS protocol, but if you want to use it, you need to use a valid SSL/TLS certificate. While configuring Ingress rules, use the **SSL/TLS Certificates** section to configure a certificate.
|
||||
|
||||
- We recommend [uploading a certificate]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/) from a known certificate authority (you'll have to do this before configuring Ingress). Then, while configuring your load balancer, use the **Choose a certificate** option and select the uploaded certificate that you want to use.
|
||||
- If you have configured [NGINX default certificate]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/#configuring-an-nginx-default-certificate), you can select **Use default ingress controller certificate**.
|
||||
|
||||
<figcaption>Load Balancer Configuration: SSL/TLS Certificate Section</figcaption>
|
||||
|
||||
|
||||
- If you have configured [NGINX default certificate]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/#configuring-an-nginx-default-certificate), you can select **Use default ingress controller certificate**.
|
||||
|
||||
### TCP Load Balancing Options
|
||||
|
||||
@@ -132,10 +100,6 @@ For the TCP protocol, Rancher v2.x supports configuring a Layer 4 load balancer
|
||||
|
||||
For example, if we create a deployment named `myapp` and specify a Layer 4 load balancer in the **Port Mapping** section, Rancher will automatically add an entry to the **Load Balancer** tab named `myapp-loadbalancer`.
|
||||
|
||||
<figcaption>Workload Deployment: Layer 4 Load Balancer Creation</figcaption>
|
||||
|
||||
|
||||
|
||||
Once configuration of the load balancer succeeds, the Rancher UI provides a link to your workload's public endpoint.
|
||||
|
||||
#### NGINX Ingress Controller TCP Support by ConfigMaps
|
||||
@@ -146,8 +110,6 @@ However, there is a workaround to use NGINX's TCP balancing by creating a Kubern
|
||||
|
||||
To configure NGINX to expose your services via TCP, you can add the ConfigMap `tcp-services` that should exist in the `ingress-nginx` namespace. This namespace also contains the NGINX Ingress Controller pods.
|
||||
|
||||
|
||||
|
||||
The key in the ConfigMap entry should be the TCP port that you want to expose for public access: `<namespace/service name>:<service port>`. As shown above, two workloads are listed in the `Default` namespace. For example, the first entry in the ConfigMap above instructs NGINX to expose the `myapp` workload (the one in the `default` namespace that's listening on private port 80) over external port `6790`. Adding these entries to the ConfigMap automatically updates the NGINX pods to configure these workloads for TCP balancing. The workloads exposed should be available at `<NodeIP>:<TCP Port>`. If they are not accessible, you might have to expose the TCP port explicitly using a NodePort service.
|
||||
|
||||
## Rancher v2.x Load Balancing Limitations
|
||||
|
||||
@@ -11,11 +11,6 @@ Use this document to correct Rancher v2.x workloads and services that list `heal
|
||||
|
||||
For example, for the image below, we would configure liveness probes for the `web` and `weblb` workloads (i.e., the Kubernetes manifests output by migration-tools CLI).
|
||||
|
||||
<figcaption>Resolve <code>health_check</code> for the <code>web</code> and <code>webLB</code> Workloads</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
## In This Document
|
||||
|
||||
<!-- TOC -->
|
||||
@@ -42,9 +37,6 @@ The health check microservice features two types of health checks, which have a
|
||||
|
||||
The following diagram displays the health check microservice evaluating a container running Nginx. Notice that the microservice is making its check across nodes.
|
||||
|
||||
|
||||
|
||||
|
||||
## Rancher v2.x Health Checks
|
||||
|
||||
In Rancher v2.x, the health check microservice is replaced with Kubernete's native health check mechanisms, called _probes_. These probes, similar to the Rancher v1.6 health check microservice, monitor the health of pods over TCP and HTTP.
|
||||
@@ -71,8 +63,6 @@ Kubernetes includes two different _types_ of probes: liveness checks and readine
|
||||
|
||||
The following diagram displays kubelets running probes on containers they are monitoring ([kubelets](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) are the primary "agent" running on each node). The node on the left is running a liveness probe, while the one of the right is running a readiness check. Notice that the kubelet is scanning containers on its host node rather than across nodes, as in Rancher v1.6.
|
||||
|
||||
|
||||
|
||||
## Configuring Probes in Rancher v2.x
|
||||
|
||||
The [migration-tool CLI]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/run-migration-tool/) cannot parse health checks from Compose files to Kubernetes manifest. Therefore, if want you to add health checks to your Rancher v2.x workloads, you'll have to add them manually.
|
||||
@@ -83,10 +73,6 @@ If the probe fails, the container is restarted per the restartPolicy defined in
|
||||
|
||||
Configure probes by using the **Health Check** section while editing deployments called out in `output.txt`.
|
||||
|
||||
<figcaption>Edit Deployment: Health Check Section</figcaption>
|
||||
|
||||
|
||||
|
||||
### Configuring Checks
|
||||
|
||||
While you create a workload using Rancher v2.x, we recommend configuring a check that monitors the health of the deployment's pods.
|
||||
@@ -99,8 +85,6 @@ TCP checks monitor your deployment's health by attempting to open a connection t
|
||||
|
||||
You can configure the probe along with values for specifying its behavior by selecting the **TCP connection opens successfully** option in the **Health Check** section. For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/). For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#health-check-parameter-mappings).
|
||||
|
||||
|
||||
|
||||
When you configure a readiness check using Rancher v2.x, the `readinessProbe` directive and the values you've set are added to the deployment's Kubernetes manifest. Configuring a readiness check also automatically adds a liveness check (`livenessProbe`) to the deployment.
|
||||
|
||||
<!--
|
||||
@@ -137,8 +121,6 @@ HTTP checks monitor your deployment's health by sending an HTTP GET request to a
|
||||
|
||||
You can configure the probe along with values for specifying its behavior by selecting the **HTTP returns successful status** or **HTTPS returns successful status**. For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/). For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#healthcheck-parameter-mappings).
|
||||
|
||||
|
||||
|
||||
When you configure a readiness check using Rancher v2.x, the `readinessProbe` directive and the values you've set are added to the deployment's Kubernetes manifest. Configuring a readiness check also automatically adds a liveness check (`livenessProbe`) to the deployment.
|
||||
|
||||
{{% /tab %}}
|
||||
@@ -149,17 +131,12 @@ When you configure a readiness check using Rancher v2.x, the `readinessProbe` di
|
||||
|
||||
While configuring a readiness check for either the TCP or HTTP protocol, you can configure a separate liveness check by clicking the **Define a separate liveness check**. For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#health-check-parameter-mappings).
|
||||
|
||||
|
||||
|
||||
### Additional Probing Options
|
||||
|
||||
Rancher v2.x, like v1.6, lets you perform health checks using the TCP and HTTP protocols. However, Rancher v2.x also lets you check the health of a pod by running a command inside of it. If the container exits with a code of `0` after running the command, the pod is considered healthy.
|
||||
|
||||
You can configure a liveness or readiness check that executes a command that you specify by selecting the `Command run inside the container exits with status 0` option from **Health Checks** while [deploying a workload]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).
|
||||
|
||||
|
||||
|
||||
|
||||
#### Health Check Parameter Mappings
|
||||
|
||||
While configuring readiness checks and liveness checks, Rancher prompts you to fill in various timeout and threshold values that determine whether the probe is a success or failure. The reference table below shows you the equivalent health check values from Rancher v1.6.
|
||||
|
||||
@@ -20,7 +20,7 @@ This command line interface tool will:
|
||||
- [A. Download the migration-tools CLI](#a-download-the-migration-tools-cli)
|
||||
- [B. Configure the migration-tools CLI](#b-configure-the-migration-tools-cli)
|
||||
- [C. Run the migration-tools CLI](#c-run-the-migration-tools-cli)
|
||||
- [D. Deploy Services Using Rancher CLI](#d-deploy-services-using-rancher-cli)
|
||||
- [D. Deploy Services Using Rancher CLI](#d-re-deploy-services-as-kubernetes-manifests)
|
||||
- [What Now?](#what-now)
|
||||
|
||||
|
||||
@@ -85,7 +85,7 @@ Next, use the migration-tools CLI to export all stacks in all of the Cattle envi
|
||||
|
||||
>**Note:** If you omit the `--docker-file` and `--rancher-file` options from your command, migration-tools uses the current working directory to find Compose files.
|
||||
|
||||
>**Want full usage and options for the migration-tools CLI?** See the [Migration Tools CLI Reference]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/migration-tools-ref/).
|
||||
>**Want full usage and options for the migration-tools CLI?** See the [Migration Tools CLI Reference]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/run-migration-tool/migration-tools-ref/).
|
||||
|
||||
### migration-tools CLI Output
|
||||
|
||||
@@ -238,15 +238,10 @@ status: {}
|
||||
|
||||
You can deploy the Kubernetes manifests created by migration-tools by importing them into Rancher v2.x.
|
||||
|
||||
<figcaption>Deploy Services: Import Kubernetes Manifest</figcaption>
|
||||
|
||||
>**Receiving an `ImportYaml Error`?**
|
||||
>
|
||||
>Delete the YAML directive listed in the error message. These are YAML directives from your v1.6 services that Kubernetes can't read.
|
||||
|
||||
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher CLI" %}}
|
||||
|
||||
@@ -266,27 +261,14 @@ Use the following Rancher CLI commands to deploy your application using Rancher
|
||||
|
||||
Following importation, you can view your v1.6 services in the v2.x UI as Kubernetes manifests by using the context menu to select `<CLUSTER> > <PROJECT>` that contains your services. The imported manifests will display on the **Workloads** and **Service Discovery** tabs.
|
||||
|
||||
<figcaption>Imported Services</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
## What Now?
|
||||
|
||||
Although the migration-tool CLI parses your Rancher v1.6 Compose files to Kubernetes manifests, there are discrepancies between v1.6 and v2.x that you must address by manually editing your parsed [Kubernetes manifests](#output). In other words, you need to edit each workload and service imported into Rancher v2.x, as displayed below.
|
||||
|
||||
<figcaption>Edit Migrated Services</figcaption>
|
||||
|
||||
|
||||
|
||||
As mentioned in [Migration Tools CLI Output](#migration-tools-cli-output), the `output.txt` files generated during parsing lists the manual steps you must make for each deployment. Review the upcoming topics for more information on manually editing your Kubernetes specs.
|
||||
|
||||
Open your `output.txt` file and take a look at its contents. When you parsed your Compose files into Kubernetes manifests, migration-tools CLI output a manifest for each workload that it creates for Kubernetes. For example, our when our [Migration Example Files]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/#migration-example-files) are parsed into Kubernetes manifests, `output.txt` lists each resultant parsed [Kubernetes manifest file](#migration-example-file-output) (i.e., workloads). Each workload features a list of action items to restore operations for the workload in v2.x.
|
||||
|
||||
<figcaption>Output.txt Example</figcaption>
|
||||
|
||||
|
||||
|
||||
The following table lists possible directives that may appear in `output.txt`, what they mean, and links on how to resolve them.
|
||||
|
||||
Directive | Instructions
|
||||
|
||||
@@ -13,8 +13,6 @@ You can schedule your migrated v1.6 services while editing a deployment. Schedul
|
||||
|
||||
<figcaption>Editing Workloads: Workload Type and Node Scheduling Sections</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
## In This Document
|
||||
|
||||
@@ -40,7 +38,6 @@ Rancher v2.x retains _all_ methods available in v1.6 for scheduling your service
|
||||
|
||||
In v1.6, you would schedule a service to a host while adding a service to a Stack. In Rancher v2.x., the equivalent action is to schedule a workload for deployment. The following composite image shows a comparison of the UI used for scheduling in Rancher v2.x versus v1.6.
|
||||
|
||||
|
||||
|
||||
## Node Scheduling Options
|
||||
|
||||
@@ -54,8 +51,8 @@ Option | v1.6 Feature | v2.x Feature
|
||||
-------|------|------
|
||||
[Schedule a certain number of pods?](#schedule-a-certain-number-of-pods) | ✓ | ✓
|
||||
[Schedule pods to specific node?](#scheduling-pods-to-a-specific-node) | ✓ | ✓
|
||||
[Schedule to nodes using labels?](#scheduling-pods-using-labels) | ✓ | ✓
|
||||
[Schedule to nodes using label affinity/anti-affinity rules?](#scheduling-pods-using-affinityanti-affinity-label) | ✓ | ✓
|
||||
[Schedule to nodes using labels?](#applying-labels-to-nodes-and-pods) | ✓ | ✓
|
||||
[Schedule to nodes using label affinity/anti-affinity rules?](#label-affinity-antiaffinity) | ✓ | ✓
|
||||
[Schedule based on resource constraints?](#scheduling-pods-using-resource-constraints) | ✓ | ✓
|
||||
[Preventing scheduling specific services to specific hosts?](#preventing-scheduling-specific-services-to-specific-nodes) | ✓ | ✓
|
||||
[Schedule services globally?](#scheduling-global-services) | ✓ | ✓
|
||||
@@ -65,17 +62,8 @@ Option | v1.6 Feature | v2.x Feature
|
||||
|
||||
In v1.6, you could control the number of container replicas deployed for a service. You can schedule pods the same way in v2.x, but you'll have to set the scale manually while editing a workload.
|
||||
|
||||
|
||||
|
||||
|
||||
During migration, you can resolve `scale` entries in `output.txt` by setting a value for the **Workload Type** option **Scalable deployment** depicted below.
|
||||
|
||||
<figcaption>Scalable Deployment Option</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Scheduling Pods to a Specific Node
|
||||
|
||||
Just as you could schedule containers to a single host in Rancher v1.6, you can schedule pods to single node in Rancher v2.x
|
||||
@@ -83,18 +71,12 @@ Just as you could schedule containers to a single host in Rancher v1.6, you can
|
||||
As you deploy a workload, use the **Node Scheduling** section to choose a node to run your pods on. The workload below is being scheduled to deploy an Nginx image with a scale of two pods on a specific node.
|
||||
<!-- Question: What would be a good use case for use of a scheduling pods on the same node?-->
|
||||
|
||||
<figcaption>Rancher v2.x: Workload Deployment</figcaption>
|
||||
|
||||
|
||||
|
||||
Rancher schedules pods to the node you select if 1) there are compute resource available for the node and 2) you've configured port mapping to use the HostPort option, that there are no port conflicts.
|
||||
|
||||
If you expose the workload using a NodePort that conflicts with another workload, the deployment gets created successfully, but no NodePort service is created. Therefore, the workload isn't exposed outside of the cluster.
|
||||
|
||||
After the workload is created, you can confirm that the pods are scheduled to your chosen node. From the **Workloads** tab, click the **Group by Node** icon to sort your workloads by node. Note that both Nginx pods are scheduled to the same node.
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
If you export the workload's manifest for Rancher v2.x, you can see in the pod spec that the workload is scheduled to the node that you selected (`nodeName: mark-do1`).
|
||||
@@ -159,10 +141,6 @@ To apply labels to pods, make additions to the **Labels and Annotations** sectio
|
||||
|
||||
Some of the most-used scheduling features in v1.6 were affinity and anti-affinity rules.
|
||||
|
||||
<figcaption><code>output.txt</code> Affinity Label</figcaption>
|
||||
|
||||
|
||||
|
||||
- **Affinity**
|
||||
|
||||
Any pods that share the same label are scheduled to the same node. Affinity can be configured in one of two ways:
|
||||
@@ -174,10 +152,6 @@ Some of the most-used scheduling features in v1.6 were affinity and anti-affinit
|
||||
|
||||
<br/>
|
||||
|
||||
<figcaption>Affinity Rules: Hard and Soft</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
- **AntiAffinity**
|
||||
|
||||
@@ -187,10 +161,6 @@ Some of the most-used scheduling features in v1.6 were affinity and anti-affinit
|
||||
|
||||
For anti-affinity rules, we recommend using labels with phrases like `NotIn` and `DoesNotExist`, as these terms are more intuitive when users are applying anti-affinity rules.
|
||||
|
||||
<figcaption>AntiAffinity Operators</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Detailed documentation for affinity/anti-affinity is available in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
|
||||
@@ -204,9 +174,6 @@ In Rancher v1.6 setups, you could prevent services from being scheduled to speci
|
||||
|
||||
In Rancher v2.x, you can prevent pods from being scheduled to specific nodes by applying _taints_ to a node. Pods will not be scheduled to a tainted node unless it has special permission, called a _toleration_. A toleration is a special label that allows a pod to be deployed to a tainted node. While editing a workload, you can apply tolerations using the **Node Scheduling** section. Click **Show advanced options**.
|
||||
|
||||
<figcaption>Applying Tolerations</figcaption>
|
||||
|
||||
|
||||
|
||||
For more information, see the Kubernetes documentation on [taints and tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/).
|
||||
|
||||
@@ -214,20 +181,10 @@ For more information, see the Kubernetes documentation on [taints and toleration
|
||||
|
||||
Rancher v1.6 included the ability to deploy [global services]({{< baseurl >}}/rancher/v1.6/en/cattle/scheduling/#global-service), which are services that deploy duplicate containers to each host in the environment (i.e., nodes in your cluster using Rancher v2.x terms). If a service has the `io.rancher.scheduler.global: 'true'` label declared, then Rancher v1.6 schedules a service container on each host in the environment.
|
||||
|
||||
|
||||
<figcaption><code>output.txt</code> Global Service Label</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
In Rancher v2.x, you can schedule a pod to each node using a [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), which is a specific type of workload <!-- link -->). A _DaemonSet_ functions exactly like a Rancher v1.6 global service. The Kubernetes scheduler deploys a pod on each node of the cluster, and as new nodes are added, the scheduler will start new pods on them provided they match the scheduling requirements of the workload. Additionally, in v2.x, you can also limit a DaemonSet to be deployed to nodes that have a specific label.
|
||||
|
||||
To create a daemonset while configuring a workload, choose **Run one pod on each node** from the the **Workload Type** options.
|
||||
|
||||
<figcaption>Workload Configuration: Choose run one pod on each node to configure daemonset</figcaption>
|
||||
|
||||
|
||||
|
||||
### Scheduling Pods Using Resource Constraints
|
||||
|
||||
While creating a service in the Rancher v1.6 UI, you could schedule its containers to hosts based on hardware requirements that you choose. The containers are then scheduled to hosts based on which ones have bandwidth, memory, and CPU capacity.
|
||||
@@ -247,10 +204,6 @@ To declare resource constraints, edit your migrated workloads, editing the **Sec
|
||||
- Memory Limit
|
||||
- CPU Limit
|
||||
|
||||
<figcaption>Scheduling: Resource Constraint Settings</figcaption>
|
||||
|
||||
|
||||
|
||||
You can find more detail about these specs and how to use them in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container).
|
||||
|
||||
### [Next: Service Discovery]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/discover-services/)
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
---
|
||||
title: v0.1.x
|
||||
title: RKE
|
||||
showBreadcrumb: false
|
||||
---
|
||||
+2
-2
@@ -12,9 +12,9 @@ Certificates are an important part of Kubernetes clusters and are used for all K
|
||||
|
||||
## Generating Certificate Signing Requests (CSRs) and Keys
|
||||
|
||||
If you want to create and sign the certificates by a real Certificate Authority (CA), you can use RKE to [generate a set of Certificate Signing Requests (CSRs) and keys]({{< baseurl >}}/rke/v0.1.x/en/installation/certs/#generating-certificate-signing-requests-csrs-and-keys).
|
||||
If you want to create and sign the certificates by a real Certificate Authority (CA), you can use RKE to [generate a set of Certificate Signing Requests (CSRs) and keys]({{< baseurl >}}/rke/latest/en/installation/certs/#generating-certificate-signing-requests-csrs-and-keys).
|
||||
|
||||
You can use the CSRs and keys to sign the certificates by a real CA. After the certificates are signed, these custom certificates can be used by RKE to as [custom certificates]({{< baseurl >}}/rke/v0.1.x/en/installation/certs/) for the Kubernetes cluster.
|
||||
You can use the CSRs and keys to sign the certificates by a real CA. After the certificates are signed, these custom certificates can be used by RKE to as [custom certificates]({{< baseurl >}}/rke/latest/en/installation/certs/) for the Kubernetes cluster.
|
||||
|
||||
## Certificate Rotation
|
||||
|
||||
+19
-19
@@ -5,31 +5,31 @@ weight: 200
|
||||
|
||||
When setting up your `cluster.yml` for RKE, there are a lot of different options that can be configured to control the behavior of how RKE launches Kubernetes.
|
||||
|
||||
There are several options that can be configured in cluster configuration option. There are several [example yamls]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/) that contain all the options.
|
||||
There are several options that can be configured in cluster configuration option. There are several [example yamls]({{< baseurl >}}/rke/latest/en/example-yamls/) that contain all the options.
|
||||
|
||||
### Configuring Nodes
|
||||
* [Nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/)
|
||||
* [Nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/)
|
||||
* [Ignoring unsupported Docker versions](#supported-docker-versions)
|
||||
* [Private Registries]({{< baseurl >}}/rke/v0.1.x/en/config-options/private-registries/)
|
||||
* [Private Registries]({{< baseurl >}}/rke/latest/en/config-options/private-registries/)
|
||||
* [Cluster Level SSH Key Path](#cluster-level-ssh-key-path)
|
||||
* [SSH Agent](#ssh-agent)
|
||||
* [Bastion Host]({{< baseurl >}}/rke/v0.1.x/en/config-options/bastion-host/)
|
||||
* [Bastion Host]({{< baseurl >}}/rke/latest/en/config-options/bastion-host/)
|
||||
|
||||
### Configuring Kubernetes Cluster
|
||||
* [Cluster Name](#cluster-name)
|
||||
* [Kubernetes Version](#kubernetes-version)
|
||||
* [System Images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/)
|
||||
* [Services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/)
|
||||
* [Extra Args and Binds and Environment Variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/)
|
||||
* [External Etcd]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/external-etcd/)
|
||||
* [Authentication]({{< baseurl >}}/rke/v0.1.x/en/config-options/authentication/)
|
||||
* [Authorization]({{< baseurl >}}/rke/v0.1.x/en/config-options/authorization/)
|
||||
* [Cloud Providers]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/)
|
||||
* [Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/)
|
||||
* [System Images]({{< baseurl >}}/rke/latest/en/config-options/system-images/)
|
||||
* [Services]({{< baseurl >}}/rke/latest/en/config-options/services/)
|
||||
* [Extra Args and Binds and Environment Variables]({{< baseurl >}}/rke/latest/en/config-options/services/services-extras/)
|
||||
* [External Etcd]({{< baseurl >}}/rke/latest/en/config-options/services/external-etcd/)
|
||||
* [Authentication]({{< baseurl >}}/rke/latest/en/config-options/authentication/)
|
||||
* [Authorization]({{< baseurl >}}/rke/latest/en/config-options/authorization/)
|
||||
* [Cloud Providers]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/)
|
||||
* [Add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/)
|
||||
* [Add-ons Jobs Timeout](#add-ons-jobs-timeout)
|
||||
* [Network Plugins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/)
|
||||
* [Ingress Controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/)
|
||||
* [User-Defined-Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/)
|
||||
* [Network Plugins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/)
|
||||
* [Ingress Controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/)
|
||||
* [User-Defined-Add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/user-defined-add-ons/)
|
||||
|
||||
|
||||
## Cluster Level Options
|
||||
@@ -62,7 +62,7 @@ You can set the Kubernetes version as follows:
|
||||
kubernetes_version: "v1.11.6-rancher1-1"
|
||||
```
|
||||
|
||||
In case both `kubernetes_version` and [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) are defined, the system images configuration will take precedence over `kubernetes_version`.
|
||||
In case both `kubernetes_version` and [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) are defined, the system images configuration will take precedence over `kubernetes_version`.
|
||||
|
||||
#### Listing Supported Kubernetes Versions
|
||||
|
||||
@@ -87,11 +87,11 @@ As of v0.2.0, if a version is defined in `kubernetes_version` and is not found i
|
||||
|
||||
Prior to v0.2.0, if a version is defined in `kubernetes_version` and is not found in the specific list of supported Kubernetes versions, the default version from the supported list is used.
|
||||
|
||||
If you want to use a different version from the supported list, please use the [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) option.
|
||||
If you want to use a different version from the supported list, please use the [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) option.
|
||||
|
||||
### Cluster Level SSH Key Path
|
||||
|
||||
RKE connects to host(s) using `ssh`. Typically, each node will have an independent path for each ssh key, i.e. `ssh_key_path`, in the `nodes` section, but if you have a SSH key that is able to access **all** hosts in your cluster configuration file, you can set the path to that ssh key at the top level. Otherwise, you would set the ssh key path in the [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/).
|
||||
RKE connects to host(s) using `ssh`. Typically, each node will have an independent path for each ssh key, i.e. `ssh_key_path`, in the `nodes` section, but if you have a SSH key that is able to access **all** hosts in your cluster configuration file, you can set the path to that ssh key at the top level. Otherwise, you would set the ssh key path in the [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/).
|
||||
|
||||
If ssh key paths are defined at the cluster level and at the node level, the node-level key will take precedence.
|
||||
|
||||
@@ -121,6 +121,6 @@ $ echo $SSH_AUTH_SOCK
|
||||
|
||||
### Add-ons Job Timeout
|
||||
|
||||
You can define [add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/) to be deployed after the Kubernetes cluster comes up, which uses Kubernetes [jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). RKE will stop attempting to retrieve the job status after the timeout, which is in seconds. The default timeout value is `30` seconds.
|
||||
You can define [add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/) to be deployed after the Kubernetes cluster comes up, which uses Kubernetes [jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). RKE will stop attempting to retrieve the job status after the timeout, which is in seconds. The default timeout value is `30` seconds.
|
||||
|
||||
```yaml
|
||||
+6
-6
@@ -5,12 +5,12 @@ weight: 260
|
||||
|
||||
RKE supports pluggable add-ons. Add-ons are used to deploy several cluster components including:
|
||||
|
||||
* [Network plug-ins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/)
|
||||
* [Ingress controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/)
|
||||
* [DNS provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/dns/)
|
||||
* [Metrics Server]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/metrics-server/)
|
||||
* [Network plug-ins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/)
|
||||
* [Ingress controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/)
|
||||
* [DNS provider]({{< baseurl >}}/rke/latest/en/config-options/add-ons/dns/)
|
||||
* [Metrics Server]({{< baseurl >}}/rke/latest/en/config-options/add-ons/metrics-server/)
|
||||
|
||||
The images used for these add-ons under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each add-on, but these can be overridden by changing the image tag in `system_images`.
|
||||
The images used for these add-ons under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each add-on, but these can be overridden by changing the image tag in `system_images`.
|
||||
|
||||
In addition to these pluggable add-ons, you can specify an add-on that you want deployed after the cluster deployment is complete.
|
||||
|
||||
@@ -28,7 +28,7 @@ As of version v0.1.7, add-ons are split into two categories:
|
||||
- **Critical add-ons:** If these add-ons fail to deploy for any reason, RKE will error out.
|
||||
- **Non-critical add-ons:** If these add-ons fail to deploy, RKE will only log a warning and continue deploying any other add-ons.
|
||||
|
||||
Currently, only the [network plug-in]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/) is considered critical. KubeDNS, [ingress controllers]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/) and [user-defined add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/) are considered non-critical.
|
||||
Currently, only the [network plug-in]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/) is considered critical. KubeDNS, [ingress controllers]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/) and [user-defined add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/user-defined-add-ons/) are considered non-critical.
|
||||
|
||||
## Add-on deployment jobs
|
||||
|
||||
+2
-2
@@ -7,13 +7,13 @@ By default, RKE deploys [kube-dns](https://github.com/kubernetes/dns) as DNS pro
|
||||
|
||||
RKE will deploy kube-dns as a Deployment with the default replica count of 1. The pod consists of 3 containers: `kubedns`, `dnsmasq` and `sidecar`. RKE will also deploy kube-dns-autoscaler as a Deployment, which will scale the kube-dns Deployment by using the number of cores and nodes. Please see [Linear Mode](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler#linear-mode) for more information about this logic.
|
||||
|
||||
The images used for kube-dns are under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with kube-dns, but these can be overridden by changing the image tag in `system_images`.
|
||||
The images used for kube-dns are under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with kube-dns, but these can be overridden by changing the image tag in `system_images`.
|
||||
|
||||
## Scheduling kube-dns
|
||||
|
||||
_Available as of v0.2.0_
|
||||
|
||||
If you only wanted ingress controllers to be deployed on specific nodes, you can set a `node_selector` for the ingress. The label in the `node_selector` would need to match the label on the nodes for the ingress controller to be deployed.
|
||||
If you only want the kube-dns pod to be deployed on specific nodes, you can set a `node_selector` in the `dns` section. The label in the `node_selector` would need to match the label on the nodes for the kube-dns pod to be deployed.
|
||||
|
||||
```yaml
|
||||
nodes:
|
||||
+1
-1
@@ -9,7 +9,7 @@ By default, RKE deploys the NGINX ingress controller on all schedulable nodes.
|
||||
|
||||
RKE will deploy the ingress controller as a DaemonSet with `hostnetwork: true`, so ports `80`, and `443` will be opened on each node where the controller is deployed.
|
||||
|
||||
The images used for ingress controller is under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with the ingress controller, but these can be overridden by changing the image tag in `system_images`.
|
||||
The images used for ingress controller is under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with the ingress controller, but these can be overridden by changing the image tag in `system_images`.
|
||||
|
||||
## Scheduling Ingress Controllers
|
||||
|
||||
+1
-1
@@ -7,7 +7,7 @@ By default, RKE deploys [Metrics Server](https://github.com/kubernetes-incubator
|
||||
|
||||
RKE will deploy Metrics Server as a Deployment.
|
||||
|
||||
The image used for Metrics Server is under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there is a default image associated with the Metrics Server, but these can be overridden by changing the image tag in `system_images`.
|
||||
The image used for Metrics Server is under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there is a default image associated with the Metrics Server, but these can be overridden by changing the image tag in `system_images`.
|
||||
|
||||
## Disabling the Metrics Server
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@ network:
|
||||
plugin: flannel
|
||||
```
|
||||
|
||||
The images used for network plug-ins are under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each network plug-in, but these can be overridden by changing the image tag in `system_images`.
|
||||
The images used for network plug-ins are under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each network plug-in, but these can be overridden by changing the image tag in `system_images`.
|
||||
|
||||
## Disabling deployment of a network plug-in
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: User-Defined Add-Ons
|
||||
weight: 263
|
||||
---
|
||||
|
||||
Besides the [network plug-in]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins) and [ingress controllers]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/), you can define any add-on that you want deployed after the Kubernetes cluster is deployed.
|
||||
Besides the [network plug-in]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins) and [ingress controllers]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/), you can define any add-on that you want deployed after the Kubernetes cluster is deployed.
|
||||
|
||||
There are two ways that you can specify an add-on.
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ authentication:
|
||||
- "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
|
||||
```
|
||||
|
||||
RKE also supports the webhook authentication strategy. You can enable both x509 and webhook strategies by using a `|` separator in the configuration. Contents of the webhook config file should be provided, see [Kubernetes webhook documentation](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) for information on the file format. Additionally, a cache timeout for webhook authentication responses can be set.
|
||||
RKE also supports the webhook authentication strategy. You can enable both x509 and webhook strategies by using a `|` separator in the configuration. Contents of the webhook config file should be provided, see [Kubernetes webhook documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) for information on the file format. Additionally, a cache timeout for webhook authentication responses can be set.
|
||||
|
||||
```yaml
|
||||
authentication:
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Bastion/Jump Host Configuration
|
||||
weight: 220
|
||||
---
|
||||
|
||||
Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/), you can configure to use a bastion host. Keep in mind that the [port requirements]({{< baseurl >}}/rke/v0.1.x/en/os/#ports) for the RKE node move to the configured bastion host.
|
||||
Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/), you can configure to use a bastion host. Keep in mind that the [port requirements]({{< baseurl >}}/rke/latest/en/os/#ports) for the RKE node move to the configured bastion host.
|
||||
|
||||
```yaml
|
||||
bastion_host:
|
||||
+5
-5
@@ -6,9 +6,9 @@ weight: 250
|
||||
RKE supports the ability to set your specific [cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/) for your Kubernetes cluster. There are specific cloud configurations for these cloud providers.
|
||||
To enable a cloud provider its name as well as any required configuration options must be provided under the `cloud_provider` directive in the cluster YML.
|
||||
|
||||
* [AWS]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/aws)
|
||||
* [Azure]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/azure)
|
||||
* [OpenStack]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/openstack)
|
||||
* [vSphere]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere)
|
||||
* [AWS]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/aws)
|
||||
* [Azure]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/azure)
|
||||
* [OpenStack]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/openstack)
|
||||
* [vSphere]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere)
|
||||
|
||||
Outside of this list, RKE also supports the ability to handle any [custom cloud provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/custom).
|
||||
Outside of this list, RKE also supports the ability to handle any [custom cloud provider]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/custom).
|
||||
+3
-3
@@ -62,7 +62,7 @@ The `internal_address` provides the ability to have nodes with multiple addresse
|
||||
|
||||
The `hostname_override` is used to be able to provide a friendly name for RKE to use when registering the node in Kubernetes. This hostname doesn't need to be a routable address, but it must be a valid [Kubernetes resource name](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). If the `hostname_override` isn't set, then the `address` directive is used when registering the node in Kubernetes.
|
||||
|
||||
> **Note:** When [cloud providers]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) are configured, you may need to override the hostname in order to use the cloud provider correctly. There is an exception for the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws), where the `hostname_override` field will be explicitly ignored.
|
||||
> **Note:** When [cloud providers]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/) are configured, you may need to override the hostname in order to use the cloud provider correctly. There is an exception for the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws), where the `hostname_override` field will be explicitly ignored.
|
||||
|
||||
### SSH Port
|
||||
|
||||
@@ -76,7 +76,7 @@ For each node, you specify the `user` to be used when connecting to this node. T
|
||||
|
||||
For each node, you specify the path, i.e. `ssh_key_path`, for the SSH private key to be used when connecting to this node. The default key path for each node is `~/.ssh/id_rsa`.
|
||||
|
||||
> **Note:** If you have a private key that can be used across all nodes, you can set the [SSH key path at the cluster level]({{< baseurl >}}/rke/v0.1.x/en/config-options/#cluster-level-ssh-key-path). The SSH key path set in each node will always take precedence.
|
||||
> **Note:** If you have a private key that can be used across all nodes, you can set the [SSH key path at the cluster level]({{< baseurl >}}/rke/latest/en/config-options/#cluster-level-ssh-key-path). The SSH key path set in each node will always take precedence.
|
||||
|
||||
### SSH Key
|
||||
|
||||
@@ -122,4 +122,4 @@ If the Docker socket is different than the default, you can set the `docker_sock
|
||||
|
||||
### Labels
|
||||
|
||||
You have the ability to add an arbitrary map of labels for each node. It can be used when using the [ingress controller's]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/) `node_selector` option.
|
||||
You have the ability to add an arbitrary map of labels for each node. It can be used when using the [ingress controller's]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/) `node_selector` option.
|
||||
+4
-4
@@ -19,7 +19,7 @@ private_registries:
|
||||
|
||||
### Default Registry
|
||||
|
||||
As of v0.1.10, RKE supports specifying a default registry from the list of private registries to be used with all [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) . In this example .RKE will use `registry.com` as the default registry for all system images, e.g. `rancher/rke-tools:v0.1.14` will become `registry.com/rancher/rke-tools:v0.1.14`.
|
||||
As of v0.1.10, RKE supports specifying a default registry from the list of private registries to be used with all [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) . In this example .RKE will use `registry.com` as the default registry for all system images, e.g. `rancher/rke-tools:v0.1.14` will become `registry.com/rancher/rke-tools:v0.1.14`.
|
||||
|
||||
```yaml
|
||||
private_registries:
|
||||
@@ -31,9 +31,9 @@ private_registries:
|
||||
|
||||
### Air-gapped Setups
|
||||
|
||||
By default, all system images are being pulled from DockerHub. If you are on a system that does not have access to DockerHub, you will need to create a private registry that is populated with all the required [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/).
|
||||
By default, all system images are being pulled from DockerHub. If you are on a system that does not have access to DockerHub, you will need to create a private registry that is populated with all the required [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/).
|
||||
|
||||
As of v0.1.10, you have to configure your private registry credentials, but you can specify this registry as a default registry so that all [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) are pulled from the designated private registry. You can use the command `rke config --system-images` to get the list of default system images to populate your private registry.
|
||||
As of v0.1.10, you have to configure your private registry credentials, but you can specify this registry as a default registry so that all [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) are pulled from the designated private registry. You can use the command `rke config --system-images` to get the list of default system images to populate your private registry.
|
||||
|
||||
Prior to v0.1.10, you had to configure your private registry credentials **and** update the names of all the [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) in the `cluster.yml` so that the image names would have the private registry URL appended before each image name.
|
||||
Prior to v0.1.10, you had to configure your private registry credentials **and** update the names of all the [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) in the `cluster.yml` so that the image names would have the private registry URL appended before each image name.
|
||||
|
||||
+3
-3
@@ -5,7 +5,7 @@ weight: 230
|
||||
|
||||
To deploy Kubernetes, RKE deploys several core components or services in Docker containers on the nodes. Based on the roles of the node, the containers deployed may be different.
|
||||
|
||||
**All services support additional [custom arguments, Docker mount binds and extra environment variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/).**
|
||||
**All services support additional [custom arguments, Docker mount binds and extra environment variables]({{< baseurl >}}/rke/latest/en/config-options/services/services-extras/).**
|
||||
|
||||
## etcd
|
||||
|
||||
@@ -13,9 +13,9 @@ Kubernetes uses [etcd](https://github.com/coreos/etcd/blob/master/Documentation/
|
||||
|
||||
RKE supports running etcd in a single node mode or in HA cluster mode. It also supports adding and removing etcd nodes to the cluster.
|
||||
|
||||
You can enable etcd to [take recurring snapshots]({{< baseurl >}}/rke/v0.1.x/en/etcd-snapshots/#recurring-snapshots). These snapshots can be used to [restore etcd]({{< baseurl >}}/rke/v0.1.x/en/etcd-snapshots/#etcd-disaster-recovery).
|
||||
You can enable etcd to [take recurring snapshots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#recurring-snapshots). These snapshots can be used to [restore etcd]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-disaster-recovery).
|
||||
|
||||
By default, RKE will deploy a new etcd service, but you can also run Kubernetes with an [external etcd service]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/external-etcd/).
|
||||
By default, RKE will deploy a new etcd service, but you can also run Kubernetes with an [external etcd service]({{< baseurl >}}/rke/latest/en/config-options/services/external-etcd/).
|
||||
|
||||
## Kubernetes API Server
|
||||
|
||||
+1
-1
@@ -5,7 +5,7 @@ weight: 232
|
||||
|
||||
By default, RKE will launch etcd servers, but RKE also supports being able to use an external etcd. RKE only supports connecting to a TLS enabled etcd setup.
|
||||
|
||||
> **Note:** RKE will not accept having external etcd servers in conjunction with [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/) with the `etcd` role.
|
||||
> **Note:** RKE will not accept having external etcd servers in conjunction with [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/) with the `etcd` role.
|
||||
|
||||
```yaml
|
||||
services:
|
||||
+2
-2
@@ -6,7 +6,7 @@ When RKE is deploying Kubernetes, there are several images that are pulled. Thes
|
||||
|
||||
As of `v0.1.6`, the functionality of a couple of the system images were consolidated into a single `rancher/rke-tools` image to simplify and speed the deployment process.
|
||||
|
||||
You can configure the [network plug-ins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/), [ingress controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/) and [dns provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/dns/) as well as the options for these add-ons separately.
|
||||
You can configure the [network plug-ins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/), [ingress controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/) and [dns provider]({{< baseurl >}}/rke/latest/en/config-options/add-ons/dns/) as well as the options for these add-ons separately.
|
||||
|
||||
This is the example of the full list of system images used to deploy Kubernetes through RKE. The image tags are dependent on the [Kubernetes image/version used](https://github.com/rancher/types/blob/master/apis/management.cattle.io/v3/k8s_defaults.go).
|
||||
|
||||
@@ -71,4 +71,4 @@ system_images:
|
||||
|
||||
### Air-gapped Setups
|
||||
|
||||
If you have an air-gapped setup and cannot access `docker.io`, you will need to set up your [private registry]({{< baseurl >}}/rke/v0.1.x/en/config-options/private-registries/) in your cluster configuration file. After you set up private registry, you will need to update these images to pull from your private registry.
|
||||
If you have an air-gapped setup and cannot access `docker.io`, you will need to set up your [private registry]({{< baseurl >}}/rke/latest/en/config-options/private-registries/) in your cluster configuration file. After you set up private registry, you will need to update these images to pull from your private registry.
|
||||
+7
-7
@@ -2,7 +2,7 @@
|
||||
title: Backups and Disaster Recovery
|
||||
weight: 150
|
||||
aliases:
|
||||
- /rke/v0.1.x/en/installation/etcd-snapshots/
|
||||
- /rke/latest/en/installation/etcd-snapshots/
|
||||
---
|
||||
|
||||
_Available as of v0.1.7_
|
||||
@@ -11,7 +11,7 @@ RKE clusters can be configured to automatically take snapshots of etcd. In a dis
|
||||
|
||||
_Available as of v0.2.0_
|
||||
|
||||
RKE can also upload your snapshots to a S3 compatible backend. Additionally, the **pki.bundle.tar.gz** file usage is no longer required as v0.2.0 has changed how the [Kubernetes cluster state is stored]({{< baseurl >}}/rke/v0.1.x/en/installation/#kubernetes-cluster-state).
|
||||
RKE can also upload your snapshots to a S3 compatible backend. Additionally, the **pki.bundle.tar.gz** file usage is no longer required as v0.2.0 has changed how the [Kubernetes cluster state is stored]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state).
|
||||
|
||||
## One-Time Snapshots
|
||||
|
||||
@@ -33,8 +33,8 @@ As of v0.2.0, the one-time snapshot can be uploaded to a S3 compatible backend b
|
||||
| `--secret-key` value | Specify s3 secretKey | * |
|
||||
| `--bucket-name` value | Specify s3 bucket name | * |
|
||||
| `--region` value | Specify the s3 bucket location (optional) | * |
|
||||
| `--ssh-agent-auth` | [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{< baseurl >}}/rke/v0.1.x/en/config-options/#ssh-agent) | |
|
||||
| `--ignore-docker-version` | [Disable Docker version check]({{< baseurl >}}/rke/v0.1.x/en/config-options/#supported-docker-versions) |
|
||||
| `--ssh-agent-auth` | [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{< baseurl >}}/rke/latest/en/config-options/#ssh-agent) | |
|
||||
| `--ignore-docker-version` | [Disable Docker version check]({{< baseurl >}}/rke/latest/en/config-options/#supported-docker-versions) |
|
||||
|
||||
### Local One-Time Snapshot Example
|
||||
|
||||
@@ -143,12 +143,12 @@ The snapshot used to restore your etcd cluster can either be stored locally in `
|
||||
| `--secret-key` value | Specify s3 secretKey | *|
|
||||
| `--bucket-name` value | Specify s3 bucket name | *|
|
||||
| `--region` value | Specify the s3 bucket location (optional) | *|
|
||||
| `--ssh-agent-auth` | [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{< baseurl >}}/rke/v0.1.x/en/config-options/#ssh-agent) | |
|
||||
| `--ignore-docker-version` | [Disable Docker version check]({{< baseurl >}}/rke/v0.1.x/en/config-options/#supported-docker-versions) |
|
||||
| `--ssh-agent-auth` | [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{< baseurl >}}/rke/latest/en/config-options/#ssh-agent) | |
|
||||
| `--ignore-docker-version` | [Disable Docker version check]({{< baseurl >}}/rke/latest/en/config-options/#supported-docker-versions) |
|
||||
|
||||
### Example of Restoring from a Local Snapshot
|
||||
|
||||
When restoring etcd from a local snapshot, the snapshot is assumed to be located in `/opt/rke/etcd-snapshots`. In versions prior to v0.2.0, the `pki.bundle.tar.gz` file is also expected to be in the same location. As of v0.2.0, this file is no longer needed as v0.2.0 has changed how the [Kubernetes cluster state is stored]({{< baseurl >}}/rke/v0.1.x/en/installation/#kubernetes-cluster-state).
|
||||
When restoring etcd from a local snapshot, the snapshot is assumed to be located in `/opt/rke/etcd-snapshots`. In versions prior to v0.2.0, the `pki.bundle.tar.gz` file is also expected to be in the same location. As of v0.2.0, this file is no longer needed as v0.2.0 has changed how the [Kubernetes cluster state is stored]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state).
|
||||
|
||||
```
|
||||
$ rke etcd snapshot-restore --config cluster.yml --name mysnapshot
|
||||
+2
-2
@@ -2,10 +2,10 @@
|
||||
title: Example Cluster.ymls
|
||||
weight: 300
|
||||
aliases:
|
||||
- /rke/v0.1.x/en/config-options/example-yamls/
|
||||
- /rke/latest/en/config-options/example-yamls/
|
||||
---
|
||||
|
||||
There are lots of different [configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) that can be set in the cluster configuration file for RKE. Here are some examples of files:
|
||||
There are lots of different [configuration options]({{< baseurl >}}/rke/latest/en/config-options/) that can be set in the cluster configuration file for RKE. Here are some examples of files:
|
||||
|
||||
> **Note for Rancher 2 users** If you are configuring Cluster Options using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) when creating [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the names of services should contain underscores only: `kube_api` and `kube_controller`. This only applies to Rancher v2.0.5 and v2.0.6.
|
||||
|
||||
+32
-25
@@ -6,18 +6,22 @@ weight: 50
|
||||
RKE is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. You can get started in a couple of quick and easy steps:
|
||||
|
||||
1. [Download the RKE Binary](#download-the-rke-binary)
|
||||
2. [Prepare the Nodes for the Kubernetes Cluster](#prepare-the-nodes-for-the-kubernetes-cluster)
|
||||
3. [Creating the Cluster Configuration File](#creating-the-cluster-configuration-file)
|
||||
4. [Deploying Kubernetes with RKE](#deploying-kubernetes-with-rke)
|
||||
5. [Interacting with your Kubernetes Cluster](#interacting-with-your-kubernetes-cluster)
|
||||
1. [Prepare the Nodes for the Kubernetes Cluster](#prepare-the-nodes-for-the-kubernetes-cluster)
|
||||
1. [Creating the Cluster Configuration File](#creating-the-cluster-configuration-file)
|
||||
1. [Deploying Kubernetes with RKE](#deploying-kubernetes-with-rke)
|
||||
1. [Save your Files](#save-your-files)
|
||||
1. [Interacting with your Kubernetes Cluster](#interacting-with-your-kubernetes-cluster)
|
||||
|
||||
## Download the RKE binary
|
||||
|
||||
1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases/latest) page. Download the latest RKE installer applicable to your Operating System:
|
||||
1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases/latest) page. Download the latest RKE installer applicable to your Operating System and Architecture:
|
||||
|
||||
- **MacOS**: `rke_darwin-amd64`
|
||||
- **Linux**: `rke_linux-amd64`
|
||||
- **Windows**: `rke_windows-amd64.exe`
|
||||
- **Linux (Intel/AMD)**: `rke_linux-amd64`
|
||||
- **Linux (ARM 32-bit)**: `rke_linux-arm`
|
||||
- **Linux (ARM 64-bit)**: `rke_linux-arm64`
|
||||
- **Windows (32-bit)**: `rke_windows-386.exe`
|
||||
- **Windows (64-bit)**: `rke_windows-amd64.exe`
|
||||
|
||||
2. Copy the RKE binary to a folder in your `$PATH` and rename it `rke` (or `rke.exe` for Windows)
|
||||
|
||||
@@ -49,20 +53,20 @@ RKE is a fast, versatile Kubernetes installer that you can use to install Kubern
|
||||
|
||||
The Kubernetes cluster components are launched using Docker on a Linux distro. You can use any Linux you want, as long as you can install Docker on it.
|
||||
|
||||
Review the [OS requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os/) and configure each node appropriately.
|
||||
Review the [OS requirements]({{< baseurl >}}/rke/latest/en/installation/os/) and configure each node appropriately.
|
||||
|
||||
## Creating the Cluster Configuration File
|
||||
|
||||
RKE uses a cluster configuration file, referred to as `cluster.yml` to determine what nodes will be in the cluster and how to deploy Kubernetes. There are [many configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) that can be set in the `cluster.yml`. In our example, we will be assuming the minimum of one [node]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes) for your Kubernetes cluster.
|
||||
RKE uses a cluster configuration file, referred to as `cluster.yml` to determine what nodes will be in the cluster and how to deploy Kubernetes. There are [many configuration options]({{< baseurl >}}/rke/latest/en/config-options/) that can be set in the `cluster.yml`. In our example, we will be assuming the minimum of one [node]({{< baseurl >}}/rke/latest/en/config-options/nodes) for your Kubernetes cluster.
|
||||
|
||||
There are two easy ways to create a `cluster.yml`:
|
||||
|
||||
- Using our [minimal `cluster.yml`]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/#minimal-cluster-yml-example) and updating it based on the node that you will be using.
|
||||
- Using our [minimal `cluster.yml`]({{< baseurl >}}/rke/latest/en/example-yamls/#minimal-cluster-yml-example) and updating it based on the node that you will be using.
|
||||
- Using `rke config` to query for all the information needed.
|
||||
|
||||
### Using `rke config`
|
||||
|
||||
Run `rke config` to create a new `cluster.yml` in the current directory. This command will prompt you for all the information needed to build a cluster. See [cluster configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) for details on the various options.
|
||||
Run `rke config` to create a new `cluster.yml` in the current directory. This command will prompt you for all the information needed to build a cluster. See [cluster configuration options]({{< baseurl >}}/rke/latest/en/config-options/) for details on the various options.
|
||||
|
||||
```
|
||||
rke config --name cluster.yml
|
||||
@@ -90,6 +94,12 @@ RKE is HA ready, you can specify more than one `controlplane` node in the `clust
|
||||
|
||||
To create an HA cluster, specify more than one host with role `controlplane`.
|
||||
|
||||
### Certificates
|
||||
|
||||
_Available as of v0.2.0_
|
||||
|
||||
By default, Kubernetes clusters require certificates and RKE auto-generates the certificates for all cluster components. You can also use [custom certificates]({{< baseurl >}}/rke/latest/en/installation/certs/). After the Kubernetes cluster is deployed, you can [manage these auto-generated certificates]({{< baseurl >}}/rke/latest/en/cert-mgmt/#certificate-rotation).
|
||||
|
||||
## Deploying Kubernetes with RKE
|
||||
|
||||
After you've created your `cluster.yml`, you can deploy your cluster with a simple command. This command assumes the `cluster.yml` file is in the same directory as where you are running the command.
|
||||
@@ -109,11 +119,16 @@ The last line should read `Finished building Kubernetes cluster successfully` to
|
||||
|
||||
> **Note:** If you have used a different file name from `cluster.yml`, then the kube config file will be named `kube_config_<FILE_NAME>.yml`.
|
||||
|
||||
### Certificates
|
||||
## Save Your Files
|
||||
|
||||
_Available as of v0.2.0_
|
||||
> **Important**
|
||||
> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
|
||||
|
||||
By default, Kubernetes clusters require certificates and RKE auto-generates the certificates for all cluster components. You can also use [custom certificates]({{< baseurl >}}/rke/v0.1.x/en/installation/certs/). After the Kubernetes cluster is deployed, you can [manage these auto-generated certificates]({{< baseurl >}}/rke/v0.1.x/en/cert-mgmt/#certifcate-rotation).
|
||||
Save a copy of the following files in a secure location:
|
||||
|
||||
- `cluster.yml`: The RKE cluster configuration file.
|
||||
- `kube_config_cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
|
||||
- `cluster.rkestate`: The [Kubernetes Cluster State file](#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
|
||||
|
||||
### Kubernetes Cluster State
|
||||
|
||||
@@ -121,21 +136,13 @@ The Kubernetes cluster state, which consists of the cluster configuration file `
|
||||
|
||||
As of v0.2.0, RKE creates a `.rkestate` file in the same directory that has the cluster configuration file `cluster.yml`. The `.rkestate` file contains the current state of the cluster including the RKE configuration and the certificates. It is required to keep this file in order to update the cluster or perform any operation on it through RKE.
|
||||
|
||||
```
|
||||
$ tree -L 1
|
||||
.
|
||||
├── cluster.rkestate
|
||||
├── cluster.yml
|
||||
├── kube_config_cluster.yml
|
||||
```
|
||||
|
||||
Prior to v0.2.0, RKE saved the Kubernetes cluster state as a secret. When updating the state, RKE pulls the secret, updates/changes the state and saves a new secret.
|
||||
|
||||
## Interacting with your Kubernetes cluster
|
||||
|
||||
After your cluster is up and running, you can start using the [generated kubeconfig file]({{< baseurl >}}/rke/v0.1.x/en/kubeconfig) to start interacting with your Kubernetes cluster using `kubectl`.
|
||||
After your cluster is up and running, you can start using the [generated kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig) to start interacting with your Kubernetes cluster using `kubectl`.
|
||||
|
||||
After installation, there are several maintenance items that might arise:
|
||||
|
||||
* [Certificate Management]({{< baseurl >}}/rke/v0.1.x/en/cert-mgmt/)
|
||||
* [Adding and Removing Nodes in the cluster]({{< baseurl >}}/rke/v0.1.x/en/managing-clusters)
|
||||
* [Certificate Management]({{< baseurl >}}/rke/latest/en/cert-mgmt/)
|
||||
* [Adding and Removing Nodes in the cluster]({{< baseurl >}}/rke/latest/en/managing-clusters)
|
||||
+2
-2
@@ -7,7 +7,7 @@ _Available as of v0.2.0_
|
||||
|
||||
By default, Kubernetes clusters require certificates and RKE auto-generates the certificates for all the Kubernetes services. RKE can also use custom certificates for these Kubernetes services.
|
||||
|
||||
When [deploying Kubernetes with RKE]({{< baseurl >}}/rke/v0.1.x/en/installation/#deploying-kubernetes-with-rke), there are two additional options that can be used with `rke up` so that RKE uses custom certificates.
|
||||
When [deploying Kubernetes with RKE]({{< baseurl >}}/rke/latest/en/installation/#deploying-kubernetes-with-rke), there are two additional options that can be used with `rke up` so that RKE uses custom certificates.
|
||||
|
||||
| Option | Description |
|
||||
| --- | --- |
|
||||
@@ -45,7 +45,7 @@ The following certificates must exist in the certificate directory.
|
||||
|
||||
If you want to create and sign the certificates by a real Certificate Authority (CA), you can use RKE to generate a set of Certificate Signing Requests (CSRs) and keys. Using the `rke cert generate-csr` command, you can generate the CSRs and keys.
|
||||
|
||||
1. Set up your `cluster.yml` with the [node information]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/).
|
||||
1. Set up your `cluster.yml` with the [node information]({{< baseurl >}}/rke/latest/en/config-options/nodes/).
|
||||
|
||||
2. Run `rke cert generate-csr` to generate certificates for the node(s) in the `cluster.yml`. By default, the CSRs and keys will be saved in `./cluster_certs`. To have them saved in a different directory, use `--cert-dir` to define what directory to have them saved in.
|
||||
|
||||
+2
-2
@@ -2,12 +2,12 @@
|
||||
title: Adding and Removing Nodes
|
||||
weight: 175
|
||||
aliases:
|
||||
- /rke/v0.1.x/en/installation/managing-clusters/
|
||||
- /rke/latest/en/installation/managing-clusters/
|
||||
---
|
||||
|
||||
### Adding/Removing Nodes
|
||||
|
||||
RKE supports adding/removing [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/) for worker and controlplane hosts.
|
||||
RKE supports adding/removing [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/) for worker and controlplane hosts.
|
||||
|
||||
In order to add additional nodes, you update the original `cluster.yml` file with any additional nodes and specify their role in the Kubernetes cluster.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Requirements
|
||||
weight: 5
|
||||
aliases:
|
||||
- /rke/v0.1.x/en/installation/os
|
||||
- /rke/latest/en/installation/os
|
||||
---
|
||||
**In this section:**
|
||||
|
||||
@@ -30,7 +30,7 @@ aliases:
|
||||
|
||||
RKE runs on almost any Linux OS with Docker installed. Most of the development and testing of RKE occurred on Ubuntu 16.04. However, some OS's have restrictions and specific requirements.
|
||||
|
||||
- [SSH user]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/#ssh-user) - The SSH user used for node access must be a member of the `docker` group on the node:
|
||||
- [SSH user]({{< baseurl >}}/rke/latest/en/config-options/nodes/#ssh-user) - The SSH user used for node access must be a member of the `docker` group on the node:
|
||||
|
||||
```
|
||||
usermod -aG docker <user_name>
|
||||
@@ -87,7 +87,7 @@ net.bridge.bridge-nf-call-iptables=1
|
||||
|
||||
### Red Hat Enterprise Linux (RHEL) / Oracle Enterprise Linux (OEL) / CentOS
|
||||
|
||||
If using Red Hat Enterprise Linux, Oracle Enterprise Linux or CentOS, you cannot use the `root` user as [SSH user]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/#ssh-user) due to [Bugzilla 1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). Please follow the instructions below how to setup Docker correctly, based on the way you installed Docker on the node.
|
||||
If using Red Hat Enterprise Linux, Oracle Enterprise Linux or CentOS, you cannot use the `root` user as [SSH user]({{< baseurl >}}/rke/latest/en/config-options/nodes/#ssh-user) due to [Bugzilla 1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). Please follow the instructions below how to setup Docker correctly, based on the way you installed Docker on the node.
|
||||
|
||||
#### Using upstream Docker
|
||||
If you are using upstream Docker, the package name is `docker-ce` or `docker-ee`. You can check the installed package by executing:
|
||||
+1
-1
@@ -3,4 +3,4 @@ title: Troubleshooting
|
||||
weight: 400
|
||||
---
|
||||
|
||||
* [SSH Connectivity Errors]({{< baseurl >}}/rke/v0.1.x/en/troubleshooting/ssh-connectivity-errors/)
|
||||
* [SSH Connectivity Errors]({{< baseurl >}}/rke/latest/en/troubleshooting/ssh-connectivity-errors/)
|
||||
@@ -3,11 +3,11 @@ title: Upgrades
|
||||
weight: 100
|
||||
---
|
||||
|
||||
After RKE has deployed Kubernetes, you can upgrade the versions of the components in your Kubernetes cluster, [definition of the Kubernetes services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/) or [add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/).
|
||||
After RKE has deployed Kubernetes, you can upgrade the versions of the components in your Kubernetes cluster, [definition of the Kubernetes services]({{< baseurl >}}/rke/latest/en/config-options/services/) or [add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/).
|
||||
|
||||
## Version Upgrades
|
||||
|
||||
RKE supports version upgrades by changing the image tags of the [system-images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/).
|
||||
RKE supports version upgrades by changing the image tags of the [system-images]({{< baseurl >}}/rke/latest/en/config-options/system-images/).
|
||||
|
||||
For example, to change the deployed Kubernetes version, you update the `rancher/hyperkube` tag from `v1.9.7` to `v1.10.3` in the `cluster.yml` that was originally used to deploy your Kubernetes cluster.
|
||||
|
||||
@@ -37,7 +37,7 @@ First, RKE will use the local `kube_config_cluster.yml` to confirm the versions
|
||||
|
||||
## Service Upgrades
|
||||
|
||||
[Services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/) can be upgraded by changing any of the services arguments or `extra_args` and running `rke up` again with the updated configuration file.
|
||||
[Services]({{< baseurl >}}/rke/latest/en/config-options/services/) can be upgraded by changing any of the services arguments or `extra_args` and running `rke up` again with the updated configuration file.
|
||||
|
||||
> **Note:** The following arguments, `service_cluster_ip_range` or `cluster_cidr`, cannot be changed as any changes to these arguments will result in a broken cluster. Currently, network pods are not automatically upgraded.
|
||||
|
||||
@@ -45,4 +45,4 @@ First, RKE will use the local `kube_config_cluster.yml` to confirm the versions
|
||||
|
||||
As of v0.1.8, upgrades to add-ons are supported.
|
||||
|
||||
[Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/) can also be upgraded by changing any of the add-ons and running `rke up` again with the updated configuration file.
|
||||
[Add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/) can also be upgraded by changing any of the add-ons and running `rke up` again with the updated configuration file.
|
||||
@@ -9,11 +9,11 @@
|
||||
<!-- TODO: Improve the engine options -->
|
||||
<p><strong>Engine Options</strong> customize the configuration of the <a href="https://docs.docker.com/engine/docker-overview/#the-docker-daemon">Docker daemon</a>. Important configuration options might include:
|
||||
<ul>
|
||||
<li><strong>Docker Engine Install URL:</strong> Determines what Docker version will be installed on the instance.</li>
|
||||
<li><strong>Docker Engine Install URL:</strong> Determines what Docker version will be installed on the instance.<br/><br/>When using RancherOS, please check what Docker versions are available using <code>sudo ros engine list</code> on the RancherOS version you want to use, as the default Docker version configured might not be available. If you experience issues installing Docker on other operating systems, please try to install Docker manually using the configured Docker Engine Install URL to troubleshoot.</li>
|
||||
<li><strong>Registry mirrors:</strong> Docker Registry mirror to be used by the Docker daemon</li>
|
||||
</ul>
|
||||
</p>
|
||||
|
||||
<p><a href="https://docs.docker.com/engine/reference/commandline/dockerd/">daemon option reference</a></p>
|
||||
<p><a href="https://docs.docker.com/engine/reference/commandline/dockerd/">Docker daemon option reference</a></p>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
map_hash_bucket_size 256;
|
||||
map $request_uri $redirect_uri {
|
||||
~^/docs/rancher/v2.0(/?.*)$ /docs/rancher/v2.x$1;
|
||||
~^/docs/rke/v0.1.x(/?.*)$ /docs/rke/latest$1;
|
||||
}
|
||||
|
||||
server {
|
||||
|
||||
Reference in New Issue
Block a user