Merge pull request #3917 from rancher/master-to-staging

Master to staging
2026-05-18 10:55:21 +00:00 · 2022-02-28 12:46:32 -05:00
parent 99509db56d 7757603c54
commit 318ca4d194
87 changed files with 445 additions and 189 deletions
@@ -0,0 +1,39 @@
+# Configuration for probot-stale - https://github.com/probot/stale
+
+# Number of days of inactivity before an Issue or Pull Request becomes stale
+daysUntilStale: 90
+
+# Number of days of inactivity before an Issue or Pull Request with the stale label is closed.
+# Set to false to disable. If disabled, issues still need to be closed manually, but will remain marked as stale.
+daysUntilClose: 30
+
+# Only issues or pull requests with all of these labels are check if stale. Defaults to `[]` (disabled)
+onlyLabels: []
+
+# Issues or Pull Requests with these labels will never be considered stale. Set to `[]` to disable
+exemptLabels: []
+
+# Set to true to ignore issues in a project (defaults to false)
+exemptProjects: true
+
+# Set to true to ignore issues in a milestone (defaults to false)
+exemptMilestones: true
+
+# Set to true to ignore issues with an assignee (defaults to false)
+exemptAssignees: true
+
+# Label to use when marking as stale
+staleLabel: status/stale
+
+# Comment to post when marking as stale. Set to `false` to disable
+markComment: >
+  This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label)
+  for 90 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the
+  issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the
+  latest release), the bot will automatically close the issue in 30 days. Thank you for your contributions.
+
+# Limit the number of actions per hour, from 1-30. Default is 30
+limitPerRun: 30
+
+# Limit to only `issues`
+only: issues
@@ -1,4 +1,4 @@
-FROM node:8-alpine
+FROM node:16-alpine

 RUN apk update && apk add py-pygments bash git asciidoc gcompat && rm -rf /var/cache/apk/*

@@ -57,7 +57,7 @@ These options can be passed in with the command line, or in the [configuration f
 | Options | Description |
 | ----------- | --------------- |
 | `--etcd-disable-snapshots` | Disable automatic etcd snapshots |
-| `--etcd-snapshot-schedule-cron` value  |  Snapshot interval time in cron spec. eg. every 5 hours `* */5 * * *`(default: `0 */12 * * *`) |
+| `--etcd-snapshot-schedule-cron` value  |  Snapshot interval time in cron spec. eg. every 5 hours `0 */5 * * *`(default: `0 */12 * * *`) |
 | `--etcd-snapshot-retention` value  | Number of snapshots to retain (default: 5) |
 | `--etcd-snapshot-dir` value  | Directory to save db snapshots. (Default location: `${data-dir}/db/snapshots`) |
 | `--cluster-reset`  | Forget all peers and become sole member of a new cluster. This can also be set with the environment variable `[$K3S_CLUSTER_RESET]`.
@@ -96,8 +96,9 @@ metadata:
  namespace: kube-system
 spec:
  valuesContent: |-
-    image: traefik
-    imageTag: v1.7.26-alpine
+    image:
+      name: traefik
+      tag: v2.6.1
    proxyProtocol:
      enabled: true
      trustedIPs:
@@ -3,7 +3,7 @@ title: "Disable Components Flags"
 weight: 60
 ---

-When starting K3s server with --cluster-init it will run all control plane components that includes (api server, controller manager, scheduler, and etcd). However you can run server nodes with certain components and execlude others, the following sections will explain how to do that.
+Starting the K3s server with `--cluster-init` will run all control plane components, including the api server, controller manager, scheduler, and etcd. However, you can run server nodes with certain components and exclude others; the following sections will explain how to do that.

 # ETCD Only Nodes

@@ -29,3 +29,6 @@ There are a few config flags that must be the same in all server nodes:
 * Network related flags: `--cluster-dns`, `--cluster-domain`, `--cluster-cidr`, `--service-cidr`
 * Flags controlling the deployment of certain components: `--disable-helm-controller`, `--disable-kube-proxy`, `--disable-network-policy` and any component passed to `--disable`
 * Feature related flags: `--secrets-encryption`
+
+## Existing clusters
+If you have an existing cluster using the default embedded SQLite database, you can convert it to etcd by simply restarting your K3s server with the `--cluster-init` flag. Once you've done that, you'll be able to add additional instances as described above.
@@ -9,6 +9,26 @@ A persistent volume (PV) is a piece of storage in the Kubernetes cluster, while

 This page describes how to set up persistent storage with a local storage provider, or with [Longhorn.](#setting-up-longhorn)

+# What's changed in K3s storage?
+
+K3s removes several optional volume plugins and all built-in (sometimes referred to as "in-tree") cloud providers. We do this in order to achieve a smaller binary size and to avoid dependence on third-party cloud or data center technologies and services, which may not be available in many K3s use cases. We are able to do this because their removal affects neither core Kubernetes functionality nor conformance.
+
+The following volume plugins have been removed from K3s:
+
+* cephfs
+* fc
+* flocker
+* git_repo
+* glusterfs
+* portworx
+* quobyte
+* rbd
+* storageos
+
+Both components have out-of-tree alternatives that can be used with K3s: The Kubernetes [Container Storage Interface (CSI)](https://github.com/container-storage-interface/spec/blob/master/spec.md) and [Cloud Provider Interface (CPI)](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/).
+
+Kubernetes maintainers are actively migrating in-tree volume plugins to CSI drivers. For more information on this migration, please refer [here](https://kubernetes.io/blog/2021/12/10/storage-in-tree-to-csi-migration-status-update/).
+
 # Setting up the Local Storage Provider
 K3s comes with Rancher's Local Path Provisioner and this enables the ability to create persistent volume claims out of the box using local storage on the respective node. Below we cover a simple example. For more information please reference the official documentation [here](https://github.com/rancher/local-path-provisioner/blob/master/README.md#usage).

@@ -1,5 +1,5 @@
 ---
-title: v2.0-v2.4.x
+title: Rancher 2.0-2.4
 weight: 3
 showBreadcrumb: false
 ---
@@ -1,8 +1,8 @@
 ---
-title: "Rancher v2.0-v2.4"
+title: "Rancher 2.0-2.4"
 shortTitle: "Rancher 2.0-2.4"
 description: "Rancher adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
-metaTitle: "Rancher 2.x Docs: What is New?"
+metaTitle: "Rancher 2.0-2.4 Docs: What is New?"
 metaDescription: "Rancher 2 adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
 insertOneSix: true
 weight: 1
@@ -18,4 +18,4 @@ Rancher adds significant value on top of Kubernetes, first by centralizing authe

 It then enables detailed monitoring and alerting for clusters and their resources, ships logs to external providers, and integrates directly with Helm via the Application Catalog. If you have an external CI/CD system, you can plug it into Rancher, but if you don't, Rancher even includes a pipeline engine to help you automatically deploy and upgrade workloads.

-Rancher is a _complete_ container management platform for Kubernetes, giving you the tools to successfully run Kubernetes anywhere.
+Rancher is a _complete_ container management platform for Kubernetes, giving you the tools to successfully run Kubernetes anywhere.
@@ -50,20 +50,20 @@ You can fill your custom catalogs with either Helm Charts or Rancher Charts, alt
        - CMS
        questions:
        - variable: persistence.enabled
-        default: "false"
-        description: "Enable persistent volume for WordPress"
-        type: boolean
-        required: true
-        label: WordPress Persistent Volume Enabled
-        show_subquestion_if: true
-        group: "WordPress Settings"
-        subquestions:
-        - variable: persistence.size
+          default: "false"
+          description: "Enable persistent volume for WordPress"
+          type: boolean
+          required: true
+          label: WordPress Persistent Volume Enabled
+          show_subquestion_if: true
+          group: "WordPress Settings"
+          subquestions:
+          - variable: persistence.size
            default: "10Gi"
            description: "WordPress Persistent Volume Size"
            type: string
            label: WordPress Volume Size
-        - variable: persistence.storageClass
+          - variable: persistence.storageClass
            default: ""
            description: "If undefined or null, uses the default StorageClass. Default to null"
            type: storageclass
@@ -196,7 +196,7 @@ helm install rancher rancher-<CHART_REPO>/rancher \
  --namespace cattle-system \
  --set hostname=rancher.my.org \
  --set ingress.tls.source=letsEncrypt \
-  --set letsEncrypt.email=me@example.org
+  --set letsEncrypt.email=me@example.org \
 ```

 Wait for Rancher to be rolled out:
@@ -126,7 +126,7 @@ To customize or use a different ingress with Rancher server you can set your own
 Example on setting a custom certificate issuer:

 ```plain
--set ingress.extraAnnotations.'certmanager\.k8s\.io/cluster-issuer'=ca-key-pair
+--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
 ```

 Example on setting a static proxy header with `ingress.configurationSnippet`. This value is parsed like a template so variables can be used.
@@ -168,7 +168,7 @@ helm upgrade rancher rancher-<CHART_REPO>/rancher \

 ### Option B: Reinstalling Rancher and cert-manager

-If you are currently running the cert-manger 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-manger due to the API change in cert-manger 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

@@ -114,7 +114,7 @@ helm upgrade --install rancher rancher-<CHART_REPO>/rancher \

 {{% accordion label="Option B: Reinstalling Rancher chart" %}}

