Merge branch 'main' into copilot/clarify-cluster-management-capabilities

clarify turtles/capi managed clusters, use imported not registered
Signed-off-by: Silvio Moioli <silvio@moioli.net>
2026-10-03 16:33:16 +00:00 · 2026-03-09 16:05:17 +01:00 · 2026-03-06 09:41:19 +01:00 · 2026-03-06 09:41:19 +01:00 · 2026-03-06 09:41:19 +01:00
2354 changed files with 10396 additions and 100697 deletions
@@ -1 +0,0 @@
-blank_issues_enabled: false
@@ -4,13 +4,6 @@ about: Track tasks that need to be done every release.
 title: '<VERSION> - Rancher Manager Release Maintenance Task Checklist'
 ---

-> [!IMPORTANT]
-> Hello, our team is currently in the process of consolidating our Rancher documentation repositories. With this change, the contents of this repository was moved to [rancher/rancher-product-docs](https://github.com/rancher/rancher-product-docs).
->
-> We understand this is a significant change and disruption to the standard process and wish to note the Rancher documentation team is here to assist in any way it can to make the transition process straight forward. Going forward, we kindly ask that any new issue reports or contributions be made to the `rancher-product-docs` repository instead. If you wish to make contributions, please refer to our updated [README](https://github.com/rancher/rancher-product-docs/blob/main/README.md) for guidance.
->
-> Please note as part of this change, the Chinese portion of the site was dropped. No URLs for the Community documentation site changed.
-
 This issue is to track tasks that need to be done every release regardless of whether the release has new feature content or not.

 - [ ] Create a new branch for the release. Release-specific updates should use this branch as its base
@@ -3,13 +3,6 @@ name: Request a New Feature
 about: For requesting new feature(s) to be added to the docs.
 ---

-> [!IMPORTANT]
-> Hello, our team is currently in the process of consolidating our Rancher documentation repositories. With this change, the contents of this repository was moved to [rancher/rancher-product-docs](https://github.com/rancher/rancher-product-docs).
->
-> We understand this is a significant change and disruption to the standard process and wish to note the Rancher documentation team is here to assist in any way it can to make the transition process straight forward. Going forward, we kindly ask that any new issue reports or contributions be made to the `rancher-product-docs` repository instead. If you wish to make contributions, please refer to our updated [README](https://github.com/rancher/rancher-product-docs/blob/main/README.md) for guidance.
->
-> Please note as part of this change, the Chinese portion of the site was dropped. No URLs for the Community documentation site changed.
-
 ## Related Issues

 <!--
@@ -3,13 +3,6 @@ name: Request an Update
 about: For fixing docs errors/typos, adding needed/missing information, updating verbiage, deleting outdated info, etc.
 ---

-> [!IMPORTANT]
-> Hello, our team is currently in the process of consolidating our Rancher documentation repositories. With this change, the contents of this repository was moved to [rancher/rancher-product-docs](https://github.com/rancher/rancher-product-docs).
->
-> We understand this is a significant change and disruption to the standard process and wish to note the Rancher documentation team is here to assist in any way it can to make the transition process straight forward. Going forward, we kindly ask that any new issue reports or contributions be made to the `rancher-product-docs` repository instead. If you wish to make contributions, please refer to our updated [README](https://github.com/rancher/rancher-product-docs/blob/main/README.md) for guidance.
->
-> Please note as part of this change, the Chinese portion of the site was dropped. No URLs for the Community documentation site changed.
-
 ## Related Issues
 <!--
 List any issues or tickets on other platforms that are associated with the request. For example, include a link to the issue tracking that feature in the Rancher repo, or list the Jira ticket number for the request.
@@ -2,13 +2,6 @@
 Check the Rancher docs issues to see if there is an existing issue for this pull request. If there is, enter the issue number below.
 -->

-> [!IMPORTANT]
-> Hello, our team is currently in the process of consolidating our Rancher documentation repositories. With this change, the contents of this repository was moved to [rancher/rancher-product-docs](https://github.com/rancher/rancher-product-docs).
->
-> We understand this is a significant change and disruption to the standard process and wish to note the Rancher documentation team is here to assist in any way it can to make the transition process straight forward. Going forward, we kindly ask that any new issue reports or contributions be made to the `rancher-product-docs` repository instead. If you wish to make contributions, please refer to our updated [README](https://github.com/rancher/rancher-product-docs/blob/main/README.md) for guidance.
->
-> Please note as part of this change, the Chinese portion of the site was dropped. No URLs for the Community documentation site changed.
-
 Fixes #[issue_number]

 ## Reminders
@@ -0,0 +1,52 @@
+name: Deploy to GitHub Pages
+
+on:
+  push:
+    branches:
+      - main
+    paths-ignore:
+      - '**/README.md'
+      - '**/.github/ISSUE_TEMPLATE/**'
+
+jobs:
+  build:
+    name: Build Docusaurus
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 18
+          cache: yarn
+
+      - name: Install dependencies
+        run: yarn install --frozen-lockfile
+      - name: Build website
+        env:
+          NODE_OPTIONS: "--max_old_space_size=10240"
+        run: yarn build --no-minify
+
+      - name: Upload Build Artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          path: build
+
+  deploy:
+    name: Deploy to GitHub Pages
+    needs: build
+
+    permissions:
+      pages: write
+      id-token: write
+    
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+
+    runs-on: ubuntu-latest
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4
@@ -11,10 +11,10 @@ jobs:
    name: Test deployment
    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
+      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
-      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4
+      - uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: yarn
@@ -28,4 +28,4 @@ jobs:
      - name: Test build website
        env:
          NODE_OPTIONS: "--max_old_space_size=10240"
-        run: yarn build --no-minify
+        run: yarn build --no-minify
@@ -1,12 +1,5 @@
 # Contribute to Rancher Docs

-> [!IMPORTANT]
-> The contents of this repository was moved to [rancher/rancher-product-docs](https://github.com/rancher/rancher-product-docs).
->
-> We understand this is a significant change and disruption to the standard process and wish to note the Rancher documentation team is here to assist in any way it can to make the transition process straight forward. Going forward, we kindly ask that any new issue reports or contributions be made to the `rancher-product-docs` repository instead. If you wish to make contributions, please refer to our updated [README](https://github.com/rancher/rancher-product-docs/blob/main/README.md) for guidance.
->
-> Please note as part of this change, the Chinese portion of the site was dropped. No URLs for the Community documentation site changed.
-
 Welcome to the [Rancher docs](https://ranchermanager.docs.rancher.com/) repository. See the [Rancher software](https://github.com/rancher/rancher) repository if you have questions or requests for the Rancher platform.

 ## Make a Suggestion
@@ -1,143 +0,0 @@
---
-title: Installing Rancher on Azure Kubernetes Service
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks"/>
-</head>
-
-This page covers how to install Rancher on Microsoft's Azure Kubernetes Service (AKS).
-
-The guide uses command line tools to provision an AKS cluster with an ingress. If you prefer to provision your cluster using the Azure portal, refer to the [official documentation](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal).
-
-If you already have an AKS Kubernetes cluster, skip to the step about [installing an ingress.](#5-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)
-
-## Prerequisites
-
-:::caution
-
-Deploying to Microsoft Azure will incur charges.
-
-:::
-
- [Microsoft Azure Account](https://azure.microsoft.com/en-us/free/): A Microsoft Azure Account is required to create resources for deploying Rancher and Kubernetes.
- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
- Your subscription has sufficient quota for at least 2 vCPUs. For details on Rancher server resource requirements, refer to [this section](../installation-requirements/installation-requirements.md)
- When installing Rancher with Helm in Azure, use the L7 load balancer to avoid networking issues. For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
-
-## 1. Prepare your Workstation
-
-Install the following command line tools on your workstation:
-
- The Azure CLI, **az:** For help, refer to these [installation steps.](https://docs.microsoft.com/en-us/cli/azure/)
- **kubectl:** For help, refer to these [installation steps.](https://kubernetes.io/docs/tasks/tools/#kubectl)
- **helm:** For help, refer to these [installation steps.](https://helm.sh/docs/intro/install/)
-
-## 2. Create a Resource Group
-
-After installing the CLI, you will need to log in with your Azure account.
-
-```
-az login
-```
-
-Create a [resource group](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal) to hold all relevant resources for your cluster. Use a location that applies to your use case.
-
-```
-az group create --name rancher-rg --location eastus
-```
-
-## 3. Create the AKS Cluster
-
-To create an AKS cluster, run the following command. Use a VM size that applies to your use case. Refer to [this article](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for available sizes and options. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
-
-```
-az aks create \
-  --resource-group rancher-rg \
-  --name rancher-server \
-  --kubernetes-version <VERSION> \
-  --node-count 3 \
-  --node-vm-size Standard_D2_v3
-```
-
-The cluster will take some time to be deployed.
-
-## 4. Get Access Credentials
-
-After the cluster is deployed, get the access credentials.
-
-```
-az aks get-credentials --resource-group rancher-rg --name rancher-server
-```
-
-This command merges your cluster's credentials into the existing kubeconfig and allows `kubectl` to interact with the cluster.
-
-## 5. Install an Ingress
-
-The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription. You can use a managed ingress controller provided by Azure or a third-party ingress controller like Traefik.
-
-:::warning
-It is not recommended to install a third-party ingress controller, like Traefik, if a managed ingress controller is already being used.
-:::
-
-:::warning
-**Ingress-NGINX EOL:** The community `ingress-nginx` controller reaches End-of-Life (EOL) in March 2026. This page uses Traefik, which is the recommended migration path for Rancher environments. 
-:::
-
-Traefik includes a native Ingress NGINX provider. This allows you to migrate from NGINX without rewriting your existing Ingress objects, as Traefik will automatically interpret `nginx.ingress.kubernetes.io` annotations. If you are upgrading a cluster that is already using `ingress-nginx`, follow this [guide](https://doc.traefik.io/traefik/migrate/nginx-to-traefik/) for more information.
-
-To install Traefik (chart version 39.0.0) on a fresh cluster, run the following `helm` commands:
-```bash
-helm repo add traefik https://traefik.github.io/charts
-helm repo update
-helm upgrade --install \
-  traefik traefik/traefik \
-  --namespace traefik \
-  --version 39.0.0 \
-  --create-namespace \
-  --set service.type=LoadBalancer \
-  --set ping.enabled=true \
-  --set service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/ping
-```
-
-## 6. Get Load Balancer IP
-
-To get the address of the load balancer, run:
-
-```bash
-kubectl get service traefik --namespace=traefik
-```
-
-The result should look similar to the following:
-
-```bash
-NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)
- AGE
-traefik  LoadBalancer   10.0.116.18    40.31.180.83   80:31229/TCP,443:31050/TCP
- 67s
-```
-
-Save the `EXTERNAL-IP`.
-
-## 7. Set up DNS
-
-External traffic to the Rancher server will need to be directed at the load balancer you created.
-
-Set up a DNS to point at the `EXTERNAL-IP` that you saved. This DNS will be used as the Rancher server URL.
-
-There are many valid ways to set up the DNS. For help, refer to the [Azure DNS documentation](https://docs.microsoft.com/en-us/azure/dns/)
-
-## 8. Install the Rancher Helm Chart
-
-Next, install the Rancher Helm chart by following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
-
-Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
-
-When installing Rancher on top of this setup, you will also need to pass the value below into the Rancher Helm install command in order to set the name of the ingress controller to be used with Rancher's ingress resource:
-
-```
--set ingress.ingressClassName=traefik
-```
-
-Refer [here for the Helm install command](install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
@@ -1,155 +0,0 @@
---
-title: Installing Rancher on Amazon EKS
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks"/>
-</head>
-
-This page covers installing Rancher on an Amazon EKS cluster.  You can also [install Rancher through the AWS Marketplace](../../quick-start-guides/deploy-rancher-manager/aws-marketplace.md).
-
-If you already have an EKS Kubernetes cluster, skip to the step about [installing an ingress.](#5-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)
-
-## Creating an EKS Cluster for the Rancher Server
-
-In this section, you'll install an EKS cluster with an ingress by using command line tools. This guide may be useful if you want to use fewer resources while trying out Rancher on EKS.
-
-:::note Prerequisites:
-
- You should already have an AWS account.
- It is recommended to use an IAM user instead of the root AWS account. You will need the IAM user's access key and secret key to configure the AWS command line interface.
- The IAM user needs the minimum IAM policies described in the official [eksctl documentation.](https://eksctl.io/usage/minimum-iam-policies/)
-
-:::
-
-### 1. Prepare your Workstation
-
-Install the following command line tools on your workstation:
-
- **The AWS CLI v2:** For help, refer to these [installation steps.](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
- **eksctl:** For help, refer to these [installation steps.](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)
- **kubectl:** For help, refer to these [installation steps.](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
- **helm:** For help, refer to these [installation steps.](https://helm.sh/docs/intro/install/)
-
-### 2. Configure the AWS CLI
-
-To configure the AWS CLI, run the following command:
-
-```
-aws configure
-```
-
-Then enter the following values:
-
-| Value | Description |
-|-------|-------------|
-| AWS Access Key ID | The access key credential for the IAM user with EKS permissions. |
-| AWS Secret Access Key | The secret key credential for the IAM user with EKS permissions. |
-| Default region name | An [AWS region](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html#Concepts.RegionsAndAvailabilityZones.Regions) where the cluster nodes will be located. |
-| Default output format | Enter `json`. |
-
-### 3. Create the EKS Cluster
-
-To create an EKS cluster, run the following command. Use the AWS region that applies to your use case. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
-
-```
-eksctl create cluster \
-  --name rancher-server \
-  --version <VERSION> \
-  --region us-west-2 \
-  --nodegroup-name ranchernodes \
-  --nodes 3 \
-  --nodes-min 1 \
-  --nodes-max 4 \
-  --managed
-```
-
-The cluster will take some time to be deployed with CloudFormation.
-
-### 4. Test the Cluster
-
-To test the cluster, run:
-
-```
-eksctl get cluster
-```
-
-The result should look like the following:
-
-```
-eksctl get cluster
-2021-03-18 15:09:35 [ℹ]  eksctl version 0.40.0
-2021-03-18 15:09:35 [ℹ]  using region us-west-2
-NAME		REGION		EKSCTL CREATED
-rancher-server-cluster		us-west-2	True
-```
-
-### 5. Install an Ingress
-
-The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription. You can use a managed ingress controller provided by AWS (ALB) or a third-party ingress controller like Traefik.
-
-:::warning
-It is not recommended to install a third-party ingress controller, like Traefik, if a managed ingress controller (ALB) is already being used.
-:::
-
-
-:::warning
-**Ingress-NGINX EOL:** The community `ingress-nginx` controller reaches End-of-Life (EOL) in March 2026. This page uses Traefik, which is the recommended migration path for Rancher environments. 
-:::
-
-Traefik includes a native Ingress NGINX provider. This allows you to migrate from NGINX without rewriting your existing Ingress objects, as Traefik will automatically interpret `nginx.ingress.kubernetes.io` annotations. If you are upgrading a cluster that is already using `ingress-nginx`, follow this [guide](https://doc.traefik.io/traefik/migrate/nginx-to-traefik/) for more information.
-
-To install Traefik (chart version 39.0.0) on a fresh cluster, run the following `helm` commands:
-```bash
-helm repo add traefik https://traefik.github.io/charts
-helm repo update
-helm upgrade --install \
-  traefik traefik/traefik \
-  --namespace traefik \
-  --version 39.0.0 \
-  --create-namespace \
-  --set service.type=LoadBalancer \
-  --set ping.enabled=true \
-```
-
-
-### 6. Get Load Balancer IP
-
-To get the address of the load balancer, run:
-
-```bash
-kubectl get service traefik --namespace=traefik
-```
-
-The result should look similar to the following:
-
-```bash
-NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)
- AGE
-traefik  LoadBalancer   10.100.90.18   a904a952c73bf4f668a17c46ac7c56ab-962521486.us-west-2.elb.amazonaws.com   80:31229/TCP,443:31050/TCP
- 67s
-```
-
-Save the `EXTERNAL-IP`.
-
-### 7. Set up DNS
-
-External traffic to the Rancher server will need to be directed at the load balancer you created.
-
-Set up a DNS to point at the external IP that you saved. This DNS will be used as the Rancher server URL.
-
-There are many valid ways to set up the DNS. For help, refer to the AWS documentation on [routing traffic to an ELB load balancer.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html)
-
-### 8. Install the Rancher Helm Chart
-
-Next, install the Rancher Helm chart by following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
-
-Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
-
-When installing Rancher on top of this setup, you will also need to pass the value below into the Rancher Helm install command in order to set the name of the ingress controller to be used with Rancher's ingress resource:
-
-```
--set ingress.ingressClassName=traefik
-```
-
-Refer [here for the Helm install command](install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
@@ -1,18 +0,0 @@
---
-title: Rancher for AWS
-description: Learn about Rancher for AWS from the AWS Marketplace listing.
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace"/>
-</head>
-
-SUSE Rancher for AWS (SRA/SRFA) is a fully managed Software-as-a-Service (SaaS) offering available through the [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-yrzugbpzuukww). It provides a centralized control plane to manage, monitor, and scale Kubernetes clusters within an AWS environment.
-
-For deployment prerequisites, architecture requirements, and subscription details, refer to the [AWS Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-yrzugbpzuukww). For more information, refer to the [product documentation](https://documentation.suse.com/cloudnative/rancher-srfa/).
-
-:::note
-
-SUSE Rancher for AWS is an offering distinct from deploying and managing the Rancher server manually on Amazon EKS. If you intend to install and manage your own Rancher deployment on an EKS cluster, refer to [Installing Rancher on Amazon EKS](../../installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md).
-
-:::
@@ -1,108 +0,0 @@
---
-title: Rancher Equinix Metal Quick Start
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/equinix-metal"/>
-</head>
-
-## This tutorial walks you through the following:
-
- Provisioning an Equinix Metal Server
- Installation of Rancher 2.x
- Creation of your first cluster
- Deployment of an application, Nginx
-
-:::caution
-
-The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. The Docker install is not recommended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
-
-:::
-
-## Quick Start Outline
-
-This Quick Start Guide is divided into different tasks for easier consumption.
-
-<br/>
-
-## Prerequisites
-
- An [Equinix Metal account](https://deploy.equinix.com/developers/docs/metal/identity-access-management/users/)
- An [Equinix Metal project](https://deploy.equinix.com/developers/docs/metal/projects/creating-a-project/)
-
-
-### 1. Provision a Equinix Metal Host
-
-Begin deploying an Equinix Metal Host. Equinix Metal Servers can be provisioned from either the Equinix Metal console, API, or CLI. You can find instructions for each deployment type on the [Equinix Metal deployment documentation](https://deploy.equinix.com/developers/docs/metal/deploy/on-demand/). You can find additional information on Equinix Metal server types in the [Equinix Metal Documentation](https://deploy.equinix.com/developers/docs/metal/hardware/standard-servers/).
-
-:::note Notes:
-
- When provisioning a new Equinix Metal Server via the CLI or API you will need to provide the following information: project-id, plan, metro, and operating-system.
- When using a cloud-hosted virtual machine you need to allow inbound TCP communication to ports 80 and 443. Please see your cloud host's documentation for information regarding port configuration.
- For a full list of port requirements, refer to [Docker Installation](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md).
- Provision the host according to our [Requirements](../../installation-and-upgrade/installation-requirements/installation-requirements.md).
-
-:::
-### 2. Install Rancher
-
-To install Rancher on your Equinix Metal host, connect to it and then use a shell to install.
-
-1.  Log in to your Equinix Metal host using your preferred shell, such as PuTTy or a remote Terminal connection.
-
-2.  From your shell, enter the following command:
-
-    ```
-    sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher
-    ```
-
-**Result:** Rancher is installed.
-
-### 3. Log In
-
-Log in to Rancher to begin using the application. After you log in, you'll make some one-time configurations.
-
-1.  Open a web browser and enter the IP address of your host: `https://<SERVER_IP>`.
-
-    Replace `<SERVER_IP>` with your host IP address.
-
-2.  When prompted, create a password for the default `admin` account.
-
-3.  Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node added to your cluster must be able to connect to this URL.<br/><br/>If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster.
-
-<br/>
-
-### 4. Create the Cluster
-
-Welcome to Rancher! You are now able to create your first Kubernetes cluster.
-
-In this task, you can use the versatile **Custom** option. This option lets you add _any_ Linux host (cloud-hosted VM, on-prem VM, or bare-metal) to be used in a cluster.
-
-1. Click **☰ > Cluster Management**.
-1. From the **Clusters** page, click **Create**.
-1. Choose **Custom**.
-1. Enter a **Cluster Name**.
-1. Click **Next**.
-1. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**.
-    - **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section.
-1. Copy the registration command to your clipboard.
-1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
-1. When you finish running the command on your Linux host, click **Done**.
-
-**Result:**
-
-Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
-
-You can access your cluster after its state is updated to **Active**.
-
-**Active** clusters are assigned two Projects:
-
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `traefik`, `kube-public`, and `kube-system` namespaces
-
-#### Finished
-
-Congratulations! You have created your first cluster.
-
-#### What's Next?
-
-Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
@@ -1,202 +0,0 @@
---
-title: Configure Keycloak (SAML)
-description: Create a Keycloak SAML client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins
---
-
-<head> 
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-keycloak-saml"/>
-</head>
-
-If your organization uses Keycloak Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
-
-## Prerequisites
-
- You must have a [Keycloak IdP Server](https://www.keycloak.org/guides#getting-started) configured.
- In Keycloak, create a [new SAML client](https://www.keycloak.org/docs/latest/server_admin/#saml-clients), with the settings below. See the [Keycloak documentation](https://www.keycloak.org/docs/latest/server_admin/#saml-clients) for help.
-
-     Setting | Value
-     ------------|------------
-      `Sign Documents` | `ON` <sup>1</sup>
-      `Sign Assertions` | `ON` <sup>1</sup>
-      All other `ON/OFF` Settings | `OFF`
-      `Client ID` | Either `https://yourRancherHostURL/v1-saml/keycloak/saml/metadata` or the value configured in the `Entry ID Field` of the Rancher Keycloak configuration<sup>2</sup>
-      `Client Name` | <CLIENT_NAME> (e.g. `rancher`)
-      `Client Protocol` | `SAML`
-      `Valid Redirect URI` | `https://yourRancherHostURL/v1-saml/keycloak/saml/acs`
-
-    ><sup>1</sup>: Optionally, you can enable either one or both of these settings.
-    ><sup>2</sup>: Rancher SAML metadata won't be generated until a SAML provider is configured and saved.
-
-  ![](/img/keycloak/keycloak-saml-client-configuration.png)
-
- In the new SAML client, create Mappers to expose the users fields
-  - Add all "Builtin Protocol Mappers"
-    ![](/img/keycloak/keycloak-saml-client-builtin-mappers.png)
-  - Create a new "Group list" mapper to map the member attribute to a user's groups
-    ![](/img/keycloak/keycloak-saml-client-group-mapper.png)
-
-## Getting the IDP Metadata
-
-<Tabs>
-<TabItem value="Keycloak 5 and earlier">
-
-To get the IDP metadata, export a `metadata.xml` file from your Keycloak client.
-From the **Installation** tab, choose the **SAML Metadata IDPSSODescriptor** format option and download your file.
-
-</TabItem>
-<TabItem value="Keycloak 6-13">
-
-1. From the **Configure** section, click the **Realm Settings** tab.
-1. Click the **General** tab.
-1. From the **Endpoints** field, click **SAML 2.0 Identity Provider Metadata**.
-
-Verify the IDP metadata contains the following attributes:
-
-```
-xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
-xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
-xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
-```
-
-Some browsers, such as Firefox, may render/process the document such that the contents appear to have been modified, and some attributes appear to be missing. In this situation, use the raw response data that can be found using your browser.
-
-The following is an example process for Firefox, but will vary slightly for other browsers:
-
-1. Press **F12** to access the developer console.
-1. Click the **Network** tab.
-1. From the table, click the row containing `descriptor`.
-1. From the details pane, click the **Response** tab.
-1. Copy the raw response data.
-
-The XML obtained contains `EntitiesDescriptor` as the root element. Rancher expects the root element to be `EntityDescriptor` rather than `EntitiesDescriptor`. So before passing this XML to Rancher, follow these steps to adjust it:
-
-1. Copy all the attributes from `EntitiesDescriptor` to the `EntityDescriptor` that are not present.
-1. Remove the `<EntitiesDescriptor>` tag from the beginning.
-1. Remove the `</EntitiesDescriptor>` from the end of the xml.
-
-You are left with something similar as the example below:
-
-```
-<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" entityID="https://{KEYCLOAK-URL}/auth/realms/{REALM-NAME}">
-....
-</EntityDescriptor>
-```
-
-</TabItem>
-<TabItem value="Keycloak 14+">
-
-1. From the **Configure** section, click the **Realm Settings** tab.
-1. Click the **General** tab.
-1. From the **Endpoints** field, click **SAML 2.0 Identity Provider Metadata**.
-
-Verify the IDP metadata contains the following attributes:
-
-```
-xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
-xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
-xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
-```
-
-Some browsers, such as Firefox, may render/process the document such that the contents appear to have been modified, and some attributes appear to be missing. In this situation, use the raw response data that can be found using your browser.
-
-The following is an example process for Firefox, but will vary slightly for other browsers:
-
-1. Press **F12** to access the developer console.
-1. Click the **Network** tab.
-1. From the table, click the row containing `descriptor`.
-1. From the details pane, click the **Response** tab.
-1. Copy the raw response data.
-
-</TabItem>
-</Tabs>
-
-## Configuring Keycloak in Rancher
-
-
-1.	In the top left corner, click **☰ > Users & Authentication**.
-1. In the left navigation menu, click **Auth Provider**.
-1. Click **Keycloak SAML**.
-1.	Complete the **Configure Keycloak Account** form. For help with filling the form, see the [configuration reference](#configuration-reference).
-1. After you complete the **Configure a Keycloak Account** form, click **Enable**.
-
-    Rancher redirects you to the IdP login page. Enter credentials that authenticate with Keycloak IdP to validate your Rancher Keycloak configuration.
-
-    :::note
-
-    You may have to disable your popup blocker to see the IdP login page.
-
-    :::
-
-**Result:** Rancher is configured to work with Keycloak. Your users can now sign into Rancher using their Keycloak logins.
-
-:::note SAML Provider Caveats:
-
- SAML Protocol does not support search or lookup for users or groups. Therefore, there is no validation on users or groups when adding them to Rancher.
- When adding users, the exact user IDs (i.e. `UID Field`) must be entered correctly. As you type the user ID, there will be no search for other  user IDs that may match.
- When adding groups, you must select the group from the drop-down that is next to the text box. Rancher assumes that any input from the text box is a user.
- The group drop-down shows only the groups that you are a member of. You will not be able to add groups that you are not a member of.
-
-:::
-
-## Configuration Reference
-
-| Field                     | Description                                                                                                                                              |
-| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Display Name Field        | The attribute that contains the display name of users. <br/><br/>Example: `givenName`                                                                    |
-| User Name Field           | The attribute that contains the user name/given name. <br/><br/>Example: `email`                                                                         |
-| UID Field                 | An attribute that is unique to every user. <br/><br/>Example: `email`                                                                                    |
-| Groups Field              | Make entries for managing group memberships. <br/><br/>Example: `member`                                                                                 |
-| Entity ID Field           | The ID that needs to be configured as a client ID in the Keycloak client. <br/><br/>Default: `https://yourRancherHostURL/v1-saml/keycloak/saml/metadata` |
-| Rancher API Host          | The URL for your Rancher Server.                                                                                                                         |
-| Private Key / Certificate | A key/certificate pair to create a secure shell between Rancher and your IdP.                                                                            |
-| IDP-metadata              | The `metadata.xml` file that you exported from your IdP server.                                                                                          |
-
-:::tip
-
-You can generate a key/certificate pair using an openssl command. For example:
-
-openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout myservice.key -out myservice.cert
-
-:::
-
-## Annex: Troubleshooting
-
-If you are experiencing issues while testing the connection to the Keycloak server, first double-check the configuration option of your SAML client. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
-
-### You are not redirected to Keycloak
-
-When you click on **Authenticate with Keycloak**, you are not redirected to your IdP.
-
-  * Verify your Keycloak client configuration.
-  * Make sure `Force Post Binding` is set to `OFF`.
-
-
-### Forbidden message displayed after IdP login
-
-You are correctly redirected to your IdP login page and you are able to enter your credentials, however you get a `Forbidden` message afterwards.
-
-  * Check the Rancher debug log.
-  * If the log displays `ERROR: either the Response or Assertion must be signed`, make sure either `Sign Documents` or `Sign assertions` is set to `ON` in your Keycloak client.
-
-### HTTP 502 when trying to access /v1-saml/keycloak/saml/metadata
-
-This is usually due to the metadata not being created until a SAML provider is configured.
-Try configuring and saving keycloak as your SAML provider and then accessing the metadata.
-
-### Keycloak Error: "We're sorry, failed to process response"
-
-  * Check your Keycloak log.
-  * If the log displays `failed: org.keycloak.common.VerificationException: Client does not have a public key`, set `Encrypt Assertions` to `OFF` in your Keycloak client.
-
-### Keycloak Error: "We're sorry, invalid requester"
-
-  * Check your Keycloak log.
-  * If the log displays `request validation failed: org.keycloak.common.VerificationException: SigAlg was null`, set `Client Signature Required` to `OFF` in your Keycloak client.
-
-## Configuring SAML Single Logout (SLO)
-
-<ConfigureSLO />
-
-## SAML and OpenLDAP Group Permissions
-
-<SamlOpenLDAPGroupPermissions />
@@ -1,118 +0,0 @@
---
-title: Configure Okta (SAML)
---
-
-<head> 
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-okta-saml"/>
-</head>
-
-If your organization uses Okta Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
-
-:::note
-
-Okta integration only supports Service Provider initiated logins.
-
-:::
-## Prerequisites
-
-In Okta, create a SAML Application with the settings below. See the [Okta documentation](https://developer.okta.com/standards/SAML/setting_up_a_saml_application_in_okta) for help.
-
-Setting | Value
------------|------------
-`Single Sign on URL` | `https://yourRancherHostURL/v1-saml/okta/saml/acs`
-`Audience URI (SP Entity ID)` | `https://yourRancherHostURL/v1-saml/okta/saml/metadata`
-
-## Configuring Okta in Rancher
-
-You can integrate Okta with Rancher, so that authenticated users can access Rancher resources through their group permissions. Okta returns a SAML assertion that authenticates a user, including which groups a user belongs to.
-
-1. In the top left corner, click **☰ > Users & Authentication**.
-1. In the left navigation menu, click **Auth Provider**.
-1. Click **Okta**.
-1. Complete the **Configure Okta Account** form. The examples below describe how you can map Okta attributes from attribute statements to fields within Rancher.
-
-    | Field                     | Description                                                                   |
-    | ------------------------- | ----------------------------------------------------------------------------- |
-    | Display Name Field        | The attribute name from an attribute statement that contains the display name of users.                        |
-    | User Name Field           | The attribute name from an attribute statement that contains the user name/given name.                         |
-    | UID Field                 | The attribute name from an attribute statement that is unique to every user.                                    |
-    | Groups Field              | The attribute name in a group attribute statement that exposes your groups.        |
-    | Rancher API Host          | The URL for your Rancher Server.                                              |
-    | Private Key / Certificate | A key/certificate pair used for Assertion Encryption.                         |
-    | Metadata XML              | The `Identity Provider metadata` file that you find in the application `Sign On` section.  |
-
-    :::tip
-
-    You can generate a key/certificate pair using an openssl command. For example:
-
-    ```
-    openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout myservice.key -out myservice.crt
-    ```
-
-    :::
-
-1. After you complete the **Configure Okta Account** form, click **Enable**.
-
-    Rancher redirects you to the IdP login page. Enter credentials that authenticate with Okta IdP to validate your Rancher Okta configuration.
-
-    :::note
-
-    If nothing seems to happen, it's likely because your browser blocked the pop-up. Make sure you disable the pop-up blocker for your rancher domain and whitelist it in any other extensions you might utilize.
-
-    :::
-
-**Result:** Rancher is configured to work with Okta. Your users can now sign into Rancher using their Okta logins.
-
-:::note SAML Provider Caveats
-
-If you configure Okta without OpenLDAP, you won't be able to search for or directly lookup users or groups. This brings several caveats:
-
- Users and groups aren't validated when you assign permissions to them in Rancher.
- When adding users, the exact user IDs (i.e. `UID Field`) must be entered correctly. As you type the user ID, there will be no search for other  user IDs that may match.
- When adding groups, you must select the group from the drop-down that is next to the text box. Rancher assumes that any input from the text box is a user.
- The group drop-down shows only the groups that you are a member of. However, if you have Administrator permissions or restricted Administrator permissions, you can join a group that you are not a member of.
-
-:::
-
-## Okta with OpenLDAP search
-
-You can add an OpenLDAP backend to assist with user and group search. Rancher will display additional users and groups from the OpenLDAP service. This allows assigning permissions to groups that the logged-in user is not already a member of.
-
-### OpenLDAP Prerequisites
-
-If you use Okta as your IdP, you can [set up an LDAP interface](https://help.okta.com/en-us/Content/Topics/Directory/LDAP-interface-main.htm) for Rancher to use. You can also configure an external OpenLDAP server.
-
-You must configure Rancher with a LDAP bind account (aka service account) so that you can search and retrieve LDAP entries for users and groups that should have access. Don't use an administrator account or personal account as an LDAP bind account. [Create](https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-add-users.htm) a dedicated account in OpenLDAP, with read-only access to users and groups under the configured searchbase.
-
-:::warning Security Considerations
-
-The OpenLDAP service account is used for all searches. Rancher users will see users and groups that the OpenLDAP service account can view, regardless of their individual SAML permissions.
-
-:::
-
-
-> **Using TLS?**
->
-> If the certificate used by the OpenLDAP server is self-signed or from an unrecognized certificate authority, Rancher needs the CA certificate (concatenated with any intermediate certificates) in PEM format. Provide this certificate during the configuration so that Rancher can validate the certificate chain.
-
-### Configure OpenLDAP in Rancher
-
-[Configure the settings](../configure-openldap/openldap-config-reference.md) for the OpenLDAP server, groups and users. Note that nested group membership isn't available.
-
-> Before you proceed with the configuration, please familiarise yourself with [external authentication configuration and principal users](authentication-config.md#external-authentication-configuration-and-principal-users).
-
-1. Sign into Rancher using a local user assigned the [administrator](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions) role (i.e., the _local principal_).
-1. In the top left corner, click **☰ > Users & Authentication**.
-1. In the left navigation menu, click **Auth Provider**.
-1. Click **Okta** or, if SAML is already configured, **Edit Config**
-1. Under **User and Group Search**, check **Configure an OpenLDAP server**
-
-If you experience issues when you test the connection to the OpenLDAP server, ensure that you entered the credentials for the service account and configured the search base correctly. Inspecting the Rancher logs can help pinpoint the root cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) for more information.
-
-## Configuring SAML Single Logout (SLO)
-
-<ConfigureSLO />
-
-## SAML and OpenLDAP Group Permissions
-
-<SamlOpenLDAPGroupPermissions />
@@ -1,74 +0,0 @@
---
-title: Configure PingIdentity (SAML)
---
-
-<head> 
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-pingidentity"/>
-</head>
-
-If your organization uses Ping Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
-
->**Prerequisites:**
->
->- You must have a [Ping IdP Server](https://www.pingidentity.com/) configured.
->- Following are the Rancher Service Provider URLs needed for configuration:
-Metadata URL: `https://<rancher-server>/v1-saml/ping/saml/metadata`
-Assertion Consumer Service (ACS) URL: `https://<rancher-server>/v1-saml/ping/saml/acs`
-Note that these URLs will not return valid data until the authentication configuration is saved in Rancher.
->- Export a `metadata.xml` file from your IdP Server. For more information, see the [PingIdentity documentation](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html).
-
-1.	In the top left corner, click **☰ > Users & Authentication**.
-1. In the left navigation menu, click **Auth Provider**.
-1. Click **Ping Identity**.
-1.	Complete the **Configure a Ping Account** form. Ping IdP lets you specify what data store you want to use. You can either add a database or use an existing ldap server. For example, if you select your Active Directory (AD) server, the examples below describe how you can map AD attributes to fields within Rancher.
-
-    1. **Display Name Field**: Enter the AD attribute that contains the display name of users (example: `displayName`).
-
-    1. **User Name Field**: Enter the AD attribute that contains the user name/given name (example: `givenName`).
-
-    1. **UID Field**: Enter an AD attribute that is unique to every user (example: `sAMAccountName`, `distinguishedName`).
-
-    1. **Groups Field**: Make entries for managing group memberships (example: `memberOf`).
-
-    1. **Entity ID Field** (optional): The published, protocol-dependent, unique identifier of your partner. This ID defines your organization as the entity operating the server for SAML 2.0 transactions. This ID may have been obtained out-of-band or via a SAML metadata file.
-
-    1. **Rancher API Host**: Enter the URL for your Rancher Server.
-
-    1. **Private Key** and **Certificate**: This is a key-certificate pair to create a secure shell between Rancher and your IdP.
-
-        You can generate one using an openssl command. For example:
-
-        ```
-        openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
-        ```
-    1. **IDP-metadata**: The `metadata.xml` file that you [exported from your IdP server](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html).
-
-
-1. After you complete the **Configure Ping Account** form, click **Enable**.
-
-    Rancher redirects you to the IdP login page. Enter credentials that authenticate with Ping IdP to validate your Rancher PingIdentity configuration.
-
-    :::note
-
-    You may have to disable your popup blocker to see the IdP login page.
-
-    :::
-
-**Result:** Rancher is configured to work with PingIdentity. Your users can now sign into Rancher using their PingIdentity logins.
-
-:::note SAML Provider Caveats
-
- Users and groups aren't validated when you assign permissions to them in Rancher.
- When adding users, the exact user IDs (i.e. `UID Field`) must be entered correctly. As you type the user ID, there will be no search for other  user IDs that may match.
- When adding groups, you must select the group from the drop-down that is next to the text box. Rancher assumes that any input from the text box is a user.
- The group drop-down shows only the groups that you are a member of. However, if you have Administrator permissions or restricted Administrator permissions, you can join a group that you are not a member of.
-
-:::
-
-## Configuring SAML Single Logout (SLO)
-
-<ConfigureSLO />
-
-## SAML and OpenLDAP Group Permissions
-
-<SamlOpenLDAPGroupPermissions />
@@ -1,61 +0,0 @@
---
-title: 2. Configuring Rancher for Microsoft AD FS
---
-
-<head> 
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-microsoft-ad-federation-service-saml/configure-rancher-for-ms-adfs"/>
-</head>
-
-After you complete [Configuring Microsoft AD FS for Rancher](configure-ms-adfs-for-rancher.md), enter your Active Directory Federation Service (AD FS) information into Rancher so that AD FS users can authenticate with Rancher.
-
-:::note Important Notes For Configuring Your ADFS Server:
-
- The SAML 2.0 WebSSO Protocol Service URL is: `https://<RANCHER_SERVER>/v1-saml/adfs/saml/acs`
- The Relying Party Trust identifier URL is: `https://<RANCHER_SERVER>/v1-saml/adfs/saml/metadata`
- You must export the `federationmetadata.xml` file from your AD FS server. This can be found at: `https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml`
-
-:::
-
-1.	In the top left corner, click **☰ > Users & Authentication**.
-1. In the left navigation menu, click **Auth Provider**.
-1. Click **ADFS**.
-1.	Complete the **Configure AD FS Account** form. Microsoft AD FS lets you specify an existing Active Directory (AD) server. The [configuration section below](#configuration) describe how you can map AD attributes to fields within Rancher.
-1. After you complete the **Configure AD FS Account** form, click **Enable**.
-
-    Rancher redirects you to the AD FS login page. Enter credentials that authenticate with Microsoft AD FS to validate your Rancher AD FS configuration.
-
-    :::note
-
-    You may have to disable your popup blocker to see the AD FS login page.
-
-    :::
-
-**Result:** Rancher is configured to work with MS FS. Your users can now sign into Rancher using their MS FS logins.
-
-## Configuration
-
-| Field | Description                |
-|---------------------------|-----------------|
-| Display Name Field        | The AD attribute that contains the display name of users. <br/><br/>Example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`                                                                      |
-| User Name Field           | The AD attribute that contains the user name/given name. <br/><br/>Example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`                                                                  |
-| UID Field                 | An AD attribute that is unique to every user. <br/><br/>Example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn`                                                                                   |
-| Groups Field              | Make entries for managing group memberships. <br/><br/>Example: `http://schemas.xmlsoap.org/claims/Group`                                                                                                      |
-| Rancher API Host          | The URL for your Rancher Server.                                                                                                                                                                               |
-| Private Key / Certificate | This is a key-certificate pair to create a secure shell between Rancher and your AD FS. Ensure you set the Common Name (CN) to your Rancher Server URL.<br/><br/>[Certificate creation command](#example-certificate-creation-command) |
-| Metadata XML              | The `federationmetadata.xml` file exported from your AD FS server. <br/><br/>You can find this file at `https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml`.                                |
-
-### Example Certificate Creation Command
-
-You can generate a certificate using an openssl command. For example:
-
-```
-openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
-```
-
-## Configuring SAML Single Logout (SLO)
-
-<ConfigureSLO />
-
-## SAML and OpenLDAP Group Permissions
-
-<SamlOpenLDAPGroupPermissions />
@@ -1,36 +0,0 @@
---
-title: Group Permissions with Shibboleth and OpenLDAP
---
-
-<head> 
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-shibboleth-saml/about-group-permissions"/>
-</head>
-
-Because Shibboleth is a SAML provider, it doesn't support searching for groups. While a Shibboleth integration can validate user credentials, it can't be used to assign permissions to groups in Rancher without additional configuration.
-
-One solution to this problem is to configure an OpenLDAP identity provider. With an OpenLDAP back end for Shibboleth, you will be able to search for groups in Rancher and assign them to resources such as clusters, projects, or namespaces from the Rancher UI.
-
-## Terminology
-
- **Shibboleth** is a single sign-on log-in system for computer networks and the Internet. It allows people to sign in using just one identity to various systems. It validates user credentials, but does not, on its own, handle group memberships.
- **SAML:** Security Assertion Markup Language, an open standard for exchanging authentication and authorization data between an identity provider and a service provider.
- **OpenLDAP:** a free, open-source implementation of the Lightweight Directory Access Protocol (LDAP). It is used to manage an organization’s computers and users. OpenLDAP is useful for Rancher users because it supports groups. In Rancher, it is possible to assign permissions to groups so that they can access resources such as clusters, projects, or namespaces, as long as the groups already exist in the identity provider.
- **IdP or IDP:** An identity provider. OpenLDAP is an example of an identity provider.
-
-## Adding OpenLDAP Group Permissions to Rancher Resources
-
-The diagram below illustrates how members of an OpenLDAP group can access resources in Rancher that the group has permissions for.
-
-For example, a cluster owner could add an OpenLDAP group to a cluster so that they have permissions view most cluster level resources and create new projects. Then the OpenLDAP group members will have access to the cluster as soon as they log in to Rancher.
-
-In this scenario, OpenLDAP allows the cluster owner to search for groups when assigning persmissions. Without OpenLDAP, the functionality to search for groups would not be supported.
-
-When a member of the OpenLDAP group logs in to Rancher, she is redirected to Shibboleth and enters her username and password.
-
-Shibboleth validates her credentials, and retrieves user attributes from OpenLDAP, including groups. Then Shibboleth sends a SAML assertion to Rancher including the user attributes. Rancher uses the group data so that she can access all of the resources and permissions that her groups have permissions for.
-
-![Adding OpenLDAP Group Permissions to Rancher Resources](/img/shibboleth-with-openldap-groups.svg)
-
-## SAML and OpenLDAP Group Permissions
-
-<SamlOpenLDAPGroupPermissions />
@@ -1,245 +0,0 @@
---
-title: Migrating Rancher to a New Cluster
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster"/>
-</head>
-
-If you are migrating Rancher to a new Kubernetes cluster, you don't need to install Rancher on the new cluster first. If Rancher is restored to a new cluster with Rancher already installed, it can cause problems.
-
-### Prerequisites
-
-These instructions assume that you have [created a backup](back-up-rancher.md) and  already installed a new Kubernetes cluster where Rancher will be deployed. The backup is specific to the Rancher application and can only migrate the Rancher application.
-
-:::caution
-
-You must use the same hostname that was set as the server URL in the original cluster. If you don't, 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 **Explore** button.
-
-:::
-
-Rancher version must be v2.5.0 and up
-
-Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes clusters such as Amazon EKS clusters. For help installing Kubernetes, refer to the documentation of the Kubernetes distribution. A Rancher-created Kubernetes distributions such as, but not limited to, [RKE](https://rke.docs.rancher.com/installation) or [K3s](https://docs.k3s.io/installation) may also be used.
-
-Since Rancher can be installed on any Kubernetes cluster, you can use this backup and restore method to migrate Rancher from one Kubernetes cluster to any other Kubernetes cluster. This method *only* migrates Rancher-related resources and won't affect other applications on the cluster. Refer to the [support matrix](https://www.suse.com/lifecycle/) to identify which Kubernetes cluster types and versions are supported for your Rancher version.
-
-### 1. Install the rancher-backup Helm chart
-
-Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-operator/tags):
-
-  1. Add the Helm repository:
-
-     ```bash
-     helm repo add rancher-charts https://charts.rancher.io
-     helm repo update
-     ```
-
-  1. Set a `CHART_VERSION` variable, selecting a `rancher-backup` chart version compatible with your version of Rancher. See the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions), within the **Rancher Apps / Cluster Tools** section, to see which `rancher-backup` versions are supported:
-
-     ```bash
-     CHART_VERSION=<chart-version>
-     ```
-
-  1. Install the charts:
-
-     ```bash
-     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
-     ```
-
-     :::note
-
-     The above assumes an environment with outbound connectivity to Docker Hub.
-
-     For an **air-gapped environment**, use the following Helm values to pull the `backup-restore-operator` and `kubectl` images from your private registry when you install the rancher-backup Helm chart.
-
-     ```bash
-     --set image.repository=<registry>/rancher/backup-restore-operator --set global.kubectl.repository=<registry>/rancher/kubectl
-     ```
-
-     If the host running the Helm commands is **also air-gapped and cannot reach charts.rancher.io**, download the charts on a non-air-gapped host and then install them from local files on the air-gapped host.
-
-     On a non-air-gapped host:
-
-     ```bash
-     helm repo add rancher-charts https://charts.rancher.io
-     helm repo update
-     helm fetch rancher-charts/rancher-backup-crd --version $CHART_VERSION
-     helm fetch rancher-charts/rancher-backup --version $CHART_VERSION
-     ```
-
-     Copy the `rancher-backup-crd-<chart-version>.tgz` and `rancher-backup-<chart-version>.tgz` files to the air-gapped host, then use them to install the charts:
-
-     ```bash
-     helm install rancher-backup-crd ./rancher-backup-crd-<chart-version>.tgz -n cattle-resources-system --create-namespace
-     helm install rancher-backup ./rancher-backup-<chart-version>.tgz -n cattle-resources-system --set image.repository=<registry>/rancher/backup-restore-operator --set global.kubectl.repository=<registry>/rancher/kubectl
-     ```
-
-     :::
-
-### 2. Restore from backup using a Restore custom resource
-
-1. When using S3 object storage as the backup source for a restore that requires credentials, create a `Secret` object in this cluster to add the S3 credentials. The secret data must have two keys - `accessKey`, and `secretKey`, that contain the S3 credentials.
-
-   The secret can be created in any namespace, this example uses the default namespace.
-
-   ```bash
-   kubectl create secret generic s3-creds \
-     --from-literal=accessKey=<access key> \
-     --from-literal=secretKey=<secret key>
-   ```
-
-   :::note
-
-   Add your access key and secret key as values for `accessKey` and `secretKey` in the command above.
-
-   :::
-
-1. Create a `Restore` object:
-
-   During a migration, `prune` must be set to `false`. See the example below:
-
-   ```yaml
-   # restore-migration.yaml
-   apiVersion: resources.cattle.io/v1
-   kind: Restore
-   metadata:
-     name: restore-migration
-   spec:
-     backupFilename: backup-b0450532-cee1-4aa1-a881-f5f48a007b1c-2020-09-15T07-27-09Z.tar.gz
-     // highlight-next-line
-     prune: false
-     // highlight-next-line
-     encryptionConfigSecretName: encryptionconfig
-     storageLocation:
-       s3:
-         credentialSecretName: s3-creds
-         credentialSecretNamespace: default
-         bucketName: backup-test
-         folder: ecm1
-         region: us-west-2
-         endpoint: s3.us-west-2.amazonaws.com
-   ```
-
-   :::note Important
-
-   The field `encryptionConfigSecretName` should be used only if your backup was created with encryption enabled.
-
-   If this applies, provide the name of the `Secret` object containing the encryption config file. If you only have the encryption config file, but don't have the secret created in this cluster, use the following steps to create the secret:
-
-   1. Create an [encryption configuration file](../../../reference-guides/backup-restore-configuration/backup-configuration.md#encryption)
-   1. The command below uses a file named `encryption-provider-config.yaml`, with the `--from-file` flag. Run the below once the `EncryptionConfiguration` is saved in a file called `encryption-provider-config.yaml`:
-
-      ```bash
-      kubectl create secret generic encryptionconfig \
-        --from-file=./encryption-provider-config.yaml \
-        -n cattle-resources-system
-      ```
-
-   :::
-
-1. Apply the manifest, and monitor the Restore status:
-   1. Apply the `Restore` object resource:
-
-      ```bash
-      kubectl apply -f restore-migration.yaml
-      ```
-
-   1. Watch the Restore status:
-      ```bash
-      kubectl get restore
-      ```
-
-   1. Watch the restoration logs:
-      ```bash
-      kubectl logs -n cattle-resources-system --tail 100 -f -l app.kubernetes.io/instance=rancher-backup
-      ```
-
-   1. Once the Restore resource has the status `Completed`, you can continue the cert-manager and Rancher installation.
-
-:::note Important:
-
-When migrating Rancher between any two different Kubernetes distributions (e.g. from K3s to RKE2), the object representing the local cluster has to be modified to allow Rancher to detect the new distribution. After the restoration is completed, and **before** bringing up Rancher on the new cluster, edit the local cluster object:
-
-```bash
-kubectl edit clusters.management.cattle.io local
-```
-
-1. Change the value of `status.driver` to `imported`.
-1. Remove `status.provider`.
-1. Remove the entire `status.version` map.
-1. Remove the label with the key `provider.cattle.io` in `metadata.labels`.
-1. Remove the annotation with the key `management.cattle.io/current-cluster-controllers-version` in `metadata.annotations`.
-1. Remove the entire `spec.rke2Config` or `spec.k3sConfig` map, if present.
-1. Save the changes.
-
-Note that removing `spec.rke2Config` or `spec.k3sConfig` will erase your distribution-specific upgrade configuration for the local cluster. It can be [reconfigured](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md) if the new distribution is configurable for the local cluster.
-
-:::
-
-### 3. Install cert-manager
-
-Follow the steps to [install cert-manager](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md#4-install-cert-manager) in the documentation about installing cert-manager on Kubernetes.
-
-### 4. Bring up Rancher with Helm
-
-Use the same version of Helm to install Rancher, that was used on the first cluster.
-
-
-```bash
-helm install rancher rancher-latest/rancher \
-  --namespace cattle-system \
-  --set hostname=<same hostname as the server URL from the first Rancher server> \
-  --version x.y.z
-```
-
-:::note
-
-If the original Rancher environment is running, you can collect the current values with a kubeconfig for the original environment:
-
-```bash
-helm get values rancher -n cattle-system -o yaml > rancher-values.yaml
-```
-
-These values can be reused using the `rancher-values.yaml` file. Be sure to switch the kubeconfig to the new Rancher environment.
-
-```bash
-helm install rancher rancher-latest/rancher -n cattle-system -f rancher-values.yaml --version x.y.z
-```
-
-:::
-
-### 5. Redirect Traffic to the New Cluster
-
-After migration completes, update your DNS records and any load balancers, so that traffic is routed correctly to the migrated cluster. Remember that you must use the same hostname that was set as the server URL in the original cluster.
-
-Full instructions on how to redirect traffic to the migrated cluster differ based on your specific environment. Refer to your hosting provider's documentation for more details.
-
-### 6. Scale Down the Original Rancher Instance
-
-After redirecting traffic to the new Rancher environment, **scale the original Rancher instance to 0 replicas** so it no longer contacts your managed clusters.
-
-Leaving the old server up can cause agents to keep contacting the original `server-url`, which often leaves clusters stuck in **Updating** in the new environment.
-
-```bash
-kubectl scale deployment rancher -n cattle-system --replicas=0
-```
-
-If you originally ran Rancher in Docker:
-
-```bash
-docker stop <original-rancher-container>
-```
-
-:::note
-
-If clusters do not automatically reconnect to the new environment after you have redirected traffic, for example if there is a delay in scaling down the original Rancher instance, you can also restart the cattle-cluster-agent pods on each cluster connected to your Rancher environment.
-
-```bash
-kubectl rollout restart deployment cattle-cluster-agent -n cattle-system
-```
-
-This triggers a rolling restart of the agent so it re-establishes the connection to the new Rancher environment.
-
-:::
@@ -1,174 +0,0 @@
---
-title: Setting up Amazon ELB Network Load Balancer
---
-
-<head> 
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer"/>
-</head>
-
-This how-to guide describes how to set up a Network Load Balancer (NLB) in Amazon's EC2 service that will direct traffic to multiple instances on EC2.
-
-These examples show the load balancer being configured to direct traffic to three Rancher server nodes. If Rancher is installed on a K3s Kubernetes cluster, only two nodes are required.
-
-This tutorial is about one possible way to set up your load balancer, not the only way. Other types of load balancers, such as a Classic Load Balancer or Application Load Balancer, could also direct traffic to the Rancher server nodes.
-
-Rancher only supports using the Amazon NLB when terminating traffic in `tcp` mode for port 443 rather than `tls` mode. This is due to the fact that the NLB does not inject the correct headers into requests when terminated at the NLB. This means that if you want to use certificates managed by the Amazon Certificate Manager (ACM), you should use an ALB.
-
-## Requirements
-
-These instructions assume you have already created Linux instances in EC2. The load balancer will direct traffic to these nodes.
-
-## 1. Create Target Groups
-
-Begin by creating two target groups for the **TCP** protocol, one with TCP port 443 and one regarding TCP port 80 (providing redirect to TCP port 443). You'll add your Linux nodes to these groups.
-
-Your first NLB configuration step is to create two target groups. Technically, only port 443 is needed to access Rancher, but it's convenient to add a listener for port 80, because traffic to port 80 will be automatically redirected to port 443.
-
-The Traefik Ingress should redirect traffic from port 80 to port 443.
-
-1. Log into the [Amazon AWS Console](https://console.aws.amazon.com/ec2/) to get started. Make sure to select the **Region** where your EC2 instances (Linux nodes) are created.
-1. Select **Services** and choose **EC2**, find the section **Load Balancing** and open **Target Groups**.
-1. Click **Create target group** to create the first target group, regarding TCP port 443.
-
-:::note
-
-For details on Traefik Ingress health checks, refer to [this section.](#health-check-paths-for-traefik-ingresses)
-
-:::
-
-#### Target Group (TCP port 443)
-
-Configure the first target group according to the table below.
-
-| Option            | Setting           |
-|-------------------|-------------------|
-| Target Group Name | `rancher-tcp-443` |
-| Target type       | `instance`        |
-| Protocol          | `TCP`             |
-| Port              | `443`             |
-| VPC               | Choose your VPC   |
-
-Health check settings:
-
-| Option              | Setting         |
-|---------------------|-----------------|
-| Protocol            | TCP             |
-| Port                | `override`,`80` |
-| Healthy threshold   | `3`             |
-| Unhealthy threshold | `3`             |
-| Timeout             | `6 seconds`     |
-| Interval            | `10 seconds`    |
-
-Click **Create target group** to create the second target group, regarding TCP port 80.
-
-#### Target Group (TCP port 80)
-
-Configure the second target group according to the table below.
-
-| Option            | Setting          |
-|-------------------|------------------|
-| Target Group Name | `rancher-tcp-80` |
-| Target type       | `instance`       |
-| Protocol          | `TCP`            |
-| Port              | `80`             |
-| VPC               | Choose your VPC  |
-
-
-Health check settings:
-
-| Option              |Setting         |
-|---------------------|----------------|
-| Protocol            | TCP            |
-| Port                | `traffic port` |
-| Healthy threshold   | `3`            |
-| Unhealthy threshold | `3`            |
-| Timeout             | `6 seconds`    |
-| Interval            | `10 seconds`   |
-
-## 2. Register Targets
-
-Next, add your Linux nodes to both target groups.
-
-Select the target group named **rancher-tcp-443**, click the tab **Targets** and choose **Edit**.
-
-![](/img/ha/nlb/edit-targetgroup-443.png)
-
-Select the instances (Linux nodes) you want to add, and click **Add to registered**.
-
-***
-**Screenshot Add targets to target group TCP port 443**<br/>
-
-![](/img/ha/nlb/add-targets-targetgroup-443.png)
-
-***
-**Screenshot Added targets to target group TCP port 443**<br/>
-
-![](/img/ha/nlb/added-targets-targetgroup-443.png)
-
-When the instances are added, click **Save** on the bottom right of the screen.
-
-Repeat those steps, replacing **rancher-tcp-443** with **rancher-tcp-80**. The same instances need to be added as targets to this target group.
-
-## 3. Create Your NLB
-
-Use Amazon's Wizard to create a Network Load Balancer. As part of this process, you'll add the target groups you created in [1. Create Target Groups](#1-create-target-groups).
-
-1.  From your web browser, navigate to the [Amazon EC2 Console](https://console.aws.amazon.com/ec2/).
-
-2.  From the navigation pane, choose **LOAD BALANCING** > **Load Balancers**.
-
-3.  Click **Create Load Balancer**.
-
-4.  Choose **Network Load Balancer** and click **Create**. Then complete each form.
-
- [Step 1: Configure Load Balancer](#step-1-configure-load-balancer)
- [Step 2: Configure Routing](#step-2-configure-routing)
- [Step 3: Register Targets](#step-3-register-targets)
- [Step 4: Review](#step-4-review)
-
-### Step 1: Configure Load Balancer
-
-Set the following fields in the form:
-
- **Name:** `rancher`
- **Scheme:** `internal` or `internet-facing`. The scheme that you choose for your NLB is dependent on the configuration of your instances and VPC. If your instances do not have public IPs associated with them, or you will only be accessing Rancher internally, you should set your NLB Scheme to `internal` rather than `internet-facing`.
- **Listeners:** The Load Balancer Protocol should be `TCP` and the corresponding Load Balancer Port should be set to `443`.
- **Availability Zones:** Select Your **VPC** and **Availability Zones**.
-
-### Step 2: Configure Routing
-
-1. From the **Target Group** drop-down, choose **Existing target group**.
-1. From the **Name** drop-down, choose `rancher-tcp-443`.
-1. Open **Advanced health check settings**, and configure **Interval** to `10 seconds`.
-
-### Step 3: Register Targets
-
-Since you registered your targets earlier, all you have to do is click **Next: Review**.
-
-### Step 4: Review
-
-Look over the load balancer details and click **Create** when you're satisfied.
-
-After AWS creates the NLB, click **Close**.
-
-## 4. Add listener to NLB for TCP port 80
-
-1. Select your newly created NLB and select the **Listeners** tab.
-
-2. Click **Add listener**.
-
-3. Use `TCP`:`80` as **Protocol** : **Port**
-
-4. Click **Add action** and choose **Forward to..**.
-
-5. From the **Forward to** drop-down, choose `rancher-tcp-80`.
-
-6. Click **Save** in the top right of the screen.
-
-## Health Check Paths for Traefik Ingresses
-
-K3s Kubernetes clusters use Traefik as the default Ingress.
-
-The health check path is `/ping`. By default `/ping` is always matched (regardless of Host), and a response from [Traefik itself](https://docs.traefik.io/operations/ping/) is always served.
-
-To simulate an accurate health check, it is a best practice to use the Host header (Rancher hostname) combined with `/ping` or `/healthz` wherever possible, to get a response from the Rancher Pods, not the Ingress.
@@ -1,169 +0,0 @@
---
-title: Setting up a High-availability RKE2 Kubernetes Cluster for Rancher
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-cluster-setup/rke2-for-rancher"/>
-</head>
-
-This section describes how to install a Kubernetes cluster according to the [best practices for the Rancher server environment.](../../../reference-guides/rancher-manager-architecture/architecture-recommendations.md#environment-for-kubernetes-installations)
-
-## Prerequisites
-
-These instructions assume you have set up three nodes, a load balancer, and a DNS record, as described in [this section.](../infrastructure-setup/ha-rke2-kubernetes-cluster.md)
-
-Note that in order for RKE2 to work correctly with the load balancer, you need to set up two listeners: one for the supervisor on port 9345, and one for the Kubernetes API on port 6443.
-
-Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/) To specify the RKE2 version, use the INSTALL_RKE2_VERSION environment variable when running the RKE2 installation script.
-
-## Installing Kubernetes
-
-### 1. Install Kubernetes and Set up the RKE2 Server
-
-RKE2 server runs with embedded etcd so you will not need to set up an external datastore to run in HA mode.
-
-On the first node, you should set up the configuration file with your own pre-shared secret as the token. The token argument can be set on startup.
-
-If you do not specify a pre-shared secret, RKE2 will generate one and place it at /var/lib/rancher/rke2/server/node-token.
-
-To avoid certificate errors with the fixed registration address, you should launch the server with the tls-san parameter set. This option adds an additional hostname or IP as a Subject Alternative Name in the server's TLS cert, and it can be specified as a list if you would like to access via both the IP and the hostname.
-
-First, you must create the directory where the RKE2 config file is going to be placed:
-
-```
-mkdir -p /etc/rancher/rke2/
-```
-
-Next, create the RKE2 config file at `/etc/rancher/rke2/config.yaml` using the following example:
-
-```
-token: my-shared-secret
-tls-san:
-  - my-kubernetes-domain.com
-  - another-kubernetes-domain.com
-```
-After that, you need to run the install command and enable and start rke2:
-
-```
-curl -sfL https://get.rke2.io | sh -
-systemctl enable rke2-server.service
-systemctl start rke2-server.service
-```
-1. To join the rest of the nodes, you need to configure each additional node with the same shared token or the one generated automatically. Here is an example of the configuration file:
-
-        token: my-shared-secret
-        server: https://<DNS-DOMAIN>:9345
-        tls-san:
-          - my-kubernetes-domain.com
-          - another-kubernetes-domain.com
-After that, you need to run the installer and enable, then start, rke2:
-
-        curl -sfL https://get.rke2.io | sh -
-        systemctl enable rke2-server.service
-        systemctl start rke2-server.service
-
-
-1. Repeat the same command on your third RKE2 server node.
-
-### 2. Confirm that RKE2 is Running
-
-Once you've launched the rke2 server process on all server nodes, ensure that the cluster has come up properly with
-
-```
-/var/lib/rancher/rke2/bin/kubectl \
-        --kubeconfig /etc/rancher/rke2/rke2.yaml get nodes
-You should see your server nodes in the Ready state.
-```
-
-Then test the health of the cluster pods:
-```
-/var/lib/rancher/rke2/bin/kubectl \
-        --kubeconfig /etc/rancher/rke2/rke2.yaml get pods --all-namespaces
-```
-
-**Result:** You have successfully set up a RKE2 Kubernetes cluster.
-
-### 3. Save and Start Using the kubeconfig File
-
-When you installed RKE2 on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/rke2/rke2.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
-
-To use this `kubeconfig` file,
-
-1. Install [kubectl,](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) a Kubernetes command-line tool.
-2. Copy the file at `/etc/rancher/rke2/rke2.yaml` and save it to the directory `~/.kube/config` on your local machine.
-3. In the kubeconfig file, the `server` directive is defined as localhost. Configure the server as the DNS of your control-plane load balancer, on port 6443. (The RKE2 Kubernetes API Server uses port 6443, while the Rancher server will be served via the Traefik Ingress on ports 80 and 443.) Here is an example `rke2.yaml`:
-
-```yml
-apiVersion: v1
-clusters:
- cluster:
-    certificate-authority-data: [CERTIFICATE-DATA]
-    server: [LOAD-BALANCER-DNS]:6443 # Edit this line
-  name: default
-contexts:
- context:
-    cluster: default
-    user: default
-  name: default
-current-context: default
-kind: Config
-preferences: {}
-users:
- name: default
-  user:
-    password: [PASSWORD]
-    username: admin
-```
-
-**Result:** You can now use `kubectl` to manage your RKE2 cluster. If you have more than one kubeconfig file, you can specify which one you want to use by passing in the path to the file when using `kubectl`:
-
-```
-kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
-```
-
-For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
-
-### 4. Check the Health of Your Cluster Pods
-
-Now that you have set up the `kubeconfig` file, you can use `kubectl` to access the cluster from your local machine.
-
-Check that all the required pods and containers are healthy are ready to continue:
-
-```
-/var/lib/rancher/rke2/bin/kubectl --kubeconfig /etc/rancher/rke2/rke2.yaml get pods -A
-NAMESPACE     NAME                                                    READY   STATUS      RESTARTS   AGE
-kube-system   cloud-controller-manager-rke2-server-1                  1/1     Running     0          2m28s
-kube-system   cloud-controller-manager-rke2-server-2                  1/1     Running     0          61s
-kube-system   cloud-controller-manager-rke2-server-3                  1/1     Running     0          49s
-kube-system   etcd-rke2-server-1                                      1/1     Running     0          2m13s
-kube-system   etcd-rke2-server-2                                      1/1     Running     0          87s
-kube-system   etcd-rke2-server-3                                      1/1     Running     0          56s
-kube-system   helm-install-rke2-canal-hs6sx                           0/1     Completed   0          2m17s
-kube-system   helm-install-rke2-coredns-xmzm8                         0/1     Completed   0          2m17s
-kube-system   helm-install-traefik-crd-z8vsz                          0/1     Completed   0          2m17s
-kube-system   helm-install-traefik-flwnl                              0/1     Completed   0          2m17s
-kube-system   helm-install-rke2-metrics-server-7sggn                  0/1     Completed   0          2m17s
-kube-system   kube-apiserver-rke2-server-1                            1/1     Running     0          116s
-kube-system   kube-apiserver-rke2-server-2                            1/1     Running     0          66s
-kube-system   kube-apiserver-rke2-server-3                            1/1     Running     0          48s
-kube-system   kube-controller-manager-rke2-server-1                   1/1     Running     0          2m30s
-kube-system   kube-controller-manager-rke2-server-2                   1/1     Running     0          57s
-kube-system   kube-controller-manager-rke2-server-3                   1/1     Running     0          42s
-kube-system   kube-proxy-rke2-server-1                                1/1     Running     0          2m25s
-kube-system   kube-proxy-rke2-server-2                                1/1     Running     0          59s
-kube-system   kube-proxy-rke2-server-3                                1/1     Running     0          85s
-kube-system   kube-scheduler-rke2-server-1                            1/1     Running     0          2m30s
-kube-system   kube-scheduler-rke2-server-2                            1/1     Running     0          57s
-kube-system   kube-scheduler-rke2-server-3                            1/1     Running     0          42s
-kube-system   rke2-canal-b9lvm                                        2/2     Running     0          91s
-kube-system   rke2-canal-khwp2                                        2/2     Running     0          2m5s
-kube-system   rke2-canal-swfmq                                        2/2     Running     0          105s
-kube-system   rke2-coredns-rke2-coredns-547d5499cb-6tvwb              1/1     Running     0          92s
-kube-system   rke2-coredns-rke2-coredns-547d5499cb-rdttj              1/1     Running     0          2m8s
-kube-system   rke2-coredns-rke2-coredns-autoscaler-65c9bb465d-85sq5   1/1     Running     0          2m8s
-kube-system   traefik-7c844b766f-m9p2w                                1/1     Running     0          52s
-kube-system   traefik-7c844b766f-s4l9k                                1/1     Running     0          52s
-kube-system   rke2-metrics-server-6564db4569-vdfkn                    1/1     Running     0          66s
-```
-
-**Result:** You have confirmed that you can access the cluster with `kubectl` and the RKE2 cluster is running successfully. Now the Rancher management server can be installed on the cluster.
@@ -1,330 +0,0 @@
---
-title: Kubernetes Resources
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/troubleshooting/other-troubleshooting-tips/kubernetes-resources"/>
-</head>
-
-The commands/steps listed on this page can be used to check the most important Kubernetes resources and apply to [Rancher Launched Kubernetes](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) clusters.
-
-Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI.
-
-
-## Nodes
-
-### Get nodes
-
-Run the command below and check the following:
-
- All nodes in your cluster should be listed, make sure there is not one missing.
- All nodes should have the **Ready** status (if not in **Ready** state, check the `kubelet` container logs on that node using `docker logs kubelet`)
- Check if all nodes report the correct version.
- Check if OS/Kernel/Docker values are shown as expected (possibly you can relate issues due to upgraded OS/Kernel/Docker)
-
-
-```
-kubectl get nodes -o wide
-```
-
-Example output:
-
-```
-NAME             STATUS   ROLES          AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
-controlplane-0   Ready    controlplane   31m   v1.13.5   138.68.188.91    <none>        Ubuntu 18.04.2 LTS   4.15.0-47-generic   docker://18.9.5
-etcd-0           Ready    etcd           31m   v1.13.5   138.68.180.33    <none>        Ubuntu 18.04.2 LTS   4.15.0-47-generic   docker://18.9.5
-worker-0         Ready    worker         30m   v1.13.5   139.59.179.88    <none>        Ubuntu 18.04.2 LTS   4.15.0-47-generic   docker://18.9.5
-```
-
-### Get node conditions
-
-Run the command below to list nodes with [Node Conditions](https://kubernetes.io/docs/concepts/architecture/nodes/#condition)
-
-```
-kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{end}}'
-```
-
-Run the command below to list nodes with [Node Conditions](https://kubernetes.io/docs/concepts/architecture/nodes/#condition) that are active that could prevent normal operation.
-
-```
-kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{if ne .type "Ready"}}{{if eq .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{else}}{{if ne .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{": "}}{{.status}}{{"\n"}}{{end}}{{end}}{{end}}{{end}}'
-```
-
-Example output:
-
-```
-worker-0: DiskPressure:True
-```
-
-## Kubernetes leader election
-
-### Kubernetes Controller Manager leader
-
-The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `kube-controller-manager` endpoint (in this example, `controlplane-0`).
-
-```
-kubectl -n kube-system get endpoints kube-controller-manager -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
-{"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}>
-```
-
-### Kubernetes Scheduler leader
-
-The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `kube-scheduler` endpoint (in this example, `controlplane-0`).
-
-```
-kubectl -n kube-system get endpoints kube-scheduler -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
-{"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}>
-```
-
-## Ingress Controller
-
-The default Ingress Controller is Traefik and is deployed as a DaemonSet in the `kube-system` namespace. The pods are only scheduled to nodes with the `worker` role.
-
-Check if the pods are running on all nodes:
-
-```
-kubectl -n kube-system get pods -o wide
-```
-
-Example RKE2 output:
-
-```
-kubectl -n kube-system get pods -o wide
-NAME                                    READY     STATUS    RESTARTS   AGE       IP               NODE
-local-path-provisioner-xxxxxxxxxx-xxxxx 1/1       Running   0          17m       x.x.x.x          worker-1
-rke2-traefik-xxxxxxxxxx-xxxxx           1/1       Running   0          14m       x.x.x.x          worker-1
-svclb-rke2-traefik-xxxxxxxx-xxxxx       1/1       Running   0          13m       x.x.x.x          worker-0
-...
-```
-
-Example K3s output:
-
-```
-kubectl -n kube-system get pods -o wide
-NAME                                    READY     STATUS    RESTARTS   AGE       IP               NODE
-local-path-provisioner-xxxxxxxxxx-xxxxx 1/1       Running   0          17m       x.x.x.x          worker-1
-traefik-xxxxxxxxxx-xxxxx                1/1       Running   0          14m       x.x.x.x          worker-1
-svclb-traefik-xxxxxxxx-xxxxx            1/1       Running   0          13m       x.x.x.x          worker-0
-...
-```
-
-If a pod is unable to run (Status is not **Running**, Ready status is not showing `1/1` or you see a high count of Restarts), check the pod details, logs and namespace events.
-
-### Pod details
-
-RKE2 example:
-
-```
-kubectl -n kube-system describe pods -l app.kubernetes.io/name=rke2-traefik
-```
-
-K3s example:
-
-```
-kubectl -n kube-system describe pods -l app.kubernetes.io/name=traefik
-```
-
-### Pod container logs
-
-The below command can show the logs of all the pods labeled "app.kubernetes.io/name=rke2-traefik" if using RKE2 or "app.kubernetes.io/name=traefik" if using K3s, but it will display only 10 lines of log because of the restrictions of the `kubectl logs` command. Refer to `--tail` of `kubectl logs -h` for more information.
-
-RKE2 example:
-
-```
-kubectl -n kube-system logs -l app.kubernetes.io/name=rke2-traefik
-```
-
-K3s example:
-
-```
-kubectl -n kube-system logs -l app.kubernetes.io/name=traefik
-```
-
-If the full log is needed, specify the pod name in the trailing command:
-
-```
-kubectl -n kube-system logs <pod name>
-```
-
-### Namespace events
-
-```
-kubectl -n kube-system get events
-```
-
-### Debug logging
-
-To enable debug logging:
-
-RKE2 example:
-
-```
-cat <<EOF | kubectl apply -f -
-apiVersion: helm.cattle.io/v1
-kind: HelmChartConfig
-metadata:
-  name: rke2-traefik
-  namespace: kube-system
-spec:
-  valuesContent: |-
-    additionalArguments:
-      - "--log.level=DEBUG"
-EOF
-```
-
-K3s example:
-
-```
-cat <<EOF | kubectl apply -f -
-apiVersion: helm.cattle.io/v1
-kind: HelmChartConfig
-metadata:
-  name: traefik
-  namespace: kube-system
-spec:
-  valuesContent: |-
-    logs:
-      general:
-        level: "DEBUG"
-EOF
-```
-
-### Check configuration
-
-Retrieve generated configuration in each pod:
-
-RKE2 example for manual Traefik configuration file check:
-
-```
-kubectl exec -n kube-system pod/traefik-xxxxxxxxx-xxxxx -- cat /var/lib/rancher/rke2/server/manifests/rke2-traefik-config.yaml
-```
-
-K3s example for manual Traefik configuration file check:
-
-```
-kubectl exec -n kube-system pod/traefik-xxxxxxxxx-xxxxx -- cat /var/lib/rancher/k3s/server/manifests/k3s-traefik-config.yaml
-```
-
-RKE2/K3s example for Traefik CLI argument configuration check:
-
-```
-kubectl get pod traefik-xxxxxxxxx-xxxxx -n kube-system -o jsonpath='{.spec.containers[0].args}'
-```
-
-## Rancher agents
-
-Communication to the cluster (Kubernetes API via `cattle-cluster-agent`) and communication to the nodes (cluster provisioning via `cattle-node-agent`) is done through Rancher agents.
-
-#### cattle-node-agent
-
-Check if the cattle-node-agent pods are present on each node, have status **Running** and don't have a high count of Restarts:
-
-```
-kubectl -n cattle-system get pods -l app=cattle-agent -o wide
-```
-
-Example output:
-
-```
-NAME                      READY     STATUS    RESTARTS   AGE       IP                NODE
-cattle-node-agent-4gc2p   1/1       Running   0          2h        x.x.x.x           worker-1
-cattle-node-agent-8cxkk   1/1       Running   0          2h        x.x.x.x           etcd-1
-cattle-node-agent-kzrlg   1/1       Running   0          2h        x.x.x.x           etcd-0
-cattle-node-agent-nclz9   1/1       Running   0          2h        x.x.x.x           controlplane-0
-cattle-node-agent-pwxp7   1/1       Running   0          2h        x.x.x.x           worker-0
-cattle-node-agent-t5484   1/1       Running   0          2h        x.x.x.x           controlplane-1
-cattle-node-agent-t8mtz   1/1       Running   0          2h        x.x.x.x           etcd-2
-```
-
-Check logging of a specific cattle-node-agent pod or all cattle-node-agent pods:
-
-```
-kubectl -n cattle-system logs -l app=cattle-agent
-```
-
-#### cattle-cluster-agent
-
-Check if the cattle-cluster-agent pod is present in the cluster, has status **Running** and doesn't have a high count of Restarts:
-
-```
-kubectl -n cattle-system get pods -l app=cattle-cluster-agent -o wide
-```
-
-Example output:
-
-```
-NAME                                    READY     STATUS    RESTARTS   AGE       IP           NODE
-cattle-cluster-agent-54d7c6c54d-ht9h4   1/1       Running   0          2h        x.x.x.x      worker-1
-```
-
-Check logging of cattle-cluster-agent pod:
-
-```
-kubectl -n cattle-system logs -l app=cattle-cluster-agent
-```
-
-## Jobs and Pods
-
-### Check that pods or jobs have status **Running**/**Completed**
-
-To check, run the command:
-
-```
-kubectl get pods --all-namespaces
-```
-
-If a pod is not in **Running** state, you can dig into the root cause by running:
-
-### Describe pod
-
-```
-kubectl describe pod POD_NAME -n NAMESPACE
-```
-
-### Pod container logs
-
-```
-kubectl logs POD_NAME -n NAMESPACE
-```
-
-If a job is not in **Completed** state, you can dig into the root cause by running:
-
-### Describe job
-
-```
-kubectl describe job JOB_NAME -n NAMESPACE
-```
-
-### Logs from the containers of pods of the job
-
-```
-kubectl logs -l job-name=JOB_NAME -n NAMESPACE
-```
-
-### Evicted pods
-
-Pods can be evicted based on [eviction signals](https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#eviction-policy).
-
-Retrieve a list of evicted pods (podname and namespace):
-
-```
-kubectl get pods --all-namespaces -o go-template='{{range .items}}{{if eq .status.phase "Failed"}}{{if eq .status.reason "Evicted"}}{{.metadata.name}}{{" "}}{{.metadata.namespace}}{{"\n"}}{{end}}{{end}}{{end}}'
-```
-
-To delete all evicted pods:
-
-```
-kubectl get pods --all-namespaces -o go-template='{{range .items}}{{if eq .status.phase "Failed"}}{{if eq .status.reason "Evicted"}}{{.metadata.name}}{{" "}}{{.metadata.namespace}}{{"\n"}}{{end}}{{end}}{{end}}' | while read epod enamespace; do kubectl -n $enamespace delete pod $epod; done
-```
-
-Retrieve a list of evicted pods, scheduled node and the reason:
-
-```
-kubectl get pods --all-namespaces -o go-template='{{range .items}}{{if eq .status.phase "Failed"}}{{if eq .status.reason "Evicted"}}{{.metadata.name}}{{" "}}{{.metadata.namespace}}{{"\n"}}{{end}}{{end}}{{end}}' | while read epod enamespace; do kubectl -n $enamespace get pod $epod -o=custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,MSG:.status.message; done
-```
-
-### Job does not complete
-
-If you have enabled Istio, and you are having issues with a Job you deployed not completing, you will need to add an annotation to your pod using [these steps.](../../how-to-guides/advanced-user-guides/istio-setup-guide/enable-istio-in-namespace.md)
-
-Since Istio Sidecars run indefinitely, a Job cannot be considered complete even after its task has completed. This is a temporary workaround and will disable Istio for any traffic to/from the annotated Pod. Keep in mind this may not allow you to continue to use a Job for integration testing, as the Job will not have access to the service mesh.
@@ -1,118 +0,0 @@
---
-title: Networking
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/troubleshooting/other-troubleshooting-tips/networking"/>
-</head>
-
-The commands/steps listed on this page can be used to check networking related issues in your cluster.
-
-Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI.
-
-## Double Check if All the Required Ports are Opened in Your (Host) Firewall
-
-Double check if all the [required ports](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) are opened in your (host) firewall. The overlay network uses UDP in comparison to all other required ports which are TCP.
-
-
-## Check if your downstream node can communicate to Rancher Manager
-
-Rancher components with HTTP endpoints generally contain a `ping` liveness probe which you can use to test connectivity. Replace the `$RANCHER_URL` as appropriate and run the following from a node to check that it has connectivity to Rancher Manager's servers in the `local` cluster. If successful, it should return `pong`.
-
-```
-curl -k https://$RANCHER_URL/ping 
-```
-
-## Check if Overlay Network is Functioning Correctly
-
-The pod can be scheduled to any of the hosts you used for your cluster, but that means that the NGINX ingress controller needs to be able to route the request from `NODE_1` to `NODE_2`. This happens over the overlay network. If the overlay network is not functioning, you will experience intermittent TCP/HTTP connection failures due to the NGINX ingress controller not being able to route to the pod.
-
-To test the overlay network, you can launch the following `DaemonSet` definition. This will run a `swiss-army-knife` container on every host (image was developed by Rancher engineers and can be found here: https://github.com/rancherlabs/swiss-army-knife), which we will use to run a `ping` test between containers on all hosts.
-
-:::caution
-
-The `swiss-army-knife` container does not support Windows nodes. It also [does not support ARM nodes](https://github.com/leodotcloud/swiss-army-knife/issues/18), such as a Raspberry Pi. When the test encounters incompatible nodes, this is recorded in the pod logs as an error message, such as `exec user process caused: exec format error` for ARM nodes, or `ImagePullBackOff (Back-off pulling image "rancherlabs/swiss-army-knife)` for Windows nodes.
-
-:::
-
-1. Save the following file as `overlaytest.yml`
-
-    ```
-    apiVersion: apps/v1
-    kind: DaemonSet
-    metadata:
-      name: overlaytest
-    spec:
-      selector:
-          matchLabels:
-            name: overlaytest
-      template:
-        metadata:
-          labels:
-            name: overlaytest
-        spec:
-          tolerations:
-          - operator: Exists
-          containers:
-          - image: rancherlabs/swiss-army-knife
-            imagePullPolicy: Always
-            name: overlaytest
-            command: ["sleep", "infinity"]
-            terminationMessagePath: /dev/termination-log
-
-    ```
-
-2. Launch it using `kubectl create -f overlaytest.yml`
-3. Wait until `kubectl rollout status ds/overlaytest -w` returns: `daemon set "overlaytest" successfully rolled out`.
-4. Run the following script, from the same location.  It will have each `overlaytest` container on every host ping each other:
-    ```
-    #!/bin/bash
-    echo "=> Start network overlay test"
-      kubectl get pods -l name=overlaytest -o jsonpath='{range .items[*]}{@.metadata.name}{" "}{@.spec.nodeName}{"\n"}{end}' |
-      while read spod shost
-        do kubectl get pods -l name=overlaytest -o jsonpath='{range .items[*]}{@.status.podIP}{" "}{@.spec.nodeName}{"\n"}{end}' |
-        while read tip thost
-          do kubectl --request-timeout='10s' exec $spod -c overlaytest -- /bin/sh -c "ping -c2 $tip > /dev/null 2>&1"
-            RC=$?
-            if [ $RC -ne 0 ]
-              then echo FAIL: $spod on $shost cannot reach pod IP $tip on $thost
-              else echo $shost can reach $thost
-            fi
-        done
-      done
-    echo "=> End network overlay test"
-    ```
-
-5. When this command has finished running, it will output the state of each route:
-
-    ```
-    => Start network overlay test
-    Error from server (NotFound): pods "wk2" not found
-    FAIL: overlaytest-5bglp on wk2 cannot reach pod IP 10.42.7.3 on wk2
-    Error from server (NotFound): pods "wk2" not found
-    FAIL: overlaytest-5bglp on wk2 cannot reach pod IP 10.42.0.5 on cp1
-    Error from server (NotFound): pods "wk2" not found
-    FAIL: overlaytest-5bglp on wk2 cannot reach pod IP 10.42.2.12 on wk1
-    command terminated with exit code 1
-    FAIL: overlaytest-v4qkl on cp1 cannot reach pod IP 10.42.7.3 on wk2
-    cp1 can reach cp1
-    cp1 can reach wk1
-    command terminated with exit code 1
-    FAIL: overlaytest-xpxwp on wk1 cannot reach pod IP 10.42.7.3 on wk2
-    wk1 can reach cp1
-    wk1 can reach wk1
-    => End network overlay test
-    ```
-    If you see error in the output, there is some issue with the route between the pods on the two hosts.  In the above output the node `wk2` has no connectivity over the overlay network. This could be because the [required ports](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for overlay networking are not opened for `wk2`.
-6. You can now clean up the DaemonSet by running `kubectl delete ds/overlaytest`.
-
-
-### Check if MTU is Correctly Configured on Hosts and on Peering/Tunnel Appliances/Devices
-
-When the MTU is incorrectly configured (either on hosts running Rancher, nodes in created/imported clusters or on appliances/devices in between), error messages will be logged in Rancher and in the agents, similar to:
-
-* `websocket: bad handshake`
-* `Failed to connect to proxy`
-* `read tcp: i/o timeout`
-
-See [Google Cloud VPN: MTU Considerations](https://cloud.google.com/vpn/docs/concepts/mtu-considerations#gateway_mtu_vs_system_mtu) for an example how to configure MTU correctly when using Google Cloud VPN between Rancher and cluster nodes.
@@ -1,112 +0,0 @@
---
-title: Rancher HA
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/troubleshooting/other-troubleshooting-tips/rancher-ha"/>
-</head>
-
-The commands/steps listed on this page can be used to check your Rancher Kubernetes Installation.
-
-Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml`).
-
-## Check Rancher Pods
-
-Rancher pods are deployed as a Deployment in the `cattle-system` namespace.
-
-Check if the pods are running on all nodes:
-
-```
-kubectl -n cattle-system get pods -l app=rancher -o wide
-```
-
-Example output:
-
-```
-NAME                       READY   STATUS    RESTARTS   AGE   IP          NODE
-rancher-7dbd7875f7-n6t5t   1/1     Running   0          8m    x.x.x.x     x.x.x.x
-rancher-7dbd7875f7-qbj5k   1/1     Running   0          8m    x.x.x.x     x.x.x.x
-rancher-7dbd7875f7-qw7wb   1/1     Running   0          8m    x.x.x.x     x.x.x.x
-```
-
-If a pod is unable to run (Status is not **Running**, Ready status is not showing `1/1` or you see a high count of Restarts), check the pod details, logs and namespace events.
-
-### Pod Details
-
-```
-kubectl -n cattle-system describe pods -l app=rancher
-```
-
-### Pod Container Logs
-
-```
-kubectl -n cattle-system logs -l app=rancher
-```
-
-### Namespace Events
-
-```
-kubectl -n cattle-system get events
-```
-
-## Check Ingress
-
-Ingress should have the correct `HOSTS` (showing the configured FQDN) and `ADDRESS` (host address(es) it will be routed to).
-
-```
-kubectl -n cattle-system get ingress
-```
-
-Example output:
-
-```
-NAME      HOSTS                    ADDRESS                   PORTS     AGE
-rancher   rancher.yourdomain.com   x.x.x.x,x.x.x.x,x.x.x.x   80, 443   2m
-```
-
-## Check Ingress Controller Logs
-
-When accessing your configured Rancher FQDN does not show you the UI, check the ingress controller logging to see what happens when you try to access Rancher:
-
-```
-kubectl -n traefik logs -l app=traefik
-```
-
-## Leader Election
-
-The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` Lease in the `kube-system` namespace (in this example, `rancher-dbc7ff869-gvg6k`).
-
-```
-kubectl -n kube-system get lease cattle-controllers
-```
-
-Example output:
-
-```
-NAME                 HOLDER                    AGE
-cattle-controllers   rancher-dbc7ff869-gvg6k   6h10m
-```
-
-### Configuration
-
-_Available as of Rancher 2.8.3_
-
-If the Kubernetes API experiences latency, the Rancher replica holding the leader lock may not be able to renew the lease before the lease becomes invalid, which can be observed in the Rancher logs:
-```
-E0629 04:13:07.293461      34 leaderelection.go:364] Failed to update lock: Put "https://172.17.0.1:443/apis/coordination.k8s.io/v1/namespaces/kube-system/leases/cattle-controllers?timeout=15m0s": context deadline exceeded
-I0629 04:13:07.293594      34 leaderelection.go:280] failed to renew lease kube-system/cattle-controllers: timed out waiting for the condition
-...
-2024/06/29 04:13:10 [FATAL] leaderelection lost for cattle-controllers
-```
-
-To mitigate this, you can set environment variables in the `rancher` Deployment to modify the default parameters for leader election:
- `CATTLE_ELECTION_LEASE_DURATION`: The [lease duration](https://pkg.go.dev/k8s.io/client-go/tools/leaderelection#LeaderElectionConfig.LeaseDuration). The default value is 45s.
- `CATTLE_ELECTION_RENEW_DEADLINE`: The [renew deadline](https://pkg.go.dev/k8s.io/client-go/tools/leaderelection#LeaderElectionConfig.RenewDeadline). The default value is 30s.
- `CATTLE_ELECTION_RETRY_PERIOD`: The [retry period](https://pkg.go.dev/k8s.io/client-go/tools/leaderelection#LeaderElectionConfig.RetryPeriod). The default value is 2s.
-
-Example:
-```
-kubectl -n cattle-system set env deploy/rancher CATTLE_ELECTION_LEASE_DURATION=2m CATTLE_ELECTION_RENEW_DEADLINE=90s CATTLE_ELECTION_RETRY_PERIOD=10s
-```
-This will temporarily increase the lease duration, renew deadline and retry period to 120, 90 and 10 seconds respectively.
-Alternatively, in order to make such changes permanent, these environment variables can be set by [using Helm values](../../getting-started/installation-and-upgrade/installation-references/helm-chart-options.md#setting-extra-environment-variables) instead.
@@ -1,22 +1,24 @@
-| Action | Rancher Launched Kubernetes Clusters |  EKS, GKE and AKS Clusters<sup>1</sup> | Other Hosted Kubernetes Clusters | Non-EKS or GKE Registered Clusters |
-| --- | --- | ---| ---|----|
-| [Using kubectl and a kubeconfig file to Access a Cluster](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) | ✓ | ✓ | ✓ | ✓ |
-| [Managing Cluster Members](../how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md) | ✓ | ✓ | ✓ | ✓ |
-| [Editing and Upgrading Clusters](../reference-guides/cluster-configuration/cluster-configuration.md) | ✓ | ✓ | ✓ | ✓<sup>2</sup> |
-| [Managing Nodes](../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md) | ✓ | ✓ | ✓ | ✓<sup>3</sup> |
-| [Managing Persistent Volumes and Storage Classes](../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) | ✓ | ✓ | ✓ | ✓ |
-| [Managing Projects, Namespaces and Workloads](../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md) | ✓ | ✓ | ✓ | ✓ |
-| [Using App Catalogs](../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md) | ✓ | ✓ | ✓ | ✓ |
-| Configuring Tools ([Alerts, Notifiers, Monitoring](../integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md), [Logging](../integrations-in-rancher/logging/logging.md), [Istio](../integrations-in-rancher/istio/istio.md)) | ✓ | ✓ | ✓ | ✓ |
-| [Running Security Scans](../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) | ✓ | ✓ | ✓ | ✓ |
-| [Ability to rotate certificates](../how-to-guides/new-user-guides/manage-clusters/rotate-certificates.md) | ✓ | ✓  |  | |
-| Ability to [backup](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md) and [restore](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Rancher-launched clusters | ✓ | ✓ |  | ✓<sup>4</sup> |
-| [Cleaning Kubernetes components when clusters are no longer reachable from Rancher](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md) | ✓ | | | |
+| Action | Rancher Launched Kubernetes Clusters |  EKS, GKE and AKS Clusters<sup>1</sup> | Other Hosted Kubernetes Clusters | Non-EKS or GKE Imported Clusters | Turtles/CAPI Clusters |
+| --- | --- | ---| ---|----|----|
+| [Using kubectl and a kubeconfig file to Access a Cluster](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) | ✓ | ✓ | ✓ | ✓ | ✓ |
+| [Managing Cluster Members](../how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md) | ✓ | ✓ | ✓ | ✓ | ✓ |
+| [Editing and Upgrading Clusters](../reference-guides/cluster-configuration/cluster-configuration.md) | ✓ | ✓ | ✓ | ✓<sup>2</sup> | ✓<sup>5</sup> |
+| [Managing Nodes](../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md) | ✓ | ✓ | ✓ | ✓<sup>3</sup> | ✓<sup>5</sup> |
+| [Managing Persistent Volumes and Storage Classes](../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) | ✓ | ✓ | ✓ | ✓ | ✓ |
+| [Managing Projects, Namespaces and Workloads](../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md) | ✓ | ✓ | ✓ | ✓ | ✓ |
+| [Using App Catalogs](../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md) | ✓ | ✓ | ✓ | ✓ | ✓ |
+| Configuring Tools ([Alerts, Notifiers, Monitoring](../integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md), [Logging](../integrations-in-rancher/logging/logging.md), [Istio](../integrations-in-rancher/istio/istio.md)) | ✓ | ✓ | ✓ | ✓ | ✓ |
+| [Running Security Scans](../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) | ✓ | ✓ | ✓ | ✓ | ✓ |
+| [Ability to rotate certificates](../how-to-guides/new-user-guides/manage-clusters/rotate-certificates.md) | ✓ | ✓  |  | | |
+| Ability to [backup](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md) and [restore](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Rancher-launched clusters | ✓ | ✓ |  | ✓<sup>4</sup> | |
+| [Cleaning Kubernetes components when clusters are no longer reachable from Rancher](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md) | ✓ | | | | |

-1. Registered EKS, GKE and AKS clusters have the same options available as EKS, GKE and AKS clusters created from the Rancher UI. The  difference is that when a registered cluster is deleted from the Rancher UI, it is not destroyed.
+1. Imported EKS, GKE and AKS clusters have the same options available as EKS, GKE, and AKS clusters created from the Rancher UI. The  difference is that when a registered cluster is deleted from the Rancher UI, it is not destroyed. Note that does not include EKS, GKE, and AKS clusters created via Turtles/CAPI, refer to the "Turtles/CAPI Clusters" column for those.

-2. Cluster configuration options can't be edited for registered clusters, except for [K3s and RKE2 clusters.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md)
+2. For imported clusters, cluster configuration options can only be edited for [K3s and RKE2 clusters.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md)

-3. For registered cluster nodes, the Rancher UI exposes the ability to cordon, drain, and edit the node.
+3. For imported cluster nodes, the Rancher UI exposes the ability to cordon, drain, and edit the node.

-4. For registered clusters using etcd as a control plane, snapshots must be taken manually outside of the Rancher UI to use for backup and recovery.
+4. For imported clusters using etcd as a control plane, snapshots must be taken manually outside of the Rancher UI to use for backup and recovery.
+
+5. Exclusively via the Cluster API.
@@ -1,115 +0,0 @@
---
-title: 配置 Okta (SAML)
---
-
-如果你的组织使用 Okta Identity Provider (IdP) 进行用户身份验证，你可以通过配置 Rancher 来允许用户使用 IdP 凭证登录。
-
-:::note
-
-Okta 集成仅支持服务提供商发起的登录。
-
-:::
-## 先决条件
-
-在 Okta 中，使用以下设置创建一个新的 SAML 应用。如需获取帮助，请参见 [Okta 文档](https://developer.okta.com/standards/SAML/setting_up_a_saml_application_in_okta)。
-
-| 设置 | 值 |
------------|------------
-| `Single Sign on URL` | `https://yourRancherHostURL/v1-saml/okta/saml/acs` |
-| `Audience URI (SP Entity ID)` | `https://yourRancherHostURL/v1-saml/okta/saml/metadata` |
-
-## 在 Rancher 中配置 Okta
-
-你可以将 Okta 与 Rancher 集成，以便经过身份认证的用户通过组权限访问 Rancher 资源。Okta 会返回一个对用户进行身份认证的 SAML 断言，包括用户所属的组。
-
-1. 在左上角，单击 **☰ > 用户 & 认证**。
-1. 在左侧导航栏，单击**认证**。
-1. 单击 **Okta**。
-1. 填写**配置 Okta 账号**表单。下面的示例描述了如何将 Okta 属性从属性语句映射到 Rancher 中的字段：
-
-   | 字段 | 描述 |
-   | ------------------------- | ----------------------------------------------------------------------------- |
-   | 显示名称字段 | 属性语句中包含用户显示名称的属性名称。 |
-   | 用户名字段 | 属性语句中包含用户名/给定名称的属性名称。 |
-   | UID 字段 | 属性语句中每个用户唯一的属性名称。 |
-   | 用户组字段 | 组属性语句中公开你的组的属性名称。 |
-   | Rancher API 主机 | Rancher Server 的 URL。 |
-   | 私钥/证书 | 密钥/证书对，用于断言加密。 |
-   | 元数据 XML | 你在应用 `Sign On` 部分中找到的 `Identity Provider metadata` 文件。 |
-
-   :::tip
-
-   你可以使用 openssl 命令生成一个密钥/证书对。例如：
-
-   ```
-   openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout myservice.key -out myservice.crt
-   ```
-
-   :::
-
-
-1. 完成**配置 Okta 账号**表单后，单击**启用**。
-
-   Rancher 会将你重定向到 IdP 登录页面。输入使用 Okta IdP 进行身份验证的凭证，来验证你的 Rancher Okta 配置。
-
-   :::note
-
-   如果什么都没有发生，很可能是因为你的浏览器阻止了弹出窗口。请在弹出窗口阻止程序中禁用 Rancher 域，并在其他类似扩展中将 Rancher 列入白名单。
-
-   :::
-
-**结果**：已将 Rancher 配置为使用 Okta。你的用户现在可以使用 Okta 登录名登录 Rancher。
-
-:::note SAML 身份提供商注意事项
-
-如果你在没有 OpenLDAP 的情况下配置 Okta，你将无法搜索或直接查找用户或组。相关的警告如下：
-
- 在 Rancher 中为用户和组分配权限时将不会验证用户和组。
- 添加用户时，必须正确输入确切的用户 ID（即 `UID` 字段）。键入用户 ID 时，将不会搜索可能匹配的其他用户 ID。
- 添加组时，必须从文本框旁边的下拉列表中选择组。Rancher 假定来自文本框的任何输入都是用户。
- The group drop-down shows only the groups that you are a member of. However, if you have Administrator permissions or restricted Administrator permissions, you can join a group that you are not a member of.
-
-:::
-
-## Okta 与 OpenLDAP 搜索
-
-你可以添加 OpenLDAP 后端来协助用户和组搜索。Rancher 将显示来自 OpenLDAP 服务的其他用户和组。这允许你将权限分配给用户不属于的组。
-
-### OpenLDAP 先决条件
-
-如果你使用 Okta 作为 IdP，你可以[设置 LDAP 接口](https://help.okta.com/en-us/Content/Topics/Directory/LDAP-interface-main.htm)以供 Rancher 使用。你还可以配置外部 OpenLDAP Server。
-
-你必须使用 LDAP 绑定帐户（也称为 ServiceAccount）来配置 Rancher，以便搜索和检索应具有访问权限的用户和组的 LDAP 条目。不要使用管理员帐户或个人帐户作为 LDAP 绑定帐户。在 OpenLDAP 中[创建](https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-add-users.htm)一个专用帐户，对搜索库下的用户和组具有只读访问权限。
-
-:::warning 安全注意事项
-
-OpenLDAP ServiceAccount 用于所有搜索。无论用户个人的 SAML 权限是什么，Rancher 用户都将看到 OpenLDAP ServiceAccount 可以查看的用户和组。
-
-:::
-
-
-> **使用 TLS？**
->
-> 如果 OpenLDAP Server 使用的证书是自签名的或来自无法识别的证书颁发机构，则 Rancher 需要 PEM 格式的 CA 证书（包含所有中间证书）。你需要在配置期间提供此证书，以便 Rancher 能够验证证书链。
-
-### 在 Rancher 中配置 OpenLDAP
-
-[配置 OpenLDAP Server、组和用户的设置](../configure-openldap/openldap-config-reference.md)。请注意，不支持嵌套组成员。
-
-> 在继续配置之前，请熟悉[外部身份认证配置和主要用户](./authentication-config.md#外部认证配置和用户主体)。
-
-1. 使用分配了 [administrator](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions) 角色（即 _本地主体_）的本地用户登录到 Rancher。
-1. 在左上角，单击 **☰ > 用户 & 认证**。
-1. 在左侧导航栏，单击**认证**。
-1. 单击 **Okta**，如果已配置 SAML，则单击**编辑配置**。
-1. 在**用户和组搜索**下，选中**配置 OpenLDAP Server**。
-
-如果你在测试与 OpenLDAP Server 的连接时遇到问题，请确保你输入了ServiceAccount 的凭证并正确配置了搜索库。你可以检查 Rancher 日志来查明根本原因。调试日志可能包含有关错误的更详细信息。请参阅[如何启用调试日志](../../../../faq/technical-items.md#如何启用调试日志记录)了解更多信息。
-
-## Configuring SAML Single Logout (SLO)
-
-<ConfigureSLO />
-
-## SAML and OpenLDAP Group Permissions
-
-<SamlOpenLDAPGroupPermissions />
@@ -1,170 +0,0 @@
---
-title: 设置 Amazon NLB 网络负载均衡器
---
-
-本文介绍了如何在 Amazon EC2 服务中设置 Amazon NLB 网络负载均衡器，用于将流量转发到 EC2 上的多个实例中。
-
-这些示例中，负载均衡器将流量转发到三个 Rancher Server 节点。如果 Rancher 安装在 K3s Kubernetes 集群上，则只需要两个节点。
-
-本文介绍的只是配置负载均衡器的其中一种方式。其他负载均衡器如传统负载路由器（Classic Load Balancer）和应用负载路由器（Application Load Balancer），也可以将流量转发到 Rancher Server 节点。
-
-Rancher 仅支持使用 Amazon NLB 以 `TCP` 模式终止 443 端口的流量，而不支持 `TLS` 模式。这试因为在 NLB 终止时，NLB 不会将正确的标头注入请求中。如果你想使用由 Amazon Certificate Manager (ACM) 托管的证书，请使用 ALB。
-
-## 要求
-
-你已在 EC2 中创建了 Linux 实例。此外，负载均衡器会把流量转发到这些节点。
-
-## 1. 创建目标组
-
-首先，为 **TCP** 协议创建两个目标组，其中一个使用 TCP 端口 443，另一个使用 TCP 端口 80（用于重定向到 TCP 端口 443）。然后，将 Linux 节点添加到这些组中。
-
-配置 NLB 的第一个步骤是创建两个目标组。一般来说，只需要端口 443 就可以访问 Rancher。但是，由于端口 80 的流量会被自动重定向到端口 443，因此，你也可以为端口 80 也添加一个监听器。
-
-The Traefik Ingress should redirect traffic from port 80 to port 443.
-
-1. 登录到 [Amazon AWS 控制台](https://console.aws.amazon.com/ec2/)。确保选择的**区域**是你创建 EC2 实例 （Linux 节点）的区域。
-1. 选择**服务** > **EC2**，找到**负载均衡器**并打开**目标组**。
-1. 单击**创建目标组**，然后创建用于 TCP 端口 443 的第一个目标组。
-
-:::note
-
-For details on Traefik Ingress health checks, refer to [this section.](#health-check-paths-for-traefik-ingresses)
-
-:::
-
-#### 目标组（TCP 端口 443）
-
-根据下表配置第一个目标组：
-
-| 选项 | 设置 |
-|-------------------|-------------------|
-| 目标组名称 | `rancher-tcp-443` |
-| 目标类型 | `instance` |
-| 协议 | `TCP` |
-| 端口 | `443` |
-| VPC | 选择 VPC |
-
-健康检查设置：
-
-| 选项 | 设置 |
-|---------------------|-----------------|
-| 协议 | TCP |
-| 端口 | `override`,`80` |
-| 健康阈值 | `3` |
-| 不正常阈值 | `3` |
-| 超时 | `6 秒` |
-| 间隔 | `10 秒` |
-
-单击**创建目标组**，然后创建用于 TCP 端口 80 的第二个目标组。
-
-#### 目标组（TCP 端口 80）
-
-根据下表配置第二个目标组：
-
-| 选项 | 设置 |
-|-------------------|------------------|
-| 目标组名称 | `rancher-tcp-80` |
-| 目标类型 | `instance` |
-| 协议 | `TCP` |
-| 端口 | `80` |
-| VPC | 选择 VPC |
-
-
-健康检查设置：
-
-| 选项 | 设置 |
-|---------------------|----------------|
-| 协议 | TCP |
-| 端口 | `traffic port` |
-| 健康阈值 | `3` |
-| 不正常阈值 | `3` |
-| 超时 | `6 秒` |
-| 间隔 | `10 秒` |
-
-## 2. 注册目标
-
-接下来，将 Linux 节点添加到两个目标组中。
-
-选择名为 **rancher-tcp-443** 的目标组，点击**目标**选项卡并选择**编辑**。
-
-![](/img/ha/nlb/edit-targetgroup-443.png)
-
-选择你要添加的实例（Linux 节点），然后单击**添加到已注册**。
-
-***
-**将目标添加到目标组 TCP 端口 443**<br/>
-
-![](/img/ha/nlb/add-targets-targetgroup-443.png)
-
-***
-**已将目标添加到目标组 TCP 端口 443**<br/>
-
-![](/img/ha/nlb/added-targets-targetgroup-443.png)
-
-添加实例后，单击右下方的**保存**。
-
-将 **rancher-tcp-443** 替换为 **rancher-tcp-80**，然后重复上述步骤。你需要将相同的实例作为目标添加到此目标组。
-
-## 3. 创建 NLB
-
-使用 Amazon 的向导创建网络负载均衡器。在这个过程中，你需要添加在 [1. 创建目标组](#1-创建目标组)中创建的目标组。
-
-1. 在网页浏览器中，导航到 [Amazon EC2 控制台](https://console.aws.amazon.com/ec2/)。
-
-2. 在导航栏中，选择**负载均衡** > **负载均衡器**。
-
-3. 单击**创建负载均衡器**。
-
-4. 选择**网络负载均衡器**并单击**创建**。然后，填写每个表格。
-
- [步骤 1：配置负载均衡器](#步骤-1配置负载均衡器)
- [步骤 2：配置路由](#步骤-2配置路由)
- [步骤 3：注册目标](#步骤-3注册目标)
- [步骤 4：审核](#步骤-4审核)
-
-### 步骤 1：配置负载均衡器
-
-在表单中设置以下字段：
-
- **名称**：`rancher`
- **Scheme**：`internal` 或 `internet-facing`。实例和 VPC 的配置决定了 NLB 的 Scheme。如果你的实例没有绑定公共 IP，或者你只需要通过内网访问 Rancher，请将 NLB 的 Scheme 设置为 `internal` 而不是 `internet-facing`。
- **监听器**：负载均衡器协议需要是 `TCP`，而且负载均衡器端口需要设为 `443`。
- **可用区：**选择你的**VPC**和**可用区**。
-
-### 步骤 2：配置路由
-
-1. 从**目标组**下拉列表中，选择 **现有目标组**。
-1. 从**名称**下拉列表中，选择 `rancher-tcp-443`。
-1. 打开**高级健康检查设置**，并将**间隔**设为 `10 秒`。
-
-### 步骤 3：注册目标
-
-由于你已经在先前步骤注册了目标，因此你只需单击 **下一步：审核**。
-
-### 步骤 4：审核
-
-检查负载均衡器信息无误后，单击**创建**。
-
-AWS 完成 NLB 创建后，单击**关闭**。
-
-## 4. 为 TCP 端口 80 向 NLB 添加监听器
-
-1. 选择新创建的 NLB 并选择**监听器**选项卡。
-
-2. 单击**添加监听器**。
-
-3. 使用 `TCP`:`80` 作为**协议**:**端口**。
-
-4. 单击**添加操作**并选择**转发到..**。
-
-5. 从**转发到**下拉列表中，选择 `rancher-tcp-80`。
-
-6. 单击右上角的**保存**。
-
-## Health Check Paths for Traefik Ingresses
-
-K3s Kubernetes clusters use Traefik as the default Ingress.
-
-The health check path is `/ping`. By default `/ping` is always matched (regardless of Host), and a response from [Traefik itself](https://docs.traefik.io/operations/ping/) is always served.
-
-To simulate an accurate health check, it is a best practice to use the Host header (Rancher hostname) combined with `/ping` or `/healthz` wherever possible, to get a response from the Rancher Pods, not the Ingress.
@@ -1,165 +0,0 @@
---
-title: 为 Rancher 设置高可用的 RKE2 Kubernetes 集群
---
-
-本文介绍了如何根据 [Rancher Server 环境的最佳实践](../../../reference-guides/rancher-manager-architecture/architecture-recommendations.md#kubernetes-安装环境)安装 Kubernetes 集群。
-
-## 先决条件
-
-以下说明假设你已参见[此章节](../infrastructure-setup/ha-rke2-kubernetes-cluster.md)配置好三个节点，一个负载均衡器和一个 DNS 记录。
-
-为了让 RKE2 与负载均衡器正常工作，你需要设置两个监听器，一个用于 9345 端口，另一个用于 6443 端口的 Kubernetes API。
-
-Rancher 需要安装在支持的 Kubernetes 版本上。如需了解你使用的 Rancher 版本支持哪些 Kubernetes 版本，请参见[支持维护条款](https://rancher.com/support-maintenance-terms/)。如需指定 RKE2 版本，请在运行 RKE2 安装脚本时，使用 `INSTALL_RKE2_VERSION` 环境变量。
-
-## 安装 Kubernetes
-
-### 1. 安装 Kubernetes 并设置 RKE2 Server
-
-RKE2 Server 使用嵌入式 etcd 运行。因此你不需要设置外部数据存储就可以在 HA 模式下运行。
-
-在第一个节点上，使用你的预共享密文作为 Token 来设置配置文件。Token 参数可以在启动时设置。
-
-如果你不指定预共享密文，RKE2 会生成一个预共享密文并将它放在 `/var/lib/rancher/rke2/server/node-token` 中。
-
-为了避免固定注册地址的证书错误，请在启动 Server 时设置 `tls-san` 参数。这个选项在 Server 的 TLS 证书中增加一个额外的主机名或 IP 作为 Subject Alternative Name。如果你想通过 IP 和主机名访问，你可以将它指定为一个列表。
-
-首先，创建用于存放 RKE2 配置文件的目录：
-
-```
-mkdir -p /etc/rancher/rke2/
-```
-
-然后，参见以下示例在 `/etc/rancher/rke2/config.yaml` 中创建 RKE2 配置文件：
-
-```
-token: my-shared-secret
-tls-san:
-  - my-kubernetes-domain.com
-  - another-kubernetes-domain.com
-```
-之后，运行安装命令并启用和启动 RKE2：
-
-```
-curl -sfL https://get.rke2.io | sh -
-systemctl enable rke2-server.service
-systemctl start rke2-server.service
-```
-1. 要加入其余的节点，使用同一个共享或自动生成的 Token 来配置每个额外的节点。以下是配置文件的示例：
-
-        token: my-shared-secret
-        server: https://<DNS-DOMAIN>:9345
-        tls-san:
-          - my-kubernetes-domain.com
-          - another-kubernetes-domain.com
-运行安装程序，然后启用并启动 RKE2：
-
-        curl -sfL https://get.rke2.io | sh -
-        systemctl enable rke2-server.service
-        systemctl start rke2-server.service
-
-
-1. 在第三 RKE2 Server 节点上运行同样的命令。
-
-### 2. 检查 RKE2 是否正常运行
-
-在所有 Server 节点上启动了 RKE2 Server 进程后，确保集群已经正常启动，请运行以下命令：
-
-```
-/var/lib/rancher/rke2/bin/kubectl \
-        --kubeconfig /etc/rancher/rke2/rke2.yaml get nodes
-现在，Server 节点的状态应该是 Ready。
-```
-
-测试集群 Pod 的健康状况：
-```
-/var/lib/rancher/rke2/bin/kubectl \
-        --kubeconfig /etc/rancher/rke2/rke2.yaml get pods --all-namespaces
-```
-
-**结果**：你已成功配置 RKE2 Kubernetes 集群。
-
-### 3. 保存并开始使用 kubeconfig 文件
-
-在每个 Rancher Server 节点安装 RKE2 时，会在每个节点的 `/etc/rancher/rke2/rke2.yaml` 中生成一个 `kubeconfig`  文件。该文件包含访问集群的凭证。请将该文件保存在安全的位置。
-
-如要使用该 `kubeconfig` 文件：
-
-1. 安装 Kubernetes 命令行工具 [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl)。
-2. 复制 `/etc/rancher/rke2/rke2.yaml` 文件并保存到本地主机的 `~/.kube/config` 目录上。
-3. 在 kubeconfig 文件中，`server` 的参数为 localhost。在端口 6443 上将服务器配置为 controlplane 负载均衡器的 DNS（RKE2 Kubernetes API Server 使用端口 6443，而 Rancher Server 将通过 Traefik Ingress 在端口 80 和 443 上提供服务。）以下是一个示例 `rke2.yaml`：
-
-```yml
-apiVersion: v1
-clusters:
- cluster:
-    certificate-authority-data: [CERTIFICATE-DATA]
-    server: [LOAD-BALANCER-DNS]:6443 # 编辑此行
-  name: default
-contexts:
- context:
-    cluster: default
-    user: default
-  name: default
-current-context: default
-kind: Config
-preferences: {}
-users:
- name: default
-  user:
-    password: [PASSWORD]
-    username: admin
-```
-
-**结果**：你可以开始使用 `kubectl` 来管理你的 RKE2 集群。如果你有多个 `kubeconfig` 文件，在使用 `kubectl` 时，你可以传入文件路径来指定要使用的 `kubeconfig` 文件：
-
-```
-kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
-```
-
-有关 `kubeconfig` 文件的详情，请参见 [RKE2 官方文档](https://docs.rke2.io/cluster_access)或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
-
-### 4. 检查集群 Pod 的健康状况
-
-现在你已经设置了 `kubeconfig` 文件。你可以使用 `kubectl` 在本地主机访问集群。
-
-检查所有需要的 Pod 和容器是否健康：
-
-```
-/var/lib/rancher/rke2/bin/kubectl --kubeconfig /etc/rancher/rke2/rke2.yaml get pods -A
-NAMESPACE     NAME                                                    READY   STATUS      RESTARTS   AGE
-kube-system   cloud-controller-manager-rke2-server-1                  1/1     Running     0          2m28s
-kube-system   cloud-controller-manager-rke2-server-2                  1/1     Running     0          61s
-kube-system   cloud-controller-manager-rke2-server-3                  1/1     Running     0          49s
-kube-system   etcd-rke2-server-1                                      1/1     Running     0          2m13s
-kube-system   etcd-rke2-server-2                                      1/1     Running     0          87s
-kube-system   etcd-rke2-server-3                                      1/1     Running     0          56s
-kube-system   helm-install-rke2-canal-hs6sx                           0/1     Completed   0          2m17s
-kube-system   helm-install-rke2-coredns-xmzm8                         0/1     Completed   0          2m17s
-kube-system   helm-install-traefik-crd-z8vsz                          0/1     Completed   0          2m17s
-kube-system   helm-install-traefik-flwnl                              0/1     Completed   0          2m17s
-kube-system   helm-install-rke2-metrics-server-7sggn                  0/1     Completed   0          2m17s
-kube-system   kube-apiserver-rke2-server-1                            1/1     Running     0          116s
-kube-system   kube-apiserver-rke2-server-2                            1/1     Running     0          66s
-kube-system   kube-apiserver-rke2-server-3                            1/1     Running     0          48s
-kube-system   kube-controller-manager-rke2-server-1                   1/1     Running     0          2m30s
-kube-system   kube-controller-manager-rke2-server-2                   1/1     Running     0          57s
-kube-system   kube-controller-manager-rke2-server-3                   1/1     Running     0          42s
-kube-system   kube-proxy-rke2-server-1                                1/1     Running     0          2m25s
-kube-system   kube-proxy-rke2-server-2                                1/1     Running     0          59s
-kube-system   kube-proxy-rke2-server-3                                1/1     Running     0          85s
-kube-system   kube-scheduler-rke2-server-1                            1/1     Running     0          2m30s
-kube-system   kube-scheduler-rke2-server-2                            1/1     Running     0          57s
-kube-system   kube-scheduler-rke2-server-3                            1/1     Running     0          42s
-kube-system   rke2-canal-b9lvm                                        2/2     Running     0          91s
-kube-system   rke2-canal-khwp2                                        2/2     Running     0          2m5s
-kube-system   rke2-canal-swfmq                                        2/2     Running     0          105s
-kube-system   rke2-coredns-rke2-coredns-547d5499cb-6tvwb              1/1     Running     0          92s
-kube-system   rke2-coredns-rke2-coredns-547d5499cb-rdttj              1/1     Running     0          2m8s
-kube-system   rke2-coredns-rke2-coredns-autoscaler-65c9bb465d-85sq5   1/1     Running     0          2m8s
-kube-system   traefik-7c844b766f-m9p2w                                1/1     Running     0          52s
-kube-system   traefik-7c844b766f-s4l9k                                1/1     Running     0          52s
-kube-system   rke2-metrics-server-6564db4569-vdfkn                    1/1     Running     0          66s
-```
-
-**结果**：你可通过使用 `kubectl` 访问集群，并且 RKE2 集群能成功运行。现在，你可以在集群上安装 Rancher Management Server。
@@ -1,79 +0,0 @@
---
-title: Rancher HA
---
-
-本文列出的命令/步骤可用于检查你的 Rancher Kubernetes 安装。
-
-请确保你配置了正确的 kubeconfig（例如，`export KUBECONFIG=$PWD/kube_config_cluster.yml`）。
-
-## 检查 Rancher Pod
-
-Rancher pod 会部署为 `cattle-system` 命名空间中的一个 Deployment。
-
-检查 pod 是否运行在所有节点上：
-
-```
-kubectl -n cattle-system get pods -l app=rancher -o wide
-```
-
-输出示例：
-
-```
-NAME                       READY   STATUS    RESTARTS   AGE   IP          NODE
-rancher-7dbd7875f7-n6t5t   1/1     Running   0          8m    x.x.x.x     x.x.x.x
-rancher-7dbd7875f7-qbj5k   1/1     Running   0          8m    x.x.x.x     x.x.x.x
-rancher-7dbd7875f7-qw7wb   1/1     Running   0          8m    x.x.x.x     x.x.x.x
-```
-
-如果 pod 无法运行（即状态不是 **Running**，Ready 状态未显示 `1/1`，或者有大量 Restarts），请检查 pod 详细信息，日志和命名空间事件。
-
-### Pod 详细信息
-
-```
-kubectl -n cattle-system describe pods -l app=rancher
-```
-
-### Pod 容器日志
-
-```
-kubectl -n cattle-system logs -l app=rancher
-```
-
-### 命名空间事件
-
-```
-kubectl -n cattle-system get events
-```
-
-## 检查 Ingress
-
-Ingress 应该具有正确的 `HOSTS`（显示配置的 FQDN）和 `ADDRESS`（将被路由到该主机地址）：
-
-```
-kubectl -n cattle-system get ingress
-```
-
-输出示例：
-
-```
-NAME      HOSTS                    ADDRESS                   PORTS     AGE
-rancher   rancher.yourdomain.com   x.x.x.x,x.x.x.x,x.x.x.x   80, 443   2m
-```
-
-## 检查 Ingress Controller 日志
-
-如果访问你配置的 Rancher FQDN 时没有显示 UI，请检查 Ingress Controller 日志以查看尝试访问 Rancher 时发生了什么：
-
-```
-kubectl -n traefik logs -l app=traefik
-```
-
-## Leader 选举
-
-Leader 由 Leader 选举确定。确定 Leader 后，Leader（`holderIdentity`）会保存在 `cattle-controllers` ConfigMap 中（在本例中为 `rancher-7dbd7875f7-qbj5k`）：
-
-```
-kubectl -n kube-system get configmap cattle-controllers -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
-{"holderIdentity":"rancher-7dbd7875f7-qbj5k","leaseDurationSeconds":45,"acquireTime":"2019-04-04T11:53:12Z","renewTime":"2019-04-04T12:24:08Z","leaderTransitions":0}
-```
-
@@ -6,8 +6,6 @@ title: Using API Tokens
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-tokens"/>
 </head>

-<v3APITokensDeprecationWarning />
-
 Rancher v2.8.0 introduced the [Rancher Kubernetes API](./api-reference.mdx) which can be used to manage Rancher resources through `kubectl`. This page covers information on API tokens used with the [Rancher CLI](../reference-guides/cli-with-rancher/cli-with-rancher.md), [kubeconfig files](../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md#about-the-kubeconfig-file), Terraform and the [v3 API browser](./v3-rancher-api-guide.md#enable-view-in-api).

 By default, some cluster-level API tokens are generated with infinite time-to-live (`ttl=0`). In other words, API tokens with `ttl=0` never expire unless you invalidate them. Tokens are not invalidated by changing a password.
@@ -6,8 +6,6 @@ title: Tokens
    <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/workflows/tokens"/>
 </head>

-<v3APITokensDeprecationWarning />
-
 ## Token Resource

 Rancher has an imperative API resource `tokens.ext.cattle.io` that allows you to generate tokens for authenticating with Rancher.
@@ -12,11 +12,11 @@ Rancher will publish deprecated features as part of the [release notes](https://

 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.14.3](https://github.com/rancher/rancher/releases/tag/v2.14.3) | June 29, 2026  |
-| [2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2) | May 28, 2026   |
-| [2.14.1](https://github.com/rancher/rancher/releases/tag/v2.14.1) | April 30, 2026 |
-| [2.14.0](https://github.com/rancher/rancher/releases/tag/v2.14.0) | March 25, 2026 |
+| [2.13.3](https://github.com/rancher/rancher/releases/tag/v2.13.3) | February 25, 2026 |
+| [2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2) | January 29, 2026 |
+| [2.13.1](https://github.com/rancher/rancher/releases/tag/v2.13.1) | December 18, 2025 |
+| [2.13.0](https://github.com/rancher/rancher/releases/tag/v2.13.0) | November 25, 2025 |

 ## What can I expect when a feature is marked for deprecation?

-In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
+In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
@@ -33,7 +33,7 @@ helm upgrade rancher ./rancher-<VERSION>.tgz \
 	--namespace cattle-system \
 	--set hostname=<RANCHER.YOURDOMAIN.COM> \
 	--set certmanager.version=<CERTMANAGER_VERSION> \
-	--set image.registry=<REGISTRY.YOURDOMAIN.COM:PORT> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
 	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
 	--set useBundledSystemChart=true # Use the packaged Rancher system charts
 ```
@@ -48,7 +48,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
 	--namespace cattle-system \
 	--set hostname=<RANCHER.YOURDOMAIN.COM> \
 	--set certmanager.version=<CERTMANAGER_VERSION> \
-	--set image.registry=<REGISTRY.YOURDOMAIN.COM:PORT> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
 	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
 	--set useBundledSystemChart=true # Use the packaged Rancher system charts
 ```
@@ -65,7 +65,7 @@ kubectl -n cattle-system apply -R -f ./rancher
 helm upgrade rancher ./rancher-<VERSION>.tgz \
 	--namespace cattle-system \
 	--set hostname=<RANCHER.YOURDOMAIN.COM> \
-	--set image.registry=<REGISTRY.YOURDOMAIN.COM:PORT> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
 	--set ingress.tls.source=secret \
 	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
 	--set useBundledSystemChart=true # Use the packaged Rancher system charts
@@ -77,7 +77,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
 helm upgrade rancher ./rancher-<VERSION>.tgz \
 	--namespace cattle-system \
 	--set hostname=<RANCHER.YOURDOMAIN.COM> \
-	--set image.registry=<REGISTRY.YOURDOMAIN.COM:PORT> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
 	--set ingress.tls.source=secret \
 	--set privateCA=true \
 	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
@@ -52,6 +52,12 @@ az group create --name rancher-rg --location eastus

 To create an AKS cluster, run the following command. Use a VM size that applies to your use case. Refer to [this article](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for available sizes and options. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.

+:::note
+
+If you're updating from an older version of Kubernetes, to Kubernetes v1.22 or above, you also need to [update](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx.
+
+:::
+
 ```
 az aks create \
  --resource-group rancher-rg \
@@ -75,46 +81,48 @@ This command merges your cluster's credentials into the existing kubeconfig and

 ## 5. Install an Ingress

-The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription. You can use a managed ingress controller provided by Azure or a third-party ingress controller like Traefik.
+The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription.

-:::warning
-It is not recommended to install a third-party ingress controller, like Traefik, if a managed ingress controller is already being used.
-:::
+To make sure that you choose the correct Ingress-NGINX Helm chart, first find an `Ingress-NGINX version` that's compatible with your Kubernetes version in the [Kubernetes/ingress-nginx support table](https://github.com/kubernetes/ingress-nginx#supported-versions-table).

-:::warning
-**Ingress-NGINX EOL:** The community `ingress-nginx` controller reaches End-of-Life (EOL) in March 2026. This page uses Traefik, which is the recommended migration path for Rancher environments. 
-:::
+Then, list the Helm charts available to you by running the following command:

-Traefik includes a native Ingress NGINX provider. This allows you to migrate from NGINX without rewriting your existing Ingress objects, as Traefik will automatically interpret `nginx.ingress.kubernetes.io` annotations. If you are upgrading a cluster that is already using `ingress-nginx`, follow this [guide](https://doc.traefik.io/traefik/migrate/nginx-to-traefik/) for more information.
-
-To install Traefik (chart version 39.0.0) on a fresh cluster, run the following `helm` commands:
-```bash
-helm repo add traefik https://traefik.github.io/charts
+```
+helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
 helm repo update
+helm search repo ingress-nginx -l
+```
+
+The `helm search` command's output contains an `APP VERSION` column. The versions under this column are equivalent to the `Ingress-NGINX version` you chose earlier. Using the app version, select a chart version that bundles an app compatible with your Kubernetes install. For example, if you have Kubernetes v1.24, you can select the v4.6.0 Helm chart, since Ingress-NGINX v1.7.0 comes bundled with that chart, and v1.7.0 is compatible with Kubernetes v1.24. When in doubt, select the most recent compatible version.
+
+Now that you know which Helm chart `version` you need, run the following command. It installs an `nginx-ingress-controller` with a Kubernetes load balancer service:
+
+```
+helm search repo ingress-nginx -l
 helm upgrade --install \
-  traefik traefik/traefik \
-  --namespace traefik \
-  --version 39.0.0 \
-  --create-namespace \
-  --set service.type=LoadBalancer \
-  --set ping.enabled=true \
-  --set service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/ping
+  ingress-nginx ingress-nginx/ingress-nginx \
+  --namespace ingress-nginx \
+  --set controller.service.type=LoadBalancer \
+  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
+  --set controller.service.externalTrafficPolicy=Local \
+  --version 4.6.0 \
+  --create-namespace
 ```

 ## 6. Get Load Balancer IP

 To get the address of the load balancer, run:

-```bash
-kubectl get service traefik --namespace=traefik
+```
+kubectl get service ingress-nginx-controller --namespace=ingress-nginx
 ```

 The result should look similar to the following:

-```bash
+```
 NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)
 AGE
-traefik  LoadBalancer   10.0.116.18    40.31.180.83   80:31229/TCP,443:31050/TCP
+ingress-nginx-controller   LoadBalancer   10.0.116.18    40.31.180.83   80:31229/TCP,443:31050/TCP
 67s
 ```

@@ -137,7 +145,7 @@ Use that DNS name from the previous step as the Rancher server URL when you inst
 When installing Rancher on top of this setup, you will also need to pass the value below into the Rancher Helm install command in order to set the name of the ingress controller to be used with Rancher's ingress resource:

 ```
--set ingress.ingressClassName=traefik
+--set ingress.ingressClassName=nginx
 ```

 Refer [here for the Helm install command](install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
@@ -52,6 +52,8 @@ Then enter the following values:

 To create an EKS cluster, run the following command. Use the AWS region that applies to your use case. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.

+**Note:** If you're updating from an older version of Kubernetes, to Kubernetes v1.22 or above, you also need to [update](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx.
+
 ```
 eksctl create cluster \
  --name rancher-server \
@@ -86,48 +88,46 @@ rancher-server-cluster		us-west-2	True

 ### 5. Install an Ingress

-The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription. You can use a managed ingress controller provided by AWS (ALB) or a third-party ingress controller like Traefik.
+The cluster needs an Ingress so that Rancher can be accessed from outside the cluster.

-:::warning
-It is not recommended to install a third-party ingress controller, like Traefik, if a managed ingress controller (ALB) is already being used.
-:::
+To make sure that you choose the correct Ingress-NGINX Helm chart, first find an `Ingress-NGINX version` that's compatible with your Kubernetes version in the [Kubernetes/ingress-nginx support table](https://github.com/kubernetes/ingress-nginx#supported-versions-table).

+Then, list the Helm charts available to you by running the following command:

-:::warning
-**Ingress-NGINX EOL:** The community `ingress-nginx` controller reaches End-of-Life (EOL) in March 2026. This page uses Traefik, which is the recommended migration path for Rancher environments. 
-:::
-
-Traefik includes a native Ingress NGINX provider. This allows you to migrate from NGINX without rewriting your existing Ingress objects, as Traefik will automatically interpret `nginx.ingress.kubernetes.io` annotations. If you are upgrading a cluster that is already using `ingress-nginx`, follow this [guide](https://doc.traefik.io/traefik/migrate/nginx-to-traefik/) for more information.
-
-To install Traefik (chart version 39.0.0) on a fresh cluster, run the following `helm` commands:
-```bash
-helm repo add traefik https://traefik.github.io/charts
+```
+helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
 helm repo update
-helm upgrade --install \
-  traefik traefik/traefik \
-  --namespace traefik \
-  --version 39.0.0 \
-  --create-namespace \
-  --set service.type=LoadBalancer \
-  --set ping.enabled=true \
+helm search repo ingress-nginx -l
 ```

+The `helm search` command's output contains an `APP VERSION` column. The versions under this column are equivalent to the `Ingress-NGINX version` you chose earlier. Using the app version, select a chart version that bundles an app compatible with your Kubernetes install. For example, if you have Kubernetes v1.23, you can select the v4.6.0 Helm chart, since Ingress-NGINX v1.7.0 comes bundled with that chart, and v1.7.0 is compatible with Kubernetes v1.23. When in doubt, select the most recent compatible version.
+
+Now that you know which Helm chart `version` you need, run the following command. It installs an `nginx-ingress-controller` with a Kubernetes load balancer service:
+
+```
+helm upgrade --install \
+  ingress-nginx ingress-nginx/ingress-nginx \
+  --namespace ingress-nginx \
+  --set controller.service.type=LoadBalancer \
+  --version 4.6.0 \
+  --create-namespace
+```

 ### 6. Get Load Balancer IP

 To get the address of the load balancer, run:

-```bash
-kubectl get service traefik --namespace=traefik
+```
+kubectl get service ingress-nginx-controller --namespace=ingress-nginx
 ```

 The result should look similar to the following:

-```bash
-NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)
+```
+NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP                                                              PORT(S)
 AGE
-traefik  LoadBalancer   10.100.90.18   a904a952c73bf4f668a17c46ac7c56ab-962521486.us-west-2.elb.amazonaws.com   80:31229/TCP,443:31050/TCP
- 67s
+ingress-nginx-controller   LoadBalancer   10.100.90.18   a904a952c73bf4f668a17c46ac7c56ab-962521486.us-west-2.elb.amazonaws.com   80:31229/TCP,443:31050/TCP
+ 27m
 ```

 Save the `EXTERNAL-IP`.
@@ -149,7 +149,7 @@ Use that DNS name from the previous step as the Rancher server URL when you inst
 When installing Rancher on top of this setup, you will also need to pass the value below into the Rancher Helm install command in order to set the name of the ingress controller to be used with Rancher's ingress resource:

 ```
--set ingress.ingressClassName=traefik
+--set ingress.ingressClassName=nginx
 ```

 Refer [here for the Helm install command](install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
@@ -124,6 +124,7 @@ When choosing a Kubernetes version, be sure to first consult the [support matrix

 To successfully create a GKE cluster with Rancher, your GKE must be in Standard mode. GKE has two modes of operation when creating a Kubernetes cluster, Autopilot and Standard mode. The cluster configuration for Autopilot mode has restrictions on editing the kube-system namespace. However, Rancher needs to create resources in the kube-system namespace during installation. As a result, you will not be able to install Rancher on a GKE cluster created in Autopilot mode. For more information about the difference between GKE Autopilot mode and Standard mode, visit [Compare GKE Autopilot and Standard.](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison)

+**Note:** If you're updating from an older version of Kubernetes, to Kubernetes v1.22 or above, you also need to [update](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx.

 ```
 gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=<VERSION>
@@ -139,48 +140,36 @@ gcloud container clusters get-credentials cluster-name

 This command configures `kubectl` to use the cluster you created.

-
 ## 7. Install an Ingress

-The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription. You can use a managed ingress controller provided by GCP or a third-party ingress controller like Traefik.
+The cluster needs an Ingress so that Rancher can be accessed from outside the cluster.

-:::warning
-It is not recommended to install a third-party ingress controller, like Traefik, if a managed ingress controller is already being used.
-:::
+The following command installs an `nginx-ingress-controller` with a LoadBalancer service:

-:::warning
-**Ingress-NGINX EOL:** The community `ingress-nginx` controller reaches End-of-Life (EOL) in March 2026. This page uses Traefik, which is the recommended migration path for Rancher environments. 
-:::
-
-Traefik includes a native Ingress NGINX provider. This allows you to migrate from NGINX without rewriting your existing Ingress objects, as Traefik will automatically interpret `nginx.ingress.kubernetes.io` annotations. If you are upgrading a cluster that is already using `ingress-nginx`, follow this [guide](https://doc.traefik.io/traefik/migrate/nginx-to-traefik/) for more information.
-
-To install Traefik (chart version 39.0.0) on a fresh cluster, run the following `helm` commands:
-```bash
-helm repo add traefik https://traefik.github.io/charts
+```
+helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
 helm repo update
 helm upgrade --install \
-  traefik traefik/traefik \
-  --namespace traefik \
-  --version 39.0.0 \
-  --create-namespace \
-  --set service.type=LoadBalancer \
-  --set ping.enabled=true \
+  ingress-nginx ingress-nginx/ingress-nginx \
+  --namespace ingress-nginx \
+  --set controller.service.type=LoadBalancer \
+  --version 4.0.18 \
+  --create-namespace
 ```

-
-## 8. Get Load Balancer IP
+## 8. Get the Load Balancer IP

 To get the address of the load balancer, run:

-```bash
-kubectl get service traefik --namespace=traefik
+```
+kubectl get service ingress-nginx-controller --namespace=ingress-nginx
 ```

 The result should look similar to the following:

 ```
 NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
-traefik   LoadBalancer   10.3.244.156   35.233.206.34   80:31876/TCP,443:32497/TCP    81s
+ingress-nginx-controller   LoadBalancer   10.3.244.156   35.233.206.34   80:31876/TCP,443:32497/TCP   81s
 ```

 Save the `EXTERNAL-IP`.
@@ -202,7 +191,7 @@ Use the DNS name from the previous step as the Rancher server URL when you insta
 When installing Rancher on top of this setup, you will also need to set the name of the ingress controller to be used with Rancher's ingress resource:

 ```
--set ingress.ingressClassName=traefik
+--set ingress.ingressClassName=nginx
 ```

 Refer [here for the Helm install command](install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
@@ -12,50 +12,28 @@ plugins:
      warn-version: latest
    exemptions:
      namespaces:
-      - calico-apiserver
-      - calico-system
-      - cattle-alerting
-      - cattle-capi-system
-      - cattle-csp-adapter-system
-      - cattle-elemental-system
-      - cattle-epinio-system
-      - cattle-externalip-system
-      - cattle-fleet-local-system
-      - cattle-fleet-system
-      - cattle-gatekeeper-system
-      - cattle-global-data
-      - cattle-global-nt
-      - cattle-impersonation-system
-      - cattle-istio
-      - cattle-istio-system
-      - cattle-logging
-      - cattle-logging-system
-      - cattle-monitoring-system
-      - cattle-neuvector-system
-      - cattle-prometheus
-      - cattle-provisioning-capi-system
-      - cattle-resources-system
-      - cattle-sriov-system
-      - cattle-system
-      - cattle-turtles-system
-      - cattle-ui-plugin-system
-      - cattle-windows-gmsa-system
-      - cert-manager
-      - cis-operator-system
-      - compliance-operator-system
-      - fleet-default
-      - fleet-local
-      - istio-system
-      - kube-node-lease
-      - kube-public
+      - ingress-nginx
      - kube-system
+      - cattle-system
+      - cattle-epinio-system
+      - cattle-fleet-system
+      - cattle-fleet-local-system
      - longhorn-system
+      - cattle-neuvector-system
+      - cattle-monitoring-system
      - rancher-alerting-drivers
-      - rancher-compliance-system
-      - security-scan
-      - sr-operator-system
+      - cis-operator-system
+      - cattle-csp-adapter-system
+      - cattle-externalip-system
+      - cattle-gatekeeper-system
+      - istio-system
+      - cattle-istio-system
+      - cattle-logging-system
+      - cattle-windows-gmsa-system
+      - cattle-sriov-system
+      - cattle-ui-plugin-system
      - tigera-operator
-      - traefik
+      - cattle-provisioning-capi-system
    kind: PodSecurityConfiguration
  name: PodSecurity
  path: ""
@@ -24,15 +24,10 @@ Follow the instructions from this page when:
 Alternative steps need to be performed for rollbacks in the following scenarios:
 - Rolling back from v2.6.4 and later to an earlier version of v2.6.x.
 - Rolling back from v2.7.7 and later to an earlier version of v2.7.x.
- Rolling back from v2.14.0 and later to an earlier version of v2.13.x.

 In Rancher v2.6.4, the cluster-api module is upgraded from v0.4.4 to v1.0.2. The cluster-api v1.0.2, in turn, upgrades the apiVersions of its Custom Resource Definitions (CRDs) from `cluster.x-k8s.io/v1alpha4` to `cluster.x-k8s.io/v1beta1`. Custom Resources (CRs) that use the older apiVersion (v1alpha4) are incompatible with v1beta1, which  causes rollbacks to fail when you attempt to move from Rancher v2.6.4 to any previous version of Rancher v2.6.x.

-In Rancher v2.7.7 through v2.13.x, the app `rancher-provisioning-capi` was installed on the upstream (local) cluster automatically as a replacement for the embedded cluster-api controllers. Conflicts and unexpected errors would occur if the upstream cluster contained both the app, and Rancher v2.7.6 and earlier. Therefore, alternative steps are needed if you attempt to move from Rancher v2.7.7-v2.13.x to any previous version of Rancher v2.7.x.
-
-In Rancher v2.13.0, Rancher Turtles became the default manager for CAPI resources, replacing the previously embedded cluster-api controllers, and in Rancher v2.14.0 the embedded cluster-api was removed entirely. As a result, if you roll back from Rancher v2.14.0 and later to an earlier version of Rancher v2.13.x and do not intend to continue using Rancher Turtles to manage CAPI resources, additional manual steps may be required to use the embedded cluster-api controllers. From Rancher v2.14.0 onward, Rancher Turtles is the only supported manager for CAPI resources.
-
-In Rancher v2.14.0, the cluster-api module is upgraded from v1.10.6 to v1.12.2. The cluster-api v1.12.2, in turn, upgrades the apiVersions of its Custom Resource Definitions (CRDs) from `cluster.x-k8s.io/v1beta1` to `cluster.x-k8s.io/v1beta2`. Rancher backup files include Cluster API CRDs. When restoring backup data from Rancher v2.13.x to a local cluster after upgrading to v2.14.0, the Rancher Backup application first restores the v1beta1 CRDs. This fails because the v1beta2 version cannot be removed from the CRDs while v1beta2 custom resources are present in the cluster.
+In Rancher v2.7.7, the app `rancher-provisioning-capi` is installed on the upstream (local) cluster automatically as a replacement for the embedded cluster-api controllers. Conflicts and unexpected errors will occur if the upstream cluster contains both the app, and Rancher v2.7.6 and earlier. Therefore, alternative steps are needed if you attempt to move from Rancher v2.7.7 to any previous version of Rancher v2.7.x.

 ### Step 1: Clean Up the Upstream (Local) Cluster

@@ -13,7 +13,7 @@ This section describes how to troubleshoot an installation of Rancher on a Kuber
 Most of the troubleshooting will be done on objects in these 3 namespaces.

 - `cattle-system` - `rancher` deployment and pods.
- `traefik` - Ingress controller pods and services.
+- `ingress-nginx` - Ingress controller pods and services.
 - `cert-manager` - `cert-manager` pods.

 ### "default backend - 404"
@@ -123,10 +123,10 @@ kubectl -n cattle-system describe ingress

 If its ready and the SSL is still not working you may have a malformed cert or secret.

-Check the `traefik` logs.
+Check the nginx-ingress-controller logs. Because the nginx-ingress-controller has multiple containers in its pod you will need to specify the name of the container.

 ```
-kubectl logs -n traefik traefik-6b94b8b688-bngw2
+kubectl -n ingress-nginx logs -f nginx-ingress-controller-rfjrq nginx-ingress-controller
 ...
 W0705 23:04:58.240571       7 backend_ssl.go:49] error obtaining PEM from secret cattle-system/tls-rancher-ingress: error retrieving secret cattle-system/tls-rancher-ingress: secret cattle-system/tls-rancher-ingress was not found
 ```
@@ -148,6 +148,11 @@ The most common cause of this issue is port 8472/UDP is not open between the nod

 Once the network issue is resolved, the `canal` pods should timeout and restart to establish their connections.

+### nginx-ingress-controller Pods show RESTARTS
+
+The most common cause of this issue is the `canal` pods have failed to establish the overlay network. See [canal Pods show READY `2/3`](#canal-pods-show-ready-23) for troubleshooting.
+
+
 ### Failed to dial to /var/run/docker.sock: ssh: rejected: administratively prohibited (open failed)

 Some causes of this error include:
@@ -26,31 +26,6 @@ Review the list of known issues for each Rancher version, which can be found in

 Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](../resources/choose-a-rancher-version.md#helm-chart-repositories) aren't supported.

-### Upgrade Path
-
-:::important
-
-**Important:** The only tested and supported Rancher upgrade path between minor versions (e.g. v2.13.x to v2.14.x) is to upgrade from the latest available patch version of your current running minor release to the latest available patch version of the next minor release.
-
-Before initiating a minor version upgrade, verify that you are running the most recent patch release of your current version.
-
-You can query the available chart versions with the Helm CLI:
-
-1. Update your local Helm repo cache.
-
-    ```
-    helm repo update
-    ```
-
-1. Search for available versions in your [specific repository](../resources/choose-a-rancher-version.md#helm-chart-repositories) (e.g., rancher-stable):
-
-    ```
-    helm search repo rancher-<CHART_REPO>/rancher --versions
-    ```
-
-If your installation is not on the latest patch version of the current minor release, you must upgrade to that version before proceeding to the next minor version.
-:::
-
 ### Helm Version

 :::important
@@ -87,6 +62,10 @@ The `CATTLE_AGENT_IMAGE` override is intended only as a temporary workaround for

 The upgrade instructions assume you are using Helm 3.

+<DeprecationHelm2 />
+
+For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+
 ### For air-gapped installs: Populate private registry

 For [air-gapped installs only,](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version. Follow the guide to [populate your private registry](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
@@ -157,21 +136,8 @@ You'll use the backup as a restore point if something goes wrong during upgrade.
    ```plain
    helm fetch rancher-<CHART_REPO>/rancher --version=2.6.8
    ```
-### 3. Review Rancher Feature Chart Versions Before Upgrade

-Rancher feature charts follow specific release lines that align with Rancher versions. Major versions of feature charts correspond to Rancher minor versions and follow a defined versioning scheme.
-
-Before upgrading Rancher, review any installed Rancher feature charts and upgrade them to the latest available version within their current chart release line. This helps ensure compatibility and avoids potential issues during or after the Rancher upgrade.
-
-To review installed feature charts:
-
-1. In the Rancher UI, go to **Apps & Marketplace**.
-2. Select **Installed Apps**.
-3. Review the chart versions and upgrade to the latest patch release within the same chart major version if needed.
-
-For more information, see the [Helm Charts in Rancher – Versioning Scheme](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#versioning-scheme).
-
-### 4. Upgrade Rancher
+### 3. Upgrade Rancher

 This section describes how to upgrade normal (Internet-connected) or air-gapped installations of Rancher with Helm.

@@ -195,17 +161,17 @@ There will be more values that are listed with this command. This is just an exa

 :::

-:::tip
+:::tip 

-Your deployment name may vary; for example, if you're deploying Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'.
-Thus:
+Your deployment name may vary; for example, if you're deploying Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'. 
+Thus: 
 ```
 helm get values rancher-stable -n cattle-system

 hostname: rancher.my.org
 ```

-:::
+::: 

 If you are upgrading cert-manager to the latest version from v1.5 or below, follow the [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#option-c-upgrade-cert-manager-from-versions-15-and-below) to learn how to upgrade cert-manager without needing to perform an uninstall or reinstall of Rancher. Otherwise, follow the [steps to upgrade Rancher](#steps-to-upgrade-rancher) below.

@@ -228,17 +194,17 @@ The above is an example, there may be more values from the previous step that ne

 :::

-:::tip
+:::tip 

-If you deploy Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'.
-Thus:
+If you deploy Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'. 
+Thus: 
 ```
 helm upgrade rancher-stable rancher-<CHART_REPO>/rancher \
  --namespace cattle-system \
  --set hostname=rancher.my.org
 ```

-:::
+::: 

 Alternatively, it's possible to export the current values to a file and reference that file during upgrade. For example, to only change the Rancher version:

@@ -248,7 +214,7 @@ Alternatively, it's possible to export the current values to a file and referenc
    ```
 1. Update only the Rancher version:

-
+    
    ```
    helm upgrade rancher rancher-<CHART_REPO>/rancher \
      --namespace cattle-system \
@@ -256,10 +222,18 @@ Alternatively, it's possible to export the current values to a file and referenc
      --version=2.6.8
    ```

-### 5. Verify the Upgrade
+### 4. Verify the Upgrade

 Log into Rancher to confirm that the upgrade succeeded.

+:::tip
+
+Having network issues following upgrade?
+
+See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
+
+:::
+
 ## Known Upgrade Issues

 A list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
@@ -32,38 +32,37 @@ For information on enabling experimental features, refer to [this page.](../../.
 | ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `additionalTrustedCAs`         | false                                                 | `bool` - See [Additional Trusted CAs](#additional-trusted-cas)                                                                                    |
 | `addLocal`                     | "true"                                                | `string` - Have Rancher detect and import the "local" (upstream) Rancher server cluster.  _Note: This option is no longer available in v2.5.0. Consider using the `restrictedAdmin` option to prevent users from modifying the local cluster._              |
-| `agentTLSMode`                 | ""                                                    | `string` - either `system-store` or `strict`. See [Agent TLS Enforcement](./tls-settings.md#agent-tls-enforcement)                                |
+| `agentTLSMode`                 | ""                                                    | `string` - either `system-store` or `strict`. See [Agent TLS Enforcement](./tls-settings.md#agent-tls-enforcement) |
 | `antiAffinity`                 | "preferred"                                           | `string` - AntiAffinity rule for Rancher pods - "preferred, required"                                                                             |
 | `auditLog.destination`         | "sidecar"                                             | `string` - Stream to sidecar container console or hostPath volume - "sidecar, hostPath"                                                           |
 | `auditLog.hostPath`            | "/var/log/rancher/audit"                              | `string` - log file destination on host (only applies when `auditLog.destination` is set to `hostPath`)                                           |
-| `auditLog.enabled`             |  false                                                | `bool` - Enables / disables audit logging.                                                                                                        |
-| `auditLog.level`               | 0                                                     | `int` - Sets the [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md) level [0-3].                                |
+| `auditLog.enabled`            |  false                            | `bool` - Enables / disables audit logging.                                           |
+| `auditLog.level`               | 0                                                     | `int` - Sets the [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md) level [0-3].                                  |
 | `auditLog.maxAge`              | 1                                                     | `int` - maximum number of days to retain old audit log files (only applies when `auditLog.destination` is set to `hostPath`)                      |
 | `auditLog.maxBackup`           | 1                                                     | `int` - maximum number of audit log files to retain (only applies when `auditLog.destination` is set to `hostPath`)                               |
 | `auditLog.maxSize`             | 100                                                   | `int` - maximum size in megabytes of the audit log file before it gets rotated (only applies when `auditLog.destination` is set to `hostPath`)    |
 | `auditLog.image.repository`    | "registry.suse.com/bci/bci-micro"                     | `string` - Location for the image used to collect audit logs.                                                                                     |
 | `auditLog.image.tag`           | "15.4.14.3"                                           | `string` - Tag for the image used to collect audit logs.                                                                                          |
-| `auditLog.image.pullPolicy`    | "IfNotPresent"                                        | `string` - Override imagePullPolicy for auditLog images - "Always", "Never", "IfNotPresent".                                                      |
-| `busyboxImage`                 | ""                                                    | `string` - Image location for busybox image used to collect audit logs. _Note: This option is deprecated use `auditLog.image.repository` to control auditing sidecar image._        |
+| `auditLog.image.pullPolicy`    | "IfNotPresent"                                        | `string` - Override imagePullPolicy for auditLog images - "Always", "Never", "IfNotPresent".                                                   |
+| `busyboxImage`                 | ""                                             | `string` - Image location for busybox image used to collect audit logs. _Note: This option is deprecated use `auditLog.image.repository` to control auditing sidecar image._        |
 | `certmanager.version`          | ""                                                    | `string` - set cert-manager compatibility                                                                                                         |
 | `debug`                        | false                                                 | `bool` - set debug flag on rancher server                                                                                                         |
-| `extraEnv`                     | []                                                    | `list` - set additional environment variables for Rancher                                                                                         |
+| `extraEnv`                     | []                                                    | `list` - set additional environment variables for Rancher                                                          |
 | `imagePullSecrets`             | []                                                    | `list` - list of names of Secret resource containing private registry credentials                                                                 |
-| `ingress.configurationSnippet` | ""                                                    | `string` - additional Nginx configuration. Can be used for proxy configuration.                                                                   |
+| `ingress.configurationSnippet` | ""                                                    | `string` - additional Nginx configuration. Can be used for proxy configuration.   |
 | `ingress.extraAnnotations`     | {}                                                    | `map` - additional annotations to customize the ingress                                                                                           |
-|  `ingress.enabled`             |  true                                                 | `string` - When set to false, Helm will not install a Rancher ingress. Set the option to false to deploy your own ingress.                        |
+|  `ingress.enabled` |  true   |    When set to false, Helm will not install a Rancher ingress. Set the option to false to deploy your own ingress.   |
 | `letsEncrypt.ingress.class`    | ""                                                    | `string` - optional ingress class for the cert-manager acmesolver ingress that responds to the Let's Encrypt ACME challenges. Options: traefik, nginx.       |                      |
-| `noProxy`                      | "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local,cattle-system.svc" | `string` - comma separated list of hostnames or ip address not to use the proxy |                           |
+| `noProxy`                      | "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local,cattle-system.svc" | `string` - comma separated list of hostnames or ip address not to use the proxy                              |                                     |
 | `proxy`                        | ""                                                    | `string` - HTTP[S] proxy server for Rancher                                                                                                       |
-| `image.registry`               | ""                                                    | `string` - Override rancher image-specific registry, e.g, http://registry.example.com/                                                            |
-| `image.repository`             | "rancher/rancher"                                     | `string` - Rancher image source                                                                                                                   |
-| `image.pullPolicy`             | "IfNotPresent"                                        | `string` - Override imagePullPolicy for rancher server images - "Always", "Never", "IfNotPresent"                                                 |
-| `image.tag`                    | ""                                                    | `string` - Defaults to .Chart.appVersion for rancher/rancher image tag                                                                            |
-| `replicas`                     | 3                                                     | `int` - Number of Rancher server replicas. Setting to -1 will dynamically choose 1, 2, or 3 based on the number of available nodes in the cluster.|
+| `rancherImage`                 | "rancher/rancher"                                     | `string` - rancher image source                                                                                                                   |
+| `rancherImagePullPolicy`       | "IfNotPresent"                                        | `string` - Override imagePullPolicy for rancher server images - "Always", "Never", "IfNotPresent"                                                 |
+| `rancherImageTag`              | same as chart version                                 | `string` - rancher/rancher image tag                                                                                                              |
+| `replicas`                     | 3                                                     | `int` - Number of Rancher server replicas. Setting to -1 will dynamically choose 1, 2, or 3 based on the number of available nodes in the cluster.                                                                                                        |
 | `resources`                    | {}                                                    | `map` - rancher pod resource requests & limits                                                                                                    |
-| `systemDefaultRegistry`        | ""                                                    | `string` - private registry to be used for all system container images, e.g., http://registry.example.com/                                        |
+| `systemDefaultRegistry`        | ""                                                    | `string` - private registry to be used for all system container images, e.g., http://registry.example.com/                   |
 | `tls`                          | "ingress"                                             | `string` - See [External TLS Termination](#external-tls-termination) for details. - "ingress, external"                                           |
-| `useBundledSystemChart`        | `false`                                               | `bool` - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations.                          |
+| `useBundledSystemChart`        | `false`                                               | `bool` - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations.  |


 When using Rancher v2.12.0 and above, Rancher will use an audit logging controller that watches `AuditPolicy` CRs for configuring additional redactions, for more info see [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md).
@@ -132,14 +131,18 @@ This option is only effective on the initial Rancher install. See [Issue 16522](

 To customize or use a different ingress with Rancher server you can set your own Ingress annotations.

-Please refer to the Traefik documentation for the full list of Ingress NGINX annotations that are [supported](https://doc.traefik.io/traefik/reference/routing-configuration/kubernetes/ingress-nginx/#annotations-support) and [unsupported](https://doc.traefik.io/traefik/reference/routing-configuration/kubernetes/ingress-nginx/#unsupported-annotations) by Traefik's kubernetesIngressNginx provider.
-
 Example on setting a custom certificate issuer:

 ```plain
 --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.
+
+```plain
+--set ingress.configurationSnippet='more_set_input_headers X-Forwarded-Host {{ .Values.hostname }};'
+```
+
 ### HTTP Proxy

 Rancher requires internet access for some functionality (Helm charts). Use `proxy` to set your proxy server or use `extraEnv` to set the `HTTPS_PROXY` environment variable to point to your proxy server.
@@ -212,6 +215,26 @@ If you are using a Private CA signed certificate (or if `agent-tls-mode` is set

 Your load balancer must support long lived websocket connections and will need to insert proxy headers so Rancher can route links correctly.

+### Configuring Ingress for External TLS when Using NGINX v0.22
+
+In NGINX v0.22, the behavior of NGINX has [changed](https://github.com/kubernetes/ingress-nginx/blob/06efac9f0b6f8f84b553f58ccecf79dc42c75cc6/Changelog.md) regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.22, you must enable the `use-forwarded-headers` option for ingress:
+
+For RKE2 installations, you can create a custom `rke2-ingress-nginx-config.yaml` file at `/var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml` containing this required setting to enable using forwarded headers with external TLS termination. Without this required setting applied, the external LB will continuously respond with redirect loops it receives from the ingress controller. (This can be created before or after rancher is installed, rke2 server agent will notice this addition and automatically apply it.)
+
+```yaml
+---
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata:
+  name: rke2-ingress-nginx
+  namespace: kube-system
+spec:
+  valuesContent: |-
+    controller:
+      config:
+        use-forwarded-headers: "true"
+```
+
 ### Required Headers

 - `Host`
@@ -228,3 +251,66 @@ Your load balancer must support long lived websocket connections and will need t
 ### Health Checks

 Rancher will respond `200` to health checks on the `/healthz` endpoint.
+
+### Example NGINX config
+
+This NGINX configuration is tested on NGINX 1.14.
+
+:::caution
+
+This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
+
+:::
+
+- Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster.
+- Replace both occurrences of `FQDN` to the DNS name for Rancher.
+- Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively.
+
+```
+worker_processes 4;
+worker_rlimit_nofile 40000;
+
+events {
+    worker_connections 8192;
+}
+
+http {
+    upstream rancher {
+        server IP_NODE_1:80;
+        server IP_NODE_2:80;
+        server IP_NODE_3:80;
+    }
+
+    map $http_upgrade $connection_upgrade {
+        default Upgrade;
+        ''      close;
+    }
+
+    server {
+        listen 443 ssl http2;
+        server_name FQDN;
+        ssl_certificate /certs/fullchain.pem;
+        ssl_certificate_key /certs/privkey.pem;
+
+        location / {
+            proxy_set_header Host $host;
+            proxy_set_header X-Forwarded-Proto $scheme;
+            proxy_set_header X-Forwarded-Port $server_port;
+            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+            proxy_pass http://rancher;
+            proxy_http_version 1.1;
+            proxy_set_header Upgrade $http_upgrade;
+            proxy_set_header Connection $connection_upgrade;
+            # This allows the ability for the execute shell window to remain open for up to 15 minutes. Without this parameter, the default is 1 minute and will automatically close.
+            proxy_read_timeout 900s;
+            proxy_buffering off;
+        }
+    }
+
+    server {
+        listen 80;
+        server_name FQDN;
+        return 301 https://$server_name$request_uri;
+    }
+}
+```
@@ -10,7 +10,10 @@ Changing the default TLS settings depends on the chosen installation method.

 ## Running Rancher in a highly available Kubernetes cluster

-When you install a Rancher managed Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. Traefik is the default ingress for K3s and can be used with RKE2, refer to [TLS Options](https://doc.traefik.io/traefik/https/tls/#tls-options) for further information.
+When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. The possible TLS settings depend on the used ingress controller:
+
+* nginx-ingress-controller (default for RKE2): [Default TLS Version and Ciphers](https://kubernetes.github.io/ingress-nginx/user-guide/tls/#default-tls-version-and-ciphers).
+* traefik (default for K3s): [TLS Options](https://doc.traefik.io/traefik/https/tls/#tls-options).

 ## Running Rancher in a single Docker container

@@ -243,18 +243,15 @@ When using the [AWS EC2 node driver](../../../how-to-guides/new-user-guides/laun
 | SSH             |   TCP    |     22      | 0.0.0.0/0 and ::/0     |  Inbound  |
 | HTTP            |   TCP    |     80      | 0.0.0.0/0 and ::/0     |  Inbound  |
 | Custom TCP Rule |   TCP    |     443     | 0.0.0.0/0 and ::/0     |  Inbound  |
-| Custom TCP Rule |   TCP    |    8443     | 0.0.0.0/0 and ::/0     |  Inbound  |
 | Custom TCP Rule |   TCP    |    2376     | 0.0.0.0/0 and ::/0     |  Inbound  |
 | Custom TCP Rule |   TCP    |    6443     | 0.0.0.0/0 and ::/0     |  Inbound  |
 | Custom TCP Rule |   TCP    |     179     | sg-xxx (rancher-nodes) |  Inbound  |
-| Custom TCP Rule |   TCP    |    5473     | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom TCP Rule |   TCP    |    9345     | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom TCP Rule |   TCP    |  2379-2380  | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom TCP Rule |   TCP    | 10250-10252 | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom TCP Rule |   TCP    |    10256    | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom UDP Rule |   UDP    |    4789     | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom UDP Rule |   UDP    |    8472     | sg-xxx (rancher-nodes) |  Inbound  |
-| Custom TCP Rule |   TCP    |    9796     | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom TCP Rule |   TCP    | 30000-32767 | 0.0.0.0/0 and ::/0     |  Inbound  |
 | Custom UDP Rule |   UDP    | 30000-32767 | 0.0.0.0/0 and ::/0     |  Inbound  |
 | All traffic     |   All    |     All     | 0.0.0.0/0 and ::/0     | Outbound  |
@@ -185,12 +185,12 @@ Placeholder | Description
    --namespace cattle-system \
    --set hostname=<RANCHER.YOURDOMAIN.COM> \
    --set certmanager.version=<CERTMANAGER_VERSION> \
-    --set image.registry=<REGISTRY.YOURDOMAIN.COM:PORT> \
+    --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
    --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
    --set useBundledSystemChart=true # Use the packaged Rancher system charts
 ```

-**Optional**: To install a specific Rancher version, set the `image.tag` value, example: `--set image.tag=v2.10.3`
+**Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.5.8`

 #### Option B: Certificates From Files Using Kubernetes Secrets

@@ -213,7 +213,7 @@ Install Rancher, declaring your chosen options. Use the reference table below to
   helm install rancher ./rancher-<VERSION>.tgz \
    --namespace cattle-system \
    --set hostname=<RANCHER.YOURDOMAIN.COM> \
-    --set image.registry=<REGISTRY.YOURDOMAIN.COM:PORT> \
+    --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
    --set ingress.tls.source=secret \
    --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
    --set useBundledSystemChart=true # Use the packaged Rancher system charts
@@ -225,7 +225,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
   helm install rancher ./rancher-<VERSION>.tgz \
    --namespace cattle-system \
    --set hostname=<RANCHER.YOURDOMAIN.COM> \
-    --set image.registry=<REGISTRY.YOURDOMAIN.COM:PORT> \
+    --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
    --set ingress.tls.source=secret \
    --set privateCA=true \
    --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
@@ -42,7 +42,7 @@ If you will use ARM64 hosts, the registry must support manifests. As of April 20

 1. Go to our [releases page,](https://github.com/rancher/rancher/releases) find the Rancher v2.x.x release that you want to install, and click **Assets**. Note: Don't use releases marked `rc` or `Pre-release`, as they are not stable for production environments.

-2. From the release's **Assets** section, download the following files, which are required to install Rancher in an air-gap environment:
+2. From the release's **Assets** section, download the following files, which are required to install Rancher in an air gap environment:

 | Release File   | Description  |
 | ---------------- | -------------- |
@@ -83,39 +83,16 @@ In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS

 ### 3. Save the images to your workstation

-(Optional) Verify the image list before pulling:
-
-```bash
-wc -l rancher-images.txt
-head rancher-images.txt
-```
-
-1. Make `rancher-save-images.sh` executable:
-   ```bash
+1. Make `rancher-save-images.sh` an executable:
+   ```
   chmod +x rancher-save-images.sh
   ```

 1. Run `rancher-save-images.sh` with the `rancher-images.txt` image list to create a tarball of all the required images:
-   ```bash
+   ```plain
   ./rancher-save-images.sh --image-list ./rancher-images.txt
   ```
-
-(Optional) Specify a custom output file:
-
-```bash
-./rancher-save-images.sh \
-  --image-list ./rancher-images.txt \
-  --images rancher-images-custom.tar.gz
-```
-
-**Result:** Docker begins pulling the images required for an air-gap installation. The process may take several minutes.
-
-1. Verify that the tarball was created:
-   ```bash
-   ls -lh rancher-images.tar.gz
-   ```
-
-If some images fail to pull, review the output and retry after resolving any issues.
+   **Result:** Docker begins pulling the images used for an air gap install. Be patient. This process takes a few minutes. When the process completes, your current directory will output a tarball named `rancher-images.tar.gz`. Check that the output is in the directory.

 ### 4. Populate the private registry

@@ -186,7 +163,7 @@ Your registry must support manifests. As of April 2020, Amazon Elastic Container
   ./rancher-save-images.ps1
   ```

-   **Result:** Docker begins pulling the images used for an air-gap install. Be patient. This process takes a few minutes. When the process completes, your current directory will output a tarball named `rancher-windows-images.tar.gz`. Check that the output is in the directory.
+   **Result:** Docker begins pulling the images used for an air gap install. Be patient. This process takes a few minutes. When the process completes, your current directory will output a tarball named `rancher-windows-images.tar.gz`. Check that the output is in the directory.

 <a name="windows-3"></a>

@@ -296,7 +273,7 @@ The workstation must have Docker 18.02+ in order to support manifests, which are
   ./rancher-save-images.sh --image-list ./rancher-images.txt
   ```

-**Result:** Docker begins pulling the images used for an air-gap install. Be patient. This process takes a few minutes. When the process completes, your current directory will output a tarball named `rancher-images.tar.gz`. Check that the output is in the directory.
+**Result:** Docker begins pulling the images used for an air gap install. Be patient. This process takes a few minutes. When the process completes, your current directory will output a tarball named `rancher-images.tar.gz`. Check that the output is in the directory.

 <a name="linux-4"></a>

@@ -10,6 +10,8 @@ Now that you have a running RKE2/K3s cluster, you can install Rancher in it. For

 ### Install the Helm CLI

+<DeprecationHelm2 />
+
 Install the [Helm](https://helm.sh/docs/intro/install/) CLI on a host where you have a kubeconfig to access your Kubernetes cluster:

 ```
@@ -8,6 +8,10 @@ title: Helm Version Requirements

 This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.

+> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+
+<DeprecationHelm2 />
+
 ## Identifying the Proper Helm v3 Version

 Select any Helm v3 version that is officially compatible with the Kubernetes version range you are using from our [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions).
@@ -27,4 +31,5 @@ To apply this rule, you may need to reference two external resources:
 ## Additional Notes

 - Helm v3.2.x or higher is required to install or upgrade Rancher v2.5.
+- Helm v2 support was removed in Rancher v2.9.x.
 - When using tools that run Helm commands for you (like Terraform), you must make sure they are configured to use the correct Helm version.
@@ -145,6 +145,18 @@ Before you can perform the upgrade, you must prepare your air gapped environment
    --set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
    ```

+    <DeprecationHelm2 />
+    
+    The Helm 2 command is as follows:
+
+    ```plain
+    helm template ./cert-manager-v0.12.0.tgz --output-dir . \
+    --name cert-manager --namespace cert-manager \
+    --set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller
+    --set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook
+    --set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
+    ```
+
 1. Download the required CRD file for cert-manager (old and new)

    ```plain
@@ -8,10 +8,20 @@ title: Upgrading and Rolling Back Kubernetes

 Following an upgrade to the latest version of Rancher, downstream Kubernetes clusters can be upgraded to use the latest supported version of Kubernetes.

+Rancher calls RKE (Rancher Kubernetes Engine) as a library when provisioning and editing RKE clusters. For more information on configuring the upgrade strategy for RKE clusters, refer to the [RKE documentation](https://rancher.com/docs/rke/latest/en/).
+
+
 ## Tested Kubernetes Versions

 Before a new version of Rancher is released, it's tested with the latest minor versions of Kubernetes to ensure compatibility. For details on which versions of Kubernetes were tested on each Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/)

+## How Upgrades Work
+
+RKE v1.1.0 changed the way that clusters are upgraded.
+
+In this section of the [RKE documentation,](https://rancher.com/docs/rke/latest/en/upgrades/how-upgrades-work) you'll learn what happens when you edit or upgrade your RKE Kubernetes cluster.
+
+
 ## Recommended Best Practice for Upgrades

 When upgrading the Kubernetes version of a cluster, we recommend that you:
@@ -48,6 +58,8 @@ A cluster can be restored to a backup in which the previous Kubernetes version w

 ## Configuring the Upgrade Strategy

+As of RKE v1.1.0, additional upgrade options became available to give you more granular control over the upgrade process. These options can be used to maintain availability of your applications during a cluster upgrade if certain [conditions and requirements](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability) are met.
+
 The upgrade strategy can be configured in the Rancher UI, or by editing the `cluster.yml`. More advanced options are available by editing the `cluster.yml`.

 ### Configuring the Maximum Unavailable Worker Nodes in the Rancher UI
@@ -67,13 +79,15 @@ To change the default number or percentage of worker nodes,

 ### Enabling Draining Nodes During Upgrades from the Rancher UI

+By default, RKE [cordons](https://kubernetes.io/docs/concepts/architecture/nodes/#manual-node-administration) each node before upgrading it. [Draining](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) is disabled during upgrades by default. If draining is enabled in the cluster configuration, RKE will both cordon and drain the node before it is upgraded.
+
 To enable draining each node during a cluster upgrade,

 1. In the upper left corner, click **☰ > Cluster Management**.
 1. On the **Clusters** page, go to the cluster you want to enable node draining and click **⋮ > Edit Config**.
 1. Click **⋮ > Edit**.
 1. In the **Upgrade Strategy** tab, go to the **Drain nodes** field and click **Yes**. Node draining is configured separately for control plane and worker nodes.
-1. Configure the options for how pods are deleted. For more information about each option, refer to [this section.](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools.md#aggressive-and-safe-draining-options)
+1. Configure the options for how pods are deleted. For more information about each option, refer to [this section.](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md#aggressive-and-safe-draining-options)
 1. Optionally, configure a grace period. The grace period is the timeout given to each pod for cleaning things up, so they will have chance to exit gracefully. Pods might need to finish any outstanding requests, roll back transactions or save state to some external storage. If this value is negative, the default value specified in the pod will be used.
 1. Optionally, configure a timeout, which is the amount of time the drain should continue to wait before giving up.
 1. Click **Save**.
@@ -87,17 +101,25 @@ To enable draining each node during a cluster upgrade,

 :::

+### Maintaining Availability for Applications During Upgrades
+
+In [this section of the RKE documentation,](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability/) you'll learn the requirements to prevent downtime for your applications when upgrading the cluster.
+
 ### Configuring the Upgrade Strategy in the cluster.yml

 More advanced upgrade strategy configuration options are available by editing the `cluster.yml`.

+For details, refer to [Configuring the Upgrade Strategy](https://rancher.com/docs/rke/latest/en/upgrades/configuring-strategy) in the RKE documentation. The section also includes an example `cluster.yml` for configuring the upgrade strategy.
+
 ## Troubleshooting

+If a node doesn't come up after an upgrade, the `rke up` command errors out.
+
 No upgrade will proceed if the number of unavailable nodes exceeds the configured maximum.

 If an upgrade stops, you may need to fix an unavailable node or remove it from the cluster before the upgrade can continue.

-A failed node could be in various states:
+A failed node could be in many different states:

 - Powered off
 - Unavailable
@@ -47,7 +47,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and

 ### Working with Cloud Infrastructure

- **Tracking nodes:** The Rancher API server tracks identities of all the [nodes](../how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools.md) in all clusters.
+- **Tracking nodes:** The Rancher API server tracks identities of all the [nodes](../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md) in all clusters.
 - **Setting up infrastructure:**  When configured to use a cloud provider, Rancher can dynamically provision [new nodes](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md) and [persistent storage](../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) in the cloud.

 ### Cluster Visibility
@@ -1,18 +1,11 @@
 ---
-title: Rancher for AWS
-description: Learn about Rancher for AWS from the AWS Marketplace listing.
+title: Rancher Prime AWS Marketplace Quick Start
+description: Deploy SUSE Rancher from the AWS Marketplace listing.
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace"/>
 </head>

-SUSE Rancher for AWS (SRA/SRFA) is a fully managed Software-as-a-Service (SaaS) offering available through the [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-yrzugbpzuukww). It provides a centralized control plane to manage, monitor, and scale Kubernetes clusters within an AWS environment.
+You can quickly deploy Rancher Prime on Amazon Elastic Kubernetes Service (EKS.) To learn more, see the [instructions](https://suse-enceladus.github.io/marketplace-docs/rancher-prime/aws/?repository=rancher-payg-billing-adapter-llc-prd) under Usage Information in the [AWS Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-f2bvszurj2p2c). 

-For deployment prerequisites, architecture requirements, and subscription details, refer to the [AWS Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-yrzugbpzuukww). For more information, refer to the [product documentation](https://documentation.suse.com/cloudnative/rancher-srfa/).
-
-:::note
-
-SUSE Rancher for AWS is an offering distinct from deploying and managing the Rancher server manually on Amazon EKS. If you intend to install and manage your own Rancher deployment on an EKS cluster, refer to [Installing Rancher on Amazon EKS](../../installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md).
-
-:::
@@ -65,7 +65,7 @@ Log in to Rancher to begin using the application. After you log in, you'll make

    Replace `<SERVER_IP>` with your host IP address.

-2.  When prompted, create a password for the default `admin` account.
+2.  When prompted, create a password for the default `admin` account there cowpoke!

 3.  Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node added to your cluster must be able to connect to this URL.<br/><br/>If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster.

@@ -97,7 +97,7 @@ You can access your cluster after its state is updated to **Active**.
 **Active** clusters are assigned two Projects:

 - `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `traefik`, `kube-public`, and `kube-system` namespaces
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces

 #### Finished

@@ -1,459 +0,0 @@
---
-title: Configuring Native CAPI Infrastructure Providers to Provision RKE2 Clusters
---
-
-:::caution
-
-**This is a technology preview and using native CAPI infrastructure providers is an experimental feature introduced in Rancher 2.14.0.** The purpose of this guide is for evaluation and **should not** be used for production clusters, and note some configuration fields are subject to change. Future versions of this feature may be incompatible with this version.
-
-:::
-
-## Overview
-
-Rancher 2.14.0 can provision RKE2 clusters using native CAPI infrastructure providers, such as [CAPA](https://cluster-api-aws.sigs.k8s.io/) (Cluster API Provider AWS) and [CAPV](https://github.com/kubernetes-sigs/cluster-api-provider-vsphere) (Cluster API Provider vSphere).
-
-Standard RKE2 provisioning relies on Rancher’s internal bootstrap and control plane providers alongside Rancher Node Drivers (via `rancher/machine`) as the infrastructure provider. This new mode allows you to substitute Rancher Node Drivers with native CAPI infrastructure providers while retaining Rancher’s bootstrap and control plane logic.
-
-This guide provides simple examples for evaluating this provisioning mode using CAPA and CAPV. Refer to the documentation of each provider for more details on available options and adapt these examples to your needs.
-
-:::note
-Provisioning with a native CAPI infrastructure provider and Rancher as a bootstrap and control plane provider is distinct from using [Rancher Turtles](https://turtles.docs.rancher.com/turtles/stable/en/index.html) and the [CAPRKE2](https://caprke2.docs.rancher.com/) provider to provision a RKE2 cluster and subsequently import it into Rancher.
-:::
-
-### Limitations and requirements
-
- Unsupported configurations: Windows worker nodes and IPv6 are currently not supported.
- UI constraints: Detailed cluster management via the UI is disabled; clusters must be created and modified by applying Kubernetes objects to the local cluster. However, the Cluster Explorer remains accessible.
- Kubernetes cloud provider requirements: A cloud-specific Kubernetes provider for the infrastructure where the downstream cluster runs is required (e.g., the [Kubernetes AWS Cloud Provider](https://cloud-provider-aws.sigs.k8s.io/) for CAPA or the `rancher-vsphere-cpi` chart for CAPV).
-
-## General steps
-
-For both CAPA and CAPV, the general steps are as follows:
-
-1. Install Rancher.
-1. Install a CAPI infrastructure provider, either CAPA or CAPV.
-1. Set-up an identity resource for the provider.
-1. Create a CAPI infrastructure cluster resource.
-1. Create one or more CAPI infrastructure machine template resources.
-1. Create a Rancher `clusters.provisioning.cattle.io` resource that references the identity, infrastructure cluster and infrastructure machine template resources.
-
-After applying the `clusters.provisioning.cattle.io` resource, the cluster appears in the Rancher Cluster Management list (click on **☰ > Cluster Management**), however the detailed view for this type of cluster is currently unavailable.
-
-To view the progress of the provisioning process and troubleshoot, refer to the status of the various CAPI and Rancher provisioning resources in the local cluster:
-
-1. Click **☰**, then click on the icon for your local cluster.
-1. Use the dropdown menu at the top to filter for **All Namespaces**.
-1. From the sidebar, select **More Resources > Cluster Provisioning**.
-
-The logs for the infrastructure provider deployment (e.g. `capa-controller-manager`) also show useful information.
-
-## Installing the infrastructure provider
-
-Rancher allows installing the infrastructure provider declaratively by creating the Rancher Turtles [`CAPIProvider`](https://turtles.docs.rancher.com/turtles/stable/en/reference/capiprovider.html) resource.
-
-### Examples
-
-CAPA:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
-  name: capa-system
---
-apiVersion: turtles-capi.cattle.io/v1alpha1
-kind: CAPIProvider
-metadata:
-  name: aws
-  namespace: capa-system
-spec:
-  type: infrastructure
-  variables:
-    # Global credentials for the provider are not needed
-    # as these examples define credentials for the AWSCluster.
-    AWS_B64ENCODED_CREDENTIALS: ""
-```
-
-CAPV:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
-  name: capv-system
---
-apiVersion: turtles-capi.cattle.io/v1alpha1
-kind: CAPIProvider
-metadata:
-  name: vsphere
-  namespace: capv-system
-spec:
-  type: infrastructure
-  variables:
-    # Global credentials for the provider are not needed
-    # as these examples define credentials for the VsphereCluster.
-    VSPHERE_USERNAME: ""
-    VSPHERE_PASSWORD: ""
-```
-
-## Provisioning a cluster
-
-For these examples, a single machine pool with all roles (control plane, etcd and worker) are used, but the examples can be adapted by specifying more machine pools and separate roles.
-
-Create the resources in your upstream cluster, and replace values within `<>` brackets.
-
-:::caution
-
-Each machine pool defined in the `clusters.provisioning.cattle.io` resource should reference a different machine template.
-
-:::
-
-### CAPA
-
-First, configure IAM as required by CAPA. These roles are assumed by downstream nodes using instance profiles to enable the Kubernetes AWS cloud provider.
-
-To do this, CAPA provides the `clusterawsadm` tool to generate and apply the required objects. Refer to the CAPA manual for more [details](https://cluster-api-aws.sigs.k8s.io/topics/using-clusterawsadm-to-fulfill-prerequisites).
-
-Then, configure the provider identity in the upstream cluster so that the CAPA provider can create resources on AWS. Refer to the manual for all [options](https://cluster-api-aws.sigs.k8s.io/topics/multitenancy).
-
-In this example, we'll use `AWSClusterStaticIdentity`.
-
-Create a secret with your credentials:
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: capa-lab-credentials
-  namespace: capa-system
-type: Opaque
-stringData:
-  AccessKeyID: <access key id>
-  SecretAccessKey: <secret access key>
-  # You might have a session token depending on your credential type.
-  # SessionToken: <session token>
-```
-
-Then, create the identity object that references the secret:
-
-```yaml
-apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
-kind: AWSClusterStaticIdentity
-metadata:
-  name: capa-lab-identity
-spec:
-  secretRef: capa-lab-credentials
-  allowedNamespaces:
-    # The namespace of the AWSCluster resource that points
-    # to this identity for provisioning.
-    list:
-      - fleet-default
-```
-
-Now, create the `AWSCluster` [resource](https://cluster-api-aws.sigs.k8s.io/crd/#infrastructure.cluster.x-k8s.io%2fv1beta2). This object defines the infrastructure configuration common to all machine pools.
-
-CAPA creates VPCs, subnets, security groups and a load balancer in its default configuration, but additional rules must be configured to allow ports needed by Rancher and RKE2. For simplicity, this example defines additional security group rules that allow all traffic between the nodes, but more restrictive rules can be configured instead.
-
-```yaml
-apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
-kind: AWSCluster
-metadata:
-  name: capa-lab
-  namespace: fleet-default
-spec:
-  identityRef:
-    kind: AWSClusterStaticIdentity
-    name: capa-lab-identity
-
-  controlPlaneLoadBalancer:
-    healthCheckProtocol: TCP
-    loadBalancerType: nlb
-
-  region: <e.g. us-east-1>
-
-  # These two additional rules allow all incoming traffic
-  # from other nodes.
-  network:
-    additionalControlPlaneIngressRules:
-      - protocol: "-1"
-        sourceSecurityGroupRoles:
-          - controlplane
-          - node   
-    additionalNodeIngressRules:
-      - protocol: "-1"
-        sourceSecurityGroupRoles:
-          - controlplane
-          - node
-```
-
-Next, create a machine template for the control plane machine pool. Create additional templates for every machine pool defined in the `clusters.provisioning.cattle.io` resource.
-
-```yaml
-apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
-kind: AWSMachineTemplate
-metadata:
-  name: capa-lab-control-plane
-  namespace: fleet-default
-spec:
-  template:
-    spec:
-      ami:
-        # The ami requires cloud-init.
-        id: <your ami>
-      # This should correspond to the profile created through clusterawsadm.
-      # Worker or etcd-only nodes should use nodes.cluster-api-provider-aws.sigs.k8s.io.
-      iamInstanceProfile: control-plane.cluster-api-provider-aws.sigs.k8s.io
-      instanceType: t3.medium
-      # This refers to the name of an EC2 key pair.
-      sshKeyName: <your ssh key>
-      rootVolume:
-        size: 16
-      cloudInit:
-        insecureSkipSecretsManager: true
-```
-
-:::caution
-The `insecureSkipSecretsManager` option is set to true to bypass the AWS secrets manager as a source of userdata for the provisioned instances. This source restricts the visibility of the userdata but requires a custom cloud-init datasource which is not currently compatible with the userdata generated by Rancher. For more information, see the [CAPA documentation](https://cluster-api-aws.sigs.k8s.io/topics/userdata-privacy).
-:::
-
-Finally, create the Rancher `clusters.provisioning.cattle.io` resource and point to the CAPA cluster and machine template that were just created.
-
-```yaml
-apiVersion: provisioning.cattle.io/v1
-kind: Cluster
-metadata:
-  name: capa-lab
-  namespace: fleet-default
-spec:
-  kubernetesVersion: v1.35.1+rke2r1
-  rkeConfig:
-    # This is the ref to the infra cluster defined above.
-    infrastructureRef:
-      kind: AWSCluster
-      name: capa-lab
-      namespace: fleet-default
-      apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
-    machinePools:
-      - name: ctrl
-        controlPlaneRole: true
-        etcdRole: true
-        workerRole: true
-        quantity: 3
-        machineConfigRef:
-          kind: AWSMachineTemplate
-          name: capa-lab-control-plane
-          namespace: fleet-default
-          apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
-    machineGlobalConfig:
-      cni: calico
-      disable-kube-proxy: false
-      etcd-expose-metrics: false
-      ingress-controller: traefik
-      protect-kernel-defaults: false
-      cloud-provider-name: external
-      node-name-from-cloud-provider-metadata: true
-    # The AWS cloud controller definition. The controller uses the IAM instance profile for its AWS credentials.
-    additionalManifest: |-
-      apiVersion: helm.cattle.io/v1
-      kind: HelmChart
-      metadata:
-        name: aws-cloud-controller-manager
-        namespace: kube-system
-      spec:
-        chart: aws-cloud-controller-manager
-        repo: https://kubernetes.github.io/cloud-provider-aws
-        targetNamespace: kube-system
-        bootstrap: true
-        valuesContent: |-
-          hostNetworking: true
-          nodeSelector:
-            node-role.kubernetes.io/control-plane: "true"
-          args:
-            - --configure-cloud-routes=false
-            - --v=5
-            - --cloud-provider=aws
-```
-
-### CAPV
-
-First, configure the provider identity in the upstream cluster so that the CAPV provider can create resources on your vSphere server. Refer to the manual for all identity [options](https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/v1.15.2/docs/identity_management.md), and for general vSphere [requirements](https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/v1.15.2/docs/getting_started.md).
-
-In this example, we'll use `VSphereClusterIdentity`.
-
-Create a secret with your credentials:
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: capv-lab-credentials
-  namespace: capv-system
-type: Opaque
-stringData:
-  username: <your vSphere username>
-  password: <your vSphere password>
-```
-
-Then, create the identity object that references the secret:
-
-```yaml
-apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-kind: VSphereClusterIdentity
-metadata:
-  name: capv-lab-identity
-spec:
-  secretName: capv-lab-credentials
-  allowedNamespaces:
-    selector:
-      # The namespace of the VSphereCluster for which this identity
-      # is used when provisioning.
-      matchLabels:
-        kubernetes.io/metadata.name: fleet-default
-```
-
-Like for CAPA, it is also necessary to install the [cloud provider for vSphere](https://github.com/kubernetes/cloud-provider-vsphere) in the downstream cluster.
-
-To securely transfer the credentials for the CPI chart, you can enable the prebootstrap feature in Rancher. This can be done by [enabling](../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md) the `provisioningprebootstrap` feature flag and causes Rancher to restart.
-
-Now, create the secret that is sent to the downstream cluster. If you use a different name to create the `clusters.provisioning.cattle.io` resource, make sure you update the `rke.cattle.io/object-authorized-for-clusters` annotation below.
-
-```yaml
-# Credential secret synced to the downstream cluster for the vsphere CPI chart.
-apiVersion: v1
-kind: Secret
-metadata:
-  name: vsphere-cpi-creds
-  namespace: fleet-default
-  annotations:
-    # Can be a comma-separated list for multiple clusters, with no spaces.
-    rke.cattle.io/object-authorized-for-clusters: capv-lab
-    provisioning.cattle.io/sync-bootstrap: "true"
-    provisioning.cattle.io/sync-target-namespace: kube-system
-type: Opaque
-stringData:
-  # Change the prefix of the key to match your vCenter host.
-  <vsphere host>.username: <your vSphere username>
-  <vsphere host>.password: <your vSphere password>
-```
-
-Now, create the `VSphereCluster` resource. This resource defines the infrastructure configuration common to all machine pools. Refer to the CAPV documentation for more configuration options.
-
-```yaml
-apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-kind: VSphereCluster
-metadata:
-  name: capv-lab
-  namespace: fleet-default
-spec:
-  identityRef:
-    kind: VSphereClusterIdentity
-    name: capv-lab-identity
-  server: <vsphere fqdn>
-```
-
-Next, create a machine template for the control plane machine pool. Create additional templates for every machine pool defined in the `clusters.provisioning.cattle.io` resource.
-
-```yaml
-apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-kind: VSphereMachineTemplate
-metadata:
-  name: capv-lab-control-plane
-  namespace: fleet-default
-spec:
-  template:
-    spec:
-      datacenter: <datacenter>
-      datastore: <datastore>
-      diskGiB: 20
-      folder: <your folder>
-      memoryMiB: 4096
-      network:
-        devices:
-        - dhcp4: true
-          networkName: <your network>
-      numCPUs: 2
-      os: Linux
-      resourcePool: <your resource pool>
-      template: <your VM template>
-```
-
-Finally, create the Rancher `clusters.provisioning.cattle.io` resource and point to the CAPV cluster and machine template that were just created. Note that this example disables the CSI chart for simplicity. The CPI chart is required.
-
-```yaml
-apiVersion: provisioning.cattle.io/v1
-kind: Cluster
-metadata:
-  name: capv-lab
-  namespace: fleet-default
-spec:
-  kubernetesVersion: v1.35.1+rke2r1
-  rkeConfig:
-    infrastructureRef:
-      kind: VSphereCluster
-      name: capv-lab
-      namespace: fleet-default
-      apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-    machinePools:
-      - name: ctrl
-        controlPlaneRole: true
-        etcdRole: true
-        workerRole: true
-        quantity: 3
-        machineConfigRef:
-          kind: VSphereMachineTemplate
-          name: capv-lab-control-plane
-          namespace: fleet-default
-          apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-    machineGlobalConfig:
-      cni: calico
-      disable-kube-proxy: false
-      etcd-expose-metrics: false
-      ingress-controller: traefik
-      protect-kernel-defaults: false
-      disable:
-        - rancher-vsphere-csi
-      cloud-provider-name: rancher-vsphere
-    chartValues:
-      rancher-vsphere-cpi:
-        vCenter:
-          datacenters: <your datacenter>
-          host: <vsphere fqdn>
-          # The credential secret is transferred by the prebootstrap mechanism,
-          # and the cpi chart expects the default name (vsphere-cpi-creds).
-          credentialsSecret:
-            generate: false
-```
-
-### Changing machine templates
-
-Machine templates for CAPI infrastructure providers, such as `AWSMachineTemplate` and `VSphereMachineTemplate` are usually immutable. To modify the configuration of the instances in a machine pool, create a new template with a different name, then edit the machine pool in `clusters.provisioning.cattle.io` to point to this new template. This causes all of the machines in that pool to be recreated with the new configuration.
-
-### Customizing userdata
-
-Custom user data can be defined for each machine pool in the `clusters.provisioning.cattle.io` resource. To do this, use the `.spec.rkeConfig.machinePools.userdata.inlineUserdata` as an inline yaml string in the plain cloud-config format. The contents of this field are merged with the userdata generated by Rancher to bootstrap the cluster nodes.
-
-:::caution
-Do not include sensitive data in this field, as it is part of a resource other than a Secret.
-
-This field is experimental and subject to change. It is only valid for native CAPI providers described in this document, and has no effect on clusters provisioned by Rancher through the standard method with node drivers.
-:::
-
-Modifying the userdata field causes all of the machines in the pool to be recreated.
-
-```yaml
-# Only some fields of the provisioning cluster resource are shown here.
-apiVersion: provisioning.cattle.io/v1
-kind: Cluster
-metadata:
-  name: capv-lab
-  namespace: fleet-default
-spec:
-  kubernetesVersion: v1.35.1+rke2r1
-  rkeConfig:
-    machinePools:
-      - name: ctrl
-        userdata:
-          inlineUserdata: |
-            runcmd:
-              - ["echo", "Hello!"]
-```
@@ -6,13 +6,8 @@ title: Configure Rancher as an OIDC provider
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/configure-oidc-provider"/>
 </head>

-Rancher can act as an OpenID Connect (OIDC) Identity Provider (IdP) for other applications. This allows you to use Rancher's centralized authentication and role-based access control (RBAC) to manage access to external, third-party applications. This can be used for enabling single sign-on (SSO) across Rancher components. For example, see the [documentation](https://documentation.suse.com/cloudnative/suse-observability/latest/en/setup/security/authentication/oidc.html) for configuring the OIDC provider for SUSE Observability.
-
-:::note
-Because OIDC is a superset of OAuth2, you can use Rancher as an OAuth2 server without requiring full OIDC. This ensures that clients utilizing the OAuth2 aspect, such as the `rancher-ai-mcp` server, are fully supported.
-:::
-
-The Rancher OIDC Provider issues access tokens for OAuth2 and OIDC that can be used as standard Bearer tokens (per RFC6750) to authenticate with Rancher. Previously, only an ID token could be used to impersonate and authenticate a user.
+Rancher can function as a standard OpenID Connect (OIDC) provider, allowing external applications to use Rancher for authentication.
+This can be used for enabling single sign-on (SSO) across Rancher Prime components. For example, see the [documentation](https://documentation.suse.com/cloudnative/suse-observability/latest/en/setup/security/authentication/oidc.html) for configuring the OIDC provider for SUSE Observability.

 The OIDC provider can be enabled with the `oidc-provider` feature flag. When this flag is on the following endpoints are available:

@@ -26,51 +21,27 @@ The OIDC provider can be enabled with the `oidc-provider` feature flag. When thi

 The OIDC provider supports the OIDC Authentication Code Flow with PKCE.

-## Configuring an OIDC Client
+## Configure OIDCClient

-An `OIDCClient` represents an external application that will be authenticating against Rancher. To register a client application, you must create an `OIDCClient` custom resource.
+An `OIDCClient` represents an external application that will be authenticating against Rancher.

-### Configuration Fields
+### Programmatically

-When defining your `OIDCClient` manifest, you must include specific fields to pass CRD validation:
+Create an `OIDCClient`:

- `spec.tokenExpirationSeconds`: This field is strictly required and will cause a validation error if omitted. It defines the lifespan of the access token.
- `spec.refreshTokenExpirationSeconds`: This field is also strictly required and will cause a validation error if omitted. It defines the lifespan of the refresh token.
- `scopes` (Optional): This field allows you to restrict the scopes that a client can request. If not explicitly configured, the allowed scopes will default to `openid`, `profile`, and `offline_access`.
-
-### Example OIDC Client Manifest
-
-Below is an example of an `OIDCClient` configuration:
-
-:::note
-You must include the expiration fields to successfully apply the resource.
-:::
-
 ```yaml
 apiVersion: management.cattle.io/v3
 kind: OIDCClient
 metadata:
-  name: example-client
+  name: oidc-client-test
 spec:
-  description: "Example OIDC Client"
-  redirectUris:
-    - "https://example-app.com/callback"
-  tokenExpirationSeconds: 3600
-  refreshTokenExpirationSeconds: 86400
-  # scopes:
-  #   - openid
-  #   - profile
-  #   - offline_access
-
+  tokenExpirationSeconds: 600 # expiration of the id_token and access_token
+  refreshTokenExpirationSeconds: 3600 # expiration of the refresh_token
+  redirectURIs:
+    - "https://myredirecturl.com" # replace with your redirect url
 ```
-
-Save this configuration to a file (e.g., `oidcclient.yaml`) and apply it to your Rancher local cluster:
-
-```
-kubectl apply -f oidcclient.yaml
-```
-
-Rancher automatically generates a client ID and client secret for each `OIDCClient`. Once the resource is created, Rancher populates the status field with the client id:
+Rancher automatically generates a client ID and client secret for each `OIDCClient`.
+Once the resource is created, Rancher populates the status field with the client id:

 ```yaml
 apiVersion: management.cattle.io/v3
@@ -82,10 +53,6 @@ spec:
  refreshTokenExpirationSeconds: 3600 # expiration of the refresh_token
  redirectURIs:
    - "https://myredirecturl.com" # replace with your redirect url
-  scopes: # Optional: Restricts the scopes the client can request. Defaults to openid, profile, and offline_access if omitted.
-    - openid
-    - profile
-    - offline_access
 status:
  clientID: client-xxx
  clientSecrets:
@@ -94,7 +61,8 @@ status:
      lastFiveCharacters: xxx
 ```

-Rancher automatically generates a Kubernetes `Secret` in the `cattle-oidc-client-secrets` namespace for each `OIDCClient` resource. The Secret's name matches the `OIDCClient` client ID. Initially, the `Secret` contains a single client secret.
+Rancher automatically generates a Kubernetes `Secret` in the `cattle-oidc-client-secrets` namespace for each `OIDCClient` resource. The Secret's name matches the `OIDCClient` client ID.
+Initially, the `Secret` contains a single client secret.

 To retrieve the client secret:

@@ -64,7 +64,7 @@ When you install the Helm chart, you should pass in feature flag names in a comm
 helm install rancher ./rancher-<VERSION>.tgz \
  --namespace cattle-system \
  --set hostname=<RANCHER.YOURDOMAIN.COM> \
-  --set image.registry=<REGISTRY.YOURDOMAIN.COM:PORT> \
+  --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
  --set ingress.tls.source=secret \
  --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
  --set useBundledSystemChart=true # Use the packaged Rancher system charts
@@ -61,12 +61,14 @@ metadata:
 ```
 In this example, if the project's quota does not include configMaps in its list of resources, then Rancher will ignore `configMaps` in this override.

-Users are advised to either use the `extended` map to configure additional custom limits for resources not built into the project, for all namespaces in the project, or to create dedicated `ResourceQuota` objects in specific namespaces for the same, just for these namespaces. Resource quotas are native Kubernetes objects, and Rancher will ignore user-defined quotas in namespaces belonging to a project with a quota, thus giving users more control.
+Users are advised to create dedicated `ResourceQuota` objects in namespaces to configure additional custom limits for resources not defined on the project.
+Resource quotas are native Kubernetes objects, and Rancher will ignore user-defined quotas in namespaces belonging to a project with a quota,
+thus giving users more control.

 The following table explains the key differences between the two quota types.

 | Rancher Resource Quotas                                    | Kubernetes Resource Quotas                               |
 | ---------------------------------------------------------- | -------------------------------------------------------- |
-| Applies to projects and namespaces.                        | Applies to namespaces only.                              |
-| Creates resource pool for all namespaces in a project.     | Applies static resource limits to individual namespaces. |
+| Applies to projects and namespace.                         | Applies to namespaces only.                              |
+| Creates resource pool for all namespaces in project.       | Applies static resource limits to individual namespaces. |
 | Applies resource quotas to namespaces through propagation. | Applies only to the assigned namespace.
@@ -48,17 +48,3 @@ Edit resource quotas when:
 1. Click **Create**.

 **Result:** The resource quota is applied to your project and namespaces. When you add more namespaces in the future, Rancher validates that the project can accommodate the namespace. If the project can't allocate the resources, you may still create namespaces, but they will be given a resource quota of 0. Subsequently, Rancher will not allow you to create any resources restricted by this quota.
-
-### Advanced: Beyond the basic Resource Quotas
-
-The set of resource quotas listed in the **Resource Type** dropdown of **Edit Config** is limited. For quotas outside of that set use **Edit Config** and **Add Resource** as already described, and select **Custom** as the resource type. This enables the edit field **Resource Identifier** for the entry of the necessary identifier. Some examples of identifiers are:
-
- `requests.nvidia.com/gpu`
- `gold.storageclass.storage.k8s.io/requests.storage`
- `count/podtemplates`
-
-:::warning
-
-While it is possible to specify `Custom` which refer to quotas in the basic builtin set it is currently **strongly** recommended to use the builtin fields for them instead. Also, in case of conflicts, i.e. specifying a quota for a resource in both its builtin field and via `Custom`, the data found in the builtin field has priority and the data in `Custom` is ignored.
-
-:::
@@ -8,7 +8,7 @@ title: Overriding the Default Limit for a Namespace

 Although the **Namespace Default Limit** propagates from the project to each namespace when created, in some cases, you may need to increase (or decrease) the quotas for a specific namespace. In this situation, you can override the default limits by editing the namespace.

-In the diagram below, the Rancher administrator has a resource quota in effect for their project. However, the administrator wants to override the cpu limits for `Namespace 3` so that it has more resources available. Therefore, the administrator [raises the cpu limits](../../../new-user-guides/manage-clusters/projects-and-namespaces.md) for `Namespace 3` so that the namespace can access more resources.
+In the diagram below, the Rancher administrator has a resource quota in effect for their project. However, the administrator wants to override the namespace limits for `Namespace 3` so that it has more resources available. Therefore, the administrator [raises the namespace limits](../../../new-user-guides/manage-clusters/projects-and-namespaces.md) for `Namespace 3` so that the namespace can access more resources.

 <sup>Namespace Default Limit Override</sup>

@@ -6,20 +6,14 @@ title: Resource Quota Type Reference
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/resource-quota-types"/>
 </head>

-When you create a resource quota, you are configuring the pool of resources available to the project. Rancher supports the use of arbitrary resource references and their quotas. This allows you to utilize all upstream [Kubernetes `ResourceQuota`](https://kubernetes.io/docs/concepts/policy/resource-quotas/#types-of-resource-quota) types when managing project resource quotas.
-
-You can set resource limits for the following predefined resource types, where the `Custom` type enables specification of arbitrary resources and their quotas.
-
-:::note
-Support for arbitrary resource references using the `Custom` type does not cover resources in the `ext.cattle.io` API group.
-:::
+When you create a resource quota, you are configuring the pool of resources available to the project. You can set the following resource limits for the following resource types.

 | Resource Type            | Description                                                                                                                                                                                       |
 | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| CPU Limit*               | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the project/namespace.<sup>1</sup> |
+| CPU Limit*                | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the project/namespace.<sup>1</sup> |
 | CPU Reservation*         | The minimum amount of CPU (in millicores) guaranteed to the project/namespace.<sup>1</sup>                                                                                                        |
-| Memory Limit*            | The maximum amount of memory (in [bytes](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory)) allocated to the project/namespace.<sup>1</sup>       |
-| Memory Reservation*      | The minimum amount of memory (in bytes) guaranteed to the project/namespace.<sup>1</sup>                                                                                                          |
+| Memory Limit*           | The maximum amount of memory (in bytes) allocated to the project/namespace.<sup>1</sup>                                                                                                           |
+| Memory Reservation*       | The minimum amount of memory (in bytes) guaranteed to the project/namespace.<sup>1</sup>                                                                                                          |
 | Storage Reservation      | The minimum amount of storage (in gigabytes) guaranteed to the project/namespace.                                                                                                                 |
 | Services Load Balancers  | The maximum number of load balancers services that can exist in the project/namespace.                                                                                                            |
 | Services Node Ports      | The maximum number of node port services that can exist in the project/namespace.                                                                                                                 |
@@ -28,23 +22,10 @@ Support for arbitrary resource references using the `Custom` type does not cover
 | ConfigMaps               | The maximum number of ConfigMaps that can exist in the project/namespace.                                                                                                                         |
 | Persistent Volume Claims | The maximum number of persistent volume claims that can exist in the project/namespace.                                                                                                           |
 | Replications Controllers | The maximum number of replication controllers that can exist in the project/namespace.                                                                                                            |
-| Secrets                  | The maximum number of secrets that can exist in the project/namespace. |                                                                                   |
-| Custom\*\*               | The specification of arbitrary resources and their quotas, beyond the resource types built into projects, as listed above.                                                      		       |
+| Secrets                  | The maximum number of secrets that can exist in the project/namespace.                                                                                                                            |

 :::note **<sup>*</sup>**

-When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project or namespace, all containers will require a respective CPU or Memory field set during creation. A container default resource limit can be set at the same time to avoid the need to explicitly set these limits for every workload. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details on why this is required.
+When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project / namespace, all containers will require a respective CPU or Memory field set during creation. A container default resource limit can be set at the same time to avoid the need to explicitly set these limits for every workload. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details on why this is required.

-:::
-
-:::note **<sup>\*\*</sup>**
-
-For example:
-
-  - `requests.nvidia.com/gpu: 4`
-  - `gold.storageclass.storage.k8s.io/requests.storage: 500Gi`
-  - `count/podtemplates: 10`
-
-See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#quota-for-extended-resources) for many more examples.
-
-:::
+:::
@@ -33,7 +33,7 @@ To use a premade dashboard, go to [https://grafana.com/grafana/dashboards](https
 To use your own dashboard:

 1. Click on the link to open Grafana. On the cluster detail page, click **Monitoring**.
-1. Log in to Grafana. Note: The default Admin username and password for the Grafana instance is `admin` and `prom-operator`. Alternative credentials can also be supplied on deploying or upgrading the chart.
+1. Log in to Grafana. Note: The default Admin username and password for the Grafana instance is `admin/prom-operator`. Alternative credentials can also be supplied on deploying or upgrading the chart.

    :::note

@@ -113,7 +113,7 @@ Note that the RBAC roles exposed by the Monitoring chart to add Grafana Dashboar
 1. On the **Clusters** page, go to the cluster where you want to configure the Grafana namespace and click **Explore**.
 1. In the left navigation bar, click **Monitoring**.
 1. Click **Grafana**.
-1. Log in to Grafana. Note: The default Admin username and password for the Grafana instance is `admin` and `prom-operator`. Alternative credentials can also be supplied on deploying or upgrading the chart.
+1. Log in to Grafana. Note: The default Admin username and password for the Grafana instance is `admin/prom-operator`. Alternative credentials can also be supplied on deploying or upgrading the chart.

    :::note

@@ -20,7 +20,7 @@ To see the links to the external monitoring UIs, including Grafana dashboards, y
 1. In the left navigation menu, click **Monitoring.**
 1. Click **Grafana.** The Grafana dashboard should open in a new tab.
 1. Go to the log in icon in the lower left corner and click **Sign In.**
-1. Log in to Grafana. The default Admin username and password for the Grafana instance is `admin` and `prom-operator`. (Regardless of who has the password, cluster administrator permission in Rancher is still required access the Grafana instance.) Alternative credentials can also be supplied on deploying or upgrading the chart.
+1. Log in to Grafana. The default Admin username and password for the Grafana instance is `admin/prom-operator`. (Regardless of who has the password, cluster administrator permission in Rancher is still required access the Grafana instance.) Alternative credentials can also be supplied on deploying or upgrading the chart.


 ### Getting the PromQL Query Powering a Grafana Panel
@@ -1,266 +0,0 @@
---
-title: Using an External Gateway with Rancher
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/rancher-deployment-guides/configure-with-existing-gateway/"/>
-</head>
-
-When using the Gateway API network exposure type, Rancher can create and manage its own Gateway resource. However, if you have an existing Gateway that you manage independently (for example, a shared Gateway used by multiple applications), you will need to create your own HTTPRoute resources to route traffic to Rancher.
-
-This section covers how to create the required HTTPRoute resources manually when using an externally managed Gateway.
-
-## Prerequisites
-
- An existing Gateway resource configured and operational in your cluster
- Knowledge of your Gateway's:
-  - Name and namespace
-  - Listener names (sectionName) for HTTP and/or HTTPS traffic
- Rancher installed with `networkExposure.type` set to something other than `gateway` (e.g., `none` or `ingress`)
-
-## Cross-Namespace Gateway Requirements
-
-If your Gateway is in a different namespace than Rancher (e.g., Gateway in `gateway-system`, Rancher in `cattle-system`), the Gateway must be configured to accept HTTPRoutes from the Rancher namespace. By default, Gateway API only allows routes from the same namespace as the Gateway.
-
-The Gateway owner must configure `allowedRoutes` on the relevant listeners. There are two options:
-
-**Option 1: Allow routes from all namespaces**
-
-```yaml
-apiVersion: gateway.networking.k8s.io/v1
-kind: Gateway
-metadata:
-  name: shared-gateway
-  namespace: gateway-system
-spec:
-  gatewayClassName: example
-  listeners:
-    - name: https
-      port: 443
-      protocol: HTTPS
-      allowedRoutes:
-        namespaces:
-          from: All
-    - name: http
-      port: 80
-      protocol: HTTP
-      allowedRoutes:
-        namespaces:
-          from: All
-```
-
-**Option 2: Allow routes from specific namespaces (more restrictive)**
-
-```yaml
-apiVersion: gateway.networking.k8s.io/v1
-kind: Gateway
-metadata:
-  name: shared-gateway
-  namespace: gateway-system
-spec:
-  gatewayClassName: example
-  listeners:
-    - name: https
-      port: 443
-      protocol: HTTPS
-      allowedRoutes:
-        namespaces:
-          from: Selector
-          selector:
-            matchLabels:
-              shared-gateway-access: "true"
-    - name: http
-      port: 80
-      protocol: HTTP
-      allowedRoutes:
-        namespaces:
-          from: Selector
-          selector:
-            matchLabels:
-              shared-gateway-access: "true"
-```
-
-When using the selector approach, ensure the Rancher namespace has the required label:
-
-```bash
-kubectl label namespace cattle-system shared-gateway-access=true
-```
-
-> **Note:** If the Gateway and Rancher are in the same namespace, no additional configuration is needed—the default `allowedRoutes` setting (`from: Same`) will permit the HTTPRoute attachment.
-
-## Determining Your Rancher Service Values
-
-Before creating HTTPRoute resources, identify the following values from your Rancher installation:
-
-| Value | How to Determine | Example |
-|-------|------------------|---------|
-| **Release Name** | The name used in `helm install <release-name>` | `rancher` |
-| **Namespace** | The namespace where Rancher is installed | `cattle-system` |
-| **Hostname** | The `hostname` value from your Helm values | `rancher.example.com` |
-| **TLS Mode** | The `tls` value from your Helm values | `ingress`, `external`, or `secret` |
-| **Service HTTP Disabled** | The `service.disableHTTP` value | `true` or `false` |
-
-The Rancher service name follows the pattern: `<release-name>-rancher` (or just `<release-name>` if the release name already contains "rancher").
-
-## HTTPRoute Configuration
-
-### Primary HTTPRoute
-
-Create an HTTPRoute to direct traffic from your Gateway to the Rancher service. The configuration depends on your TLS setup:
-
-**When TLS terminates at the Gateway or within Kubernetes (`tls: ingress`, `tls: secret`, or `tls: letsEncrypt`):**
-
-```yaml
-apiVersion: gateway.networking.k8s.io/v1
-kind: HTTPRoute
-metadata:
-  name: rancher
-  namespace: cattle-system  # Must match Rancher's namespace
-spec:
-  parentRefs:
-    - name: <your-gateway-name>
-      namespace: <your-gateway-namespace>
-      sectionName: <your-https-listener-name>  # Your Gateway's HTTPS listener
-  hostnames:
-    - <your-rancher-hostname>  # e.g., rancher.example.com
-  rules:
-    - matches:
-        - path:
-            type: PathPrefix
-            value: /
-      backendRefs:
-        - name: rancher  # Your Rancher service name
-          port: 80       # Use 443 if service.disableHTTP=true
-```
-
-**When TLS terminates externally (`tls: external`):**
-
-```yaml
-apiVersion: gateway.networking.k8s.io/v1
-kind: HTTPRoute
-metadata:
-  name: rancher
-  namespace: cattle-system
-spec:
-  parentRefs:
-    - name: <your-gateway-name>
-      namespace: <your-gateway-namespace>
-      sectionName: <your-http-listener-name>  # Your Gateway's HTTP listener
-  hostnames:
-    - <your-rancher-hostname>
-  rules:
-    - matches:
-        - path:
-            type: PathPrefix
-            value: /
-      backendRefs:
-        - name: rancher
-          port: 80
-```
-
-### HTTP to HTTPS Redirect Route (Optional)
-
-If TLS terminates at or within Kubernetes (not externally), you may want to redirect HTTP traffic to HTTPS. Create an additional HTTPRoute:
-
-```yaml
-apiVersion: gateway.networking.k8s.io/v1
-kind: HTTPRoute
-metadata:
-  name: rancher-http-redirect
-  namespace: cattle-system
-spec:
-  parentRefs:
-    - name: <your-gateway-name>
-      namespace: <your-gateway-namespace>
-      sectionName: <your-http-listener-name>  # Your Gateway's HTTP listener
-  hostnames:
-    - <your-rancher-hostname>
-  rules:
-    - filters:
-        - type: RequestRedirect
-          requestRedirect:
-            scheme: https
-            statusCode: 301
-```
-
-## Using extraObjects
-
-You can include these HTTPRoute resources directly in your Rancher Helm installation using the `extraObjects` value. This keeps all resources managed together:
-
-```yaml
-# values.yaml
-hostname: rancher.example.com
-tls: ingress
-
-extraObjects:
-  - apiVersion: gateway.networking.k8s.io/v1
-    kind: HTTPRoute
-    metadata:
-      name: rancher
-    spec:
-      parentRefs:
-        - name: my-shared-gateway
-          namespace: gateway-system
-          sectionName: https
-      hostnames:
-        - rancher.example.com
-      rules:
-        - matches:
-            - path:
-                type: PathPrefix
-                value: /
-          backendRefs:
-            - name: rancher
-              port: 80
-
-  - apiVersion: gateway.networking.k8s.io/v1
-    kind: HTTPRoute
-    metadata:
-      name: rancher-http-redirect
-    spec:
-      parentRefs:
-        - name: my-shared-gateway
-          namespace: gateway-system
-          sectionName: http
-      hostnames:
-        - rancher.example.com
-      rules:
-        - filters:
-            - type: RequestRedirect
-              requestRedirect:
-                scheme: https
-                statusCode: 301
-```
-
-## Backend Port Selection
-
-The port in `backendRefs` depends on your `service.disableHTTP` setting:
-
-| `service.disableHTTP` | Backend Port |
-|-----------------------|--------------|
-| `false` (default)     | `80`         |
-| `true`                | `443`        |
-
-## Listener Selection Summary
-
-| TLS Configuration | Primary Route Listener | Redirect Route |
-|-------------------|------------------------|----------------|
-| `tls: external`   | HTTP listener          | Not needed     |
-| `tls: ingress`    | HTTPS listener         | HTTP listener (optional) |
-| `tls: secret`     | HTTPS listener         | HTTP listener (optional) |
-| `tls: letsEncrypt`| HTTPS listener         | HTTP listener (optional) |
-
-## Troubleshooting
-
-**HTTPRoute not being accepted:**
- Verify the Gateway name and namespace are correct
- Ensure the `sectionName` matches an existing listener on your Gateway
- Check that the listener allows routes from the Rancher namespace (see Gateway's `allowedRoutes` configuration)
-
-**Connection refused or timeouts:**
- Confirm the Rancher service exists and has endpoints: `kubectl get endpoints rancher -n cattle-system`
- Verify the backend port matches your `service.disableHTTP` setting
-
-**Certificate errors:**
- If using `tls: ingress` or `tls: secret`, ensure your Gateway's HTTPS listener has the appropriate certificate configured
- Verify the certificate covers your Rancher hostname
@@ -1,10 +0,0 @@
---
-title: Rancher Deployment Guides
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/rancher-deployment-guides"/>
-</head>
-
- [Using an External Gateway with Rancher](configure-with-existing-gateway.md)
-
@@ -14,7 +14,7 @@ If you want to standardize the hardware in your clusters, use RKE templates conj

 ### Node Templates

-Node templates are responsible for node configuration and node provisioning in Rancher. From your user profile, you can set up node templates to define which templates are used in each of your node pools. With node pools enabled, you can make sure you have the required number of nodes in each node pool, and ensure that all nodes in the pool are the same.
+[Node templates](../../../../reference-guides/user-settings/manage-node-templates.md) are responsible for node configuration and node provisioning in Rancher. From your user profile, you can set up node templates to define which templates are used in each of your node pools. With node pools enabled, you can make sure you have the required number of nodes in each node pool, and ensure that all nodes in the pool are the same.

 ### Terraform

@@ -53,16 +53,12 @@ if the user has not yet logged in to Rancher. However, if the user has previousl
 | Client Secret             | The generated Secret of your Amazon Cognito App Client.                                                                                                                                                                                             |
 | Issuer                    | The Issuer URL of your Amazon Cognito App Client. It follows the format `https://cognito-idp.{region}.amazonaws.com/{userPoolId}`, and can be found in the App Client settings page. Rancher uses the Issuer URL to fetch all of the required URLs. |

-## OIDC Support for PKCE Extension
-
-<OIDCPKCESupport />
-
-## Configuring OIDC Single Logout (SLO)
-
-<ConfigureSLOOidc />
-
 ## Troubleshooting

 ### You are not redirected to your authentication provider

 If you fill out the **Configure an Amazon Cognito account** form and click on **Enable**, and you are not redirected to Amazon Cognito, verify your Amazon Cognito configuration.
+
+## Configuring OIDC Single Logout (SLO)
+
+<ConfigureSLOOidc />
@@ -139,14 +139,6 @@ For example, if your IdP sends `groups` in a claim called `custom_roles`, enter
 | Custom Email Claim | `email` | The name of the claim in the OIDC token that contains the user's email address. |
 | Custom Groups Claim | `groups` | The name of the claim in the OIDC token that contains the user's group memberships (used for RBAC). |

-## OIDC Support for PKCE Extension
-
-<OIDCPKCESupport />
-
-## Configuring OIDC Single Logout (SLO)
-
-<ConfigureSLOOidc />
-
 ## Troubleshooting

 If you are experiencing issues while testing the connection to the OIDC server, first double-check the configuration options of your OIDC client. You can also inspect the Rancher logs to help pinpoint what's causing issues. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
@@ -164,3 +156,7 @@ If the `Issuer` and `Auth Endpoint` are generated incorrectly, open the **Config
 ### Error: "Invalid grant_type"

 In some cases, the "Invalid grant_type" error message may be misleading and is actually caused by setting the `Valid Redirect URI` incorrectly.
+
+## Configuring OIDC Single Logout (SLO)
+
+<ConfigureSLOOidc />
@@ -168,14 +168,6 @@ After configuration is completed, Rancher user permissions need to be reapplied

 :::

-## OIDC Support for PKCE Extension
-
-<OIDCPKCESupport />
-
-## Configuring OIDC Single Logout (SLO)
-
-<ConfigureSLOOidc />
-
 ## Annex: Troubleshooting

 If you are experiencing issues while testing the connection to the Keycloak server, first double-check the configuration options of your OIDC client. You may also inspect the Rancher logs to help pinpoint what's causing issues. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
@@ -211,3 +203,7 @@ To resolve this, you can either:
    3. Save your changes.
 
 2. Reconfigure your Keycloak OIDC setup using a user that is assigned to at least one group in Keycloak.
+
+## Configuring OIDC Single Logout (SLO)
+
+<ConfigureSLOOidc />
@@ -196,7 +196,3 @@ Try configuring and saving keycloak as your SAML provider and then accessing the
 ## Configuring SAML Single Logout (SLO)

 <ConfigureSLO />
-
-## SAML and OpenLDAP Group Permissions
-
-<SamlOpenLDAPGroupPermissions />
@@ -112,7 +112,3 @@ If you experience issues when you test the connection to the OpenLDAP server, en
 ## Configuring SAML Single Logout (SLO)

 <ConfigureSLO />
-
-## SAML and OpenLDAP Group Permissions
-
-<SamlOpenLDAPGroupPermissions />
@@ -68,7 +68,3 @@ Note that these URLs will not return valid data until the authentication configu
 ## Configuring SAML Single Logout (SLO)

 <ConfigureSLO />
-
-## SAML and OpenLDAP Group Permissions
-
-<SamlOpenLDAPGroupPermissions />
@@ -55,7 +55,3 @@ openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -da
 ## Configuring SAML Single Logout (SLO)

 <ConfigureSLO />
-
-## SAML and OpenLDAP Group Permissions
-
-<SamlOpenLDAPGroupPermissions />
@@ -10,14 +10,14 @@ Because Shibboleth is a SAML provider, it doesn't support searching for groups.

 One solution to this problem is to configure an OpenLDAP identity provider. With an OpenLDAP back end for Shibboleth, you will be able to search for groups in Rancher and assign them to resources such as clusters, projects, or namespaces from the Rancher UI.

-## Terminology
+### Terminology

 - **Shibboleth** is a single sign-on log-in system for computer networks and the Internet. It allows people to sign in using just one identity to various systems. It validates user credentials, but does not, on its own, handle group memberships.
 - **SAML:** Security Assertion Markup Language, an open standard for exchanging authentication and authorization data between an identity provider and a service provider.
 - **OpenLDAP:** a free, open-source implementation of the Lightweight Directory Access Protocol (LDAP). It is used to manage an organization’s computers and users. OpenLDAP is useful for Rancher users because it supports groups. In Rancher, it is possible to assign permissions to groups so that they can access resources such as clusters, projects, or namespaces, as long as the groups already exist in the identity provider.
 - **IdP or IDP:** An identity provider. OpenLDAP is an example of an identity provider.

-## Adding OpenLDAP Group Permissions to Rancher Resources
+### Adding OpenLDAP Group Permissions to Rancher Resources

 The diagram below illustrates how members of an OpenLDAP group can access resources in Rancher that the group has permissions for.

@@ -30,7 +30,3 @@ When a member of the OpenLDAP group logs in to Rancher, she is redirected to Shi
 Shibboleth validates her credentials, and retrieves user attributes from OpenLDAP, including groups. Then Shibboleth sends a SAML assertion to Rancher including the user attributes. Rancher uses the group data so that she can access all of the resources and permissions that her groups have permissions for.

 ![Adding OpenLDAP Group Permissions to Rancher Resources](/img/shibboleth-with-openldap-groups.svg)
-
-## SAML and OpenLDAP Group Permissions
-
-<SamlOpenLDAPGroupPermissions />
@@ -31,17 +31,11 @@ _Cluster roles_ are roles that you can assign to users, granting them access to

 - **Cluster Owner:**

-  These users have full control over the cluster and all resources in it.
+    These users have full control over the cluster and all resources in it.

 - **Cluster Member:**

-  These users can view most cluster level resources and create new projects.
-
-  :::warning
-  
-  When a Cluster Member creates a project, the user is automatically assigned [Project Owner privileges](#project-roles). This grants them comprehensive control over the project and its associated resources, including permissions to deploy workloads. Without enforced [Pod Security Standards (PSS) and Pod Security Admission (PSA)](../pod-security-standards.md), a Cluster Member is able to execute privileged containers in the cluster.
-  
-  :::
+    These users can view most cluster level resources and create new projects.

 #### Custom Cluster Roles

@@ -1,28 +1,14 @@
 ---
-title: Notifications
+title: Notification Center
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/notification-center"/>
 </head>

-The Rancher dashboard delivers dynamic notifications and system alerts to ensure that you stay informed about the latest updates, lifecycle events, and statuses relevant to your deployment.
-
-## Dynamic Content
-
-Rancher fetches dynamic content, including notifications about new releases, End of Maintenance (EOM) or End of Life (EOL) statuses, and other important announcements.
-
-Dynamic content is delivered to users through three areas in the Rancher dashboard. 
-
-* **Home page notification banner**: A dynamic banner displayed at the top of the home page for high-priority announcements.
-* **Home page section below the Links**: A dedicated area on the home page, located beneath the **Links** section, that displays relevant updates and resources.
-* **[Notification center](#what-is-the-notification-center)**: A centralized hub for all notifications, including system alerts, resources and announcements.
-
-To interact with these notifications, click **Learn More** on the listed resource. You can also dismiss the notification.
-
 ## What is the Notification Center?

-The notification center acts as a central repository for both system-generated alerts and dynamic announcements. You can access it by clicking the bell icon in the top right corner of the Rancher dashboard.
+The Notification Center, located in the upper-right corner of your Rancher dashboard and marked by a bell icon, is your central hub for staying informed about various events within Rancher.

 Notifications are categorized by severity and type:

@@ -17,7 +17,7 @@ The policies shipped by default in Rancher aim to provide a trade-off between se

 ## Assign a Pod Security Admissions (PSA) Configuration Template

-You can assign a PSA template at the same time that you create a downstream cluster. You can also add a template by configuring an existing downstream cluster.
+You can assign a PSA template at the same time that you create a downstream cluster. You can also add a template by configuring an existing cluster.

 ### Assign a Template During Cluster Creation
 <Tabs>
@@ -91,7 +91,6 @@ When you run Rancher on a Kubernetes cluster that enforces a restrictive securit
 - `calico-apiserver`
 - `calico-system`
 - `cattle-alerting`
- `cattle-capi-system`
 - `cattle-csp-adapter-system`
 - `cattle-elemental-system`
 - `cattle-epinio-system`
@@ -113,25 +112,22 @@ When you run Rancher on a Kubernetes cluster that enforces a restrictive securit
 - `cattle-resources-system`
 - `cattle-sriov-system`
 - `cattle-system`
- `cattle-turtles-system`
 - `cattle-ui-plugin-system`
 - `cattle-windows-gmsa-system`
 - `cert-manager`
 - `cis-operator-system`
- `compliance-operator-system`
 - `fleet-default`
 - `fleet-local`
+- `ingress-nginx`
 - `istio-system`
 - `kube-node-lease`
 - `kube-public`
 - `kube-system`
 - `longhorn-system`
 - `rancher-alerting-drivers`
- `rancher-compliance-system`
 - `security-scan`
 - `sr-operator-system`
 - `tigera-operator`
- `traefik`

 Rancher, some Rancher owned charts, and RKE2 and K3s distributions all use these namespaces. A subset of the listed namespaces are already exempt in the built-in Rancher `rancher-restricted` policy, for use in downstream clusters. For a complete template which has all the exemptions you need to run Rancher, please refer to this [sample Admission Configuration](../../../reference-guides/rancher-security/psa-restricted-exemptions.md).

@@ -234,7 +234,7 @@ docker stop <original-rancher-container>

 :::note

-If clusters do not automatically reconnect to the new environment after you have redirected traffic, for example if there is a delay in scaling down the original Rancher instance, you can also restart the cattle-cluster-agent pods on each cluster connected to your Rancher environment.
+If you wish to keep the original Rancher environment running, you can also restart the cattle-cluster-agent pods on each cluster connected to your Rancher environment.

 ```bash
 kubectl rollout restart deployment cattle-cluster-agent -n cattle-system
@@ -67,7 +67,6 @@ Before you create your own custom catalog, you should have a basic understanding


 ### Chart.yaml
-
 #### Annotations

 Rancher supports additional annotations that you can add to the `Chart.yaml` file. These annotations allow you to define application dependencies or configure additional UI defaults:
@@ -82,7 +81,7 @@ Rancher supports additional annotations that you can add to the `Chart.yaml` fil
 | catalog.cattle.io/requests-memory | Total amount of memory that should be unreserved in the cluster. If less memory is available, a warning will be shown | 2Gi |
 | catalog.cattle.io/os              | Restricts the OS where this chart can be installed. Possible values: `linux`, `windows`. Default: no restriction | linux |

-#### Keywords
+### Keywords

 With the `keywords` option in the `Chart.yaml` file it is possible to provide a list of categories for sorting your application in the Rancher UI, like `infrastructure`, `monitoring` and more.

@@ -8,12 +8,14 @@ title: Setting up Amazon ELB Network Load Balancer

 This how-to guide describes how to set up a Network Load Balancer (NLB) in Amazon's EC2 service that will direct traffic to multiple instances on EC2.

-These examples show the load balancer being configured to direct traffic to three Rancher server nodes. If Rancher is installed on a K3s Kubernetes cluster, only two nodes are required.
+These examples show the load balancer being configured to direct traffic to three Rancher server nodes. If Rancher is installed on an RKE Kubernetes cluster, three nodes are required. If Rancher is installed on a K3s Kubernetes cluster, only two nodes are required.

 This tutorial is about one possible way to set up your load balancer, not the only way. Other types of load balancers, such as a Classic Load Balancer or Application Load Balancer, could also direct traffic to the Rancher server nodes.

 Rancher only supports using the Amazon NLB when terminating traffic in `tcp` mode for port 443 rather than `tls` mode. This is due to the fact that the NLB does not inject the correct headers into requests when terminated at the NLB. This means that if you want to use certificates managed by the Amazon Certificate Manager (ACM), you should use an ALB.

+
+
 ## Requirements

 These instructions assume you have already created Linux instances in EC2. The load balancer will direct traffic to these nodes.
@@ -24,7 +26,7 @@ Begin by creating two target groups for the **TCP** protocol, one with TCP port

 Your first NLB configuration step is to create two target groups. Technically, only port 443 is needed to access Rancher, but it's convenient to add a listener for port 80, because traffic to port 80 will be automatically redirected to port 443.

-The Traefik Ingress should redirect traffic from port 80 to port 443.
+Regardless of whether an NGINX Ingress or Traefik Ingress controller is used, the Ingress should redirect traffic from port 80 to port 443.

 1. Log into the [Amazon AWS Console](https://console.aws.amazon.com/ec2/) to get started. Make sure to select the **Region** where your EC2 instances (Linux nodes) are created.
 1. Select **Services** and choose **EC2**, find the section **Load Balancing** and open **Target Groups**.
@@ -32,7 +34,7 @@ The Traefik Ingress should redirect traffic from port 80 to port 443.

 :::note

-For details on Traefik Ingress health checks, refer to [this section.](#health-check-paths-for-traefik-ingresses)
+Health checks are handled differently based on the Ingress. For details, refer to [this section.](#health-check-paths-for-nginx-ingress-and-traefik-ingresses)

 :::

@@ -165,10 +167,13 @@ After AWS creates the NLB, click **Close**.

 6. Click **Save** in the top right of the screen.

-## Health Check Paths for Traefik Ingresses
+## Health Check Paths for NGINX Ingress and Traefik Ingresses

-K3s Kubernetes clusters use Traefik as the default Ingress.
+K3s and RKE Kubernetes clusters handle health checks differently because they use different Ingresses by default.

-The health check path is `/ping`. By default `/ping` is always matched (regardless of Host), and a response from [Traefik itself](https://docs.traefik.io/operations/ping/) is always served.
+For RKE Kubernetes clusters, NGINX Ingress is used by default, whereas for K3s Kubernetes clusters, Traefik is the default Ingress.

-To simulate an accurate health check, it is a best practice to use the Host header (Rancher hostname) combined with `/ping` or `/healthz` wherever possible, to get a response from the Rancher Pods, not the Ingress.
+- **Traefik:** The health check path is `/ping`. By default `/ping` is always matched (regardless of Host), and a response from [Traefik itself](https://docs.traefik.io/operations/ping/) is always served.
+- **NGINX Ingress:** The default backend of the NGINX Ingress controller has a `/healthz` endpoint. By default `/healthz` is always matched (regardless of Host), and a response from [`ingress-nginx` itself](https://github.com/kubernetes/ingress-nginx/blob/0cbe783f43a9313c9c26136e888324b1ee91a72f/charts/ingress-nginx/values.yaml#L212) is always served.
+
+To simulate an accurate health check, it is a best practice to use the Host header (Rancher hostname) combined with `/ping` or `/healthz` (for K3s or for RKE clusters, respectively) wherever possible, to get a response from the Rancher Pods, not the Ingress.
@@ -91,7 +91,7 @@ To use this `kubeconfig` file,

 1. Install [kubectl,](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) a Kubernetes command-line tool.
 2. Copy the file at `/etc/rancher/rke2/rke2.yaml` and save it to the directory `~/.kube/config` on your local machine.
-3. In the kubeconfig file, the `server` directive is defined as localhost. Configure the server as the DNS of your control-plane load balancer, on port 6443. (The RKE2 Kubernetes API Server uses port 6443, while the Rancher server will be served via the Traefik Ingress on ports 80 and 443.) Here is an example `rke2.yaml`:
+3. In the kubeconfig file, the `server` directive is defined as localhost. Configure the server as the DNS of your control-plane load balancer, on port 6443. (The RKE2 Kubernetes API Server uses port 6443, while the Rancher server will be served via the NGINX Ingress on ports 80 and 443.) Here is an example `rke2.yaml`:

 ```yml
 apiVersion: v1
@@ -140,8 +140,7 @@ kube-system   etcd-rke2-server-2                                      1/1     Ru
 kube-system   etcd-rke2-server-3                                      1/1     Running     0          56s
 kube-system   helm-install-rke2-canal-hs6sx                           0/1     Completed   0          2m17s
 kube-system   helm-install-rke2-coredns-xmzm8                         0/1     Completed   0          2m17s
-kube-system   helm-install-traefik-crd-z8vsz                          0/1     Completed   0          2m17s
-kube-system   helm-install-traefik-flwnl                              0/1     Completed   0          2m17s
+kube-system   helm-install-rke2-ingress-nginx-flwnl                   0/1     Completed   0          2m17s
 kube-system   helm-install-rke2-metrics-server-7sggn                  0/1     Completed   0          2m17s
 kube-system   kube-apiserver-rke2-server-1                            1/1     Running     0          116s
 kube-system   kube-apiserver-rke2-server-2                            1/1     Running     0          66s
@@ -161,8 +160,9 @@ kube-system   rke2-canal-swfmq                                        2/2     Ru
 kube-system   rke2-coredns-rke2-coredns-547d5499cb-6tvwb              1/1     Running     0          92s
 kube-system   rke2-coredns-rke2-coredns-547d5499cb-rdttj              1/1     Running     0          2m8s
 kube-system   rke2-coredns-rke2-coredns-autoscaler-65c9bb465d-85sq5   1/1     Running     0          2m8s
-kube-system   traefik-7c844b766f-m9p2w                                1/1     Running     0          52s
-kube-system   traefik-7c844b766f-s4l9k                                1/1     Running     0          52s
+kube-system   rke2-ingress-nginx-controller-69qxc                     1/1     Running     0          52s
+kube-system   rke2-ingress-nginx-controller-7hprp                     1/1     Running     0          52s
+kube-system   rke2-ingress-nginx-controller-x658h                     1/1     Running     0          52s
 kube-system   rke2-metrics-server-6564db4569-vdfkn                    1/1     Running     0          66s
 ```

@@ -33,21 +33,27 @@ For more information, refer to the section on [hosted Kubernetes clusters.](set-

 ## Launching Kubernetes with Rancher

-Rancher uses [RKE2](https://docs.rke2.io/) or [K3s](https://docs.k3s.io/) as a library when provisioning Kubernetes on your own nodes. RKE2 is Rancher’s own lightweight Kubernetes installer.
+Rancher uses the [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) as a library when provisioning Kubernetes on your own nodes. RKE is Rancher’s own lightweight Kubernetes installer.

-In RKE2 clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform.
+In RKE clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform.

-If you already have a node that you want to add to an RKE2 cluster, you can add it to the cluster by running a Rancher RKE2 agent container on it.
+These nodes can be dynamically provisioned through Rancher's UI, which calls [Docker Machine](https://github.com/docker/docs/blob/vnext-engine/machine/overview.md) to launch nodes on various cloud providers.

-For more information, refer to [Launching Kubernetes with Rancher](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
+If you already have a node that you want to add to an RKE cluster, you can add it to the cluster by running a Rancher agent container on it.
+
+For more information, refer to the section on [RKE clusters.](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)

 ### Launching Kubernetes and Provisioning Nodes in an Infrastructure Provider

 Rancher can dynamically provision nodes in infrastructure providers such as Amazon EC2, DigitalOcean, Azure, or vSphere, then install Kubernetes on them.

+Using Rancher, you can create pools of nodes based on a [node template](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates). This template defines the parameters used to launch nodes in your cloud providers.
+
 One benefit of using nodes hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher can automatically replace it, thus maintaining the expected cluster configuration.

-For more information, refer to [Launching Kubernetes on New Nodes in an Infrastructure Provider](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)
+The cloud providers available for creating a node template are decided based on the [node drivers](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-drivers) active in the Rancher UI.
+
+For more information, refer to the section on [nodes hosted by an infrastructure provider](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)

 ### Launching Kubernetes on Existing Custom Nodes

@@ -65,10 +71,10 @@ 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, refer to [Registering Existing Clusters](register-existing-clusters.md).
+For more information, see [this page.](register-existing-clusters.md)

 ## Programmatically Creating Clusters

-The most common way to programmatically deploy Kubernetes clusters through Rancher is by using the Rancher2 Terraform provider. Refer to the documentation for [creating clusters with Terraform](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster).
+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, and AKS clusters can be created or imported with Terraform.
+EKS, GKE, AKS clusters and RKE clusters can be created or imported with Terraform.
@@ -47,7 +47,7 @@ SUSE Linux may have a firewall that blocks all ports by default. In that situati

 ### Flatcar Container Linux Nodes

-When [Launching Kubernetes with Rancher](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) using Flatcar Container Linux nodes, it is required to use the following configuration in the Cluster Config File.
+When [Launching Kubernetes with Rancher](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) using Flatcar Container Linux nodes, it is required to use the following configuration in the [Cluster Config File](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-cluster-config-file-reference)

 <Tabs>
 <TabItem value="Canal">
@@ -69,7 +69,7 @@ Specifically, the value should be a comma-delimited string which only contains I

 - Your cluster is registered and assigned a state of **Pending**. Rancher is deploying resources to manage your cluster.
 - You can access your cluster after its state is updated to **Active**.
- **Active** clusters are assigned two Projects: `Default` (containing the namespace `default`) and `System` (containing the namespaces `cattle-system`, `traefik`, `kube-public` and `kube-system`, if present).
+- **Active** clusters are assigned two Projects: `Default` (containing the namespace `default`) and `System` (containing the namespaces `cattle-system`, `ingress-nginx`, `kube-public` and `kube-system`, if present).


 :::note
@@ -63,7 +63,7 @@ You can access your cluster after its state is updated to **Active**.
 **Active** clusters are assigned two Projects:

 - `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `traefik`, `kube-public`, and `kube-system` namespaces
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces

 ## EKS Cluster Configuration Reference

@@ -307,41 +307,6 @@ The following are the required permissions for installing the Amazon EBS CSI Dri
 }
 ```

-### IPv6 Dual-Stack Networking Permissions
-
-The following are the additional permissions required for provisioning an **IPv6** EKS cluster from Rancher.
-
-> **Note:** These permissions are only necessary when Rancher is **creating** a new IPv6 cluster. During new cluster creation, Rancher needs these permissions to generate the dual-stack VPC, create the IAM OIDC provider, and assign an inline policy (`RancherManaged_AllowIPv6ForCNI`) to the Node Instance Role. 
-> 
-> If you are registering (importing) an existing EKS cluster that already has IPv6 configured, these additional permissions are **not required**.
-
-```json
-{
-  "Version": "2012-10-17",
-  "Statement": [
-    {
-      "Effect": "Allow",
-      "Action": [
-        "ec2:AssignIpv6Addresses",
-        "ec2:UnassignIpv6Addresses",
-        "ec2:AssignPrivateIpAddresses",
-        "ec2:UnassignPrivateIpAddresses",
-        "ec2:AssociateVpcCidrBlock",
-        "ec2:DisassociateVpcCidrBlock",
-        "iam:PutRolePolicy",
-        "iam:CreateOpenIDConnectProvider",
-        "iam:ListOpenIDConnectProviders",
-        "eks:AssociateIdentityProviderConfig",
-        "eks:DescribeIdentityProviderConfig",
-        "eks:ListIdentityProviderConfigs",
-        "sts:AssumeRoleWithWebIdentity"
-      ],
-      "Resource": "*"
-    }
-  ]
-}
-```
-
 ## Syncing

 The EKS provisioner can synchronize the state of an EKS cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md)
@@ -75,7 +75,7 @@ You can access your cluster after its state is updated to **Active**.
 **Active** clusters are assigned two Projects:

 - `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `traefik`, `kube-public`, and `kube-system` namespaces
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces

 ## Private Clusters

@@ -1,62 +0,0 @@
---
-title: Guide to Ingress NGINX Retirement
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/guide-to-ingress-nginx-retirement"/>
-</head>
-
-The Kubernetes SIG Network and the Security Response Committee announced the [retirement of the Ingress NGINX project](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/). Upstream best-effort maintenance, and all associated upstream releases, bug fixes, or security updates, ended March 2026.
-
-To support users during this transition, Rancher provides clear migration paths to Traefik. This guide centralizes the information on how to proceed based on your specific deployment scenario.
-
-## Support and timelines
-
-Rancher and RKE2 life cycles align with the upstream retirement schedule.
-
-:::warning
-After March 2026, upstream Ingress NGINX images no longer receive updates. Any images built with patches after this date are restricted to commercial customers. Users must migrate to Traefik or another supported Ingress controller before this deadline to ensure continued security and compatibility.
-:::
-
-## Migration paths by environment
-
-For organizations ready to move, there is a supported path to Traefik. Traefik includes a compatibility layer that can interpret many existing Ingress NGINX annotations. Identify your cluster environment below to find the correct migration approach.
-
-### Standalone RKE2 clusters
-
-For standalone or imported RKE2 clusters currently using Ingress NGINX, follow the official migration [guide for standalone RKE2 clusters](https://support.scc.suse.com/s/kb/Migrating-from-Ingress-NGINX-to-Traefik-in-a-standalone-RKE2-cluster?language=en_US).
-
-The migration process involves a four-phase strategy:
-
-1. **Dual ingress controller setup:** Enable Traefik alongside Ingress NGINX using temporary, non-conflicting ports.
-1. **Parallel migration and validation:** Duplicate Ingress resources and test Traefik's handling of the existing annotations.
-1. **Final switchover:** Remove Ingress NGINX and configure Traefik to use the standard ports.
-1. **Cleanup:** Delete the legacy Ingress objects.
-
-### Rancher server on RKE2 (local clusters)
-
-When migrating a Rancher local cluster, the Rancher Ingress resource requires specific handling to prevent lockouts. Follow the specific [guide for migrating the Rancher Ingress to Traefik in an RKE2 cluster](https://support.scc.suse.com/s/kb/How-to-migrate-the-Rancher-Ingress-to-Traefik-in-an-RKE2-cluster?language=en_US). This guide builds upon the standalone migration phases but includes steps tailored to the Rancher management server.
-
-### Downstream RKE2 clusters (provisioned by Rancher)
-
-For RKE2 clusters provisioned and managed by Rancher, migration options are integrated directly into the user interface.
-
-:::note
-This migration option is only possible in Rancher v2.14.0+.
-:::
-
-The cluster configuration interface provides a Dual Mode migration option. This allows you to safely test and migrate traffic from Ingress NGINX to Traefik directly from the cluster management page. For more information, refer to the documentation.
-
-### Rancher on managed Kubernetes (Amazon EKS, Azure AKS, Google GKE)
-
-If you run Rancher on a managed Kubernetes service such as [Amazon Elastic Kubernetes Service (EKS)](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md#5-install-an-ingress), [Azure Kubernetes Service (AKS)](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md#5-install-an-ingress), or [Google Kubernetes Engine (GKE)](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md#7-install-an-ingress), the recommendation is to migrate to Traefik.
-
-Users should deploy and migrate to the upstream Traefik proxy distribution.
-
-## Impact on other open source projects
-
-The retirement of Ingress NGINX impacts other related projects in the following ways:
-
- Longhorn: There is no impact on the Longhorn backend. However, administrators must reconfigure their Ingress to upgrade the Longhorn UI. For more information, refer to [Create an Ingress with Basic Authentication (Traefik)](https://longhorn.io/docs/1.11.1/deploy/accessing-the-ui/longhorn-ingress-traefik/).
- Fleet: Configuring a webhook service is affected. Refer to the [Fleet documentation](https://fleet.rancher.io/0.15/how-tos-for-users/webhook#_1_configure_the_webhook_service) for more information.
- Ingress NGINX references in documentation for other projects have been removed.
@@ -7,6 +7,14 @@ description: Configuring an Ingress
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/ingress-configuration"/>
 </head>

+:::note
+
+For Kubernetes v1.21 and up, the NGINX Ingress controller no longer runs in hostNetwork by default. It instead uses hostPorts for port 80 and port 443, so you can configure the admission webhook to be accessible only through the ClusterIP. This ensures that the webhook is only accessible from within the cluster.
+
+Because of this change to the controller, the default RKE1 behavior no longer sets `hostNetwork` to `true`. However, you must set `hostNetwork` to `true` for TCP- and UDP-based Services to work. To do so, [edit](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#editing-clusters-with-yaml) the cluster's YAML and follow the steps in the [official RKE1 documentation](https://rke.docs.rancher.com/config-options/add-ons/ingress-controllers#configuring-network-options).
+
+:::
+
 ## Specify a hostname to use

 If you use this option, Ingress routes requests for a hostname to the service or workload that you specify.
@@ -32,4 +40,6 @@ You must have an SSL certificate that Ingress can use to encrypt and decrypt com

 ## Labels and Annotations

-Please refer to the Traefik documentation for the full list of Ingress NGINX annotations that are [supported](https://doc.traefik.io/traefik/reference/routing-configuration/kubernetes/ingress-nginx/#annotations-support) and [unsupported](https://doc.traefik.io/traefik/reference/routing-configuration/kubernetes/ingress-nginx/#unsupported-annotations) by Traefik's kubernetesIngressNginx provider.
+Add [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) and/or [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to provide metadata for your Ingress controller.
+
+For a list of annotations available for use, see the [Nginx Ingress Controller Documentation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/).
@@ -11,11 +11,13 @@ Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer

 ## Layer-4 Load Balancer

-Layer-4 load balancer (or the external load balancer) forwards traffic to NodePorts. Layer-4 load balancer allows you to forward both HTTP and TCP traffic.
+Layer-4 load balancer (or the external load balancer) forwards traffic to Nodeports. Layer-4 load balancer allows you to forward both HTTP and TCP traffic.
+
+Often, the Layer-4 load balancer is supported by the underlying cloud provider, so when you deploy RKE clusters on bare-metal servers and vSphere clusters, Layer-4 load balancer is not supported. However, a single [globally managed config-map](https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/) can be used to expose services on NGINX or third-party ingress.

 :::note

-It is possible to deploy a cluster with a non-cloud load balancer, such as [MetalLB.](https://metallb.universe.tf/) However, that use case is more advanced than the Layer-4 load balancer supported by a cloud provider, and it is not configurable in Rancher.
+It is possible to deploy a cluster with a non-cloud load balancer, such as [MetalLB.](https://metallb.universe.tf/) However, that use case is more advanced than the Layer-4 load balancer supported by a cloud provider, and it is not configurable in Rancher or RKE.

 :::

@@ -28,11 +30,17 @@ Cluster Deployment                            | Layer-4 Load Balancer Support
 Amazon EKS                | Supported by AWS cloud provider
 Google GKE                   | Supported by GCE cloud provider
 Azure AKS                       | Supported by Azure cloud provider
-Third-party MetalLB | third-party Ingress*
+RKE on EC2                 | Supported by AWS cloud provider
+RKE on DigitalOcean         | Limited NGINX or third-party Ingress*
+RKE on vSphere           | Limited NGINX or third party-Ingress*
+RKE on Custom Hosts<br/>(e.g. bare-metal servers) | Limited NGINX or third-party Ingress*
+Third-party MetalLB | Limited NGINX or third-party Ingress*
+
+\* Services can be exposed through a single [globally managed config-map.](https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/)

 ## Layer-7 Load Balancer

-Layer-7 load balancer (or the ingress controller) supports host and path-based load balancing and SSL termination. Layer-7 load balancer only forwards HTTP and HTTPS traffic and therefore they listen on ports 80 and 443 only. Cloud providers such as Amazon and Google support layer-7 load balancer.
+Layer-7 load balancer (or the ingress controller) supports host and path-based load balancing and SSL termination. Layer-7 load balancer only forwards HTTP and HTTPS traffic and therefore they listen on ports 80 and 443 only. Cloud providers such as Amazon and Google support layer-7 load balancer. In addition, RKE clusters deploys the Nginx Ingress Controller.

 ### Support for Layer-7 Load Balancing

@@ -43,12 +51,16 @@ Cluster Deployment                            | Layer-7 Load Balancer Support
 Amazon EKS                                    | Supported by AWS cloud provider
 Google GKE                                    | Supported by GKE cloud provider
 Azure AKS                                     | Not Supported
+RKE on EC2                                    | Nginx Ingress Controller
+RKE on DigitalOcean                           | Nginx Ingress Controller
+RKE on vSphere                                | Nginx Ingress Controller
+RKE on Custom Hosts<br/>(e.g. bare-metal servers) | Nginx Ingress Controller

 ### Host Names in Layer-7 Load Balancer

 Some cloud-managed layer-7 load balancers (such as the ALB ingress controller on AWS) expose DNS addresses for ingress rules. You need to map (via CNAME) your domain name to the DNS address generated by the layer-7 load balancer.

-Other layer-7 load balancers, such as the Google Load Balancer, directly expose one or more IP addresses. Google Load Balancer provides a single routable IP address. You can do either of the following:
+Other layer-7 load balancers, such as the Google Load Balancer or Nginx Ingress Controller, directly expose one or more IP addresses. Google Load Balancer provides a single routable IP address. Nginx Ingress Controller exposes the external IP of all nodes that run the Nginx Ingress Controller. You can do either of the following:

 1.	Configure your own DNS to map (via A records) your domain name to the IP addresses exposes by the Layer-7 load balancer.
 2.	Ask Rancher to generate an xip.io host name for your ingress rule. Rancher will take one of your exposed IPs, say `a.b.c.d`, and generate a host name `<ingressname>.<namespace>.a.b.c.d.xip.io`.
@@ -42,16 +42,24 @@ As mentioned in the limitations above, the disadvantages of using a load balance
 - If you run multiple services in your cluster, you must have a load balancer for each service.
 - It can be expensive to have a load balancer for every service.

-In contrast, when an ingress is used as the entry point into a cluster, the ingress can route traffic to multiple services with greater flexibility. It can map multiple HTTP requests to services without individual IP addresses for each service.
+In contrast, when an ingress is used as the entrypoint into a cluster, the ingress can route traffic to multiple services with greater flexibility. It can map multiple HTTP requests to services without individual IP addresses for each service.

 Therefore, it is useful to have an ingress if you want multiple services to be exposed with the same IP address, the same Layer 7 protocol, or the same privileged node-ports: 80 and 443.

 Ingress works in conjunction with one or more ingress controllers to dynamically route service requests. When the ingress receives a request, the ingress controller(s) in your cluster direct the request to the correct service based on service subdomains or path rules that you've configured.

-Your ingress, which creates a port of entry to your cluster similar to a load balancer, can reside within your cluster or externally.
+Each Kubernetes Ingress resource corresponds roughly to a file in `/etc/nginx/sites-available/` containing a `server{}` configuration block, where requests for specific files and folders are configured.
+
+Your ingress, which creates a port of entry to your cluster similar to a load balancer, can reside within your cluster or externally. Ingress and ingress controllers residing in RKE-launched clusters are powered by [Nginx](https://www.nginx.com/).

 Ingress can provide other functionality as well, such as SSL termination, name-based virtual hosting, and more.

+:::note Using Rancher in a High Availability Configuration?
+
+Refrain from adding an Ingress to the `local` cluster. The Nginx Ingress Controller that Rancher uses acts as a global entry point for _all_ clusters managed by Rancher, including the `local` cluster.  Therefore, when users try to access an application, your Rancher connection may drop due to the Nginx configuration being reloaded. We recommend working around this issue by deploying applications only in clusters that you launch using Rancher.
+
+:::
+
 - For more information on how to set up ingress in Rancher, see [Ingress](add-ingresses.md).
 - For complete information about ingress and ingress controllers, see the [Kubernetes Ingress Documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/)
 - When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.
@@ -9,7 +9,7 @@ title: Rancher Agents
 There are two different agent resources deployed on Rancher managed clusters:

 - [cattle-cluster-agent](#cattle-cluster-agent)
- [rancher-system-agent](#rancher-system-agent)
+- [cattle-node-agent](#cattle-node-agent)

 For a conceptual overview of how the Rancher server provisions clusters and communicates with them, refer to the [architecture](../../../reference-guides/rancher-manager-architecture/rancher-manager-architecture.md).

@@ -17,9 +17,9 @@ For a conceptual overview of how the Rancher server provisions clusters and comm

 The `cattle-cluster-agent` is used to connect to the Kubernetes API of [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) clusters. The `cattle-cluster-agent` is deployed using a Deployment resource.

-### rancher-system-agent
+### cattle-node-agent

-The `rancher-system-agent` is a daemon used to manage nodes in a Rancher provisioned RKE2/K3s Kubernetes cluster when performing cluster lifecycle operations. Examples of cluster operations include upgrading the Kubernetes version and creating/restoring etcd snapshots. The `rancher-system-agent` is designed to apply plans to the Rancher system and can support both local and remote plans.
+The `cattle-node-agent` is used to interact with nodes in a [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) cluster when performing cluster operations. Examples of cluster operations are upgrading Kubernetes version and creating/restoring etcd snapshots. The `cattle-node-agent` is deployed using a DaemonSet resource to make sure it runs on every node. The `cattle-node-agent` is used as fallback option to connect to the Kubernetes API of [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) clusters when `cattle-cluster-agent` is unavailable.

 ### Requests

@@ -27,12 +27,39 @@ The `cattle-cluster-agent` pod does not define the default CPU and memory reques

 To configure request values through the UI:

+<Tabs groupId="k8s-distro">
+<TabItem value="RKE">
+
+1. When you [create](./launch-kubernetes-with-rancher.md) or edit an existing cluster, go to the **Cluster Options** section.
+1. Expand the **Cluster Configuration** subsection.
+1. Configure your request values using the **CPU Requests** and **Memory Requests** fields as needed.
+
+</TabItem>
+<TabItem value="RKE2/K3s">
+
 1. When you [create](./launch-kubernetes-with-rancher.md) or edit an existing cluster, go to the **Cluster Configuration**.
 1. Select the **Cluster Agent** subsection.
 1. Configure your request values using the **CPU Reservation** and **Memory Reservation** fields as needed.

+</TabItem>
+</Tabs>
+
 If you prefer to configure via YAML, add the following snippet to your configuration file:

+<Tabs groupId="k8s-distro">
+<TabItem value="RKE">
+
+```yaml
+cluster_agent_deployment_customization:
+  override_resource_requirements:
+    requests:
+      cpu: 50m
+      memory: 100Mi
+```
+
+</TabItem>
+<TabItem value="RKE2/K3s">
+
 ```yaml
 spec:
  clusterAgentDeploymentCustomization:
@@ -42,6 +69,9 @@ spec:
        memory: 100Mi 
 ```

+</TabItem>
+</Tabs>
+
 ### Scheduling rules

 The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`.
@@ -51,6 +81,7 @@ If control plane nodes are present in the cluster, the default tolerations will
 | Component              | nodeAffinity nodeSelectorTerms             | nodeSelector | Tolerations                                                                    |
 | ---------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
 | `cattle-cluster-agent` | `beta.kubernetes.io/os:NotIn:windows`      | none         | **Note:** These are the default tolerations, and will be replaced by tolerations matching taints applied to controlplane nodes.<br/><br/>`effect:NoSchedule`<br/>`key:node-role.kubernetes.io/controlplane`<br/>`value:true`<br/><br/>`effect:NoSchedule`<br/>`key:node-role.kubernetes.io/control-plane`<br/>`operator:Exists`<br/><br/>`effect:NoSchedule`<br/>`key:node-role.kubernetes.io/master`<br/>`operator:Exists` |
+| `cattle-node-agent`    | `beta.kubernetes.io/os:NotIn:windows`      | none         | `operator:Exists`                                                              |

 The `cattle-cluster-agent` Deployment has preferred scheduling rules using `preferredDuringSchedulingIgnoredDuringExecution`, favoring to be scheduled on nodes with the `controlplane` node. When there are no controlplane nodes visible in the cluster (this is usually the case when using [Clusters from Hosted Kubernetes Providers](../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md)), you can add the label `cattle.io/cluster-agent=true` on a node to prefer scheduling the `cattle-cluster-agent` pod to that node.

@@ -48,7 +48,7 @@ You can access your cluster after its state is updated to **Active**.
 **Active** clusters are assigned two Projects:

 - `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `traefik`, `kube-public`, and `kube-system` namespaces
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces

 ## Optional Next Steps

@@ -78,7 +78,7 @@ You can access your cluster after its state is updated to **Active**.
 **Active** clusters are assigned two Projects:

 - `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `traefik`, `kube-public`, and `kube-system` namespaces
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces

 ### GCE Best Practices

@@ -65,7 +65,7 @@ You can access your cluster after its state is updated to **Active**.
 **Active** clusters are assigned two Projects:

 - `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `traefik`, `kube-public`, and `kube-system` namespaces
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces

 ### Optional Next Steps

@@ -87,7 +87,7 @@ You can access your cluster after its state is updated to **Active**.
 **Active** clusters are assigned two Projects:

 - `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `traefik`, `kube-public`, and `kube-system` namespaces
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces


 ### Optional Next Steps
@@ -13,6 +13,9 @@ Rancher can provision nodes in AOS (AHV) and install Kubernetes on them. When cr

 A Nutanix cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role.

+- [Creating a Nutanix Cluster](provision-kubernetes-clusters-in-aos.md#creating-a-nutanix-aos-cluster)
+- [Provisioning Storage](provision-kubernetes-clusters-in-aos.md)
+
 ## Creating a Nutanix Cluster

-Refer to the [Provisioning Kubernetes Clusters in Nutanix AOS](provision-kubernetes-clusters-in-aos.md) to learn how to use Rancher to install an [RKE2](https://docs.rke2.io/)/[K3s](https://docs.k3s.io/) Kubernetes cluster in Nutanix AOS.
+In [this section,](provision-kubernetes-clusters-in-aos.md) you'll learn how to use Rancher to install an [RKE2](https://docs.rke2.io/)/[K3s](https://docs.k3s.io/) Kubernetes cluster in Nutanix AOS.
@@ -6,4 +6,91 @@ title: Provisioning Kubernetes Clusters in Nutanix AOS
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/nutanix/provision-kubernetes-clusters-in-aos"/>
 </head>

-To use Rancher to install an RKE2/K3s Kubernetes cluster in Nutanix AOS (AHV) refer to the [Nutanix documentation](https://portal.nutanix.com/page/documents/solutions/details?targetId=BP-2103-Rancher-SUSE-Nutanix:new-rke2-or-k3s-clusters-deployment.html).
+To use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in Nutanix AOS (AHV):
+
+1. Locate Rancher's built-in Nutanix [node driver and activate it](../../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#activatingdeactivating-node-drivers).
+
+1. Create a node template, which Rancher will use to provision nodes in Nutanix AOS.
+
+1. Create a Nutanix AOS cluster in Rancher. When configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
+
+For details on configuring the Nutanix AOS node template, refer to the [Nutanix AOS node template configuration reference.](../../../../../reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix.md)
+
+For details on configuring RKE Kubernetes clusters in Rancher, refer to the [cluster configuration reference.](../../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)
+
+- [Preparation in Nutanix AOS](#preparation-in-nutanix-aos)
+- [Creating a Nutanix AOS Cluster](#creating-a-nutanix-aos-cluster)
+
+## Preparation in Nutanix AOS
+
+The following sections describe the requirements for setting up Nutanix AOS so that Rancher can provision VMs and clusters.
+
+:::note
+
+The node templates are documented and tested with Nutanix AOS version 5.20.2 and 6.0.1.
+
+:::
+
+### Create Credentials in Nutanix AOS
+
+Before proceeding to create a cluster, you must ensure that you have a [Nutanix Prism Central user account](https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v6_0:wc-user-create-wc-t.html) with admin permissions. When you set up a node template, the template will need to use these credentials.
+
+### Network Permissions
+
+You must ensure that the hosts running the Rancher server are able to establish the following network connections:
+
+- To the Nutanix Prism Central API (usually port 9440/TCP).
+- To port 22/TCP and 2376/TCP on the created VMs
+
+See [Node Networking Requirements](../../../kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for a detailed list of port requirements applicable for creating nodes on an infrastructure provider.
+
+### VM-VM Anti-Affinity Policies
+
+Setting up [VM-VM Anti-Affinity Policies](https://portal.nutanix.com/page/documents/details?targetId=AHV-Admin-Guide-v6_1:ahv-vm-anti-affinity-t.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate AHV hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes.
+
+## Creating a Nutanix AOS Cluster
+
+1. [Create a node template ](#1-create-a-node-template)
+2. [Create a cluster with node pools using the node template](#2-create-a-cluster-with-node-pools-using-the-node-template)
+
+### 1. Create a node template
+
+Creating a [node template](../use-new-nodes-in-an-infra-provider.md#node-templates) for Nutanix AOS will allow Rancher to provision new nodes in Nutanix AOS. Node templates can be reused for other clusters.
+
+1. Click **☰ > Cluster Management**.
+1. Click **RKE1 Configuration > Node Templates**.
+1. Click **Create**.
+1. Click **Add Template**.
+1. Click **Nutanix**.
+1. Fill out a node template for Nutanix AOS. For help filling out the form, refer to the Nutanix AOS node template [configuration reference.](../../../../../reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix.md).
+1. Click **Create**.
+
+### 2. Create a cluster with node pools using the node template
+
+Use Rancher to create a Kubernetes cluster in Nutanix AOS.
+
+1. Click **☰ > Cluster Management**.
+1. On the **Clusters** page, click **Create**.
+1. Click **Nutanix**.
+1. Enter a **Cluster Name**, then click **Continue**.
+1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users who can access the cluster. Use the **Role** drop-down to set permissions for each user.
+1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used, and whether you want to enable project network isolation. To see more cluster options, click on **Show advanced options**. For help configuring the cluster, refer to the [RKE cluster configuration reference.](../../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)
+1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to the nodes, see [this section.](../use-new-nodes-in-an-infra-provider.md#node-pools)
+1. Review your options to confirm they're correct. Then click **Create**.
+
+**Result:** Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
+
+You can access your cluster after its state is updated to **Active**.
+
+**Active** clusters are assigned two Projects:
+
+- `Default`, containing the `default` namespace
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
+
+## Optional Next Steps
+
+After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
+
+- **Access your cluster with the kubectl CLI:** Follow [these steps](../../../../new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-from-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
+
+- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps](../../../../new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
@@ -6,10 +6,130 @@ title: Launching Kubernetes on New Nodes in an Infrastructure Provider
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider"/>
 </head>

-When you [create an RKE2 cluster](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md#cluster-config-file-reference) using a machine config in Rancher, each resulting node pool is shown in a new **Machine Pools** tab. You can see the machine pools by doing the following:
+When you create an RKE or RKE2 cluster using a node template in Rancher, each resulting node pool is shown in a new **Machine Pools** tab. You can see the machine pools by doing the following:
+
+1. Click  **☰ > Cluster Management**.
+1. Click the name of the RKE or RKE2 cluster.
+
+## RKE Clusters
+
+Using Rancher, you can create pools of nodes based on a [node template](#node-templates). This node template defines the parameters you want to use to launch nodes in your infrastructure providers or cloud providers.
+
+One benefit of installing Kubernetes on node pools hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher can automatically create another node to join the cluster to ensure that the count of the node pool is as expected.
+
+The available cloud providers to create a node template are decided based on active [node drivers](#node-drivers).
+
+### Node Templates
+
+A node template is the saved configuration for the parameters to use when provisioning nodes in a specific cloud provider. These nodes can be launched from the UI. Rancher uses [Docker Machine](https://github.com/docker/docs/blob/vnext-engine/machine/overview.md) to provision these nodes. The available cloud providers to create node templates are based on the active node drivers in Rancher.
+
+After you create a node template in Rancher, it's saved so that you can use this template again to create node pools. Node templates are bound to your login. After you add a template, you can remove them from your user profile.
+
+#### Node Labels
+
+You can add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) on each node template, so that any nodes created from the node template will automatically have these labels on them.
+
+Invalid labels can prevent upgrades or can prevent Rancher from starting. For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)
+
+#### Node Taints
+
+You can add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) on each node template, so that any nodes created from the node template will automatically have these taints on them.
+
+Since taints can be added at a node template and node pool, if there is no conflict with the same key and effect of the taints, all taints will be added to the nodes. If there are taints with the same key and different effect, the taints from the node pool will override the taints from the node template.
+
+#### Administrator Control of Node Templates
+
+Administrators can control all node templates. Admins can now maintain all the node templates within Rancher. When a node template owner is no longer using Rancher, the node templates created by them can be managed by administrators so the cluster can continue to be updated and maintained.
+
+To access all node templates, an administrator will need to do the following:

 1. Click **☰ > Cluster Management**.
-1. Click the name of the RKE2 cluster.
+1. Click **RKE1 Configuration > Node Templates**.
+
+**Result:** All node templates are listed. The templates can be edited or cloned by clicking the **⋮**.
+
+### Node Pools
+
+Using Rancher, you can create pools of nodes based on a [node template](#node-templates).
+
+A node template defines the configuration of a node, like what operating system to use, number of CPUs, and amount of memory.
+
+The benefit of using a node pool is that if a node is destroyed or deleted, you can increase the number of live nodes to compensate for the node that was lost. The node pool helps you ensure that the count of the node pool is as expected.
+
+Each node pool must have one or more nodes roles assigned.
+
+Each node role (i.e. etcd, controlplane, and worker) should be assigned to a distinct node pool. Although it is possible to assign multiple node roles to a node pool, this should not be done for production clusters.
+
+The recommended setup is to have:
+
+- a node pool with the etcd node role and a count of three
+- a node pool with the controlplane node role and a count of at least two
+- a node pool with the worker node role and a count of at least two
+
+**RKE1 downstream cluster nodes in an air-gapped environment:**
+
+By default, Rancher tries to run the Docker Install script when provisioning RKE1 downstream cluster nodes, such as in vSphere. However, the Rancher Docker installation script would fail in air-gapped environments. To work around this issue, you may choose to skip installing Docker when creating a Node Template where Docker is pre-installed onto a VM image. You can accomplish this by selecting **None** in the dropdown list for `Docker Install URL` under **Engine Options** in the Rancher UI.
+
+<figcaption>**Engine Options Dropdown:**</figcaption>
+
+![Engine Options Dropdown](/img/node-template-engine-options-rke1.png)
+
+#### Node Pool Taints
+
+If you haven't defined [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) on your node template, you can add taints for each node pool. The benefit of adding taints to a node pool is that you can change the node template without having to first ensure that the taint exists in the new template.
+
+For each taint, they will automatically be added to any created node in the node pool. Therefore, if you add taints to a node pool that have existing nodes, the taints won't apply to existing nodes in the node pool, but any new node added into the node pool will get the taint.
+
+When there are taints on the node pool and node template, if there is no conflict with the same key and effect of the taints, all taints will be added to the nodes. If there are taints with the same key and different effect, the taints from the node pool will override the taints from the node template.
+
+#### About Node Auto-replace
+
+If a node is in a node pool, Rancher can automatically replace unreachable nodes. Rancher will use the existing node template for the given node pool to recreate the node if it becomes inactive for a specified number of minutes.
+
+:::caution
+
+Self-healing node pools are designed to help you replace worker nodes for <b>stateless</b> applications. It is not recommended to enable node auto-replace on a node pool of master nodes or nodes with persistent volumes attached, because VMs are treated ephemerally. When a node in a node pool loses connectivity with the cluster, its persistent volumes are destroyed, resulting in data loss for stateful applications.
+
+:::
+
+Node auto-replace works on top of the Kubernetes node controller. The node controller periodically checks the status of all the nodes (configurable via the `--node-monitor-period` flag of the `kube-controller`). When a node is unreachable, the node controller will taint that node. When this occurs, Rancher will begin its deletion countdown. You can configure the amount of time Rancher waits to delete the node. If the taint is not removed before the deletion countdown ends, Rancher will proceed to delete the node object. Rancher will then provision a node in accordance with the set quantity of the node pool.
+
+#### Enabling Node Auto-replace
+
+When you create the node pool, you can specify the amount of time in minutes that Rancher will wait to replace an unresponsive node.
+
+1. In the form for creating or editing a cluster, go to the **Node Pools** section.
+1. Go to the node pool where you want to enable node auto-replace. In the **Recreate Unreachable After** field, enter the number of minutes that Rancher should wait for a node to respond before replacing the node.
+1. Fill out the rest of the form for creating or editing the cluster.
+
+**Result:** Node auto-replace is enabled for the node pool.
+
+#### Disabling Node Auto-replace
+
+You can disable node auto-replace from the Rancher UI with the following steps:
+
+1. Click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to disable node auto-replace and click **⋮ > Edit Config**.
+1. In the **Node Pools** section, go to the node pool where you want to enable node auto-replace. In the **Recreate Unreachable After** field, enter 0.
+1. Click **Save**.
+
+**Result:** Node auto-replace is disabled for the node pool.
+
+### Cloud Credentials
+
+Node templates can use cloud credentials to store credentials for launching nodes in your cloud provider, which has some benefits:
+
+- Credentials are stored as a Kubernetes secret, which is not only more secure, but it also allows you to edit a node template without having to enter your credentials every time.
+
+- After the cloud credential is created, it can be re-used to create additional node templates.
+
+- Multiple node templates can share the same cloud credential to create node pools. If your key is compromised or expired, the cloud credential can be updated in a single place, which allows all node templates that are using it to be updated at once.
+
+After cloud credentials are created, the user can start [managing the cloud credentials that they created](../../../../reference-guides/user-settings/manage-cloud-credentials.md).
+
+### Node Drivers
+
+If you don't find the node driver that you want to use, you can see if it is available in Rancher's built-in [node drivers and activate it](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#activatingdeactivating-node-drivers), or you can [add your own custom node driver](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#adding-custom-node-drivers).

 ## RKE2 Clusters

@@ -27,6 +147,8 @@ The RKE2 CLI exposes two roles, `server` and `agent`, which represent the Kubern

 The same functionality of using `etcd`, `controlplane` and `worker` nodes is possible in the RKE2 CLI by using flags and node tainting to control where workloads and the Kubernetes master were scheduled. The reason those roles were not implemented as first-class roles in the RKE2 CLI is that RKE2 is conceptualized as a set of raw building blocks that are best leveraged through an orchestration system such as Rancher.

+The implementation of the three node roles in Rancher means that Rancher managed RKE2 clusters are able to easily leverage all of the same architectural best practices that are recommended for RKE clusters.
+
 In our [recommended cluster architecture](../../kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md), we outline how many nodes of each role clusters should have:

 - At least three nodes with the role etcd to survive losing one node
@@ -86,7 +86,7 @@ You can access your cluster after its state is updated to **Active**.
 **Active** clusters are assigned two Projects:

 - `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `traefik`, `kube-public`, and `kube-system` namespaces
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces


 ## Optional Next Steps
@@ -25,6 +25,21 @@ After you download the kubeconfig file, you are able to use the kubeconfig file

 If admins have [kubeconfig token generation turned off](../../../../api/api-tokens.md#disable-tokens-in-generated-kubeconfigs), the kubeconfig file requires that the [Rancher CLI](../../../../reference-guides/cli-with-rancher/rancher-cli.md) to be present in your PATH.

+### Two Authentication Methods for RKE Clusters
+
+If the cluster is not an [RKE cluster,](../../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) the kubeconfig file allows you to access the cluster in only one way: it lets you be authenticated with the Rancher server, then Rancher allows you to run kubectl commands on the cluster.
+
+For RKE clusters, the kubeconfig file allows you to be authenticated in two ways:
+
+- **Through the Rancher server authentication proxy:** Rancher's authentication proxy validates your identity, then connects you to the downstream cluster that you want to access.
+- **Directly with the downstream cluster's API server:** RKE clusters have an authorized cluster endpoint enabled by default. This endpoint allows you to access your downstream Kubernetes cluster with the kubectl CLI and a kubeconfig file, and it is enabled by default for RKE clusters. In this scenario, the downstream cluster's Kubernetes API server authenticates you by calling a webhook (the `kube-api-auth` microservice) that Rancher set up.
+
+This second method, the capability to connect directly to the cluster's Kubernetes API server, is important because it lets you access your downstream cluster if you can't connect to Rancher.
+
+To use the authorized cluster endpoint, you need to configure kubectl to use the extra kubectl context in the kubeconfig file that Rancher generates for you when the RKE cluster is created. This file can be downloaded from the cluster view in the Rancher UI, and the instructions for configuring kubectl are on [this page.](use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster)
+
+These methods of communicating with downstream Kubernetes clusters are also explained in the [architecture page](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md) in the larger context of explaining how Rancher works and how Rancher communicates with downstream clusters.
+
 ### About the kube-api-auth Authentication Webhook

 The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint). When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.
@@ -92,7 +92,7 @@ Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).

 :::

-1. Open a web browser, navigate to [GitHub](https://github.com/rancher/rancher/blob/main/cleanup/user-cluster.sh), and download `user-cluster.sh`.
+1. Open a web browser, navigate to [GitHub](https://github.com/rancher/rancher/blob/master/cleanup/user-cluster.sh), and download `user-cluster.sh`.

 1. Make the script executable by running the following command from the same directory as `user-cluster.sh`:

@@ -65,8 +65,7 @@ In clusters that store data on GlusterFS volumes, you may experience an issue wh
 In [Rancher Launched Kubernetes clusters](../../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) that store data on iSCSI volumes, you may experience an issue where kubelets fail to automatically connect with iSCSI volumes. For details on resolving this issue, refer to [this page.](manage-persistent-storage/install-iscsi-volumes.md)

 ### hostPath Volumes
-
-Both K3s and RKE2 support mounting hostPath volumes using the [Rancher Local Path Provisioner](https://github.com/rancher/local-path-provisioner). For configuration information, depending on your distribution refer to [K3s - Volumes and Storage](https://docs.k3s.io/add-ons/storage#setting-up-the-local-storage-provider) or [RKE2 - Advanced Options and Configuration](https://docs.rke2.io/advanced#extra-control-plane-component-volume-mounts).
+Before you create a hostPath volume, you need to set up an [extra_bind](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/#extra-binds/) in your cluster configuration. This will mount the path as a volume in your kubelets, which can then be used for hostPath volumes in your workloads.

 ### Migrating VMware vSphere Cloud Provider from In-tree to Out-of-tree

--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Petr Kovar	76cb8bbd34	Merge branch 'main' into copilot/clarify-cluster-management-capabilities	2026-03-09 16:05:17 +01:00
Silvio Moioli	c332bc07b1	clarify turtles/capi managed clusters, use imported not registered Signed-off-by: Silvio Moioli <silvio@moioli.net>	2026-03-06 09:41:19 +01:00
copilot-swe-agent[bot]andmoio	aa7ca68533	Update cluster capabilities table: rename to Imported Clusters, reword footnotes, add Turtles/CAPI column Co-authored-by: moio <250541+moio@users.noreply.github.com>	2026-03-06 09:41:19 +01:00
copilot-swe-agent[bot]	dd49eee58b	Initial plan	2026-03-06 09:41:19 +01:00