mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-27 05:28:22 +00:00
Fix tabs: add import statements, specify value, spacing
This commit is contained in:
+13
-6
@@ -3,6 +3,9 @@ title: Upgrading Kubernetes without Upgrading Rancher
|
||||
weight: 1120
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
_Available as of v2.3.0_
|
||||
|
||||
The RKE metadata feature allows you to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. This feature is useful for taking advantage of patch versions of Kubernetes, for example, if you want to upgrade to Kubernetes v1.14.7 when your Rancher server originally supported v1.14.6.
|
||||
@@ -11,7 +14,7 @@ The RKE metadata feature allows you to provision clusters with new versions of K
|
||||
|
||||
Rancher's Kubernetes metadata contains information specific to the Kubernetes version that Rancher uses to provision [RKE clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/). Rancher syncs the data periodically and creates custom resource definitions (CRDs) for **system images,** **service options** and **addon templates.** Consequently, when a new Kubernetes version is compatible with the Rancher server version, the Kubernetes metadata makes the new version available to Rancher for provisioning clusters. The metadata gives you an overview of the information that the [Rancher Kubernetes Engine]({{<baseurl>}}/rke/latest/en/) (RKE) uses for deploying various Kubernetes versions.
|
||||
|
||||
This table below describes the CRDs that are affected by the periodic data sync.
|
||||
This table below describes the CRDs that are affected by the periodic data sync.
|
||||
|
||||
> **Note:** Only administrators can edit metadata CRDs. It is recommended not to update existing objects unless explicitly advised.
|
||||
|
||||
@@ -31,7 +34,7 @@ Administrators might configure the RKE metadata settings to do the following:
|
||||
|
||||
The option to refresh the Kubernetes metadata is available for administrators by default, or for any user who has the **Manage Cluster Drivers** [global role.]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/global-permissions/)
|
||||
|
||||
To force Rancher to refresh the Kubernetes metadata, a manual refresh action is available under **Tools > Drivers > Refresh Kubernetes Metadata** on the right side corner.
|
||||
To force Rancher to refresh the Kubernetes metadata, a manual refresh action is available under **Tools > Drivers > Refresh Kubernetes Metadata** on the right side corner.
|
||||
|
||||
You can configure Rancher to only refresh metadata when desired by setting `refresh-interval-minutes` to `0` (see below) and using this button to perform the metadata refresh manually when desired.
|
||||
|
||||
@@ -44,7 +47,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>
|
||||
<TabItem label="Rancher v2.4+">
|
||||
<TabItem value="Rancher v2.4+">
|
||||
|
||||
To edit the metadata config in Rancher,
|
||||
|
||||
1. Go to the **Global** view and click the **Settings** tab.
|
||||
@@ -56,9 +60,11 @@ 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.
|
||||
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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher v2.3">
|
||||
<TabItem value="Rancher v2.3">
|
||||
|
||||
To edit the metadata config in Rancher,
|
||||
|
||||
1. Go to the **Global** view and click the **Settings** tab.
|
||||
@@ -67,11 +73,12 @@ To edit the metadata config in Rancher,
|
||||
|
||||
- `refresh-interval-minutes`: This is the amount of time that Rancher waits to sync the metadata. To disable the periodic refresh, set `refresh-interval-minutes` to 0.
|
||||
- `url`: This is the HTTP path that Rancher fetches data from.
|
||||
- `branch`: This refers to the Git branch name if the URL is a Git URL.
|
||||
- `branch`: This refers to the Git branch name if the URL is a Git URL.
|
||||
|
||||
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.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+8
-5
@@ -5,6 +5,9 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/tasks/global-configuration/roles/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Within Rancher, _roles_ determine what actions a user can make within a cluster or project.
|
||||
|
||||
Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access.
|
||||
@@ -31,7 +34,7 @@ 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>
|
||||
<TabItem label="Rancher v2.0.7+">
|
||||
<TabItem value="Rancher v2.0.7+">
|
||||
|
||||
1. From the **Global** view, select **Security > Roles** from the main menu.
|
||||
|
||||
@@ -51,7 +54,7 @@ The steps to add custom roles differ depending on the version of Rancher.
|
||||
1. Use the **Grant Resources** options to assign individual [Kubernetes API endpoints](https://kubernetes.io/docs/reference/) to the role.
|
||||
|
||||
> When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
|
||||
|
||||
|
||||
> The Resource text field provides a method to search for pre-defined Kubernetes API resources, or enter a custom resource name for the grant. The pre-defined or `(Custom)` resource must be selected from the dropdown, after entering a resource name into this field.
|
||||
|
||||
You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign.
|
||||
@@ -61,7 +64,7 @@ The steps to add custom roles differ depending on the version of Rancher.
|
||||
1. Click **Create**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.0.7">
|
||||
<TabItem value="Rancher before v2.0.7">
|
||||
|
||||
1. From the **Global** view, select **Security > Roles** from the main menu.
|
||||
|
||||
@@ -84,7 +87,7 @@ The steps to add custom roles differ depending on the version of Rancher.
|
||||
1. Use the **Grant Resources** options to assign individual [Kubernetes API endpoints](https://kubernetes.io/docs/reference/) to the role.
|
||||
|
||||
> When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
|
||||
|
||||
|
||||
> The Resource text field provides a method to search for pre-defined Kubernetes API resources, or enter a custom resource name for the grant. The pre-defined or `(Custom)` resource must be selected from the dropdown, after entering a resource name into this field.
|
||||
|
||||
You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign.
|
||||
@@ -129,7 +132,7 @@ Custom global roles don't have to be based on existing roles. To create a custom
|
||||
1. In the **Grant Resources** section, select the Kubernetes resource operations that will be enabled for users with the custom role.
|
||||
|
||||
> The Resource text field provides a method to search for pre-defined Kubernetes API resources, or enter a custom resource name for the grant. The pre-defined or `(Custom)` resource must be selected from the dropdown, after entering a resource name into this field.
|
||||
|
||||
|
||||
1. Click **Save.**
|
||||
|
||||
## Deleting a Custom Global Role
|
||||
|
||||
+9
-3
@@ -13,6 +13,10 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/backup/rke-backups
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/backup/rke-backups/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This section describes how to create backups of your high-availability Rancher install.
|
||||
|
||||
In an RKE installation, the cluster data is replicated on each of three etcd nodes in the cluster, providing redundancy and data duplication in case one of the nodes fails.
|
||||
@@ -68,10 +72,10 @@ 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>
|
||||
<TabItem label="RKE v0.2.0+">
|
||||
<TabItem value="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.
|
||||
2. Edit the code for the `etcd` service to enable recurring snapshots. Snapshots can be saved in a S3 compatible backend.
|
||||
|
||||
```
|
||||
services:
|
||||
@@ -101,8 +105,9 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="RKE v0.1.x">
|
||||
<TabItem value="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,6 +127,7 @@ 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/`.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+8
-3
@@ -3,6 +3,9 @@ title: Backing up a Cluster
|
||||
weight: 2045
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) can be easily performed.
|
||||
@@ -28,11 +31,11 @@ This section covers the following topics:
|
||||
# How Snapshots Work
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.4.0+">
|
||||
<TabItem value="Rancher v2.4.0+">
|
||||
|
||||
### Snapshot Components
|
||||
|
||||
When Rancher creates a snapshot, it includes three components:
|
||||
When Rancher creates a snapshot, it includes three components:
|
||||
|
||||
- The cluster data in etcd
|
||||
- The Kubernetes version
|
||||
@@ -85,7 +88,8 @@ On restore, the following process is used:
|
||||
5. The cluster is restored and post-restore actions will be done in the cluster.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.4.0">
|
||||
<TabItem value="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,6 +132,7 @@ 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.
|
||||
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+7
-2
@@ -4,6 +4,9 @@ description: Learn about cluster cleanup when removing nodes from your Rancher-l
|
||||
weight: 2055
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This section describes how to disconnect a node from a Rancher-launched Kubernetes cluster and remove all of the Kubernetes components from the node. This process allows you to use the node for other purposes.
|
||||
|
||||
When you use Rancher to install Kubernetes on new nodes in an infrastructure provider, resources (containers/virtual network interfaces) and configuration items (certificates/configuration files) are created.
|
||||
@@ -56,7 +59,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>
|
||||
<TabItem label="By UI / API">
|
||||
<TabItem value="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.
|
||||
@@ -70,7 +74,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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="By Script">
|
||||
<TabItem value="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:**
|
||||
|
||||
@@ -3,6 +3,9 @@ title: Nodes and Node Pools
|
||||
weight: 2030
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab. Depending on the [option used]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/) to provision the cluster, there are different node options available.
|
||||
|
||||
> If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters]({{< baseurl >}}/rancher/v2.0-v2.4/en/cluster-admin/editing-clusters/#editing-clusters-with-yaml).
|
||||
@@ -131,7 +134,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>
|
||||
<TabItem label="Rancher v2.2.x+">
|
||||
<TabItem value="Rancher v2.2.x+">
|
||||
|
||||
There are two drain modes: aggressive and safe.
|
||||
|
||||
- **Aggressive Mode**
|
||||
@@ -143,8 +147,9 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.x">
|
||||
<TabItem value="Rancher before v2.2.x">
|
||||
|
||||
The following list describes each drain option:
|
||||
|
||||
@@ -159,6 +164,7 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
@@ -219,7 +225,7 @@ cattle.rancher.io/node-status: ignore
|
||||
|
||||
**Result:** If you add the node to a cluster, Rancher will not attempt to sync with this node. The node can still be part of the cluster and can be listed with `kubectl`.
|
||||
|
||||
If the label is added before the node is added to the cluster, the node will not be shown in the Rancher UI.
|
||||
If the label is added before the node is added to the cluster, the node will not be shown in the Rancher UI.
|
||||
|
||||
If the label is added after the node is added to a Rancher cluster, the node will not be removed from the UI.
|
||||
|
||||
|
||||
+9
-6
@@ -1,8 +1,11 @@
|
||||
---
|
||||
title: Restoring a Cluster from Backup
|
||||
title: Restoring a Cluster from Backup
|
||||
weight: 2050
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
etcd backup and recovery for [Rancher launched Kubernetes clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) can be easily performed. Snapshots of the etcd database are taken and saved either locally onto the etcd nodes or to a S3 compatible target. The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.
|
||||
@@ -33,7 +36,7 @@ If your Kubernetes cluster is broken, you can restore the cluster from a snapsho
|
||||
Restores changed in Rancher v2.4.0.
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.4.0+">
|
||||
<TabItem value="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:
|
||||
|
||||
@@ -58,9 +61,9 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.4.0">
|
||||
<TabItem value="Rancher before v2.4.0">
|
||||
|
||||
> **Prerequisites:**
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - Make sure your etcd nodes are healthy. If you are restoring a cluster with unavailable etcd nodes, it's recommended that all etcd nodes are removed from Rancher before attempting to restore. For clusters in which Rancher used node pools to provision [nodes in an infrastructure provider]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/), new etcd nodes will automatically be created. For [custom clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/custom-nodes/), please ensure that you add new etcd nodes to the cluster.
|
||||
> - To restore snapshots from S3, the cluster needs to be configured to [take recurring snapshots on S3.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/backing-up-etcd/#configuring-recurring-snapshots)
|
||||
@@ -71,7 +74,7 @@ When rolling back to a prior Kubernetes version, the [upgrade strategy options](
|
||||
|
||||
3. Select the snapshot that you want to use for restoring your cluster from the dropdown of available snapshots.
|
||||
|
||||
4. Click **Save**.
|
||||
4. Click **Save**.
|
||||
|
||||
**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.
|
||||
|
||||
@@ -106,7 +109,7 @@ If the group of etcd nodes loses quorum, the Kubernetes cluster will report a fa
|
||||
|
||||
5. Run the revised command.
|
||||
|
||||
6. After the single nodes is up and running, Rancher recommends adding additional etcd nodes to your cluster. If you have a [custom cluster]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/custom-nodes) and you want to reuse an old node, you are required to [clean up the nodes]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/cleaning-cluster-nodes/) before attempting to add them back into a cluster.
|
||||
6. After the single nodes is up and running, Rancher recommends adding additional etcd nodes to your cluster. If you have a [custom cluster]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/custom-nodes) and you want to reuse an old node, you are required to [clean up the nodes]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/cleaning-cluster-nodes/) before attempting to add them back into a cluster.
|
||||
|
||||
# Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0
|
||||
|
||||
|
||||
+9
-2
@@ -3,6 +3,9 @@ title: Upgrading and Rolling Back Kubernetes
|
||||
weight: 70
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Following an upgrade to the latest version of Rancher, downstream Kubernetes clusters can be upgraded to use the latest supported version of Kubernetes.
|
||||
|
||||
Rancher calls RKE (Rancher Kubernetes Engine) as a library when provisioning and editing RKE clusters. For more information on configuring the upgrade strategy for RKE clusters, refer to the [RKE documentation]({{<baseurl>}}/rke/latest/en/).
|
||||
@@ -45,7 +48,8 @@ In this section of the [RKE documentation,]({{<baseurl>}}/rke/latest/en/upgrades
|
||||
# Recommended Best Practice for Upgrades
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.4+">
|
||||
<TabItem value="Rancher v2.4+">
|
||||
|
||||
When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
|
||||
1. Take a snapshot.
|
||||
@@ -53,8 +57,10 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.4">
|
||||
<TabItem value="Rancher before v2.4">
|
||||
|
||||
When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
|
||||
1. Take a snapshot.
|
||||
@@ -62,6 +68,7 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+7
-3
@@ -3,6 +3,9 @@ title: Node Requirements for Rancher Managed Clusters
|
||||
weight: 1
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This page describes the requirements for the Rancher managed Kubernetes clusters where your apps and services will be installed. These downstream clusters should be separate from the three-node cluster running Rancher.
|
||||
|
||||
> If Rancher is installed on a high-availability Kubernetes cluster, the Rancher server three-node cluster and downstream clusters have different requirements. For Rancher installation requirements, refer to the node requirements in the [installation section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/requirements/)
|
||||
@@ -39,7 +42,7 @@ 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>
|
||||
<TabItem label="Canal">
|
||||
<TabItem value="Canal">
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config:
|
||||
@@ -54,9 +57,9 @@ rancher_kubernetes_engine_config:
|
||||
extra_args:
|
||||
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="Calico">
|
||||
</TabItem>
|
||||
<TabItem value="Calico">
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config:
|
||||
@@ -71,6 +74,7 @@ rancher_kubernetes_engine_config:
|
||||
extra_args:
|
||||
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+8
-4
@@ -3,12 +3,15 @@ title: Azure Node Template Configuration
|
||||
weight: 1
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
<TabItem value="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.
|
||||
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.
|
||||
|
||||
- **Placement** sets the geographical region where your cluster is hosted and other location metadata.
|
||||
- **Network** configures the networking used in your cluster.
|
||||
@@ -22,9 +25,9 @@ The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-d
|
||||
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
<TabItem value="Rancher before v2.2.0">
|
||||
|
||||
- **Account Access** stores your account information for authenticating with Azure.
|
||||
- **Account Access** stores your account information for authenticating with Azure.
|
||||
- **Placement** sets the geographical region where your cluster is hosted and other location metadata.
|
||||
- **Network** configures the networking used in your cluster.
|
||||
- **Instance** customizes your VM configuration.
|
||||
@@ -35,5 +38,6 @@ 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/)
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+16
-13
@@ -6,9 +6,12 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/tasks/clusters/creating-a-cluster/create-cluster-azure/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
In this section, you'll learn how to install an [RKE]({{<baseurl>}}/rke/latest/en/) Kubernetes cluster in Azure through Rancher.
|
||||
|
||||
First, you will set up your Azure cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in Azure.
|
||||
First, you will set up your Azure cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in Azure.
|
||||
|
||||
Then you will create an Azure 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 Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
@@ -27,31 +30,31 @@ For more information on configuring Azure node templates, refer to the [Azure no
|
||||
- [Creating an Azure Cluster](#creating-an-azure-cluster)
|
||||
|
||||
# Preparation in Azure
|
||||
|
||||
|
||||
Before creating a node template in Rancher using a cloud infrastructure such as Azure, we must configure Rancher to allow the manipulation of resources in an Azure subscription.
|
||||
|
||||
To do this, we will first create a new Azure **service principal (SP)** in Azure **Active Directory (AD)**, which, in Azure, is an application user who has permission to manage Azure resources.
|
||||
|
||||
The following is a template `az cli` script that you have to run for creating an service principal, where you have to enter your SP name, role, and scope:
|
||||
|
||||
|
||||
```
|
||||
az ad sp create-for-rbac \
|
||||
--name="<Rancher ServicePrincipal name>" \
|
||||
--role="Contributor" \
|
||||
--scopes="/subscriptions/<subscription Id>"
|
||||
```
|
||||
|
||||
|
||||
The creation of this service principal returns three pieces of identification information, *The application ID, also called the client ID*, *The client secret*, and *The tenant ID*. This information will be used when you create a node template for Azure.
|
||||
|
||||
# Creating an Azure Cluster
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
<TabItem value="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)
|
||||
|
||||
|
||||
### 1. Create your cloud credentials
|
||||
|
||||
1. In the Rancher UI, click the user profile button in the upper right corner, and click **Cloud Credentials.**
|
||||
@@ -61,7 +64,7 @@ The creation of this service principal returns three pieces of identification in
|
||||
1. Enter your Azure credentials.
|
||||
1. Click **Create.**
|
||||
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
|
||||
### 2. Create a node template with your cloud credentials
|
||||
|
||||
@@ -83,19 +86,19 @@ Use Rancher to create a Kubernetes cluster in Azure.
|
||||
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. Review your options to confirm they're correct. Then click **Create**.
|
||||
|
||||
**Result:**
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
<TabItem value="Rancher before v2.2.0">
|
||||
|
||||
Use Rancher to create a Kubernetes cluster in Azure.
|
||||
|
||||
@@ -104,16 +107,16 @@ Use Rancher to create a Kubernetes cluster in Azure.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options.** For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options)
|
||||
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. To create a node template, click **Add Node Template** and complete the **Azure Options** form. For help filling out the form, refer to the [Azure node template configuration reference.](./azure-node-template-config) For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. To create a node template, click **Add Node Template** and complete the **Azure Options** form. For help filling out the form, refer to the [Azure node template configuration reference.](./azure-node-template-config) For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. Review your options to confirm they're correct. Then click **Create**.
|
||||
|
||||
**Result:**
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
+16
-10
@@ -5,14 +5,19 @@ weight: 2215
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/tasks/clusters/creating-a-cluster/create-cluster-digital-ocean/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in DigitalOcean.
|
||||
|
||||
First, you will set up your DigitalOcean cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in DigitalOcean.
|
||||
First, you will set up your DigitalOcean cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in DigitalOcean.
|
||||
|
||||
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>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
<TabItem value="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)
|
||||
@@ -26,7 +31,7 @@ Then you will create a DigitalOcean cluster in Rancher, and when configuring the
|
||||
1. Enter your Digital Ocean credentials.
|
||||
1. Click **Create.**
|
||||
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
|
||||
### 2. Create a node template with your cloud credentials
|
||||
|
||||
@@ -43,41 +48,42 @@ Creating a [node template]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioni
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options.** For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options)
|
||||
1. Add one or more node pools to your cluster. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. Add one or more node pools to your cluster. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. Review your options to confirm they're correct. Then click **Create**.
|
||||
|
||||
**Result:**
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
<TabItem value="Rancher before v2.2.0">
|
||||
|
||||
1. From the **Clusters** page, click **Add Cluster**.
|
||||
1. Choose **DigitalOcean**.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options.** For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options)
|
||||
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. To create a node template, click **Add Node Template** and complete the **Digital Ocean Options** form. For help filling out the form, refer to the [Digital Ocean node template configuration reference.](./do-node-template-config) For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. To create a node template, click **Add Node Template** and complete the **Digital Ocean Options** form. For help filling out the form, refer to the [Digital Ocean node template configuration reference.](./do-node-template-config) For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. Review your options to confirm they're correct. Then click **Create**.
|
||||
|
||||
**Result:**
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+7
-2
@@ -3,8 +3,11 @@ title: DigitalOcean Node Template Configuration
|
||||
weight: 1
|
||||
----
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
<TabItem value="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 +23,9 @@ 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/)
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
<TabItem value="Rancher before v2.2.0">
|
||||
|
||||
### Access Token
|
||||
|
||||
@@ -39,5 +43,6 @@ 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/)
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
+12
-8
@@ -3,10 +3,13 @@ title: EC2 Node Template Configuration
|
||||
weight: 1
|
||||
---
|
||||
|
||||
For more details about EC2, nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
For more details about EC2, nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
<TabItem value="Rancher v2.2.0+">
|
||||
|
||||
### Region
|
||||
|
||||
@@ -14,13 +17,13 @@ In the **Region** field, select the same region that you used when creating your
|
||||
|
||||
### Cloud Credentials
|
||||
|
||||
Your AWS account access information, stored in a [cloud credential.]({{<baseurl>}}/rancher/v2.0-v2.4/en/user-settings/cloud-credentials/)
|
||||
Your AWS account access information, stored in a [cloud credential.]({{<baseurl>}}/rancher/v2.0-v2.4/en/user-settings/cloud-credentials/)
|
||||
|
||||
See [Amazon Documentation: Creating Access Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) how to create an Access Key and Secret Key.
|
||||
|
||||
See [Amazon Documentation: Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) how to create an IAM policy.
|
||||
|
||||
See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach an IAM
|
||||
See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach an IAM
|
||||
|
||||
See our three example JSON policies:
|
||||
|
||||
@@ -30,7 +33,7 @@ See our three example JSON policies:
|
||||
|
||||
### Authenticate & Configure Nodes
|
||||
|
||||
Choose an availability zone and network settings for your cluster.
|
||||
Choose an availability zone and network settings for your cluster.
|
||||
|
||||
### Security Group
|
||||
|
||||
@@ -49,7 +52,7 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
<TabItem value="Rancher before v2.2.0">
|
||||
|
||||
### Account Access
|
||||
|
||||
@@ -59,7 +62,7 @@ See [Amazon Documentation: Creating Access Keys](https://docs.aws.amazon.com/IAM
|
||||
|
||||
See [Amazon Documentation: Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) how to create an IAM policy.
|
||||
|
||||
See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach an IAM
|
||||
See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach an IAM
|
||||
|
||||
See our three example JSON policies:
|
||||
|
||||
@@ -72,7 +75,7 @@ See our three example JSON policies:
|
||||
**Zone and Network** configures the availability zone and network settings for your cluster.
|
||||
|
||||
### Security Groups
|
||||
|
||||
|
||||
**Security Groups** creates or configures the Security Groups applied to your nodes. Please refer to [Amazon EC2 security group when using Node Driver]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/requirements/ports/#rancher-aws-ec2-security-group) to see what rules are created in the `rancher-nodes` Security Group.
|
||||
|
||||
### Instance
|
||||
@@ -95,5 +98,6 @@ 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/)
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+13
-9
@@ -4,9 +4,13 @@ shortTitle: Amazon EC2
|
||||
description: Learn the prerequisites and steps required in order for you to create an Amazon EC2 cluster using Rancher
|
||||
weight: 2210
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in Amazon EC2.
|
||||
|
||||
First, you will set up your EC2 cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in EC2.
|
||||
First, you will set up your EC2 cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in EC2.
|
||||
|
||||
Then you will create an EC2 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.
|
||||
|
||||
@@ -26,7 +30,7 @@ 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>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
<TabItem value="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)
|
||||
@@ -42,7 +46,7 @@ The steps to create a cluster differ based on your Rancher version.
|
||||
1. Enter your AWS EC2 **Access Key** and **Secret Key.**
|
||||
1. Click **Create.**
|
||||
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
|
||||
### 2. Create a node template with your cloud credentials and information from EC2
|
||||
|
||||
@@ -59,24 +63,24 @@ Add one or more node pools to your cluster. For more information about node pool
|
||||
1. From the **Clusters** page, click **Add Cluster**.
|
||||
1. Choose **Amazon EC2**.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Create a node pool for each Kubernetes role. For each node pool, choose a node template that you created. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. Create a node pool for each Kubernetes role. For each node pool, choose a node template that you created. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. Refer to [Selecting Cloud Providers]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/cloud-providers/) to configure the Kubernetes Cloud Provider. For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options)
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:**
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
<TabItem value="Rancher before v2.2.0">
|
||||
|
||||
1. From the **Clusters** page, click **Add Cluster**.
|
||||
1. Choose **Amazon EC2**.
|
||||
@@ -88,13 +92,13 @@ You can access your cluster after its state is updated to **Active.**
|
||||
1. **Optional:** Add additional node pools.
|
||||
1. Review your cluster settings to confirm they are correct. Then click **Create**.
|
||||
|
||||
**Result:**
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
+15
-9
@@ -3,9 +3,13 @@ title: Provisioning Kubernetes Clusters in vSphere
|
||||
weight: 1
|
||||
---
|
||||
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
In this section, you'll learn how to use Rancher to install an [RKE]({{<baseurl>}}/rke/latest/en/) Kubernetes cluster in vSphere.
|
||||
|
||||
First, you will set up your vSphere cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision nodes in vSphere.
|
||||
First, you will set up your vSphere cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision nodes in vSphere.
|
||||
|
||||
Then you will create a vSphere 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.
|
||||
|
||||
@@ -51,7 +55,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>
|
||||
<TabItem label="Rancher v2.2.0+">
|
||||
<TabItem value="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)
|
||||
@@ -65,7 +70,7 @@ The a vSphere cluster is created in Rancher depends on the Rancher version.
|
||||
1. Enter your vSphere credentials. For help, refer to **Account Access** in the [configuration reference for your Rancher version.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/)
|
||||
1. Click **Create.**
|
||||
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
|
||||
### 2. Create a node template with your cloud credentials
|
||||
|
||||
@@ -91,18 +96,19 @@ Use Rancher to create a Kubernetes cluster in vSphere.
|
||||
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to the nodes, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/#node-pools)
|
||||
1. Review your options to confirm they're correct. Then click **Create**.
|
||||
|
||||
**Result:**
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.0">
|
||||
<TabItem value="Rancher before v2.2.0">
|
||||
|
||||
Use Rancher to create a Kubernetes cluster in vSphere.
|
||||
|
||||
@@ -116,16 +122,16 @@ For Rancher versions before v2.0.4, when you create the cluster, you will also n
|
||||
1. If you want to dynamically provision persistent storage or other infrastructure later, you will need to enable the vSphere cloud provider by modifying the cluster YAML file. For details, refer to [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere)
|
||||
1. Add one or more [node pools]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) to your cluster. Each node pool uses a node template to provision new nodes. To create a node template, click **Add Node Template** and complete the **vSphere Options** form. For help filling out the form, refer to the vSphere node template configuration reference. Refer to the newest version of the configuration reference that is less than or equal to your Rancher version:
|
||||
- [v2.0.4]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.0.4)
|
||||
- [before v2.0.4]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/prior-to-2.0.4)
|
||||
- [before v2.0.4]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/prior-to-2.0.4)
|
||||
1. Review your options to confirm they're correct. Then click **Create** to start provisioning the VMs and Kubernetes services.
|
||||
|
||||
**Result:**
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
+7
-2
@@ -6,6 +6,10 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/helm-charts/legacy-catalogs/launching-apps
|
||||
---
|
||||
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Within a project, when you want to deploy applications from catalogs, the applications available in your project will be based on the [scope of the catalogs]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/legacy-catalogs/#catalog-scopes).
|
||||
|
||||
If your application is using ingresses, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/globaldns/).
|
||||
@@ -57,7 +61,7 @@ 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>
|
||||
<TabItem label="UI">
|
||||
<TabItem value="UI">
|
||||
|
||||
### Using a questions.yml file
|
||||
|
||||
@@ -68,7 +72,7 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Editing YAML Files">
|
||||
<TabItem value="Editing YAML Files">
|
||||
|
||||
_Available as of v2.1.0_
|
||||
|
||||
@@ -101,5 +105,6 @@ 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).
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
+14
-10
@@ -6,13 +6,16 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/k8s-install/
|
||||
- /rancher/v2.0-v2.4/en/installation/k8s-install/helm-rancher
|
||||
- /rancher/v2.0-v2.4/en/installation/k8s-install/kubernetes-rke
|
||||
- /rancher/v2.0-v2.4/en/installation/ha-server-install
|
||||
- /rancher/v2.0-v2.4/en/installation/ha-server-install
|
||||
- /rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/install
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
# Prerequisite
|
||||
|
||||
Set up the Rancher server's local Kubernetes cluster.
|
||||
Set up the Rancher server's local Kubernetes cluster.
|
||||
|
||||
The cluster requirements depend on the Rancher version:
|
||||
|
||||
@@ -96,7 +99,7 @@ There are three recommended options for the source of the certificate used for T
|
||||
|
||||
### 5. Install cert-manager
|
||||
|
||||
> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/chart-options/#external-tls-termination).
|
||||
> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/chart-options/#external-tls-termination).
|
||||
|
||||
This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
|
||||
|
||||
@@ -154,15 +157,14 @@ cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
|
||||
The exact command to install Rancher differs depending on the certificate configuration.
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Rancher-generated Certificates">
|
||||
|
||||
<TabItem value="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.
|
||||
|
||||
Because `rancher` is the default option for `ingress.tls.source`, we are not specifying `ingress.tls.source` when running the `helm install` command.
|
||||
|
||||
- Set the `hostname` to the DNS name you pointed at your load balancer.
|
||||
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
|
||||
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
|
||||
- To install a specific Rancher version, use the `--version` flag, example: `--version 2.3.6`
|
||||
|
||||
```
|
||||
@@ -180,7 +182,7 @@ deployment "rancher" successfully rolled out
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Let's Encrypt">
|
||||
<TabItem value="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.
|
||||
|
||||
@@ -189,7 +191,7 @@ In the following command,
|
||||
- `hostname` is set to the public DNS record,
|
||||
- `ingress.tls.source` is set to `letsEncrypt`
|
||||
- `letsEncrypt.email` is set to the email address used for communication about your certificate (for example, expiry notices)
|
||||
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
|
||||
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
|
||||
|
||||
```
|
||||
helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
@@ -208,7 +210,8 @@ deployment "rancher" successfully rolled out
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Certificates from Files">
|
||||
<TabItem value="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.
|
||||
@@ -219,7 +222,7 @@ Although an entry in the `Subject Alternative Names` is technically required, ha
|
||||
|
||||
- Set the `hostname`.
|
||||
- Set `ingress.tls.source` to `secret`.
|
||||
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
|
||||
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
|
||||
|
||||
```
|
||||
helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
@@ -239,6 +242,7 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+8
-6
@@ -10,20 +10,23 @@ aliases:
|
||||
- /rancher/v2.x/en/installation/install-rancher-on-k8s/upgrades/helm2/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
> Helm 3 has been released. If you are using Helm 2, we recommend [migrating to Helm 3](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) because it is simpler to use and more secure than Helm 2.
|
||||
>
|
||||
> The [current instructions for Upgrading Rancher Installed on Kubernetes](https://rancher.com/docs/rancher/v2.0-v2.4/en/upgrades/upgrades/ha/) use Helm 3.
|
||||
>
|
||||
> This section provides a copy of the older instructions for upgrading Rancher with Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
The following instructions will guide you through using Helm to upgrade a Rancher server that is installed on a Kubernetes cluster.
|
||||
The following instructions will guide you through using Helm to upgrade a Rancher server that is installed on a Kubernetes cluster.
|
||||
|
||||
To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services]({{<baseurl>}}/rke/latest/en/config-options/services/) or [add-ons]({{<baseurl>}}/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE]({{<baseurl>}}/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
|
||||
|
||||
If you installed Rancher using the RKE Add-on yaml, follow the directions to [migrate or upgrade]({{<baseurl>}}/rancher/v2.0-v2.4/en/upgrades/upgrades/migrating-from-rke-add-on).
|
||||
|
||||
>**Notes:**
|
||||
>
|
||||
>
|
||||
> - [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753) Upgrade cert-manager to the latest version by following [these instructions.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/upgrading-cert-manager)
|
||||
> - If you are upgrading Rancher from v2.x to v2.3+, and you are using external TLS termination, you will need to edit the cluster.yml to [enable using forwarded host headers.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/chart-options/#configuring-ingress-for-external-tls-when-using-nginx-v0-25)
|
||||
> - The upgrade instructions assume you are using Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) This [section]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/helm2) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
@@ -85,7 +88,7 @@ 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>
|
||||
<TabItem label="Kubernetes Upgrade">
|
||||
<TabItem value="Kubernetes Upgrade">
|
||||
|
||||
Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
|
||||
|
||||
@@ -114,7 +117,7 @@ helm upgrade --install rancher rancher-<CHART_REPO>/rancher \
|
||||
|
||||
{{% accordion label="Option B: Reinstalling Rancher chart" %}}
|
||||
|
||||
If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
|
||||
If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
|
||||
|
||||
1. Uninstall Rancher
|
||||
|
||||
@@ -137,8 +140,7 @@ If you are currently running the cert-manager whose version is older than v0.11,
|
||||
{{% /accordion %}}
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="Kubernetes Air Gap Upgrade">
|
||||
<TabItem value="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.
|
||||
|
||||
|
||||
+8
-3
@@ -7,6 +7,10 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades-rollbacks/upgrades/namespace-migration
|
||||
- /rancher/v2.x/en/installation/install-rancher-on-k8s/upgrades/namespace-migration/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
>This section applies only to Rancher upgrades from v2.0.6 or earlier to v2.0.7 or later. Upgrades from v2.0.7 to later version are unaffected.
|
||||
|
||||
In Rancher v2.0.6 and prior, system namespaces crucial for Rancher and Kubernetes operations were not assigned to any Rancher project by default. Instead, these namespaces existed independently from all Rancher projects, but you could move these namespaces into any project without affecting cluster operations.
|
||||
@@ -72,7 +76,8 @@ Reset the cluster nodes' network policies to restore connectivity.
|
||||
>Download and setup [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Kubernetes Install">
|
||||
<TabItem value="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`.
|
||||
@@ -172,8 +177,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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher Launched Kubernetes">
|
||||
<br/>
|
||||
<TabItem value="Rancher Launched Kubernetes">
|
||||
|
||||
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:
|
||||
|
||||
- Using the cluster's [embedded kubectl shell]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/kubectl/).
|
||||
|
||||
+10
-6
@@ -16,6 +16,10 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/
|
||||
- /rancher/v2.0-v2.4/en/upgrades/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
The following instructions will guide you through upgrading a Rancher server that was installed on a Kubernetes cluster with Helm. These steps also apply to air gap installs with Helm.
|
||||
|
||||
For the instructions to upgrade Rancher installed with Docker, refer to [this page.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades)
|
||||
@@ -35,7 +39,7 @@ If you installed Rancher using the RKE Add-on yaml, follow the directions to [mi
|
||||
|
||||
Helm should be run from the same location as your kubeconfig file, or the same location where you run your kubectl commands from.
|
||||
|
||||
If you installed Kubernetes with RKE, the config will have been created in the directory you ran `rke up` in.
|
||||
If you installed Kubernetes with RKE, the config will have been created in the directory you ran `rke up` in.
|
||||
|
||||
The kubeconfig can also be manually targeted for the intended cluster with the `--kubeconfig` tag (see: https://helm.sh/docs/helm/helm/)
|
||||
|
||||
@@ -115,7 +119,7 @@ You'll use the backup as a restoration point if something goes wrong during upgr
|
||||
helm fetch rancher-<CHART_REPO>/rancher
|
||||
```
|
||||
You can fetch the chart for the specific version you are upgrading to by adding in the `--version=` tag. For example:
|
||||
|
||||
|
||||
```plain
|
||||
helm fetch rancher-<CHART_REPO>/rancher --version=v2.4.11
|
||||
```
|
||||
@@ -125,7 +129,7 @@ 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>
|
||||
<TabItem label="Kubernetes Upgrade">
|
||||
<TabItem value="Kubernetes Upgrade">
|
||||
|
||||
Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
|
||||
|
||||
@@ -168,7 +172,7 @@ helm upgrade rancher rancher-<CHART_REPO>/rancher \
|
||||
|
||||
### Option B: Reinstalling Rancher and cert-manager
|
||||
|
||||
If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
|
||||
If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
|
||||
|
||||
1. Uninstall Rancher
|
||||
|
||||
@@ -186,9 +190,9 @@ If you are currently running the cert-manager whose version is older than v0.11,
|
||||
--set hostname=rancher.my.org
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="Kubernetes Air Gap Upgrade">
|
||||
</TabItem>
|
||||
<TabItem value="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.
|
||||
|
||||
|
||||
+7
-4
@@ -9,10 +9,13 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/install-rancher/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
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>
|
||||
<TabItem label="Kubernetes Install (Recommended)">
|
||||
<TabItem value="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.
|
||||
|
||||
@@ -230,11 +233,11 @@ These resources could be helpful when installing Rancher:
|
||||
- [Troubleshooting Rancher Kubernetes Installations]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/troubleshooting/)
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Docker Install">
|
||||
<TabItem value="Docker Install">
|
||||
|
||||
The Docker installation is for Rancher users who want to test out Rancher.
|
||||
The Docker installation is for Rancher users who want 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.
|
||||
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:** 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.
|
||||
|
||||
|
||||
+10
-4
@@ -5,18 +5,21 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/install-kube
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
> Skip this section if you are installing Rancher on a single node with Docker.
|
||||
|
||||
This section describes how to install a Kubernetes cluster according to our [best practices for the Rancher server environment.]({{<baseurl>}}/rancher/v2.0-v2.4/en/overview/architecture-recommendations/#environment-for-kubernetes-installations) This cluster should be dedicated to run only the Rancher server.
|
||||
|
||||
For Rancher before v2.4, Rancher should be installed on an [RKE]({{<baseurl>}}/rke/latest/en/) (Rancher Kubernetes Engine) Kubernetes cluster. RKE is a CNCF-certified Kubernetes distribution that runs entirely within Docker containers.
|
||||
|
||||
In Rancher v2.4, the Rancher management server can be installed on either an RKE cluster or a K3s Kubernetes cluster. K3s is also a fully certified Kubernetes distribution released by Rancher, but is newer than RKE. We recommend installing Rancher on K3s because K3s is easier to use, and more lightweight, with a binary size of less than 100 MB. The Rancher management server can only be run on a Kubernetes cluster in an infrastructure provider where Kubernetes is installed using RKE or K3s. Use of Rancher on hosted Kubernetes providers, such as EKS, is not supported. Note: After Rancher is installed on an RKE cluster, there is no migration path to a K3s setup at this time.
|
||||
In Rancher v2.4, the Rancher management server can be installed on either an RKE cluster or a K3s Kubernetes cluster. K3s is also a fully certified Kubernetes distribution released by Rancher, but is newer than RKE. We recommend installing Rancher on K3s because K3s is easier to use, and more lightweight, with a binary size of less than 100 MB. The Rancher management server can only be run on a Kubernetes cluster in an infrastructure provider where Kubernetes is installed using RKE or K3s. Use of Rancher on hosted Kubernetes providers, such as EKS, is not supported. Note: After Rancher is installed on an RKE cluster, there is no migration path to a K3s setup at this time.
|
||||
|
||||
The steps to set up an air-gapped Kubernetes cluster on RKE or K3s are shown below.
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="K3s">
|
||||
<TabItem value="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.
|
||||
|
||||
@@ -96,7 +99,7 @@ The node-token is on the server at `/var/lib/rancher/k3s/server/node-token`
|
||||
|
||||
When you installed K3s on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/k3s/k3s.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
|
||||
|
||||
To use this `kubeconfig` file,
|
||||
To use this `kubeconfig` file,
|
||||
|
||||
1. Install [kubectl,](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) a Kubernetes command-line tool.
|
||||
2. Copy the file at `/etc/rancher/k3s/k3s.yaml` and save it to the directory `~/.kube/config` on your local machine.
|
||||
@@ -139,8 +142,10 @@ 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).
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="RKE">
|
||||
<TabItem value="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,6 +217,7 @@ 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._
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+7
-4
@@ -8,6 +8,9 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/config-rancher-for-private-reg/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This section describes how to set up your private registry so that when you install Rancher, Rancher will pull all the required images from this registry.
|
||||
|
||||
By default, all images used to [provision Kubernetes clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/) or launch any [tools]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/) in Rancher, e.g. monitoring, pipelines, alerts, are pulled from Docker Hub. In an air gapped installation of Rancher, you will need a private registry that is located somewhere accessible by your Rancher server. Then, you will load the registry with all the images.
|
||||
@@ -23,7 +26,7 @@ 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>
|
||||
<TabItem label="Linux Only Clusters">
|
||||
<TabItem value="Linux Only Clusters">
|
||||
|
||||
For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
|
||||
|
||||
@@ -54,7 +57,7 @@ If you will use ARM64 hosts, the registry must support manifests. As of April 20
|
||||
|
||||
> Skip this step if you are using your own certificates, or if you are terminating TLS on an external load balancer.
|
||||
|
||||
In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://hub.helm.sh/charts/jetstack/cert-manager) image to `rancher-images.txt` as well.
|
||||
In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://hub.helm.sh/charts/jetstack/cert-manager) image to `rancher-images.txt` as well.
|
||||
|
||||
1. Fetch the latest `cert-manager` Helm chart and parse the template for image details:
|
||||
|
||||
@@ -107,8 +110,9 @@ 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>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Linux and Windows Clusters">
|
||||
<TabItem value="Linux and Windows Clusters">
|
||||
|
||||
_Available as of v2.3.0_
|
||||
|
||||
@@ -289,7 +293,6 @@ chmod +x rancher-load-images.sh
|
||||
--registry <REGISTRY.YOURDOMAIN.COM:PORT>
|
||||
```
|
||||
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+10
-3
@@ -5,6 +5,9 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/air-gap-single-node/provision-host
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
In this section, you will provision the underlying infrastructure for your Rancher management server in an air gapped environment. You will also set up the private Docker registry that must be available to your Rancher node(s).
|
||||
|
||||
An air gapped environment is an environment where the Rancher server is installed offline or behind a firewall.
|
||||
@@ -12,7 +15,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>
|
||||
<TabItem label="K3s">
|
||||
<TabItem value="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 +86,9 @@ 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)
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="RKE">
|
||||
<TabItem value="RKE">
|
||||
|
||||
To install the Rancher management server on a high-availability RKE cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
@@ -146,8 +151,10 @@ 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)
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Docker">
|
||||
<TabItem value="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.
|
||||
|
||||
+6
-2
@@ -9,6 +9,9 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/upgrades/single-node/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
The following instructions will guide you through upgrading a Rancher server that was installed with Docker.
|
||||
|
||||
# Prerequisites
|
||||
@@ -130,7 +133,7 @@ To see the command to use when starting the new Rancher server container, choose
|
||||
- Docker Upgrade for Air Gap Installs
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Docker Upgrade">
|
||||
<TabItem value="Docker Upgrade">
|
||||
|
||||
Select which option you had installed Rancher server
|
||||
|
||||
@@ -238,7 +241,7 @@ docker run -d --volumes-from rancher-data \
|
||||
{{% /accordion %}}
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Docker Air Gap Upgrade">
|
||||
<TabItem value="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,6 +331,7 @@ docker run -d --volumes-from rancher-data \
|
||||
```
|
||||
|
||||
{{% /accordion %}}
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+9
-5
@@ -4,6 +4,9 @@ description: Learn the node requirements for each node running Rancher server wh
|
||||
weight: 1
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This page describes the software, hardware, and networking requirements for the nodes where the Rancher server will be installed. The Rancher server can be installed on a single node or a high-availability Kubernetes cluster.
|
||||
|
||||
> It is important to note that if you install Rancher on a Kubernetes cluster, requirements are different from the [node requirements for downstream user clusters,]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/node-requirements/) which will run your apps and services.
|
||||
@@ -64,7 +67,7 @@ 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>
|
||||
<TabItem label="RKE">
|
||||
<TabItem value="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 +83,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.
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="K3s">
|
||||
</TabItem>
|
||||
<TabItem value="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 +99,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.
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="Docker">
|
||||
</TabItem>
|
||||
<TabItem value="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,6 +110,7 @@ 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 |
|
||||
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+5
-2
@@ -11,10 +11,13 @@ aliases:
|
||||
- /rancher/v2.x/en/installation/resources/advanced/air-gap-helm2/install-rancher/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
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>
|
||||
<TabItem label="Kubernetes Install (Recommended)">
|
||||
<TabItem value="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.
|
||||
|
||||
@@ -223,7 +226,7 @@ These resources could be helpful when installing Rancher:
|
||||
- [Troubleshooting Rancher Kubernetes Installations]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/troubleshooting/)
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Docker Install">
|
||||
<TabItem value="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.
|
||||
|
||||
|
||||
+6
-2
@@ -11,6 +11,9 @@ aliases:
|
||||
- /rancher/v2.x/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
> **Prerequisites:** You must have a [private registry](https://docs.docker.com/registry/deploying/) available to use.
|
||||
>
|
||||
> **Note:** Populating the private registry with images is the same process for HA and Docker installations, the differences in this section is based on whether or not you are planning to provision a Windows cluster or not.
|
||||
@@ -22,7 +25,7 @@ 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>
|
||||
<TabItem label="Linux Only Clusters">
|
||||
<TabItem value="Linux Only Clusters">
|
||||
|
||||
For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
|
||||
|
||||
@@ -100,8 +103,9 @@ 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>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Linux and Windows Clusters">
|
||||
<TabItem value="Linux and Windows Clusters">
|
||||
|
||||
_Available as of v2.3.0_
|
||||
|
||||
|
||||
+9
-4
@@ -8,12 +8,15 @@ aliases:
|
||||
- /rancher/v2.x/en/installation/resources/advanced/air-gap-helm2/prepare-nodes/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This section is about how to prepare your node(s) to install 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.
|
||||
|
||||
# Prerequisites
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Kubernetes Install (Recommended)">
|
||||
<TabItem value="Kubernetes Install (Recommended)">
|
||||
|
||||
### OS, Docker, Hardware, and Networking
|
||||
|
||||
@@ -33,8 +36,9 @@ 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.
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Docker Install">
|
||||
<TabItem value="Docker Install">
|
||||
|
||||
### OS, Docker, Hardware, and Networking
|
||||
|
||||
@@ -45,13 +49,14 @@ 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/).
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Set up Infrastructure
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Kubernetes Install (Recommended)">
|
||||
<TabItem value="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.
|
||||
|
||||
@@ -87,7 +92,7 @@ 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 Amazon NLB load balancer, refer to [this page.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/nlb)
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Docker Install">
|
||||
<TabItem value="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.
|
||||
|
||||
|
||||
+8
-3
@@ -5,6 +5,9 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/options/server-tags
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This section describes how to choose a Rancher version.
|
||||
|
||||
For a high-availability installation of Rancher, which is recommended for production, the Rancher server is installed using a **Helm chart** on a Kubernetes cluster. 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.
|
||||
@@ -12,7 +15,7 @@ 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>
|
||||
<TabItem label="Helm Charts">
|
||||
<TabItem value="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 +80,10 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Docker Images">
|
||||
<TabItem value="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 +101,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.
|
||||
|
||||
</TabItem>
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+9
-2
@@ -5,6 +5,10 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/options/feature-flags/
|
||||
- /rancher/v2.0-v2.4/en/admin-settings/feature-flags/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Rancher includes some features that are experimental and disabled by default. You might want to enable these features, for example, if you decide that the benefits of using an [unsupported storage type]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/feature-flags/enable-not-default-storage-drivers) outweighs the risk of using an untested feature. Feature flags were introduced to allow you to try these features that are not enabled by default.
|
||||
|
||||
The features can be enabled in three ways:
|
||||
@@ -50,7 +54,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>
|
||||
<TabItem label="Kubernetes Install">
|
||||
<TabItem value="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 +104,10 @@ 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
|
||||
```
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Docker Install">
|
||||
<TabItem value="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:
|
||||
|
||||
```
|
||||
|
||||
+5
-2
@@ -7,6 +7,9 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/options/local-system-charts
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
The [System Charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS.
|
||||
|
||||
In an air gapped installation of Rancher, you will need to configure Rancher to use a local copy of the system charts. This section describes how to use local system charts using a CLI flag in Rancher v2.3.0, and using a Git mirror for Rancher versions before v2.3.0.
|
||||
@@ -30,7 +33,7 @@ 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>
|
||||
<TabItem label="Rancher UI">
|
||||
<TabItem value="Rancher UI">
|
||||
|
||||
In the catalog management page in the Rancher UI, follow these steps:
|
||||
|
||||
@@ -47,7 +50,7 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher API">
|
||||
<TabItem value="Rancher API">
|
||||
|
||||
1. Log into Rancher.
|
||||
|
||||
|
||||
@@ -2,9 +2,12 @@
|
||||
title: Pipelines
|
||||
weight: 11
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/k8s-in-rancher/pipelines
|
||||
- /rancher/v2.0-v2.4/en/k8s-in-rancher/pipelines
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Rancher's pipeline provides a simple CI/CD experience. Use it to automatically checkout code, run builds or scripts, publish Docker images or catalog applications, and deploy the updated software to users.
|
||||
|
||||
Setting up a pipeline can help developers deliver new software as quickly and efficiently as possible. Using Rancher, you can integrate with a GitHub repository to setup a continuous integration (CI) pipeline.
|
||||
@@ -14,7 +17,7 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins
|
||||
- Build your application from code to image.
|
||||
- Validate your builds.
|
||||
- Deploy your build images to your cluster.
|
||||
- Run unit tests.
|
||||
- Run unit tests.
|
||||
- Run regression tests.
|
||||
|
||||
>**Notes:**
|
||||
@@ -96,7 +99,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>
|
||||
<TabItem label="GitHub">
|
||||
<TabItem value="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 +113,9 @@ Select your provider's tab below and follow the directions.
|
||||
|
||||
1. Click **Authenticate**.
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="GitLab">
|
||||
<TabItem value="GitLab">
|
||||
|
||||
_Available as of v2.1.0_
|
||||
|
||||
@@ -127,10 +132,11 @@ _Available as of v2.1.0_
|
||||
1. Click **Authenticate**.
|
||||
|
||||
>**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+.
|
||||
> 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.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Bitbucket Cloud">
|
||||
<TabItem value="Bitbucket Cloud">
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
@@ -146,8 +152,9 @@ _Available as of v2.2.0_
|
||||
|
||||
1. Click **Authenticate**.
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Bitbucket Server">
|
||||
<TabItem value="Bitbucket Server">
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
@@ -169,6 +176,7 @@ _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).
|
||||
>
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
@@ -213,7 +221,7 @@ Now that repositories are added to your project, you can start configuring the p
|
||||
|
||||
1. Set up the trigger rules for the pipeline.
|
||||
|
||||
1. Enter a **Timeout** for the pipeline.
|
||||
1. Enter a **Timeout** for the pipeline.
|
||||
|
||||
1. When all the stages and steps are configured, click **Done**.
|
||||
|
||||
|
||||
@@ -5,6 +5,9 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/k8s-in-rancher/pipelines/storage
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
The pipelines' internal Docker registry and the Minio workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.
|
||||
|
||||
This section assumes that you understand how persistent storage works in Kubernetes. For more information, refer to the section on [how storage works.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/volumes-and-storage/how-storage-works/)
|
||||
@@ -25,35 +28,26 @@ 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>
|
||||
<TabItem label="Add a new persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
<Tabs>
|
||||
<TabItem value="Add a new persistent volume">
|
||||
|
||||
1. Select a volume claim **Source**:
|
||||
1. Enter a **Name** for the volume claim.
|
||||
1. Select a volume claim **Source**:
|
||||
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
|
||||
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
|
||||
1. From the **Customize** section, choose the read/write access for the volume.
|
||||
1. Click **Define**.
|
||||
|
||||
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
|
||||
</TabItem>
|
||||
<TabItem value="Use an existing persistent volume">
|
||||
|
||||
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
|
||||
1. From the **Customize** section, choose the read/write access for the volume.
|
||||
1. Enter a **Name** for the volume claim.
|
||||
1. Choose a **Persistent Volume Claim** from the drop-down.
|
||||
1. From the **Customize** section, choose the read/write access for the volume.
|
||||
1. Click **Define**.
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="Use an existing persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
1. Choose a **Persistent Volume Claim** from the drop-down.
|
||||
|
||||
1. From the **Customize** section, choose the read/write access for the volume.
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
</TabItem>
|
||||
|
||||
</Tabs>
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container.
|
||||
|
||||
@@ -69,34 +63,26 @@ 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>
|
||||
<TabItem value="Add a new persistent volume">
|
||||
|
||||
<TabItem label="Add a new persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
1. Enter a **Name** for the volume claim.
|
||||
1. Select a volume claim **Source**:
|
||||
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
|
||||
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
|
||||
1. From the **Customize** section, choose the read/write access for the volume.
|
||||
1. Click **Define**.
|
||||
|
||||
1. Select a volume claim **Source**:
|
||||
</TabItem>
|
||||
<TabItem value="Use an existing persistent volume">
|
||||
|
||||
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
|
||||
1. Enter a **Name** for the volume claim.
|
||||
1. Choose a **Persistent Volume Claim** from the drop-down.
|
||||
1. From the **Customize** section, choose the read/write access for the volume.
|
||||
1. Click **Define**.
|
||||
|
||||
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
|
||||
1. From the **Customize** section, choose the read/write access for the volume.
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Use an existing persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
1. Choose a **Persistent Volume Claim** from the drop-down.
|
||||
|
||||
1. From the **Customize** section, choose the read/write access for the volume.
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container.
|
||||
|
||||
|
||||
+6
-5
@@ -5,6 +5,9 @@ aliases:
|
||||
- /rancher/v2.x/en/v1.6-migration/monitor-apps/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Rancher v1.6 provided TCP and HTTP health checks on your nodes and services using its own health check microservice. These health checks monitored your containers to confirm they're operating as intended. If a container failed a health check, Rancher would destroy the unhealthy container and then replicates a healthy one to replace it.
|
||||
|
||||
For Rancher v2.x, we've replaced the health check microservice, leveraging instead Kubernetes' native health check support.
|
||||
@@ -92,8 +95,7 @@ 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>
|
||||
|
||||
<TabItem label="TCP Check">
|
||||
<TabItem value="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 +131,9 @@ When you configure a readiness check using Rancher v2.x, the `readinessProbe` di
|
||||
|
||||
-->
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="HTTP Check">
|
||||
</TabItem>
|
||||
<TabItem value="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).
|
||||
|
||||
@@ -142,7 +144,6 @@ 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.
|
||||
|
||||
</TabItem>
|
||||
|
||||
</Tabs>
|
||||
|
||||
### Configuring Separate Liveness Checks
|
||||
|
||||
+8
-8
@@ -5,6 +5,9 @@ aliases:
|
||||
- /rancher/v2.x/en/v1.6-migration/run-migration-tool/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Although your services from v1.6 won't work in Rancher v2.x by default, that doesn't mean you have to start again from square one, manually rebuilding your applications in v2.x. To help with migration from v1.6 to v2.x, Rancher has developed a migration tool. The migration-tools CLI is a utility that helps you recreate your applications in Rancher v2.x. This tool exports your Rancher v1.6 services as Compose files and converts them to a Kubernetes manifest that Rancher v2.x can consume.
|
||||
|
||||
Additionally, for each Rancher v1.6-specific Compose directive that cannot be consumed by Kubernetes, migration-tools CLI provides instructions on how to manually recreate them in Rancher v2.x.
|
||||
@@ -122,7 +125,7 @@ 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>
|
||||
<TabItem label="web-deployment.yaml">
|
||||
<TabItem value="web-deployment.yaml">
|
||||
|
||||
```YAML
|
||||
apiVersion: extensions/v1beta1
|
||||
@@ -160,7 +163,7 @@ status: {}
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="web-service.yaml">
|
||||
<TabItem value="web-service.yaml">
|
||||
|
||||
```YAML
|
||||
apiVersion: v1
|
||||
@@ -188,7 +191,7 @@ status:
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="database-deployment.yaml">
|
||||
<TabItem value="database-deployment.yaml">
|
||||
|
||||
```YAML
|
||||
apiVersion: extensions/v1beta1
|
||||
@@ -225,8 +228,6 @@ status: {}
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
|
||||
|
||||
</Tabs>
|
||||
|
||||
-->
|
||||
@@ -236,7 +237,7 @@ 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>
|
||||
<TabItem label="Rancher UI">
|
||||
<TabItem value="Rancher UI">
|
||||
|
||||
You can deploy the Kubernetes manifests created by migration-tools by importing them into Rancher v2.x.
|
||||
|
||||
@@ -249,8 +250,7 @@ You can deploy the Kubernetes manifests created by migration-tools by importing
|
||||

|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Rancher CLI">
|
||||
|
||||
<TabItem value="Rancher CLI">
|
||||
|
||||
>**Prerequisite:** [Install Rancher CLI]({{<baseurl>}}/rancher/v2.0-v2.4/en/cli/) for Rancher v2.x.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user