-If you are currently running the cert-manger 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-manger due to the API change in cert-manger 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

@@ -3,7 +3,7 @@ title: Installing Docker
 weight: 1
 ---

-For Helm CLI installs, Docker is required to be installed on any node that runs the Rancher server.
+Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker.

 There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.

@@ -131,7 +131,12 @@ deployment "rancher" successfully rolled out

 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. This configuration uses HTTP validation (`HTTP-01`) so the load balancer must have a public DNS record and be accessible from the internet.

- Set `hostname` to the public DNS record, set `ingress.tls.source` to `letsEncrypt` and `letsEncrypt.email` to the email address used for communication about your certificate (for example, expiry notices)
+In the following command,
+
+- Set `hostname` to the public DNS record that resolves to your load balancer.
+- Set `ingress.tls.source` to `letsEncrypt`.
+- Set `letsEncrypt.email` to the email address used for communication about your certificate (for example, expiry notices).
+- Set `letsEncrypt.ingress.class` to whatever your ingress controller is, e.g., `traefik`, `nginx`, `haproxy`, etc.
 - If you are installing an alpha version, Helm requires adding the `--devel` option to the command. 

 ```
@@ -140,7 +145,8 @@ helm install rancher-<CHART_REPO>/rancher \
  --namespace cattle-system \
  --set hostname=rancher.my.org \
  --set ingress.tls.source=letsEncrypt \
-  --set letsEncrypt.email=me@example.org
+  --set letsEncrypt.email=me@example.org \ 
+  --set letsEncrypt.ingress.class=nginx
 ```

 Wait for Rancher to be rolled out:
@@ -107,7 +107,7 @@ When installing Rancher with Docker, use the `--features` option. In the below e
 docker run -d -p 80:80 -p 443:443 \
  --restart=unless-stopped \
  rancher/rancher:rancher-latest \
-  --features=<FEATURE-FLAG-NAME-1>=true,<FEATURE-NAME-2>=true # Available as of v2.3.0
+  --features=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true # Available as of v2.3.0
 ```

 {{% /tab %}}
@@ -1,20 +0,0 @@
---
-title: Installing Docker
-weight: 1
-aliases:
-  - /rancher/v2.0-v2.4/en/installation/requirements/installing-docker
---
-
-Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker.
-
-There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.
-
-Another option is to use one of Rancher's Docker installation scripts, which are available for most recent versions of Docker.
-
-For example, this command could be used to install Docker 19.03 on Ubuntu:
-
-```
-curl https://releases.rancher.com/install-docker/19.03.sh | sh
-```
-
-Rancher has installation scripts for every version of upstream Docker that Kubernetes supports. To find out whether a script is available for installing a certain Docker version, refer to this [GitHub repository,](https://github.com/rancher/install-docker) which contains all of Rancher's Docker installation scripts.
@@ -19,7 +19,7 @@ To address these changes, this guide will do two things:
 1. Explain the cert-manager API changes and link to cert-manager's official documentation for migrating your data

 > **Important:**
-> If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
+> 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, you need to reinstall both of them:

 > 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
 > 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
@@ -19,7 +19,7 @@ To address these changes, this guide will do two things:
 1. Explain the cert-manager API changes and link to cert-manager's offficial documentation for migrating your data

 > **Important:**
-> If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
+> 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, you need to reinstall both of them:

 > 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
 > 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
@@ -37,7 +37,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and

 - **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/) on existing nodes, or perform [Kubernetes upgrades.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/upgrading-kubernetes)
 - **Catalog management:** Rancher provides the ability to use a [catalog of Helm charts]({{<baseurl>}}/rancher/v2.0-v2.4/en/catalog/) that make it easy to repeatedly deploy applications.
- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{<baseurl>}}/rancher/v2.0-v2.4/en/project-admin/) and for [managing applications within projects.]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/)
+- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you to manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{<baseurl>}}/rancher/v2.0-v2.4/en/project-admin/) and for [managing applications within projects.]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/)
 - **Pipelines:** Setting up a [pipeline]({{<baseurl>}}/rancher/v2.0-v2.4/en/project-admin/pipelines/) can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects.
 - **Istio:** Our [integration with Istio]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/) is designed so that a Rancher operator, such as an administrator or cluster owner, can deliver Istio to developers. Then developers can use Istio to enforce security policies, troubleshoot problems, or manage traffic for green/blue deployments, canary deployments, or A/B testing.

@@ -43,4 +43,4 @@ For details on project-level logging, see [this section.](./project-logging)

 _Available as of v2.2.0_

-Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. For details, refer to the [monitoring section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/monitoring)
+Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. For details, refer to the [monitoring section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-monitoring)
@@ -1,5 +1,5 @@
 ---
-title: Rancher 2.5.7-2.5.9
+title: Rancher 2.5
 weight: 2
 showBreadcrumb: false
 ---
@@ -2,7 +2,7 @@
 title: "Rancher 2.5"
 shortTitle: "Rancher 2.5"
 description: "Rancher adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
-metaTitle: "Rancher 2.5.7-2.5.9 Docs: What is New?"
+metaTitle: "Rancher 2.5 Docs: What is New?"
 metaDescription: "Rancher 2 adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
 insertOneSix: false
 weight: 2
@@ -21,13 +21,19 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes
 - [K3s Kubernetes installation docs]({{<baseurl>}}/k3s/latest/en/installation/)

 ### 1. Install the rancher-backup Helm chart
-Install version 1.x.x of the rancher-backup chart.
+Install version 1.x.x of the rancher-backup chart. The following assumes a connected environment with access to DockerHub:
+
 ```
 helm repo add rancher-charts https://charts.rancher.io
 helm repo update
 helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
 helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
 ```
+</br>
+For an **air-gapped environment**, use the option below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup-crd helm chart.
+```
+--set image.repository $REGISTRY/rancher/backup-restore-operator
+``` 

 ### 2. Restore from backup using a Restore custom resource

@@ -19,9 +19,12 @@ If you encounter this issue, you can work around it by installing the initiator

 After installing the initiator tool on your nodes, edit the YAML for your cluster, editing the kubelet configuration to mount the iSCSI binary and configuration, as shown in the sample below.

->**Note:**
+>**Notes:**
+>  
+>- Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.</br>
+></br>
 >
->Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.
+>- The example YAML below does not apply to K3s, but only to RKE clusters. Since the K3s kubelet does not run in a container, adding extra binds is not necessary. However, all iSCSI tools must still be installed on your K3s nodes.

 ```
 services:
@@ -23,13 +23,13 @@ The control that Rancher has to manage a registered cluster depends on the type
 {{% tabs %}}
 {{% tab "v2.5.9+" %}}

