mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 12:38:05 +00:00
Updating tabs
This commit is contained in:
Jennifer Travinski
+6
-6
@@ -43,8 +43,8 @@ The RKE metadata config controls how often Rancher syncs metadata and where it d
|
||||
|
||||
The way that the metadata is configured depends on the Rancher version.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.4+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.4+">
|
||||
To edit the metadata config in Rancher,
|
||||
|
||||
1. Go to the **Global** view and click the **Settings** tab.
|
||||
@@ -57,8 +57,8 @@ To edit the metadata config in Rancher,
|
||||
If you don't have an air gap setup, you don't need to specify the URL where Rancher gets the metadata, because the default setting is to pull from [Rancher's metadata Git repository.](https://github.com/rancher/kontainer-driver-metadata/blob/dev-v2.5/data/data.json)
|
||||
|
||||
However, if you have an [air gap setup,](#air-gap-setups) you will need to mirror the Kubernetes metadata repository in a location available to Rancher. Then you need to change the URL to point to the new location of the JSON file.
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.3" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher v2.3">
|
||||
To edit the metadata config in Rancher,
|
||||
|
||||
1. Go to the **Global** view and click the **Settings** tab.
|
||||
@@ -72,8 +72,8 @@ To edit the metadata config in Rancher,
|
||||
If you don't have an air gap setup, you don't need to specify the URL or Git branch where Rancher gets the metadata, because the default setting is to pull from [Rancher's metadata Git repository.](https://github.com/rancher/kontainer-driver-metadata.git)
|
||||
|
||||
However, if you have an [air gap setup,](#air-gap-setups) you will need to mirror the Kubernetes metadata repository in a location available to Rancher. Then you need to change the URL and Git branch in the `rke-metadata-config` settings to point to the new location of the repository.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Air Gap Setups
|
||||
|
||||
|
||||
+6
-6
@@ -30,8 +30,8 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als
|
||||
|
||||
The steps to add custom roles differ depending on the version of Rancher.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.0.7+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.0.7+">
|
||||
|
||||
1. From the **Global** view, select **Security > Roles** from the main menu.
|
||||
|
||||
@@ -60,8 +60,8 @@ The steps to add custom roles differ depending on the version of Rancher.
|
||||
|
||||
1. Click **Create**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.0.7" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.0.7">
|
||||
|
||||
1. From the **Global** view, select **Security > Roles** from the main menu.
|
||||
|
||||
@@ -93,8 +93,8 @@ The steps to add custom roles differ depending on the version of Rancher.
|
||||
|
||||
1. Click **Create**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Creating a Custom Global Role
|
||||
|
||||
|
||||
+6
-6
@@ -67,8 +67,8 @@ To take recurring snapshots, enable the `etcd-snapshot` service, which is a serv
|
||||
|
||||
The steps to enable recurring snapshots differ based on the version of RKE.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "RKE v0.2.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="RKE v0.2.0+">
|
||||
|
||||
1. Open `rancher-cluster.yml` with your favorite text editor.
|
||||
2. Edit the code for the `etcd` service to enable recurring snapshots. Snapshots can be saved in a S3 compatible backend.
|
||||
@@ -101,8 +101,8 @@ The steps to enable recurring snapshots differ based on the version of RKE.
|
||||
```
|
||||
|
||||
**Result:** RKE is configured to take recurring snapshots of `etcd` on all nodes running the `etcd` role. Snapshots are saved locally to the following directory: `/opt/rke/etcd-snapshots/`. If configured, the snapshots are also uploaded to your S3 compatible backend.
|
||||
{{% /tab %}}
|
||||
{{% tab "RKE v0.1.x" %}}
|
||||
</TabItem>
|
||||
<TabItem label="RKE v0.1.x">
|
||||
|
||||
1. Open `rancher-cluster.yml` with your favorite text editor.
|
||||
2. Edit the code for the `etcd` service to enable recurring snapshots.
|
||||
@@ -122,8 +122,8 @@ The steps to enable recurring snapshots differ based on the version of RKE.
|
||||
```
|
||||
|
||||
**Result:** RKE is configured to take recurring snapshots of `etcd` on all nodes running the `etcd` role. Snapshots are saved locally to the following directory: `/opt/rke/etcd-snapshots/`.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Option B: One-Time Snapshots
|
||||
|
||||
+6
-6
@@ -27,8 +27,8 @@ This section covers the following topics:
|
||||
|
||||
# How Snapshots Work
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.4.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.4.0+">
|
||||
|
||||
### Snapshot Components
|
||||
|
||||
@@ -84,8 +84,8 @@ On restore, the following process is used:
|
||||
4. The other etcd nodes download the snapshot and validate the checksum so that they all use the same snapshot for the restore.
|
||||
5. The cluster is restored and post-restore actions will be done in the cluster.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.4.0" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.4.0">
|
||||
When Rancher creates a snapshot, only the etcd data is included in the snapshot.
|
||||
|
||||
Because the Kubernetes version is not included in the snapshot, there is no option to restore a cluster to a different Kubernetes version.
|
||||
@@ -128,8 +128,8 @@ On restore, the following process is used:
|
||||
4. The other etcd nodes download the snapshot and validate the checksum so that they all use the same snapshot for the restore.
|
||||
5. The cluster is restored and post-restore actions will be done in the cluster.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Configuring Recurring Snapshots
|
||||
|
||||
|
||||
+6
-6
@@ -55,8 +55,8 @@ For imported clusters, the process for removing Rancher is a little different. Y
|
||||
|
||||
After the imported cluster is detached from Rancher, the cluster's workloads will be unaffected and you can access the cluster using the same methods that you did before the cluster was imported into Rancher.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "By UI / API" %}}
|
||||
<Tabs>
|
||||
<TabItem label="By UI / API">
|
||||
>**Warning:** This process will remove data from your cluster. Make sure you have created a backup of files you want to keep before executing the command, as data will be lost.
|
||||
|
||||
After you initiate the removal of an imported cluster using the Rancher UI (or API), the following events occur.
|
||||
@@ -69,8 +69,8 @@ After you initiate the removal of an imported cluster using the Rancher UI (or A
|
||||
|
||||
**Result:** All components listed for imported clusters in [What Gets Removed?](#what-gets-removed) are deleted.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "By Script" %}}
|
||||
</TabItem>
|
||||
<TabItem label="By Script">
|
||||
Rather than cleaning imported cluster nodes using the Rancher UI, you can run a script instead. This functionality is available since `v2.1.0`.
|
||||
|
||||
>**Prerequisite:**
|
||||
@@ -100,8 +100,8 @@ Rather than cleaning imported cluster nodes using the Rancher UI, you can run a
|
||||
|
||||
**Result:** The script runs. All components listed for imported clusters in [What Gets Removed?](#what-gets-removed) are deleted.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Windows Nodes
|
||||
|
||||
|
||||
@@ -130,8 +130,8 @@ However, you can override the conditions draining when you initiate the drain. Y
|
||||
|
||||
The node draining options are different based on your version of Rancher.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.2.x+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.x+">
|
||||
There are two drain modes: aggressive and safe.
|
||||
|
||||
- **Aggressive Mode**
|
||||
@@ -143,8 +143,8 @@ There are two drain modes: aggressive and safe.
|
||||
- **Safe Mode**
|
||||
|
||||
If a node has standalone pods or ephemeral data it will be cordoned but not drained.
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.2.x" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.x">
|
||||
|
||||
The following list describes each drain option:
|
||||
|
||||
@@ -159,8 +159,8 @@ The following list describes each drain option:
|
||||
- **Even if there are pods using emptyDir**
|
||||
|
||||
If a pod uses emptyDir to store local data, you might not be able to safely delete it, since the data in the emptyDir will be deleted once the pod is removed from the node. Similar to the first option, Kubernetes expects the implementation to decide what to do with these pods. Choosing this option will delete these pods.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Grace Period
|
||||
|
||||
|
||||
+6
-6
@@ -32,8 +32,8 @@ If your Kubernetes cluster is broken, you can restore the cluster from a snapsho
|
||||
|
||||
Restores changed in Rancher v2.4.0.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.4.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.4.0+">
|
||||
|
||||
Snapshots are composed of the cluster data in etcd, the Kubernetes version, and the cluster configuration in the `cluster.yml.` These components allow you to select from the following options when restoring a cluster from a snapshot:
|
||||
|
||||
@@ -57,8 +57,8 @@ When rolling back to a prior Kubernetes version, the [upgrade strategy options](
|
||||
|
||||
**Result:** The cluster will go into `updating` state and the process of restoring the `etcd` nodes from the snapshot will start. The cluster is restored when it returns to an `active` state.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.4.0" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.4.0">
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
@@ -75,8 +75,8 @@ When rolling back to a prior Kubernetes version, the [upgrade strategy options](
|
||||
|
||||
**Result:** The cluster will go into `updating` state and the process of restoring the `etcd` nodes from the snapshot will start. The cluster is restored when it returns to an `active` state.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Recovering etcd without a Snapshot
|
||||
|
||||
|
||||
+6
-6
@@ -44,8 +44,8 @@ In this section of the [RKE documentation,]({{<baseurl>}}/rke/latest/en/upgrades
|
||||
|
||||
# Recommended Best Practice for Upgrades
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.4+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.4+">
|
||||
When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
|
||||
1. Take a snapshot.
|
||||
@@ -53,8 +53,8 @@ When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
1. If the upgrade fails, revert the cluster to the pre-upgrade Kubernetes version. This is achieved by selecting the **Restore etcd and Kubernetes version** option. This will return your cluster to the pre-upgrade kubernetes version before restoring the etcd snapshot.
|
||||
|
||||
The restore operation will work on a cluster that is not in a healthy or active state.
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.4" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.4">
|
||||
When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
|
||||
1. Take a snapshot.
|
||||
@@ -62,8 +62,8 @@ When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
1. If the upgrade fails, restore the cluster from the etcd snapshot.
|
||||
|
||||
The cluster cannot be downgraded to a previous Kubernetes version.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Upgrading the Kubernetes Version
|
||||
|
||||
|
||||
+6
-6
@@ -38,8 +38,8 @@ SUSE Linux may have a firewall that blocks all ports by default. In that situati
|
||||
|
||||
When [Launching Kubernetes with Rancher]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) using Flatcar Container Linux nodes, it is required to use the following configuration in the [Cluster Config File]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/#cluster-config-file)
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Canal"%}}
|
||||
<Tabs>
|
||||
<TabItem label="Canal">
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config:
|
||||
@@ -54,9 +54,9 @@ rancher_kubernetes_engine_config:
|
||||
extra_args:
|
||||
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
|
||||
```
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% tab "Calico"%}}
|
||||
<TabItem label="Calico">
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config:
|
||||
@@ -71,8 +71,8 @@ rancher_kubernetes_engine_config:
|
||||
extra_args:
|
||||
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
It is also required to enable the Docker service, you can enable the Docker service using the following command:
|
||||
|
||||
|
||||
+6
-6
@@ -5,8 +5,8 @@ weight: 1
|
||||
|
||||
For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.2.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
|
||||
Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
|
||||
|
||||
@@ -21,8 +21,8 @@ The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-d
|
||||
- **Registry mirrors:** Docker Registry mirror to be used by the Docker daemon
|
||||
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.2.0" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
|
||||
- **Account Access** stores your account information for authenticating with Azure.
|
||||
- **Placement** sets the geographical region where your cluster is hosted and other location metadata.
|
||||
@@ -35,5 +35,5 @@ The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-d
|
||||
- **Docker Engine Install URL:** Determines what Docker version will be installed on the instance.
|
||||
- **Registry mirrors:** Docker Registry mirror to be used by the Docker daemon
|
||||
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -45,8 +45,8 @@ The creation of this service principal returns three pieces of identification in
|
||||
|
||||
# Creating an Azure Cluster
|
||||
|
||||
{{%tabs %}}
|
||||
{{% tab "Rancher v2.2.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
|
||||
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
|
||||
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
|
||||
@@ -94,8 +94,8 @@ You can access your cluster after its state is updated to **Active.**
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.2.0" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
|
||||
Use Rancher to create a Kubernetes cluster in Azure.
|
||||
|
||||
@@ -118,8 +118,8 @@ You can access your cluster after its state is updated to **Active.**
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Optional Next Steps
|
||||
|
||||
|
||||
+6
-6
@@ -11,8 +11,8 @@ First, you will set up your DigitalOcean cloud credentials in Rancher. Then you
|
||||
|
||||
Then you will create a DigitalOcean cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.2.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
|
||||
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
|
||||
3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
|
||||
@@ -57,8 +57,8 @@ You can access your cluster after its state is updated to **Active.**
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.2.0" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
|
||||
1. From the **Clusters** page, click **Add Cluster**.
|
||||
1. Choose **DigitalOcean**.
|
||||
@@ -78,8 +78,8 @@ You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Optional Next Steps
|
||||
|
||||
|
||||
+6
-6
@@ -3,8 +3,8 @@ title: DigitalOcean Node Template Configuration
|
||||
weight: 1
|
||||
----
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.2.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
|
||||
Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
|
||||
|
||||
@@ -20,8 +20,8 @@ The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-d
|
||||
- **Docker Engine Install URL:** Determines what Docker version will be installed on the instance.
|
||||
- **Registry mirrors:** Docker Registry mirror to be used by the Docker daemon
|
||||
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.2.0" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
|
||||
### Access Token
|
||||
|
||||
@@ -39,5 +39,5 @@ The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-d
|
||||
- **Docker Engine Install URL:** Determines what Docker version will be installed on the instance.
|
||||
- **Registry mirrors:** Docker Registry mirror to be used by the Docker daemon
|
||||
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
+6
-6
@@ -5,8 +5,8 @@ weight: 1
|
||||
|
||||
For more details about EC2, nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.2.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
|
||||
### Region
|
||||
|
||||
@@ -48,8 +48,8 @@ If you need to pass an **IAM Instance Profile Name** (not ARN), for example, whe
|
||||
|
||||
In the **Engine Options** section of the node template, you can configure the Docker daemon. You may want to specify the docker version or a Docker registry mirror.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.2.0" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
|
||||
### Account Access
|
||||
|
||||
@@ -95,5 +95,5 @@ The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-d
|
||||
- **Docker Engine Install URL:** Determines what Docker version will be installed on the instance.
|
||||
- **Registry mirrors:** Docker Registry mirror to be used by the Docker daemon
|
||||
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -25,8 +25,8 @@ Then you will create an EC2 cluster in Rancher, and when configuring the new clu
|
||||
|
||||
The steps to create a cluster differ based on your Rancher version.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.2.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
|
||||
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
|
||||
2. [Create a node template with your cloud credentials and information from EC2](#2-create-a-node-template-with-your-cloud-credentials-and-information-from-ec2)
|
||||
@@ -75,8 +75,8 @@ You can access your cluster after its state is updated to **Active.**
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.2.0" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
|
||||
1. From the **Clusters** page, click **Add Cluster**.
|
||||
1. Choose **Amazon EC2**.
|
||||
@@ -99,8 +99,8 @@ You can access your cluster after its state is updated to **Active.**
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
### Optional Next Steps
|
||||
|
||||
After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
|
||||
|
||||
+6
-6
@@ -50,8 +50,8 @@ If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https:
|
||||
|
||||
The a vSphere cluster is created in Rancher depends on the Rancher version.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.2.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
|
||||
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
|
||||
3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
|
||||
@@ -101,8 +101,8 @@ You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.2.0" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
|
||||
Use Rancher to create a Kubernetes cluster in vSphere.
|
||||
|
||||
@@ -130,8 +130,8 @@ You can access your cluster after its state is updated to **Active.**
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
|
||||
+6
-6
@@ -56,8 +56,8 @@ For each Helm chart, there are a list of desired answers that must be entered in
|
||||
|
||||
> For example, when entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is required to wrap the values with double quotes (i.e., ``"abc, bcd"``).
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "UI" %}}
|
||||
<Tabs>
|
||||
<TabItem label="UI">
|
||||
|
||||
### Using a questions.yml file
|
||||
|
||||
@@ -67,8 +67,8 @@ If the Helm chart that you are deploying contains a `questions.yml` file, Ranche
|
||||
|
||||
For native Helm charts (i.e., charts from the **Helm Stable** or **Helm Incubator** catalogs or a [custom Helm chart repository]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/legacy-catalogs/catalog-config/#custom-helm-chart-repository)), answers are provided as key value pairs in the **Answers** section. These answers are used to override the default values.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Editing YAML Files" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Editing YAML Files">
|
||||
|
||||
_Available as of v2.1.0_
|
||||
|
||||
@@ -101,5 +101,5 @@ servers[0].host=example
|
||||
_Available as of v2.2.0_
|
||||
|
||||
You can directly paste that YAML formatted structure into the YAML editor. By allowing custom values to be set using a YAML formatted structure, Rancher has the ability to easily customize for more complicated input values (e.g. multi-lines, array and JSON objects).
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
+8
-8
@@ -153,8 +153,8 @@ cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
|
||||
|
||||
The exact command to install Rancher differs depending on the certificate configuration.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher-generated Certificates" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher-generated Certificates">
|
||||
|
||||
|
||||
The default is for Rancher to generate a CA and uses `cert-manager` to issue the certificate for access to the Rancher server interface.
|
||||
@@ -179,8 +179,8 @@ Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are
|
||||
deployment "rancher" successfully rolled out
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Let's Encrypt" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Let's Encrypt">
|
||||
|
||||
This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA.
|
||||
|
||||
@@ -207,8 +207,8 @@ Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are
|
||||
deployment "rancher" successfully rolled out
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Certificates from Files" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Certificates from Files">
|
||||
In this option, Kubernetes secrets are created from your own certificates for Rancher to use.
|
||||
|
||||
When you run this command, the `hostname` option must match the `Common Name` or a `Subject Alternative Names` entry in the server certificate or the Ingress controller will fail to configure correctly.
|
||||
@@ -239,8 +239,8 @@ helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
```
|
||||
|
||||
Now that Rancher is deployed, see [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/encryption/tls-secrets/) to publish the certificate files so Rancher and the Ingress controller can use them.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
The Rancher chart configuration has many options for customizing the installation to suit your specific environment. Here are some common advanced scenarios.
|
||||
|
||||
|
||||
+6
-6
@@ -84,8 +84,8 @@ of your Kubernetes cluster running Rancher server. You'll use the snapshot as a
|
||||
|
||||
This section describes how to upgrade normal (Internet-connected) or air gap installations of Rancher with Helm.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Kubernetes Upgrade" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Kubernetes Upgrade">
|
||||
|
||||
Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
|
||||
|
||||
@@ -136,9 +136,9 @@ If you are currently running the cert-manager whose version is older than v0.11,
|
||||
|
||||
{{% /accordion %}}
|
||||
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% tab "Kubernetes Air Gap Upgrade" %}}
|
||||
<TabItem label="Kubernetes Air Gap Upgrade">
|
||||
|
||||
1. Render the Rancher template using the same chosen options that were used when installing Rancher. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
|
||||
|
||||
@@ -202,8 +202,8 @@ helm template ./rancher-<VERSION>.tgz --output-dir . \
|
||||
kubectl -n cattle-system apply -R -f ./rancher
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### D. Verify the Upgrade
|
||||
|
||||
|
||||
+6
-6
@@ -71,8 +71,8 @@ Reset the cluster nodes' network policies to restore connectivity.
|
||||
>
|
||||
>Download and setup [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Kubernetes Install" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Kubernetes Install">
|
||||
1. From **Terminal**, change directories to your kubectl file that's generated during Rancher install, `kube_config_rancher-cluster.yml`. This file is usually in the directory where you ran RKE during Rancher installation.
|
||||
|
||||
1. Before repairing networking, run the following two commands to make sure that your nodes have a status of `Ready` and that your cluster components are `Healthy`.
|
||||
@@ -171,8 +171,8 @@ Reset the cluster nodes' network policies to restore connectivity.
|
||||
|
||||
1. Log into the Rancher UI and view your clusters. Created clusters will show errors from attempting to contact Rancher while it was unavailable. However, these errors should resolve automatically.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher Launched Kubernetes" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher Launched Kubernetes">
|
||||
<br/>
|
||||
If you can access Rancher, but one or more of the clusters that you launched using Rancher has no networking, you can repair them by moving them:
|
||||
|
||||
@@ -185,7 +185,7 @@ If you can access Rancher, but one or more of the clusters that you launched usi
|
||||
done
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
+6
-6
@@ -124,8 +124,8 @@ You'll use the backup as a restoration point if something goes wrong during upgr
|
||||
|
||||
This section describes how to upgrade normal (Internet-connected) or air gap installations of Rancher with Helm.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Kubernetes Upgrade" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Kubernetes Upgrade">
|
||||
|
||||
Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
|
||||
|
||||
@@ -186,9 +186,9 @@ If you are currently running the cert-manager whose version is older than v0.11,
|
||||
--set hostname=rancher.my.org
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% tab "Kubernetes Air Gap Upgrade" %}}
|
||||
<TabItem label="Kubernetes Air Gap Upgrade">
|
||||
|
||||
Render the Rancher template using the same chosen options that were used when installing Rancher. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
|
||||
|
||||
@@ -252,8 +252,8 @@ Use `kubectl` to apply the rendered manifests.
|
||||
kubectl -n cattle-system apply -R -f ./rancher
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# 4. Verify the Upgrade
|
||||
|
||||
|
||||
+6
-6
@@ -11,8 +11,8 @@ aliases:
|
||||
|
||||
This section is about how to deploy Rancher for your air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy. There are _tabs_ for either a high availability (recommended) or a Docker installation.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Kubernetes Install (Recommended)" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Kubernetes Install (Recommended)">
|
||||
|
||||
Rancher recommends installing Rancher on a Kubernetes cluster. A highly available Kubernetes install is comprised of three nodes running the Rancher server components on a Kubernetes cluster. The persistence layer (etcd) is also replicated on these three nodes, providing redundancy and data duplication in case one of the nodes fails.
|
||||
|
||||
@@ -229,8 +229,8 @@ These resources could be helpful when installing Rancher:
|
||||
- [Adding TLS secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/encryption/tls-secrets/)
|
||||
- [Troubleshooting Rancher Kubernetes Installations]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/troubleshooting/)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker Install" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Docker Install">
|
||||
|
||||
The Docker installation is for Rancher users who want to test out Rancher.
|
||||
|
||||
@@ -354,5 +354,5 @@ If you are installing Rancher v2.3.0+, the installation is complete.
|
||||
|
||||
If you are installing Rancher versions before v2.3.0, you will not be able to use the packaged system charts. Since the Rancher system charts are hosted in Github, an air gapped installation will not be able to access these charts. Therefore, you must [configure the Rancher system charts]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/local-system-charts/).
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -15,8 +15,8 @@ In Rancher v2.4, the Rancher management server can be installed on either an RKE
|
||||
|
||||
The steps to set up an air-gapped Kubernetes cluster on RKE or K3s are shown below.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "K3s" %}}
|
||||
<Tabs>
|
||||
<TabItem label="K3s">
|
||||
|
||||
In this guide, we are assuming you have created your nodes in your air gapped environment and have a secure Docker private registry on your bastion server.
|
||||
|
||||
@@ -139,8 +139,8 @@ Upgrading an air-gap environment can be accomplished in the following manner:
|
||||
1. Download the new air-gap images (tar file) from the [releases](https://github.com/rancher/k3s/releases) page for the version of K3s you will be upgrading to. Place the tar in the `/var/lib/rancher/k3s/agent/images/` directory on each node. Delete the old tar file.
|
||||
2. Copy and replace the old K3s binary in `/usr/local/bin` on each node. Copy over the install script at https://get.k3s.io (as it is possible it has changed since the last release). Run the script again just as you had done in the past with the same environment variables.
|
||||
3. Restart the K3s service (if not restarted automatically by installer).
|
||||
{{% /tab %}}
|
||||
{{% tab "RKE" %}}
|
||||
</TabItem>
|
||||
<TabItem label="RKE">
|
||||
We will create a Kubernetes cluster using Rancher Kubernetes Engine (RKE). Before being able to start your Kubernetes cluster, you’ll need to install RKE and create a RKE config file.
|
||||
|
||||
### 1. Install RKE
|
||||
@@ -212,8 +212,8 @@ 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 the current state of the cluster including the RKE configuration and the certificates.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
> **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
|
||||
|
||||
|
||||
+6
-6
@@ -22,8 +22,8 @@ The steps in this section differ depending on whether or not you are planning to
|
||||
>
|
||||
> If the registry has certs, follow [this K3s documentation](https://rancher.com/docs/k3s/latest/en/installation/private-registry/) about adding a private registry. The certs and registry configuration files need to be mounted into the Rancher container.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Linux Only Clusters" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Linux Only Clusters">
|
||||
|
||||
For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
|
||||
|
||||
@@ -107,8 +107,8 @@ The `rancher-images.txt` is expected to be on the workstation in the same direct
|
||||
```plain
|
||||
./rancher-load-images.sh --image-list ./rancher-images.txt --registry <REGISTRY.YOURDOMAIN.COM:PORT>
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab "Linux and Windows Clusters" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Linux and Windows Clusters">
|
||||
|
||||
_Available as of v2.3.0_
|
||||
|
||||
@@ -290,8 +290,8 @@ chmod +x rancher-load-images.sh
|
||||
```
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### [Next step for Kubernetes Installs - Launch a Kubernetes Cluster]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/other-installation-methods/air-gap/launch-kubernetes/)
|
||||
|
||||
|
||||
+8
-8
@@ -11,8 +11,8 @@ An air gapped environment is an environment where the Rancher server is installe
|
||||
|
||||
The infrastructure depends on whether you are installing Rancher on a K3s Kubernetes cluster, an RKE Kubernetes cluster, or a single Docker container. For more information on each installation option, refer to [this page.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/)
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "K3s" %}}
|
||||
<Tabs>
|
||||
<TabItem label="K3s">
|
||||
We recommend setting up the following infrastructure for a high-availability installation:
|
||||
|
||||
- **Two Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
|
||||
@@ -82,8 +82,8 @@ Rancher supports air gap installs using a private registry. You must have your o
|
||||
In a later step, when you set up your K3s Kubernetes cluster, you will create a [private registries configuration file]({{<baseurl>}}/k3s/latest/en/installation/private-registry/) with details from this registry.
|
||||
|
||||
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
|
||||
{{% /tab %}}
|
||||
{{% tab "RKE" %}}
|
||||
</TabItem>
|
||||
<TabItem label="RKE">
|
||||
|
||||
To install the Rancher management server on a high-availability RKE cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
@@ -146,8 +146,8 @@ In a later step, when you set up your RKE Kubernetes cluster, you will create a
|
||||
|
||||
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Docker">
|
||||
> The Docker installation is for Rancher users that are wanting to test out Rancher. Since there is only one node and a single Docker container, if the node goes down, you will lose all the data of your Rancher server.
|
||||
>
|
||||
> For Rancher v2.0-v2.4, there is no migration path from a Docker installation to a high-availability installation. Therefore, you may want to use a Kubernetes installation from the start.
|
||||
@@ -166,7 +166,7 @@ Rancher supports air gap installs using a Docker private registry on your bastio
|
||||
|
||||
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### [Next: Collect and Publish Images to your Private Registry]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/other-installation-methods/air-gap/populate-private-registry/)
|
||||
|
||||
+6
-6
@@ -129,8 +129,8 @@ To see the command to use when starting the new Rancher server container, choose
|
||||
- Docker Upgrade
|
||||
- Docker Upgrade for Air Gap Installs
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Docker Upgrade" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Docker Upgrade">
|
||||
|
||||
Select which option you had installed Rancher server
|
||||
|
||||
@@ -237,8 +237,8 @@ docker run -d --volumes-from rancher-data \
|
||||
|
||||
{{% /accordion %}}
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker Air Gap Upgrade" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Docker Air Gap Upgrade">
|
||||
|
||||
For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
|
||||
|
||||
@@ -328,8 +328,8 @@ docker run -d --volumes-from rancher-data \
|
||||
```
|
||||
|
||||
{{% /accordion %}}
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:** You have upgraded Rancher. Data from your upgraded server is now saved to the `rancher-data` container for use in future upgrades.
|
||||
|
||||
|
||||
+8
-8
@@ -63,8 +63,8 @@ This section describes the CPU, memory, and disk requirements for the nodes wher
|
||||
|
||||
Hardware requirements scale based on the size of your Rancher deployment. Provision each individual node according to the requirements. The requirements are different depending on if you are installing Rancher in a single container with Docker, or if you are installing Rancher on a Kubernetes cluster.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "RKE" %}}
|
||||
<Tabs>
|
||||
<TabItem label="RKE">
|
||||
|
||||
These requirements apply to each host in an [RKE Kubernetes cluster where the Rancher server is installed.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/)
|
||||
|
||||
@@ -80,9 +80,9 @@ Performance increased in Rancher v2.4.0. For the requirements of Rancher before
|
||||
|
||||
Every use case and environment is different. Please [contact Rancher](https://rancher.com/contact/) to review yours.
|
||||
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% tab "K3s" %}}
|
||||
<TabItem label="K3s">
|
||||
|
||||
These requirements apply to each host in a [K3s Kubernetes cluster where the Rancher server is installed.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/)
|
||||
|
||||
@@ -96,9 +96,9 @@ These requirements apply to each host in a [K3s Kubernetes cluster where the Ran
|
||||
|
||||
Every use case and environment is different. Please [contact Rancher](https://rancher.com/contact/) to review yours.
|
||||
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% tab "Docker" %}}
|
||||
<TabItem label="Docker">
|
||||
|
||||
These requirements apply to a host with a [single-node]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker) installation of Rancher.
|
||||
|
||||
@@ -107,8 +107,8 @@ These requirements apply to a host with a [single-node]({{<baseurl>}}/rancher/v2
|
||||
| Small | Up to 5 | Up to 50 | 1 | 4 GB |
|
||||
| Medium | Up to 15 | Up to 200 | 2 | 8 GB |
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### CPU and Memory for Rancher before v2.4.0
|
||||
|
||||
|
||||
+6
-6
@@ -13,8 +13,8 @@ aliases:
|
||||
|
||||
This section is about how to deploy Rancher for your air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy. There are _tabs_ for either a high availability (recommended) or a Docker installation.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Kubernetes Install (Recommended)" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Kubernetes Install (Recommended)">
|
||||
|
||||
Rancher recommends installing Rancher on a Kubernetes cluster. A highly available Kubernetes Installation is comprised of three nodes running the Rancher server components on a Kubernetes cluster. The persistence layer (etcd) is also replicated on these three nodes, providing redundancy and data duplication in case one of the nodes fails.
|
||||
|
||||
@@ -222,8 +222,8 @@ These resources could be helpful when installing Rancher:
|
||||
- [Adding TLS secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/)
|
||||
- [Troubleshooting Rancher Kubernetes Installations]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/troubleshooting/)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker Install" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Docker Install">
|
||||
|
||||
The Docker installation is for Rancher users that are wanting to **test** out Rancher. Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server. **Important: If you install Rancher following the Docker installation guide, there is no upgrade path to transition your Docker installation to a Kubernetes Installation.** Instead of running the single node installation, you have the option to follow the Kubernetes Install guide, but only use one node to install Rancher. Afterwards, you can scale up the etcd nodes in your Kubernetes cluster to make it a Kubernetes Installation.
|
||||
|
||||
@@ -331,5 +331,5 @@ If you are installing Rancher v2.3.0+, the installation is complete.
|
||||
|
||||
If you are installing Rancher versions before v2.3.0, you will not be able to use the packaged system charts. Since the Rancher system charts are hosted in Github, an air gapped installation will not be able to access these charts. Therefore, you must [configure the Rancher system charts]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/local-system-charts/).
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -21,8 +21,8 @@ This section describes how to set up your private registry so that when you inst
|
||||
|
||||
By default, we provide the steps of how to populate your private registry assuming you are provisioning Linux only clusters, but if you plan on provisioning any [Windows clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/windows-clusters/), there are separate instructions to support the images needed for a Windows cluster.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Linux Only Clusters" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Linux Only Clusters">
|
||||
|
||||
For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
|
||||
|
||||
@@ -100,8 +100,8 @@ Move the images in the `rancher-images.tar.gz` to your private registry using th
|
||||
```plain
|
||||
./rancher-load-images.sh --image-list ./rancher-images.txt --registry <REGISTRY.YOURDOMAIN.COM:PORT>
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab "Linux and Windows Clusters" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Linux and Windows Clusters">
|
||||
|
||||
_Available as of v2.3.0_
|
||||
|
||||
@@ -268,8 +268,8 @@ Move the images in the `rancher-images.tar.gz` to your private registry using th
|
||||
|
||||
{{% /accordion %}}
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### [Next: Kubernetes Installs - Launch a Kubernetes Cluster with RKE]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/other-installation-methods/air-gap/launch-kubernetes/)
|
||||
|
||||
|
||||
+12
-12
@@ -12,8 +12,8 @@ This section is about how to prepare your node(s) to install Rancher for your ai
|
||||
|
||||
# Prerequisites
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Kubernetes Install (Recommended)" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Kubernetes Install (Recommended)">
|
||||
|
||||
### OS, Docker, Hardware, and Networking
|
||||
|
||||
@@ -33,8 +33,8 @@ The following CLI tools are required for the Kubernetes Install. Make sure these
|
||||
- [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. Refer to the [Helm version requirements]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/helm-version) to choose a version of Helm to install Rancher.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker Install" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Docker Install">
|
||||
|
||||
### OS, Docker, Hardware, and Networking
|
||||
|
||||
@@ -45,13 +45,13 @@ Make sure that your node(s) fulfill the general [installation requirements.]({{<
|
||||
Rancher supports air gap installs using a private registry. You must have your own private registry or other means of distributing Docker images to your machines.
|
||||
|
||||
If you need help with creating a private registry, please refer to the [Docker documentation](https://docs.docker.com/registry/).
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Set up Infrastructure
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Kubernetes Install (Recommended)" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Kubernetes Install (Recommended)">
|
||||
|
||||
Rancher recommends installing Rancher on a Kubernetes cluster. A highly available Kubernetes install is comprised of three nodes running the Rancher server components on a Kubernetes cluster. The persistence layer (etcd) is also replicated on these three nodes, providing redundancy and data duplication in case one of the nodes fails.
|
||||
|
||||
@@ -86,8 +86,8 @@ You will need to configure a load balancer as a basic Layer 4 TCP forwarder to d
|
||||
- For an example showing how to set up an NGINX load balancer, refer to [this page.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/nginx)
|
||||
- For an example showing how to set up an Amazon NLB load balancer, refer to [this page.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/nlb)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker Install" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Docker Install">
|
||||
|
||||
The Docker installation is for Rancher users that are wanting to test out Rancher. Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
|
||||
|
||||
@@ -101,7 +101,7 @@ These hosts will be disconnected from the internet, but require being able to co
|
||||
|
||||
View hardware and software requirements for each of your cluster nodes in [Requirements]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/requirements).
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### [Next: Collect and Publish Images to your Private Registry]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/other-installation-methods/air-gap/populate-private-registry/)
|
||||
|
||||
+6
-6
@@ -11,8 +11,8 @@ For a high-availability installation of Rancher, which is recommended for produc
|
||||
|
||||
For Docker installations of Rancher, which is used for development and testing, you will install Rancher as a **Docker image.**
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Helm Charts" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Helm Charts">
|
||||
|
||||
When installing, upgrading, or rolling back Rancher Server when it is [installed on a Kubernetes cluster]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/), Rancher server is installed using a Helm chart on a Kubernetes cluster. Therefore, as you prepare to install or upgrade a high availability Rancher configuration, you must add a Helm chart repository that contains the charts for installing Rancher.
|
||||
|
||||
@@ -77,8 +77,8 @@ After installing Rancher, if you want to change which Helm chart repository to i
|
||||
```
|
||||
|
||||
4. Continue to follow the steps to [upgrade Rancher]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha) from the new Helm chart repository.
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker Images" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Docker Images">
|
||||
When performing [Docker installs]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/single-node), upgrades, or rollbacks, you can use _tags_ to install a specific version of Rancher.
|
||||
|
||||
### Server Tags
|
||||
@@ -96,5 +96,5 @@ Rancher Server is distributed as a Docker image, which have tags attached to the
|
||||
> - The `master` tag or any tag with `-rc` or another suffix is meant for the Rancher testing team to validate. You should not use these tags, as these builds are not officially supported.
|
||||
> - Want to install an alpha review for preview? Install using one of the alpha tags listed on our [announcements page](https://forums.rancher.com/c/announcements) (e.g., `v2.2.0-alpha1`). Caveat: Alpha releases cannot be upgraded to or from any other release.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -49,8 +49,8 @@ When you install Rancher, enable the feature you want with a feature flag. The c
|
||||
|
||||
> **Note:** Values set from the Rancher API will override the value passed in through the command line.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Kubernetes Install" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Kubernetes Install">
|
||||
When installing Rancher with a Helm chart, use the `--features` option. In the below example, two features are enabled by passing the feature flag names names in a comma separated list:
|
||||
|
||||
```
|
||||
@@ -99,8 +99,8 @@ helm template ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--set 'extraEnv[0].value=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true' # Available as of v2.3.0
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker Install" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Docker Install">
|
||||
When installing Rancher with Docker, use the `--features` option. In the below example, two features are enabled by passing the feature flag names in a comma separated list:
|
||||
|
||||
```
|
||||
@@ -110,8 +110,8 @@ docker run -d -p 80:80 -p 443:443 \
|
||||
--features=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true # Available as of v2.3.0
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Enabling Features with the Rancher UI
|
||||
|
||||
|
||||
+6
-6
@@ -29,8 +29,8 @@ Refer to the release notes in the `system-charts` repository to see which branch
|
||||
|
||||
Rancher needs to be configured to use your Git mirror of the `system-charts` repository. You can configure the system charts repository either from the Rancher UI or from Rancher's API view.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher UI" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher UI">
|
||||
|
||||
In the catalog management page in the Rancher UI, follow these steps:
|
||||
|
||||
@@ -46,8 +46,8 @@ In the catalog management page in the Rancher UI, follow these steps:
|
||||
|
||||
**Result:** Rancher is configured to download all the required catalog items from your `system-charts` repository.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher API" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher API">
|
||||
|
||||
1. Log into Rancher.
|
||||
|
||||
@@ -65,5 +65,5 @@ In the catalog management page in the Rancher UI, follow these steps:
|
||||
|
||||
**Result:** Rancher is configured to download all the required catalog items from your `system-charts` repository.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
@@ -95,8 +95,8 @@ Before you can start configuring a pipeline for your repository, you must config
|
||||
|
||||
Select your provider's tab below and follow the directions.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "GitHub" %}}
|
||||
<Tabs>
|
||||
<TabItem label="GitHub">
|
||||
1. From the **Global** view, navigate to the project that you want to configure pipelines.
|
||||
|
||||
1. Select **Tools > Pipelines** in the navigation bar. In versions before v2.2.0, you can select **Resources > Pipelines**.
|
||||
@@ -109,8 +109,8 @@ Select your provider's tab below and follow the directions.
|
||||
|
||||
1. Click **Authenticate**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "GitLab" %}}
|
||||
</TabItem>
|
||||
<TabItem label="GitLab">
|
||||
|
||||
_Available as of v2.1.0_
|
||||
|
||||
@@ -129,8 +129,8 @@ _Available as of v2.1.0_
|
||||
>**Note:**
|
||||
> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
|
||||
> 2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
|
||||
{{% /tab %}}
|
||||
{{% tab "Bitbucket Cloud" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Bitbucket Cloud">
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
@@ -146,8 +146,8 @@ _Available as of v2.2.0_
|
||||
|
||||
1. Click **Authenticate**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Bitbucket Server" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Bitbucket Server">
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
@@ -169,8 +169,8 @@ _Available as of v2.2.0_
|
||||
> 1. Setup Rancher server with a certificate from a trusted CA.
|
||||
> 1. If you're using self-signed certificates, import Rancher server's certificate to the Bitbucket server. For instructions, see the Bitbucket server documentation for [configuring self-signed certificates](https://confluence.atlassian.com/bitbucketserver/if-you-use-self-signed-certificates-938028692.html).
|
||||
>
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:** After the version control provider is authenticated, you will be automatically re-directed to start configuring which repositories you want start using with a pipeline.
|
||||
|
||||
|
||||
@@ -25,8 +25,8 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
- **Add Volume > Use an existing persistent volume (claim)**
|
||||
|
||||
1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
|
||||
{{% tabs %}}
|
||||
{{% tab "Add a new persistent volume" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Add a new persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
@@ -39,9 +39,9 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% tab "Use an existing persistent volume" %}}
|
||||
<TabItem label="Use an existing persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
@@ -51,9 +51,9 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% /tabs %}}
|
||||
</Tabs>
|
||||
|
||||
1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container.
|
||||
|
||||
@@ -69,9 +69,9 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
- **Add Volume > Use an existing persistent volume (claim)**
|
||||
|
||||
1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
|
||||
{{% tabs %}}
|
||||
<Tabs>
|
||||
|
||||
{{% tab "Add a new persistent volume" %}}
|
||||
<TabItem label="Add a new persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
@@ -84,8 +84,8 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Use an existing persistent volume" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Use an existing persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
@@ -95,8 +95,8 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container.
|
||||
|
||||
|
||||
+6
-6
@@ -91,9 +91,9 @@ Configure probes by using the **Health Check** section while editing deployments
|
||||
|
||||
While you create a workload using Rancher v2.x, we recommend configuring a check that monitors the health of the deployment's pods.
|
||||
|
||||
{{% tabs %}}
|
||||
<Tabs>
|
||||
|
||||
{{% tab "TCP Check" %}}
|
||||
<TabItem label="TCP Check">
|
||||
|
||||
TCP checks monitor your deployment's health by attempting to open a connection to the pod over a specified port. If the probe can open the port, it's considered healthy. Failure to open it is considered unhealthy, which notifies Kubernetes that it should kill the pod and then replace it according to its [restart policy](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy). (this applies to Liveness probes, for Readiness probes, it will mark the pod as Unready).
|
||||
|
||||
@@ -129,9 +129,9 @@ When you configure a readiness check using Rancher v2.x, the `readinessProbe` di
|
||||
|
||||
-->
|
||||
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% tab "HTTP Check" %}}
|
||||
<TabItem label="HTTP Check">
|
||||
|
||||
HTTP checks monitor your deployment's health by sending an HTTP GET request to a specific URL path that you define. If the pod responds with a message range of `200`-`400`, the health check is considered successful. If the pod replies with any other value, the check is considered unsuccessful, so Kubernetes kills and replaces the pod according to its [restart policy](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy). (this applies to Liveness probes, for Readiness probes, it will mark the pod as Unready).
|
||||
|
||||
@@ -141,9 +141,9 @@ You can configure the probe along with values for specifying its behavior by sel
|
||||
|
||||
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 %}}
|
||||
</TabItem>
|
||||
|
||||
{{% /tabs %}}
|
||||
</Tabs>
|
||||
|
||||
### Configuring Separate Liveness Checks
|
||||
|
||||
|
||||
+14
-14
@@ -121,8 +121,8 @@ File | Description
|
||||
<!--
|
||||
The following tabs display the contents of each parsed file. We've omitted `webLB-deployment.yaml` and `webLB-service.yaml` because we aren't migrating them to v2.x.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "web-deployment.yaml" %}}
|
||||
<Tabs>
|
||||
<TabItem label="web-deployment.yaml">
|
||||
|
||||
```YAML
|
||||
apiVersion: extensions/v1beta1
|
||||
@@ -159,8 +159,8 @@ spec:
|
||||
status: {}
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "web-service.yaml" %}}
|
||||
</TabItem>
|
||||
<TabItem label="web-service.yaml">
|
||||
|
||||
```YAML
|
||||
apiVersion: v1
|
||||
@@ -187,8 +187,8 @@ status:
|
||||
loadBalancer: {}
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "database-deployment.yaml" %}}
|
||||
</TabItem>
|
||||
<TabItem label="database-deployment.yaml">
|
||||
|
||||
```YAML
|
||||
apiVersion: extensions/v1beta1
|
||||
@@ -224,10 +224,10 @@ status: {}
|
||||
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
|
||||
{{% /tabs %}}
|
||||
</Tabs>
|
||||
|
||||
-->
|
||||
|
||||
@@ -235,8 +235,8 @@ status: {}
|
||||
|
||||
>**Note:** Although these instructions deploy your v1.6 services in Rancher v2.x, they will not work correctly until you adjust their Kubernetes manifests.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher UI" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher UI">
|
||||
|
||||
You can deploy the Kubernetes manifests created by migration-tools by importing them into Rancher v2.x.
|
||||
|
||||
@@ -248,8 +248,8 @@ You can deploy the Kubernetes manifests created by migration-tools by importing
|
||||
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher CLI" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher CLI">
|
||||
|
||||
|
||||
>**Prerequisite:** [Install Rancher CLI]({{<baseurl>}}/rancher/v2.0-v2.4/en/cli/) for Rancher v2.x.
|
||||
@@ -262,8 +262,8 @@ Use the following Rancher CLI commands to deploy your application using Rancher
|
||||
./rancher kubectl create -f <SERVICE_YAML_FILE> # DEPLOY THE SERVICE YAML
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
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 **Resources > Workloads** and on the tab at **Resources > Workloads > Service Discovery.** (In Rancher v2.x before v2.3.0, these are on the **Workloads** and **Service Discovery** tabs in the top navigation bar.)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user