-## Kubernetes Node Roles
+### Kubernetes Node Roles

 Registered RKE Kubernetes clusters must have all three node roles - etcd, controlplane and worker. A cluster with only controlplane components cannot be registered in Rancher.

 For more information on RKE node roles, see the [best practices.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/production/#cluster-architecture)

-## Permissions
+### Permissions

 If your existing Kubernetes cluster already has a `cluster-admin` role defined, you must have this `cluster-admin` privilege to register the cluster in Rancher.

@@ -47,10 +47,14 @@ By default, GKE users are not given this privilege, so you will need to run the

 If you are registering a K3s cluster, make sure the `cluster.yml` is readable. It is protected by default. For details, refer to [Configuring a K3s cluster to enable importation to Rancher.](#configuring-a-k3s-cluster-to-enable-registration-in-rancher)

+### EKS Clusters
+
+EKS clusters must have at least one managed node group to be imported into Rancher or provisioned from Rancher successfully.
+
 {{% /tab %}}
 {{% tab "Rancher before v2.5.9" %}}

-## Permissions
+### Permissions

 If your existing Kubernetes cluster already has a `cluster-admin` role defined, you must have this `cluster-admin` privilege to register the cluster in Rancher.

@@ -67,6 +71,11 @@ before running the `kubectl` command to register the cluster.
 By default, GKE users are not given this privilege, so you will need to run the command before registering GKE clusters. To learn more about role-based access control for GKE, please click [here](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control).

 If you are registering a K3s cluster, make sure the `cluster.yml` is readable. It is protected by default. For details, refer to [Configuring a K3s cluster to enable importation to Rancher.](#configuring-a-k3s-cluster-to-enable-registration-in-rancher)
+
+### EKS Clusters
+
+EKS clusters must have at least one managed node group to be imported into Rancher or provisioned from Rancher successfully.
+
 {{% /tab %}}
 {{% /tabs %}}

@@ -110,6 +119,34 @@ The option can also be specified using the environment variable `K3S_KUBECONFIG_
 $ curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -s -
 ```

+### Configuring an Imported EKS Cluster with Terraform
+
+You should define **only** the minimum fields that Rancher requires when importing an EKS cluster with Terraform. This is important as Rancher will overwrite what was in the EKS cluster with any config that the user has provided. 
+
+>**Warning:** Even a small difference between the current EKS cluster and a user-provided config could have unexpected results.
+
+The minimum config fields required by Rancher to import EKS clusters with Terraform using `eks_config_v2` are as follows:
+
+- cloud_credential_id
+- name
+- region
+- imported (this field should always be set to `true` for imported clusters)
+
+Example YAML configuration for imported EKS clusters:
+
+```
+resource "rancher2_cluster" "my-eks-to-import" {
+  name        = "my-eks-to-import"
+  description = "Terraform EKS Cluster"
+  eks_config_v2 {
+    cloud_credential_id = rancher2_cloud_credential.aws.id
+    name                = var.aws_eks_name
+    region              = var.aws_region
+    imported            = true
+  }
+}
+```
+
 # Management Capabilities for Registered Clusters

 The control that Rancher has to manage a registered cluster depends on the type of cluster.
@@ -17,7 +17,7 @@ In this section,
 - **RKE (Rancher Kubernetes Engine)** is a certified Kubernetes distribution and CLI/library which creates and manages a Kubernetes cluster.
 - **K3s (Lightweight Kubernetes)** is also a fully compliant Kubernetes distribution. It is newer than RKE, easier to use, and more lightweight, with a binary size of less than 100 MB.
 - **RKE2** is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
- **RancherD** is a new tool for installing Rancher, which is available as of Rancher v2.5.4. It is an experimental feature. RancherD is a single binary that first launches an RKE2 Kubernetes cluster, then installs the Rancher server Helm chart on the cluster.
+- **RancherD** was an experimental tool for installing Rancher; a single binary that first launched an RKE2 Kubernetes cluster, then installed the Rancher server Helm chart on the cluster. It was available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.

 # Changes to Installation in Rancher v2.5

@@ -37,9 +37,7 @@ We recommend using Helm, a Kubernetes package manager, to install Rancher on mul

 ### High-availability Kubernetes Install with RancherD

-_Available as of v2.5.4_
-
-> This is an experimental feature.
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.

 RancherD is a single binary that first launches an RKE2 Kubernetes cluster, then installs the Rancher server Helm chart on the cluster.

@@ -190,7 +190,7 @@ deployment "rancher" successfully rolled out

 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.

->**Note:**: You need to have port 80 open as the HTTP-01 challenge can only be done on port 80.
+>**Note:** You need to have port 80 open as the HTTP-01 challenge can only be done on port 80.

 In the following command,

@@ -198,6 +198,7 @@ In the following command,
 - Set `replicas` to the number of replicas to use for the Rancher Deployment. This defaults to 3; if you have less than 3 nodes in your cluster you should reduce it accordingly.
 - Set `ingress.tls.source` to `letsEncrypt`.
 - Set `letsEncrypt.email` to the email address used for communication about your certificate (for example, expiry notices).
+- Set `letsEncrypt.ingress.class` to whatever your ingress controller is, e.g., `traefik`, `nginx`, `haproxy`, etc.
 - To install a specific Rancher version, use the `--version` flag, example: `--version 2.3.6`.
 - If you are installing an alpha version, Helm requires adding the `--devel` option to the command. 

@@ -207,7 +208,8 @@ helm install rancher rancher-<CHART_REPO>/rancher \
  --set hostname=rancher.my.org \
  --set replicas=3 \
  --set ingress.tls.source=letsEncrypt \
-  --set letsEncrypt.email=me@example.org
+  --set letsEncrypt.email=me@example.org \
+  --set letsEncrypt.ingress.class=nginx
 ```

 Wait for Rancher to be rolled out:
@@ -124,7 +124,7 @@ To customize or use a different ingress with Rancher server you can set your own
 Example on setting a custom certificate issuer:

 ```plain
--set ingress.extraAnnotations.'certmanager\.k8s\.io/cluster-issuer'=ca-key-pair
+--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
 ```

 Example on setting a static proxy header with `ingress.configurationSnippet`. This value is parsed like a template so variables can be used.
@@ -165,7 +165,7 @@ helm upgrade rancher rancher-<CHART_REPO>/rancher \

 ### Option B: Reinstalling Rancher and cert-manager

-If you are currently running the cert-manger 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-manger due to the API change in cert-manger 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

@@ -6,9 +6,7 @@ aliases:
  - /rancher/v2.x/en/installation/install-rancher-on-linux/
 ---

-_Available as of Rancher v2.5.4_
-
-> This is an experimental feature.
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.

 We are excited to introduce a new, simpler way to install Rancher called RancherD.

@@ -6,7 +6,7 @@ aliases:
  - /rancher/v2.x/en/installation/install-rancher-on-linux/rancherd-configuration/
 ---

-> RancherD is an experimental feature.
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.

 In RancherD, a server node is defined as a machine (bare-metal or virtual) running the `rancherd server` command. The server runs the Kubernetes API as well as Kubernetes workloads.

@@ -22,7 +22,7 @@ In the RancherD installation instructions, we recommend running three server nod

 # Certificates for the Rancher Server

-Rancherd does not use cert-manger to provision certs. Instead RancherD allows you to bring your own self-signed or trusted certs by storing the .pem files in `/etc/rancher/ssl/`. When doing this you should also set the `publicCA` parameter to `true` in your HelmChartConfig. For more information on the HelmChartConfig, refer to the section about [customizing the RancherD Helm chart.](#customizing-the-rancherd-helm-chart)
+Rancherd does not use cert-manager to provision certs. Instead RancherD allows you to bring your own self-signed or trusted certs by storing the .pem files in `/etc/rancher/ssl/`. When doing this you should also set the `publicCA` parameter to `true` in your HelmChartConfig. For more information on the HelmChartConfig, refer to the section about [customizing the RancherD Helm chart.](#customizing-the-rancherd-helm-chart)

 Private key: `/etc/rancher/ssl/key.pem`

@@ -6,6 +6,6 @@ aliases:
  - /rancher/v2.x/en/installation/install-rancher-on-linux/rollbacks/
 ---

-> RancherD is an experimental feature.
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.

 To roll back Rancher to a previous version, re-run the installation script with the previous version specified in the `INSTALL_RANCHERD_VERSION` environment variable.
@@ -6,7 +6,7 @@ aliases:
  - /rancher/v2.x/en/installation/install-rancher-on-linux/upgrades/
 ---

-> RancherD is an experimental feature.
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.

 When RancherD is upgraded, the Rancher Helm controller and the Fleet pods are upgraded.

@@ -80,7 +80,7 @@ If you are installing Rancher on a K3s cluster with Alpine Linux, follow [these

 ### RancherD Specific Requirements

-_The RancherD install is available as of v2.5.4. It is an experimental feature._
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.

 At this time, only Linux OSes that leverage systemd are supported.

@@ -103,6 +103,7 @@ The Ingress should be deployed as DaemonSet to ensure your load balancer can suc
 Docker is required for Helm chart installs, and it can be installed by following the steps in the official [Docker documentation.](https://docs.docker.com/) Rancher also provides [scripts]({{<baseurl>}}/rancher/v2.5/en/installation/requirements/installing-docker) to install Docker with one command.

 Docker is not required for RancherD installs.
+
 # Hardware Requirements

 The following sections describe the CPU, memory, and disk requirements for the nodes where the Rancher server is installed.
@@ -143,7 +144,7 @@ These CPU and memory requirements apply to each host in a [K3s Kubernetes cluste

 ### RancherD

-_RancherD is available as of v2.5.4. It is an experimental feature._
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.

 These CPU and memory requirements apply to each instance with RancherD installed. Minimum recommendations are outlined here.

@@ -3,7 +3,7 @@ title: Installing Docker
 weight: 1
 ---

-For Helm CLI installs, Docker is required to be installed on any node that runs the Rancher server.
+Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker.

 There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.

@@ -119,6 +119,8 @@ The following tables break down the port requirements for inbound and outbound t

 ### Ports for Rancher Server Nodes on RancherD or RKE2

+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
+
 {{% accordion label="Click to expand" %}}

 The RancherD (or RKE2) server needs port 6443 and 9345 to be accessible by other nodes in the cluster.
@@ -14,6 +14,8 @@ For Docker installations of Rancher, which is used for development and testing,

 The Helm chart version also applies to RancherD installs because RancherD installs the Rancher Helm chart on a Kubernetes cluster.

+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
+
 {{% tabs %}}
 {{% tab "Helm Charts" %}}

@@ -56,7 +56,7 @@ 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.

-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:
+When installing Rancher with a Helm chart, use the `--set` option. In the below example, two features are enabled by passing the feature flag names in a comma separated list:

 ```
 helm install rancher-latest/rancher \
@@ -131,7 +131,7 @@ When installing Rancher with Docker, use the `--features` option. In the below e
 docker run -d -p 80:80 -p 443:443 \
  --restart=unless-stopped \
  rancher/rancher:rancher-latest \
-  --features=<FEATURE-FLAG-NAME-1>=true,<FEATURE-NAME-2>=true 
+  --features=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true
 ```


@@ -1,20 +0,0 @@
---
-title: Installing Docker
-weight: 1
-aliases:
-  - /rancher/v2.5/en/installation/requirements/installing-docker
---
-
-Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker. Docker is not required for RancherD installs.
-
-There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.
-
-Another option is to use one of Rancher's Docker installation scripts, which are available for most recent versions of Docker.
-
-For example, this command could be used to install Docker 19.03 on Ubuntu:
-
-```
-curl https://releases.rancher.com/install-docker/19.03.sh | sh
-```
-
-Rancher has installation scripts for every version of upstream Docker that Kubernetes supports. To find out whether a script is available for installing a certain Docker version, refer to this [GitHub repository,](https://github.com/rancher/install-docker) which contains all of Rancher's Docker installation scripts.
@@ -20,7 +20,7 @@ To address these changes, this guide will do two things:
 1. Explain the cert-manager API changes and link to cert-manager's official documentation for migrating your data

 > **Important:**
-> If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
+> 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, you need to reinstall both of them:

 > 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
 > 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
@@ -18,7 +18,7 @@ To address these changes, this guide will do two things:
 1. Explain the cert-manager API changes and link to cert-manager's offficial documentation for migrating your data

 > **Important:**
-> If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
+> 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, you need to reinstall both of them:

 > 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
 > 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
@@ -39,7 +39,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and

 - **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/) on existing nodes, or perform [Kubernetes upgrades.]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/upgrading-kubernetes)
 - **Catalog management:** Rancher provides the ability to use a [catalog of Helm charts]({{<baseurl>}}/rancher/v2.5/en/catalog/) that make it easy to repeatedly deploy applications.
- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{<baseurl>}}/rancher/v2.5/en/project-admin/) and for [managing applications within projects.]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/)
+- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you to manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{<baseurl>}}/rancher/v2.5/en/project-admin/) and for [managing applications within projects.]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/)
 - **Pipelines:** Setting up a [pipeline]({{<baseurl>}}/rancher/v2.5/en/project-admin/pipelines/) can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects.
 - **Istio:** Our [integration with Istio]({{<baseurl>}}/rancher/v2.5/en/istio/) is designed so that a Rancher operator, such as an administrator or cluster owner, can deliver Istio to developers. Then developers can use Istio to enforce security policies, troubleshoot problems, or manage traffic for green/blue deployments, canary deployments, or A/B testing.

@@ -1,5 +1,5 @@
 ---
-title: v2.6.x
+title: Rancher 2.6
 weight: 1
 showBreadcrumb: false
 ---
@@ -2,7 +2,7 @@
 title: "Rancher 2.6"
 shortTitle: "Rancher 2.6  (Latest)"
 description: "Rancher adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
-metaTitle: "Rancher 2.x Docs: What is New?"
+metaTitle: "Rancher 2.6 Docs: What is New?"
 metaDescription: "Rancher 2 adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
 insertOneSix: false
 weight: 1
@@ -25,6 +25,8 @@ To require new clusters to use an RKE template, administrators can turn on RKE t
 1. Go to the `cluster-template-enforcement` setting. Click **⋮ > Edit Setting**.
 1. Set the value to **True** and click **Save**.

+    >**Important:** When the admin sets the `cluster-template-enforcement` to <b>True</b>, they also need to share the `clusterTemplates` with users so that users can select one of these templates to create the cluster.
+
 **Result:** All clusters provisioned by Rancher must use a template, unless the creator is an administrator.

 # Disabling RKE Template Enforcement
@@ -9,7 +9,7 @@ If you are migrating Rancher to a new Kubernetes cluster, you don't need to inst

 These instructions assume you have [created a backup](../back-up-rancher) and you have already installed a new Kubernetes cluster where Rancher will be deployed.

-It is required to use the same hostname that was set as the server URL in the first cluster.
+>**Warning:** It is required to use the same hostname that was set as the server URL in the first cluster. If not done, downstream clusters will show as unavailable in the cluster management page of the UI, and you won't be able to click inside the cluster or on the cluster's <b>Explore</b> button.

 Rancher version must be v2.5.0 and up

@@ -19,13 +19,18 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes
 - [K3s Kubernetes installation docs]({{<baseurl>}}/k3s/latest/en/installation/)

 ### 1. Install the rancher-backup Helm chart
-Install version 2.x.x of the rancher-backup chart.
+Install version 2.x.x of the rancher-backup chart. The following assumes a connected environment with access to DockerHub:
 ```
 helm repo add rancher-charts https://charts.rancher.io
 helm repo update
 helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
 helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
 ```
+</br>
+For an **air-gapped environment**, use the option below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup-crd helm chart.
+```
+--set image.repository $REGISTRY/rancher/backup-restore-operator
+```

 ### 2. Restore from backup using a Restore custom resource

@@ -36,7 +41,9 @@ helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-sy
 >
 > - Note that when making or restoring backups for v1.22, the Rancher version and the local cluster's Kubernetes version should be the same. The Kubernetes version should be considered when restoring a backup since the supported apiVersion in the cluster and in the backup file could be different.

-If you are using an S3 store as the backup source, and need to use your S3 credentials for restore, create a secret in this cluster using your S3 credentials. The Secret data must have two keys, `accessKey` and `secretKey` containing the s3 credentials like this:
+If you are using an S3 store as the backup source and need to use your S3 credentials for restore, create a secret in this cluster using your S3 credentials. The Secret data must have two keys - `accessKey` and `secretKey` - that contain the S3 credentials.
+
+**Warning:** The values `accessKey` and `secretKey` in the example below must be base64-encoded first when creating the object directly. If not encoded first, the pasted values will cause errors when you are attempting to backup or restore.

 ```yaml
 apiVersion: v1
@@ -49,7 +56,7 @@ stringData:
  secretKey: <Enter your base64-encoded secret key>
 ```

-This secret can be created in any namespace, with the above example it will get created in the default namespace
+This secret can be created in any namespace; with the above example, it will get created in the default namespace.

 In the Restore custom resource, `prune` must be set to false. 

@@ -103,13 +103,13 @@ The address range assigned to the services in the cluster. Must be a valid CIDR

 _Mutable: no_

-> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/gke/private-clusters/).
+> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/).

 Assign nodes only internal IP addresses. Private cluster nodes cannot access the public internet unless additional networking steps are taken in GCP.

 ### Enable Private Endpoint

-> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/gke/#private-clusters).
+> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/).

 _Mutable: no_

@@ -8,7 +8,7 @@ This section covers the configuration options that are available in Rancher for

 # Overview

-You can configure the Kubernetes options one of two ways:
+You can configure the Kubernetes options in one of the two following ways:

 - [Rancher UI](#configuration-options-in-the-rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster.
 - [Cluster Config File](#cluster-config-file): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE2 config file. Using a config file allows you to set any of the [options](https://docs.rke2.io/install/install_options/install_options) available in an RKE2 installation.
@@ -28,15 +28,17 @@ For more detail, see [Upgrading Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluste

 The [Network Provider](https://kubernetes.io/docs/concepts/cluster-administration/networking/) that the cluster uses.

-> After you launch the cluster, you cannot change your network provider. Therefore, choose which network provider you want to use carefully, as Kubernetes doesn't allow switching between network providers. Once a cluster is created with a network provider, changing network providers would require you  tear down the entire cluster and all its applications.
+> After you launch the cluster, you cannot change your network provider. Therefore, choose which network provider you want to use carefully, as Kubernetes doesn't allow switching between network providers. Once a cluster is created with a network provider, changing network providers would require you to tear down the entire cluster and all its applications.

 Out of the box, Rancher is compatible with the following network providers:

 - [Canal](https://github.com/projectcalico/canal)
- [Cilium](https://cilium.io/)
+- [Cilium](https://cilium.io/)*
 - [Calico](https://docs.projectcalico.org/v3.11/introduction/)
 - [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)

+\* When using [project network isolation](#project-network-isolation) in the [Cilium CNI]({{<baseurl>}}/rancher/v2.6/en/faq/networking/cni-providers/#cilium), it is possible to enable cross-node ingress routing. Click the [CNI provider docs]({{<baseurl>}}/rancher/v2.6/en/faq/networking/cni-providers/#ingress-routing-across-nodes-in-cilium) to learn more.
+
 For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/install/network_options/).

 #### Cloud Provider
@@ -81,7 +83,7 @@ Each cloud provider capable of launching a cluster using RKE2 can collect metric

 ### Add-On Config

-Additional Kubernetes manifests, managed as a [Add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/), to apply to the cluster on startup. Refer to the [RKE2 documentation](https://docs.rke2.io/helm/#automatically-deploying-manifests-and-helm-charts) for details.
+Additional Kubernetes manifests, managed as an [Add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/), to apply to the cluster on startup. Refer to the [RKE2 documentation](https://docs.rke2.io/helm/#automatically-deploying-manifests-and-helm-charts) for details.

 ### Agent Environment Vars

@@ -139,7 +141,7 @@ Select the image repository to pull Rancher images from. For more details and co

 ### Upgrade Strategy

-#### Controle Plane Concurrency
+#### Control Plane Concurrency

 Select how many nodes can be upgraded at the same time. Can be a fixed number or percentage.

@@ -17,9 +17,12 @@ If you encounter this issue, you can work around it by installing the initiator

 After installing the initiator tool on your nodes, edit the YAML for your cluster, editing the kubelet configuration to mount the iSCSI binary and configuration, as shown in the sample below.

->**Note:**
+>**Notes:**
+>  
+>- Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.</br>
+></br> 
 >
->Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.
+>- The example YAML below does not apply to K3s, but only to RKE clusters. Since the K3s kubelet does not run in a container, adding extra binds is not necessary. However, all iSCSI tools must still be installed on your K3s nodes.

 ```
 services:
@@ -20,6 +20,7 @@ This section covers the following topics:
  - [Launching Kubernetes and Provisioning Nodes in an Infrastructure Provider](#launching-kubernetes-and-provisioning-nodes-in-an-infrastructure-provider)
  - [Launching Kubernetes on Existing Custom Nodes](#launching-kubernetes-on-existing-custom-nodes)
 - [Registering Existing Clusters](#registering-existing-clusters)
+- [Programmatically Creating Clusters](#programmatically-creating-clusters)

  <!-- /TOC -->

@@ -78,3 +79,9 @@ Registering EKS clusters now provides additional benefits. For the most part, re
 When you delete an EKS cluster that was created in Rancher, the cluster is destroyed. When you delete an EKS cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher.

 For more information, see [this page.](./registered-clusters)
+
+# Programmatically Creating Clusters
+
+The most common way to programmatically deploy Kubernetes clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
+
+EKS, GKE, AKS clusters and RKE clusters can be created or imported with Terraform.
@@ -16,6 +16,7 @@ You can use Rancher to create a cluster hosted in Microsoft Azure Kubernetes Ser
 - [Private Clusters](#private-clusters)
 - [Minimum AKS Permissions](#minimum-aks-permissions)
 - [Syncing](#syncing)
+- [Programmatically Creating AKS Clusters](#programmatically-creating-aks-clusters)

 # Prerequisites in Microsoft Azure

@@ -152,3 +153,7 @@ For more information about connecting to an AKS private cluster, see the [AKS do
 The AKS provisioner can synchronize the state of an AKS cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/syncing)

 For information on configuring the refresh interval, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/#configuring-the-refresh-interval)
+
+# Programmatically Creating AKS Clusters
+
+The most common way to programmatically deploy AKS clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
@@ -17,6 +17,7 @@ Amazon EKS provides a managed control plane for your Kubernetes cluster. Amazon
 - [Minimum EKS Permissions](#minimum-eks-permissions)
 - [Syncing](#syncing)
 - [Troubleshooting](#troubleshooting)
+- [Programmatically Creating EKS Clusters](#programmatically-creating-eks-clusters)
 # Prerequisites in Amazon Web Services

 >**Note**
@@ -108,4 +109,8 @@ If your changes were overwritten, it could be due to the way the cluster data is

 If an unauthorized error is returned while attempting to modify or register the cluster and the cluster was not created with the role or user that your credentials belong to, refer to [Security and Compliance.](#security-and-compliance)

-For any issues or troubleshooting details for your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html).
+For any issues or troubleshooting details for your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html).
+
+# Programmatically Creating EKS Clusters
+
+The most common way to programmatically deploy EKS clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
@@ -10,6 +10,7 @@ weight: 2105
 - [Configuration Reference](#configuration-reference)
 - [Updating Kubernetes Version](#updating-kubernetes-version)
 - [Syncing](#syncing)
+- [Programmatically Creating GKE Clusters](#programmatically-creating-gke-clusters)

 # Prerequisites

@@ -98,3 +99,6 @@ The GKE provisioner can synchronize the state of a GKE cluster between Rancher a

 For information on configuring the refresh interval, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/#configuring-the-refresh-interval)

+# Programmatically Creating GKE Clusters
+
+The most common way to programmatically deploy GKE clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
@@ -17,13 +17,13 @@ The control that Rancher has to manage a registered cluster depends on the type

 # Prerequisites

-## Kubernetes Node Roles
+### Kubernetes Node Roles

 Registered RKE Kubernetes clusters must have all three node roles - etcd, controlplane and worker. A cluster with only controlplane components cannot be registered in Rancher.

 For more information on RKE node roles, see the [best practices.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production/#cluster-architecture)

-## Permissions
+### Permissions

 If your existing Kubernetes cluster already has a `cluster-admin` role defined, you must have this `cluster-admin` privilege to register the cluster in Rancher.

@@ -41,12 +41,16 @@ By default, GKE users are not given this privilege, so you will need to run the

 If you are registering a K3s cluster, make sure the `cluster.yml` is readable. It is protected by default. For details, refer to [Configuring a K3s cluster to enable importation to Rancher.](#configuring-a-k3s-cluster-to-enable-registration-in-rancher)

+### EKS Clusters
+
+EKS clusters must have at least one managed node group to be imported into Rancher or provisioned from Rancher successfully.
+
 # Registering a Cluster

 1. Click **☰ > Cluster Management**.
 1. On the **Clusters** page, **Import Existing**.
-1. Enter a **Cluster Name**.
 1. Choose the type of cluster.
+1. Enter a **Cluster Name**.
 4. 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.
 5. If it is a generic custom cluster, use **Agent Environment Variables** under **Cluster Options** to set environment variables for [rancher cluster agent]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
 6. Click **Create**.
@@ -82,6 +86,34 @@ The option can also be specified using the environment variable `K3S_KUBECONFIG_
 $ curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -s -
 ```

+### Configuring an Imported EKS Cluster with Terraform
+
+You should define **only** the minimum fields that Rancher requires when importing an EKS cluster with Terraform. This is important as Rancher will overwrite what was in the EKS cluster with any config that the user has provided.
+
+>**Warning:** Even a small difference between the current EKS cluster and a user-provided config could have unexpected results.
+
+The minimum config fields required by Rancher to import EKS clusters with Terraform using `eks_config_v2` are as follows:
+
+- cloud_credential_id
+- name
+- region
+- imported (this field should always be set to `true` for imported clusters)
+
+Example YAML configuration for imported EKS clusters:
+
+```
+resource "rancher2_cluster" "my-eks-to-import" {
+  name        = "my-eks-to-import"
+  description = "Terraform EKS Cluster"
+  eks_config_v2 {
+    cloud_credential_id = rancher2_cloud_credential.aws.id
+    name                = var.aws_eks_name
+    region              = var.aws_region
+    imported            = true
+  }
+}
+```
+
 # Management Capabilities for Registered Clusters

 The control that Rancher has to manage a registered cluster depends on the type of cluster.
@@ -168,7 +200,7 @@ Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and
 >
 > - The following steps will work on both RKE2 and K3s clusters registered in v2.6.x as well as those registered (or imported) from a previous version of Rancher with an upgrade to v2.6.x.
 >
-> - These steps will alter the configuration of the downstream RKE2 and K3s clusters and deploy the `kube-api-authn-webhook`. If a future implementation of ACE requires an update to the `kube-api-authn-webhook`, then this would also have to be done manually. For more information on this webhook, click [here]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/ace/#about-the-kube-api-auth-authentication-webhook).
+> - These steps will alter the configuration of the downstream RKE2 and K3s clusters and deploy the `kube-api-authn-webhook`. If a future implementation of the ACE requires an update to the `kube-api-authn-webhook`, then this would also have to be done manually. For more information on this webhook, click [here]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/ace/#about-the-kube-api-auth-authentication-webhook).

 ###### **Manual steps to be taken on the control plane of each downstream cluster to enable ACE:**

@@ -197,11 +229,15 @@ Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and
        kube-apiserver-arg:
            - authentication-token-webhook-config-file=/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml
        
-1. Finally, run the following commands:
+1. Run the following commands:

        sudo systemctl stop {rke2,k3s}-server
        sudo systemctl start {rke2,k3s}-server

+1. Finally, you **must** go back to the Rancher UI and edit the imported cluster there to complete the ACE enablement. Click on **⋮ > Edit Config**, then click the **Networking** tab under Cluster Configuration. Finally, click the **Enabled** button for **Authorized Endpoint**. Once the ACE is enabled, you then have the option of entering a fully qualified domain name (FQDN) and certificate information.  
+      
+      >**Note:** The <b>FQDN</b> field is optional, and if one is entered, it should point to the downstream cluster. Certificate information is only needed if there is a load balancer in front of the downstream cluster that is using an untrusted certificate. If you have a valid certificate, then nothing needs to be added to the <b>CA Certificates</b> field.
+
 # Annotating Registered Clusters

 For all types of registered Kubernetes clusters except for K3s Kubernetes clusters, Rancher doesn't have any information about how the cluster is provisioned or configured.
@@ -54,3 +54,7 @@ In this scenario, you want to install Kubernetes on bare-metal servers, on-prem
 If you want to reuse a node from a previous custom cluster, [clean the node]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cleaning-cluster-nodes/) before using it in a cluster again. If you reuse a node that hasn't been cleaned, cluster provisioning may fail.

 For more information, refer to the section on [custom nodes.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes/)
+
+# Programmatically Creating RKE Clusters
+
+The most common way to programmatically deploy RKE clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
@@ -28,7 +28,7 @@ This guide covers the following topics:
 - [Configuration for Storage Classes in Azure](#configuration-for-storage-classes-in-azure)
  <!-- /TOC -->

-  # Changes in Rancher v2.6
+# Changes in Rancher v2.6

 _Tech Preview_

@@ -43,6 +43,8 @@ The RKE2 provisioning tech preview also includes installing RKE2 on Windows clus

 Windows Support for RKE2 Custom Clusters requires choosing Calico as the CNI.

+>**Important:** Rancher will allow Windows workload pods to deploy on both Windows and Linux worker nodes by default. When creating mixed clusters in RKE2, you must edit the `nodeSelector` in the chart to direct the pods to be placed onto a compatible Windows node. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) for more information on how to use `nodeSelector` to assign pods to nodes.
+
 # Requirements for Windows Clusters

 The general node requirements for networking, operating systems, and Docker are the same as the node requirements for a [Rancher installation]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/).
@@ -11,7 +11,7 @@ The following chart describes the feature parity between Windows and Linux on Ra
 --- | --- | ---
 **Distributions** |  | 
 RKE | Supported | Supported
-RKE2 | Supported | Tenatively Planned For 2.6.x
+RKE2 | Supported | In Preview in Rancher 2.6.0, General Availability Planned for Rancher 2.6.4
 K3S | Supported | Not Supported
 EKS | Supported | Not Supported
 GKE | Supported | Not Supported
@@ -38,7 +38,7 @@ Backup/Restore Operator | Supported | Not Supported
 **CNI / Add-ons** |  | 
 Flannel | Supported | Supported
 Canal | Supported | Not Supported
-Calico | Supported | Tentatively Planned for 2.6.x
+Calico | Supported | In Preview in Rancher 2.6.0, General Availability Planned for Rancher 2.6.4
 Cilium | Supported | Not Supported
 Multus | Supported | Not Supported
 Traefik | Supported | Not Supported
@@ -0,0 +1,46 @@
+---
+title: Dockershim
+weight: 300
+---
+
+The Dockershim is the CRI compliant layer between the Kubelet and the Docker daemon. As part of the Kubernetes 1.20 release, the [deprecation of the in-tree Dockershim was announced](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/). Removal is currently scheduled for Kubernetes 1.24. For more information on the deprecation and its timelines, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
+
+RKE clusters, starting with Kubernetes 1.21, now support the external Dockershim to continue leveraging Docker as the CRI runtime. We now implement the upstream open source community Dockershim announced by [Mirantis and Docker](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) to ensure RKE clusters can continue to leverage Docker.
+
+To enable the external Dockershim, configure the following option.
+
+```
+enable_cri_dockerd: true
+```
+
+For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher even after the removal of in-tree Dockershim in Kubernetes 1.24.
+
+### FAQ
+
+<br>
+
+Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?  
+
+The upstream support of Dockershim begins for RKE in Kubernetes 1.21. You will need to be on Rancher 2.6 or above to have support for RKE with Kubernetes 1.21. See our [support matrix](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/) for details.
+
+<br> 
+
+Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?   
+
+A. The version of Dockershim in RKE with Kubernetes 1.20 will continue to work and is not scheduled for removal upstream until Kubernetes 1.24. It will only emit a warning of its future deprecation, which Rancher has mitigated in RKE with Kubernetes 1.21. You can plan your upgrade to Kubernetes 1.21 as you would normally, but should consider enabling the external Dockershim by Kubernetes 1.22. The external Dockershim will need to be enabled before upgrading to Kubernetes 1.24, at which point the existing implementation will be removed.
+
+For more information on the deprecation and its timeline, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
+
+<br>
+
+Q: What are my other options if I don’t want to depend on the Dockershim? 
+
+A: You can use a runtime like containerd with Kubernetes that does not require Dockershim support. RKE2 or K3s are two options for doing this.
+
+<br>
+
+Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?  
+
+A: Rancher is exploring the possibility of an in-place upgrade path. Alternatively you can always migrate workloads from one cluster to another using kubectl. 
+
+<br>
@@ -58,7 +58,7 @@ Canal is a CNI network provider that gives you the best of Flannel and Calico. I

 In Rancher, Canal is the default CNI network provider combined with Flannel and VXLAN encapsulation.

-Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (healthcheck). For details, refer to [the port requirements for user clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/)
+Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (health checks). If using Wireguard, you should open UDP ports `51820` and `51821`. For more details, refer to [the port requirements for user clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/).

 {{< img "/img/rancher/canal-diagram.png" "Canal Diagram">}}

@@ -75,7 +75,7 @@ Encapsulated traffic is unencrypted by default. Flannel provides two solutions f
 * [IPSec](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#ipsec), which makes use of [strongSwan](https://www.strongswan.org/) to establish encrypted IPSec tunnels between Kubernetes workers. It is an experimental backend for encryption.
 * [WireGuard](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#wireguard), which is a more faster-performing alternative to strongSwan.

-Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (healthcheck). See [the port requirements for user clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/#networking-requirements) for more details.
+Kubernetes workers should open UDP port `8472` (VXLAN). See [the port requirements for user clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/#networking-requirements) for more details.

 ![Flannel Diagram]({{<baseurl>}}/img/rancher/flannel-diagram.png)

@@ -107,7 +107,7 @@ Calico enables networking and network policy in Kubernetes clusters across the c

 Calico also provides a stateless IP-in-IP or VXLAN encapsulation mode that can be used, if necessary. Calico also offers policy isolation, allowing you to secure and govern your Kubernetes workloads using advanced ingress and egress policies.

-Kubernetes workers should open TCP port `179` (BGP). See [the port requirements for user clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/#networking-requirements) for more details.
+Kubernetes workers should open TCP port `179` if using BGP or UDP port `4789` if using VXLAN encapsulation. In addition, TCP port `5473` is needed when using Typha. See [the port requirements for user clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/#networking-requirements) for more details.

 ![Calico Diagram]({{<baseurl>}}/img/rancher/calico-diagram.svg)

@@ -122,7 +122,26 @@ For more information, see the following pages:

 Cilium enables networking and network policies (L3, L4, and L7) in Kubernetes. By default, Cilium uses eBPF technologies to route packets inside the node and VXLAN to send packets to other nodes. Unencapsulated techniques can also be configured. 

-Cilium recommends kernel versions greater than 5.2 to be able to leverage the full potential of eBPF. Kubernetes workers should open TCP port `8472` for VXLAN and TCP port `4140` for health checks. In addition, ICMP 8/0 must be enabled for health checks. For more information, check [Cilium System Requirements](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements).
+Cilium recommends kernel versions greater than 5.2 to be able to leverage the full potential of eBPF. Kubernetes workers should open TCP port `8472` for VXLAN and TCP port `4240` for health checks. In addition, ICMP 8/0 must be enabled for health checks. For more information, check [Cilium System Requirements](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements).
+
+##### Ingress Routing Across Nodes in Cilium
+<br>
+By default, Cilium does not allow pods to contact pods on other nodes. To work around this, enable the ingress controller to route requests across nodes with a `CiliumNetworkPolicy`.
+
+After selecting the Cilium CNI and enabling Project Network Isolation for your new cluster, configure as follows:
+
+```
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: hn-nodes
+  namespace: default
+spec:
+  endpointSelector: {} 
+  ingress:
+    - fromEntities:
+      - remote-node
+```

 ## CNI Features by Provider

@@ -181,7 +181,7 @@ deployment "rancher" successfully rolled out

 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.

->**Note:**: You need to have port 80 open as the HTTP-01 challenge can only be done on port 80.
+>**Note:** You need to have port 80 open as the HTTP-01 challenge can only be done on port 80.

 In the following command,

@@ -189,6 +189,7 @@ In the following command,
 - Set the `bootstrapPassword` to something unique for the `admin` user.
 - `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)
+- Set `letsEncrypt.ingress.class` to whatever your ingress controller is, e.g., `traefik`, `nginx`, `haproxy`, etc.
 - If you are installing an alpha version, Helm requires adding the `--devel` option to the command. 

 ```
@@ -197,7 +198,8 @@ helm install rancher rancher-<CHART_REPO>/rancher \
  --set hostname=rancher.my.org \
  --set bootstrapPassword=admin \
  --set ingress.tls.source=letsEncrypt \
-  --set letsEncrypt.email=me@example.org
+  --set letsEncrypt.email=me@example.org \
+  --set letsEncrypt.ingress.class=nginx
 ```

 Wait for Rancher to be rolled out:
@@ -137,7 +137,7 @@ To customize or use a different ingress with Rancher server you can set your own
 Example on setting a custom certificate issuer:

 ```plain
--set ingress.extraAnnotations.'certmanager\.k8s\.io/cluster-issuer'=ca-key-pair
+--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
 ```

 Example on setting a static proxy header with `ingress.configurationSnippet`. This value is parsed like a template so variables can be used.
@@ -148,7 +148,7 @@ helm upgrade rancher rancher-<CHART_REPO>/rancher \

 ### Option B: Reinstalling Rancher and cert-manager

-If you are currently running the cert-manger 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-manger due to the API change in cert-manger 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

@@ -180,12 +180,4 @@ To operate properly, Rancher requires a number of ports to be open on Rancher no

 # Dockershim Support

-In Kubernetes v1.20, the dockershim became deprecated, and Docker became deprecated as a container runtime for Kubernetes. Dockershim was built into Kubernetes as a type of adapter that allowed Kubernetes to manage Docker containers. It was necessary because the Docker Daemon was not compliant with the CRI (Container Runtime Interface) that was created for Kubernetes. The dockershim is still included in the kubelet in Kubernetes v1.20. 
-
-Rancher plans to implement the [upstream open source community Dockershim announced by Mirantis and Docker](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) to ensure RKE clusters can continue to leverage Docker as their container runtime. Users of RKE will be able to continue upgrading and building new RKE clusters leveraging Docker as the runtime and install method.
-
-For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher going forward.
-
-For more information on the deprecation of Docker as a container runtime for Kubernetes, see the [official Kubernetes blog post](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/) and the [official blog post from Mirantis.](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/)
-
-The dockershim deprecation schedule is tracked by the upstream Kubernetes community in [Kubernetes Enhancement Proposal (KEP) 1985.](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim) 
+For more information on Dockershim support, refer to [this page]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/dockershim/).
@@ -0,0 +1,44 @@
+---
+title: Dockershim
+weight: 300
+---
+
+The Dockershim is the CRI compliant layer between the Kubelet and the Docker daemon. As part of the Kubernetes 1.20 release, the [deprecation of the in-tree Dockershim was announced](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/). For more information on the deprecation and its timelines, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
+
+RKE clusters now support the external Dockershim to continue leveraging Docker as the CRI runtime. We now implement the upstream open source community external Dockershim announced by [Mirantis and Docker](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) to ensure RKE clusters can continue to leverage Docker.
+
+To enable the external Dockershim, configure the following option.
+
+```
+enable_cri_dockerd: true
+```
+
+For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher going forward.
+
+### FAQ
+
+<br>
+
+Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?  
+
+A The upstream support of Dockershim begins for RKE in Kubernetes 1.21. You will need to be on a version of Rancher that supports RKE 1.21. See our support matrix for details.
+
+<br> 
+
+Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?   
+
+A. The version of Dockershim in RKE with Kubernetes 1.20 will continue to work and it is not deprecated until a later release. For information on the timeline, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed). It will only emit a warning of its future deprecation, which Rancher has mitigated in RKE with Kubernetes 1.21. You can plan your upgrade to 1.21 as you would normally.
+
+<br>
+
+Q: What are my other options if I don’t want to depend on the Dockershim? 
+
+A: You can use a runtime like containerd with Kubernetes that does not require Dockershim support. RKE2 or K3s are two options for doing this.
+
+<br>
+
+Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?  
+
+A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path. 
+
+<br>
@@ -3,7 +3,7 @@ title: Installing Docker
 weight: 1
 ---

-For Helm CLI installs, Docker is required to be installed on any node that runs the Rancher server.
+Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker.

 There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.

@@ -88,6 +88,7 @@ The following tables break down the port requirements for traffic between the Ra
 | TCP | 2379 | etcd client requests |
 | TCP | 2380 | etcd peer communication |
 | TCP | 6443 | Kubernetes apiserver |
+| TCP | 8443 | Nginx Ingress's Validating Webhook |
 | UDP | 8472 | Canal/Flannel VXLAN overlay networking |
 | TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
 | TCP | 10250 | Metrics server communication with all nodes |
@@ -26,12 +26,12 @@ For example, if you install Rancher, then set a feature flag to true with the Ra
 The following is a list of the feature flags available in Rancher:

 - `harvester`: This feature flag is available starting in v2.6.1. It is used to manage access to the Virtualization Management page where users can navigate directly to Harvester clusters and access the Harvester UI. For more information, see [this page]({{<baseurl>}}/rancher/v2.6/en/virtualization-admin/#feature-flag/).
- `rke2`: We have introduced the ability to provision RKE2 clusters as tech preview. By default, this feature flag is enabled, which allows users to attempt to provision these type of clusters. 
+- `rke2`: We have introduced the ability to provision RKE2 clusters as tech preview. By default, this feature flag is enabled, which allows users to attempt to provision these type of clusters.
 - `fleet`: The previous `fleet` feature flag is now required to be enabled as the Fleet capabilities are leveraged within the new provisioning framework. If you had this feature flag disabled in earlier versions, upon upgrading to Rancher v2.6, the flag will automatically be enabled. See this [page]({{<baseurl>}}/rancher/v2.6/en/deploy-across-clusters/fleet) for more information.
 - `continuous-delivery`: In Rancher v2.5.x, Fleet came with a GitOps feature that could not be disabled separately from Fleet. In Rancher v2.6, the `continuous-delivery` feature flag was introduced to allow the GitOps feature of Fleet to be disabled. For more information, see [this page.](./continuous-delivery).
 - `legacy`: There are a set of features from previous versions that are slowly being phased out of Rancher for newer iterations of the feature. This is a mix of deprecated features as well as features that will eventually be moved to newer variations in Rancher. By default, this feature flag is disabled for new installations. If you are upgrading from a previous version, this feature flag would be enabled.
 - `token-hashing`: Used to enable new token-hashing feature. Once enabled, existing tokens will be hashed and all new tokens will be hashed automatically using the SHA256 algorithm. Once a token is hashed it cannot be undone. Once this feature flag is enabled, it cannot be disabled. See [hashing of tokens]({{<baseurl>}}/rancher/v2.6/en/api/api-tokens) for more information.
- `unsupported-storage-drivers`: This feature [allows unsupported storage drivers.]({{<baseurl>}}/rancher/v2.6/en/installation/resources/feature-flags/enable-not-default-storage-drivers). In other words, it enables types for storage providers and provisioners that are not enabled by default. 
+- `unsupported-storage-drivers`: This feature [allows unsupported storage drivers.]({{<baseurl>}}/rancher/v2.6/en/installation/resources/feature-flags/enable-not-default-storage-drivers). In other words, it enables types for storage providers and provisioners that are not enabled by default.
 - `istio-virtual-service-ui`: This feature enables a [UI to create, read, update, and delete Istio virtual services and destination rules,]({{<baseurl>}}/rancher/v2.6/en/installation/resources/feature-flags/istio-virtual-service-ui) which are traffic management features of Istio.
 - `multi-cluster-management`: Used for multi-cluster provisioning and management of Kubernetes clusters. This feature flag can only be set at install time and not changed afterwards.

@@ -61,7 +61,7 @@ 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.

-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:
+When installing Rancher with a Helm chart, use the `--set` option. In the below example, two features are enabled by passing the feature flag names in a comma separated list:

 ```
 helm install rancher rancher-latest/rancher \
@@ -102,7 +102,7 @@ When installing Rancher with Docker, use the `--features` option. In the below e
 docker run -d -p 80:80 -p 443:443 \
  --restart=unless-stopped \
  rancher/rancher:rancher-latest \
-  --features=<FEATURE-FLAG-NAME-1>=true,<FEATURE-NAME-2>=true 
+  --features=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true
 ```


@@ -1,18 +0,0 @@
---
-title: Installing Docker
-weight: 1
---
-
-Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker.
-
-There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.
-
-Another option is to use one of Rancher's Docker installation scripts, which are available for most recent versions of Docker.
-
-For example, this command could be used to install Docker 19.03 on Ubuntu:
-
-```
-curl https://releases.rancher.com/install-docker/19.03.sh | sh
-```
-
-Rancher has installation scripts for every version of upstream Docker that Kubernetes supports. To find out whether a script is available for installing a certain Docker version, refer to this [GitHub repository,](https://github.com/rancher/install-docker) which contains all of Rancher's Docker installation scripts.
@@ -80,6 +80,8 @@ ingress:
 > Please see the [RKE Documentation]({{<baseurl>}}/rke/latest/en/config-options/) for the full list of options and capabilities.
 > 
 > For tuning your etcd cluster for larger Rancher installations, see the [etcd settings guide]({{<baseurl>}}/rancher/v2.6/en/installation/resources/advanced/etcd/).
+>
+> For more information regarding Dockershim support, refer to [this page]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/dockershim/)

 ### 2. Run RKE

@@ -15,7 +15,7 @@ To address these changes, this guide will do two things:
 1. Explain the cert-manager API changes and link to cert-manager's official documentation for migrating your data

 > **Important:**
-> If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
+> 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, you need to reinstall both of them:

 > 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
 > 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
@@ -38,7 +38,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and

 - **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/) on existing nodes, or perform [Kubernetes upgrades.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/upgrading-kubernetes)
 - **Catalog management:** Rancher provides the ability to use a [catalog of Helm charts]({{<baseurl>}}/rancher/v2.6/en/helm-charts/) that make it easy to repeatedly deploy applications.
- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{<baseurl>}}/rancher/v2.6/en/project-admin/) and for [managing applications within projects.]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/)
+- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you to manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{<baseurl>}}/rancher/v2.6/en/project-admin/) and for [managing applications within projects.]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/)
 - **Pipelines:** Setting up a [pipeline]({{<baseurl>}}/rancher/v2.6/en/project-admin/pipelines/) can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects.
 - **Istio:** Our [integration with Istio]({{<baseurl>}}/rancher/v2.6/en/istio/) is designed so that a Rancher operator, such as an administrator or cluster owner, can deliver Istio to developers. Then developers can use Istio to enforce security policies, troubleshoot problems, or manage traffic for green/blue deployments, canary deployments, or A/B testing.

@@ -110,4 +110,4 @@ If you are using an [authorized cluster endpoint (ACE),]({{<baseurl>}}/rancher/v

 If you are using private CA signed certificates on the load balancer, you have to supply the CA certificate, which will be included in the generated kubeconfig file to validate the certificate chain. See the documentation on [kubeconfig files]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/) and [API keys]({{<baseurl>}}/rancher/v2.6/en/user-settings/api-keys/#creating-an-api-key) for more information.

-As of Rancher v2.6.3, ACE support is available for registered RKE2 and K3s clusters. To view the manual steps to perform on the downstream cluster to enable the ACE, click [here]({{<baseurl>}}/v2.6/en/cluster-provisioning/registered-clusters/#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters).
+As of Rancher v2.6.3, ACE support is available for registered RKE2 and K3s clusters. To view the manual steps to perform on the downstream cluster to enable the ACE, click [here]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters).
@@ -109,7 +109,7 @@ An authorized cluster endpoint allows users to connect to the Kubernetes API ser

 > The authorized cluster endpoint only works on Rancher-launched Kubernetes clusters. In other words, it only works in clusters where Rancher [used RKE]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters) to provision the cluster. The ACE is not available for clusters in a hosted Kubernetes provider, such as Amazon's EKS.

-> The [ACE is available for registered RKE2 and K3s clusters]({{<baseurl>}}/v2.6/en/cluster-provisioning/registered-clusters/#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters) as of Rancher v2.6.3. 
+> The [ACE is available for registered RKE2 and K3s clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters) as of Rancher v2.6.3. 

 There are two main reasons why a user might need the authorized cluster endpoint:

@@ -5,12 +5,14 @@ weight: 100

 Use one of the following guides to deploy and provision Rancher and a Kubernetes cluster in the provider of your choice.

- [DigitalOcean](./digital-ocean-qs) (uses Terraform)
 - [AWS](./amazon-aws-qs) (uses Terraform)
+- [AWS Marketplace](./amazon-aws-marketplace-qs) (uses Amazon EKS)
 - [Azure](./microsoft-azure-qs) (uses Terraform)
+- [DigitalOcean](./digital-ocean-qs) (uses Terraform)
 - [GCP](./google-gcp-qs) (uses Terraform)
 - [Hetzner Cloud](./hetzner-cloud-qs) (uses Terraform)
 - [Vagrant](./quickstart-vagrant)
+- [Equinix Metal](./equinix-metal-qs)


 If you prefer, the following guide will take you through the same process in individual steps. Use this if you want to run Rancher in a different provider, on prem, or if you would just like to see how easy it is.
@@ -0,0 +1,7 @@
+---
+title: Rancher AWS Marketplace Quick Start
+description: Use Amazon EKS to deploy Rancher server.
+weight: 110
+---
+
+There is now an additional way for you to deploy the Rancher server in AWS by using Amazon EKS. To learn more, see our [Amazon Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-2yzbnvagmi4as).
@@ -53,11 +53,11 @@ Suggestions include:
 8. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
 9. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/aws`.

-#### Result
+##### Result

 Two Kubernetes clusters are deployed into your AWS account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.

-### What's Next?
+## What's Next?

 Use Rancher to create a deployment. For more information, see [Creating Deployments]({{<baseurl>}}/rancher/v2.6/en/quick-start-guide/workload).

@@ -1,7 +1,7 @@
 ---
 title: Rancher DigitalOcean Quick Start Guide
 description: Read this step by step Rancher DigitalOcean guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 100
+weight: 120
 ---
 The following steps will quickly deploy a Rancher server on DigitalOcean in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.

@@ -1,6 +1,6 @@
 ---
 title: Rancher Equinix Metal Quick Start
-weight: 300
+weight: 250
 ---

 ## This tutorial walks you through the following:
@@ -1,7 +1,7 @@
 ---
 title: Rancher GCP Quick Start Guide
 description: Read this step by step Rancher GCP guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 100
+weight: 130
 ---
 The following steps will quickly deploy a Rancher server on GCP in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.

@@ -1,7 +1,7 @@
 ---
 title: Rancher Hetzner Cloud Quick Start Guide
 description: Read this step by step Rancher Hetzner Cloud guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 100
+weight: 140
 ---
 The following steps will quickly deploy a Rancher server on Hetzner Cloud in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.

@@ -1,7 +1,7 @@
 ---
 title: Rancher Azure Quick Start Guide
 description: Read this step by step Rancher Azure guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 100
+weight: 115
 ---

 The following steps will quickly deploy a Rancher server on Azure in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
@@ -30,7 +30,7 @@ The following steps quickly deploy a Rancher Server with a single node cluster a

 4. To initiate the creation of the environment run, `vagrant up --provider=virtualbox`.

-5. Once provisioning finishes, go to `https://192.168.56.101` in the browser. The default user/password is `admin/admin`.
+5. Once provisioning finishes, go to `https://192.168.56.101` in the browser. The default user/password is `admin/adminPassword`.

 **Result:** Rancher Server and your Kubernetes cluster is installed on VirtualBox.

@@ -27,10 +27,9 @@ There are a few things worth noting:

 As of version v0.1.7, add-ons are split into two categories:

- **Critical add-ons:** If these add-ons fail to deploy for any reason, RKE will error out.
- **Non-critical add-ons:** If these add-ons fail to deploy, RKE will only log a warning and continue deploying any other add-ons.
+- **Critical add-ons:** If these add-ons fail to deploy for any reason, RKE will error out. All system add-ons, such as the [network plug-in]({{<baseurl>}}/rke/latest/en/config-options/add-ons/network-plugins/), KubeDNS, and [ingress controllers]({{<baseurl>}}/rke/latest/en/config-options/add-ons/ingress-controllers/), are considered critical.

-Currently, only the [network plug-in]({{<baseurl>}}/rke/latest/en/config-options/add-ons/network-plugins/) is considered critical. KubeDNS, [ingress controllers]({{<baseurl>}}/rke/latest/en/config-options/add-ons/ingress-controllers/) and [user-defined add-ons]({{<baseurl>}}/rke/latest/en/config-options/add-ons/user-defined-add-ons/) are considered non-critical.
+- **Non-critical add-ons:** If these add-ons fail to deploy, RKE will only log a warning and continue deploying any other add-ons. [User-defined add-ons]({{<baseurl>}}/rke/latest/en/config-options/add-ons/user-defined-add-ons/) are considered non-critical.

 # Add-on Deployment Jobs

@@ -106,14 +106,14 @@ OPTIONS:
 This command will perform the following actions:

 - Generate a new random 32-byte encryption key
- Generate a new provider configuration with the new key as the first provider and the second key as the second provider. When the secrets are rewritten, the first key will be used to encrypt the data on the write operation, while the second key (the old key) will be used to decrypt the stored data during the the read operation
+- Generate a new provider configuration with the new key as the first provider and the old key as the second provider. When the secrets are rewritten, the first key will be used to encrypt the data on the write operation, while the second key (the old key) will be used to decrypt the stored data during the the read operation
 - Deploy the new provider configuration to all `controlplane` nodes and restart the `kube-apiserver`
 - Rewrite all secrets. This process will re-encrypt all the secrets with the new key.
 - Update the configuration to remove the old key and restart the `kube-apiserver`

 ### Rotating Keys by Disabling and Re-enabling Encryption in cluster.yml

-For a cluster with encryption enabled, you can rotate the encryption keys by updating `cluster.yml`. If you enable and re-enable the data encryption in the `cluster.yml`, RKE will not reuse old keys. Instead, it will generate new keys every time, yielding the same result as a key rotation with the RKE CLI.
+For a cluster with encryption enabled, you can rotate the encryption keys by updating `cluster.yml`. If you disable and re-enable the data encryption in the `cluster.yml`, RKE will not reuse old keys. Instead, it will generate new keys every time, yielding the same result as a key rotation with the RKE CLI.

 # Custom At-Rest Data Encryption Configuration
 With managed configuration, RKE provides the user with a very simple way to enable and disable encryption with minimal interaction and configuration. However, it doesn't allow for any customization to the configuration.
@@ -15,11 +15,11 @@
    </div>

    <div class="head-blank">
-    
+
    </div>

    <div class="row max-sized contents-container background-base-gray-side">
-      
+
      {{ $url := urls.Parse .Permalink }}
      {{ $path := split $url.Path "/" }}
      {{ $product := index $path 1 }}
@@ -37,10 +37,15 @@
      {{end}}
      {{ if in .Dir "os/v1.x" }}
      <div class="alert alert-notice">
-          <strong>RancherOS 1.x is currently in a maintain-only-as-essential mode.</strong> It is no longer being actively maintained at a code level other than addressing critical or security fixes. For more information about the support status of RancherOS, see <a href="https://rancher.com/docs/os/v1.x/en/support/"> this page.</a> 
+          <strong>RancherOS 1.x is currently in a maintain-only-as-essential mode.</strong> It is no longer being actively maintained at a code level other than addressing critical or security fixes. For more information about the support status of RancherOS, see <a href="https://rancher.com/docs/os/v1.x/en/support/"> this page.</a>
      </div>
      {{end}}
-      
+      {{ if or (in .Dir "/v2.0-v2.4") (in .Dir "/v2.5") }}
+      <div class="alert alert-notice">
+          <strong>You are viewing the documentation for an older Rancher release.</strong> If you're looking for the documentation for the latest Rancher release, go to <a href="https://rancher.com/docs/rancher/v2.6/en/"> this page</a> instead.
+      </div>
+      {{end}}
+
      <div class="
        col-xl-3
        col-lg-4
@@ -248,4 +253,4 @@
    });
  });
 </script>
-{{ end }}
+{{ end }}