Merge pull request #1524 from rancher/v2.9.3

Merge v2.9.3 release branch into main
Merge pull request #1523 from rancher/v2.8.9
2026-09-29 22:49:17 +00:00 · 2024-10-24 19:22:08 -07:00 · 2024-10-24 19:22:03 -07:00 · 2024-10-24 19:21:56 -07:00 · 2024-10-24 14:36:06 -07:00 · 2024-10-24 14:36:03 -07:00
1099 changed files with 5359 additions and 16707 deletions
@@ -0,0 +1,8 @@
+version: 2
+
+updates:
+  - package-ecosystem: gitsubmodule
+    schedule:
+        interval: "daily"
+    directory: /
+    
@@ -4,6 +4,8 @@ on:
  push:
    branches:
      - main
+    paths-ignore:
+      - '**/README.md'

 jobs:
  build:
@@ -2,8 +2,8 @@ name: Test deployment

 on:
  pull_request:
-    branches:
-      - main
+    paths-ignore:
+      - '**/README.md'

 jobs:
  test-deploy:
@@ -1,58 +0,0 @@
-# This action gets all changed markdown files in /docs and /versioned_docs using tj-actions/changed-files@v42
-# It compares new commits in the PR with the base commit (github.event.pull_request.base.sha)
-# It checks if no markdown files are changed 
-# It shows a count of markdown files and lists all changed markdown files
-# It uses Vale (https://vale.sh/docs/vale-cli/installation/) to provide feedback base off the SUSE Style Guide / OpenSUSE style rules (https://github.com/openSUSE/suse-vale-styleguide)
-
-name: Style check
-on: [pull_request]
-
-jobs:
-  vale-lint:
-    name: runner / vale
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        continue-on-error: true
-        with:
-          fetch-depth: 0  # OR "2" -> To retrieve the preceding commit.
-          submodules: true
-      - name: Get all changed markdown files
-        continue-on-error: true
-        id: changed-markdown-files
-        uses: tj-actions/changed-files@v42
-        with:
-            # Avoid using single or double quotes for multiline patterns
-            files: |
-               docs/**
-               versioned_docs/**
-            separator: ","
-            base_sha: ${{ github.event.pull_request.base.sha }}
-        env:
-            ALL_CHANGED_FILES: ${{ 0 }}
-      - name: No files changed?
-        continue-on-error: true
-        if: steps.changed-markdown-files.outputs.any_changed == 'false'
-        run: |
-              echo "No files changed"
-              echo "ALL_CHANGED_FILES=$ALL_CHANGED_FILES" >> $GITHUB_ENV
-      - name: List all changed files markdown files
-        continue-on-error: true
-        if: steps.changed-markdown-files.outputs.any_changed == 'true'
-        env:
-            ALL_CHANGED_FILES: ${{ steps.changed-markdown-files.outputs.all_changed_files }}
-            ALL_CHANGED_FILES_COUNT: ${{ steps.changed-markdown-files.outputs.all_changed_files_count }}
-            SHA: ${{ github.head_ref }}
-            HEAD: ${{ github.base_ref }}
-        run: |
-            echo "Total Files Changed:" ${ALL_CHANGED_FILES_COUNT}
-            echo ${ALL_CHANGED_FILES}
-            echo "ALL_CHANGED_FILES=$ALL_CHANGED_FILES" >> $GITHUB_ENV
-      - uses: errata-ai/vale-action@v2.1.0
-        continue-on-error: true
-        if: steps.changed-markdown-files.outputs.any_changed == 'true'
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        with:
-          separator: ", "
-          files: ${{ env.ALL_CHANGED_FILES }}
@@ -1,7 +1,7 @@
-StylesPath = .github/styles
+StylesPath = .github/styles/suse-vale-styleguide

 [formtats]
 mdx = md

 [*.md]
-BasedOnStyles = suse-vale-styleguide
+BasedOnStyles = common
@@ -15,9 +15,9 @@ To get started, [fork](https://github.com/rancher/rancher-docs/fork) and clone t

 Our repository doesn't allow you to make changes directly to the `main` branch. Create a working branch and make pull requests from your fork to [rancher/rancher-docs](https://github.com/rancher/rancher-docs).

-For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of December 2023, the most recently released version of Rancher is 2.8.
+For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of August 2024, the most recently released version of Rancher is 2.9.

-Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.8`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.
+Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.9`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.

 If a file is moved or renamed, you'll also need to edit the `sidebars.js` files for each affected version, as well as the list of redirects in `docusaurus.config.js`. See [Moving or Renaming Docs](./moving-or-renaming-docs.md).

@@ -1,5 +1,6 @@
 ---
 title: API Reference
+hide_table_of_contents: true
 ---

 <head>
@@ -6,7 +6,7 @@ title: Using API Tokens
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-tokens"/>
 </head>

-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), [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).
+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.

@@ -10,7 +10,7 @@ Rancher v2.8.0 introduced the Rancher Kubernetes API (RK-API). The previous v3 R

 ## How to Use the API

-The previous v3 API has its own user interface accessible from a [web browser](./v3-rancher-api-guide.md#enable-view-in-api). This is an easy way to see resources, perform actions, and see the equivalent `curl` or HTTP request & response. To access it:
+The previous v3 API has its own user interface accessible from a [web browser](#enable-view-in-api). This is an easy way to see resources, perform actions, and see the equivalent `curl` or HTTP request & response. To access it:

 <Tabs>
 <TabItem value="Rancher v2.6.4+">
@@ -6,18 +6,21 @@ title: Deprecated Features in Rancher
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
 </head>

-### What is Rancher's deprecation policy?
+## What is Rancher's deprecation policy?

 We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).

-### Where can I find out which features have been deprecated in Rancher?
+## Where can I find out which features have been deprecated in Rancher?

 Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:

 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 |
+| [2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) | Oct 24, 2024 |
+| [2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2) | Sep 19, 2024 |
+| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 |
+| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 |

-### What can I expect when a feature is marked for deprecation?
+## 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.
@@ -18,19 +18,19 @@ enable_cri_dockerd: true

 For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher even after the removal of in-tree Dockershim in Kubernetes 1.24.

-### FAQ
+## FAQ

 <br/>

-Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?
+Q: Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?

 The upstream support of Dockershim begins for RKE in Kubernetes 1.21. You will need to be on Rancher 2.6 or above to have support for RKE with Kubernetes 1.21. See our [support matrix](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/) for details.

 <br/>

-Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?
+Q: I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?

-A. The version of Dockershim in RKE with Kubernetes 1.20 will continue to work and is not scheduled for removal upstream until Kubernetes 1.24. It will only emit a warning of its future deprecation, which Rancher has mitigated in RKE with Kubernetes 1.21. You can plan your upgrade to Kubernetes 1.21 as you would normally, but should consider enabling the external Dockershim by Kubernetes 1.22. The external Dockershim will need to be enabled before upgrading to Kubernetes 1.24, at which point the existing implementation will be removed.
+A: The version of Dockershim in RKE with Kubernetes 1.20 will continue to work and is not scheduled for removal upstream until Kubernetes 1.24. It will only emit a warning of its future deprecation, which Rancher has mitigated in RKE with Kubernetes 1.21. You can plan your upgrade to Kubernetes 1.21 as you would normally, but should consider enabling the external Dockershim by Kubernetes 1.22. The external Dockershim will need to be enabled before upgrading to Kubernetes 1.24, at which point the existing implementation will be removed.

 For more information on the deprecation and its timeline, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).

@@ -8,11 +8,11 @@ title: Installing and Configuring kubectl

 `kubectl` is a CLI utility for running commands against Kubernetes clusters. It's required for many maintenance and administrative tasks in Rancher 2.x.

-### Installation
+## Installation

 See [kubectl Installation](https://kubernetes.io/docs/tasks/tools/install-kubectl/) for installation on your operating system.

-### Configuration
+## Configuration

 When you create a Kubernetes cluster with RKE, RKE creates a `kube_config_cluster.yml` in the local directory that contains credentials to connect to your new cluster with tools like `kubectl` or `helm`.

@@ -9,11 +9,11 @@ title: Rancher is No Longer Needed
 This page is intended to answer questions about what happens if you don't want Rancher anymore, if you don't want a cluster to be managed by Rancher anymore, or if the Rancher server is deleted.


-### If the Rancher server is deleted, what happens to the workloads in my downstream clusters?
+## If the Rancher server is deleted, what happens to the workloads in my downstream clusters?

 If Rancher is ever deleted or unrecoverable, all workloads in the downstream Kubernetes clusters managed by Rancher will continue to function as normal.

-### If the Rancher server is deleted, how do I access my downstream clusters?
+## If the Rancher server is deleted, how do I access my downstream clusters?

 The capability to access a downstream cluster without Rancher depends on the type of cluster and the way that the cluster was created. To summarize:

@@ -21,7 +21,7 @@ The capability to access a downstream cluster without Rancher depends on the typ
 - **Hosted Kubernetes clusters:** If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider's cloud credentials.
 - **RKE clusters:** To access an [RKE cluster,](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.

-### What if I don't want Rancher anymore?
+## What if I don't want Rancher anymore?

 :::note

@@ -44,7 +44,7 @@ If you installed Rancher with Docker, you can uninstall Rancher by removing the

 Imported clusters will not be affected by Rancher being removed. For other types of clusters, refer to the section on [accessing downstream clusters when Rancher is removed.](#if-the-rancher-server-is-deleted-how-do-i-access-my-downstream-clusters)

-### What if I don't want my registered cluster managed by Rancher?
+## What if I don't want my registered cluster managed by Rancher?

 If a registered cluster is deleted from the Rancher UI, the cluster is detached from Rancher, leaving it intact and accessible by the same methods that were used to access it before it was registered in Rancher.

@@ -56,7 +56,7 @@ To detach the cluster,

 **Result:** The registered cluster is detached from Rancher and functions normally outside of Rancher.

-### What if I don't want my RKE cluster or hosted Kubernetes cluster managed by Rancher?
+## What if I don't want my RKE cluster or hosted Kubernetes cluster managed by Rancher?

 At this time, there is no functionality to detach these clusters from Rancher. In this context, "detach" is defined as the ability to remove Rancher components from the cluster and manage access to the cluster independently of Rancher.

@@ -1,21 +1,20 @@
 ---
 title: Security FAQ
-
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/security"/>
 </head>

-### Is there a Hardening Guide?
+## Is there a Hardening Guide?

 The Hardening Guide is located in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.

-### Have hardened Rancher Kubernetes clusters been evaluated by the CIS Kubernetes Benchmark? Where can I find the results?
+## Have hardened Rancher Kubernetes clusters been evaluated by the CIS Kubernetes Benchmark? Where can I find the results?

 We have run the CIS Kubernetes benchmark against a hardened Rancher Kubernetes cluster.  The results of that assessment can be found in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.

-### How does Rancher verify communication with downstream clusters, and what are some associated security concerns?
+## How does Rancher verify communication with downstream clusters, and what are some associated security concerns?

 Communication between the Rancher server and downstream clusters is performed through agents. Rancher uses either a registered certificate authority (CA) bundle or the local trust store to verify communication between Rancher agents and the Rancher server. Using a CA bundle for verification is more strict, as only the certificates based on that bundle are trusted. If TLS verification for a explicit CA bundle fails, Rancher may fall back to using the local trust store for verifying future communication. Any CA within the local trust store can then be used to generate a valid certificate.

@@ -6,9 +6,10 @@ title: Technical FAQ
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/technical-items"/>
 </head>

-### How can I reset the administrator password?
+## How can I reset the administrator password?
+
+Docker install:

-Docker Install:
 ```
 $ docker exec -ti <container_id> reset-password
 New password for default administrator (user-xxxxx):
@@ -16,6 +17,7 @@ New password for default administrator (user-xxxxx):
 ```

 Kubernetes install (Helm):
+
 ```
 $ KUBECONFIG=./kube_config_cluster.yml
 $ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher --no-headers | head -1 | awk '{ print $1 }') -c rancher -- reset-password
@@ -23,10 +25,10 @@ New password for default administrator (user-xxxxx):
 <new_password>
 ```

+## I deleted/deactivated the last admin, how can I fix it?

+Docker install:

-### I deleted/deactivated the last admin, how can I fix it?
-Docker Install:
 ```
 $ docker exec -ti <container_id> ensure-default-admin
 New default administrator (user-xxxxx)
@@ -35,38 +37,40 @@ New password for default administrator (user-xxxxx):
 ```

 Kubernetes install (Helm):
+
 ```
 $ KUBECONFIG=./kube_config_cluster.yml
 $ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin
 New password for default administrator (user-xxxxx):
 <new_password>
 ```
-### How can I enable debug logging?
+
+## How can I enable debug logging?

 See [Troubleshooting: Logging](../troubleshooting/other-troubleshooting-tips/logging.md)

-### My ClusterIP does not respond to ping
+## My ClusterIP does not respond to ping

 ClusterIP is a virtual IP, which will not respond to ping. Best way to test if the ClusterIP is configured correctly, is by using `curl` to access the IP and port to see if it responds.

-### Where can I manage Node Templates?
+## Where can I manage Node Templates?

 Node Templates can be accessed by opening your account menu (top right) and selecting `Node Templates`.

-### Why is my Layer-4 Load Balancer in `Pending` state?
+## Why is my Layer-4 Load Balancer in `Pending` state?

 The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, this needs a cloud provider or controller that can satisfy these requests, otherwise these will be in `Pending` state forever. More information can be found on [Cloud Providers](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md) or [Create External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)

-### Where is the state of Rancher stored?
+## Where is the state of Rancher stored?

 - Docker Install: in the embedded etcd of the `rancher/rancher` container, located at `/var/lib/rancher`.
 - Kubernetes install: in the etcd of the RKE cluster created to run Rancher.

-### How are the supported Docker versions determined?
+## How are the supported Docker versions determined?

 We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.

-### How can I access nodes created by Rancher?
+## How can I access nodes created by Rancher?

 SSH keys to access the nodes created by Rancher can be downloaded via the **Nodes** view. Choose the node which you want to access and click on the vertical ⋮ button at the end of the row, and choose **Download Keys** as shown in the picture below.

@@ -78,14 +82,14 @@ Unzip the downloaded zip file, and use the file `id_rsa` to connect to you host.
 $ ssh -i id_rsa user@ip_of_node
 ```

-### How can I automate task X in Rancher?
+## How can I automate task X in Rancher?

 The UI consists of static files, and works based on responses of the API. That means every action/task that you can execute in the UI, can be automated via the API. There are 2 ways to do this:

 * Visit `https://your_rancher_ip/v3` and browse the API options.
 * Capture the API calls when using the UI (Most commonly used for this is [Chrome Developer Tools](https://developers.google.com/web/tools/chrome-devtools/#network) but you can use anything you like)

-### The IP address of a node changed, how can I recover?
+## The IP address of a node changed, how can I recover?

 A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and readd it. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.

@@ -93,11 +97,11 @@ When the IP address of the node changed, Rancher lost connection to the node, so

 When the node is removed from the cluster, and the node is cleaned, you can readd the node to the cluster.

-### How can I add more arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
+## How can I add more arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?

 You can add more arguments/binds/environment variables via the [Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-cluster-config-file-reference) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls](https://rancher.com/docs/rke/latest/en/example-yamls/).

-### How do I check if my certificate chain is valid?
+## How do I check if my certificate chain is valid?

 Use the `openssl verify` command to validate your certificate chain:

@@ -138,7 +142,7 @@ subject= /C=GB/ST=England/O=Alice Ltd/CN=rancher.yourdomain.com
 issuer= /C=GB/ST=England/O=Alice Ltd/CN=Alice Intermediate CA
 ```

-### How do I check `Common Name` and `Subject Alternative Names` in my server certificate?
+## How do I check `Common Name` and `Subject Alternative Names` in my server certificate?

 Although technically an entry in `Subject Alternative Names` is required, having the hostname in both `Common Name` and as entry in `Subject Alternative Names` gives you maximum compatibility with older browser/applications.

@@ -156,7 +160,7 @@ openssl x509 -noout -in cert.pem -text | grep DNS
                DNS:rancher.my.org
 ```

-### Why does it take 5+ minutes for a pod to be rescheduled when a node has failed?
+## Why does it take 5+ minutes for a pod to be rescheduled when a node has failed?

 This is due to a combination of the following default Kubernetes settings:

@@ -175,6 +179,6 @@ In Kubernetes v1.13, the `TaintBasedEvictions` feature is enabled by default. Se
  * `default-not-ready-toleration-seconds`: Indicates the tolerationSeconds of the toleration for notReady:NoExecute that is added by default to every pod that does not already have such a toleration.
  * `default-unreachable-toleration-seconds`: Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration.

-### Can I use keyboard shortcuts in the UI?
+## Can I use keyboard shortcuts in the UI?

 Yes, most parts of the UI can be reached using keyboard shortcuts. For an overview of the available shortcuts, press `?` anywhere in the UI.
@@ -6,11 +6,11 @@ title: Telemetry FAQ
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/telemetry"/>
 </head>

-### What is Telemetry?
+## What is Telemetry?

 Telemetry collects aggregate information about the size of Rancher installations, versions of components used, and which features are used.  This information is used by Rancher Labs to help make the product better and is not shared with third-parties.

-### What information is collected?
+## What information is collected?

 No specific identifying information like usernames, passwords, or the names or addresses of user resources will ever be collected.

@@ -24,12 +24,12 @@ The primary things collected include:
  - The image name & version of Rancher that is running.
  - A unique randomly-generated identifier for this installation.

-### Can I see the information that is being sent?
+## Can I see the information that is being sent?

 If Telemetry is enabled, you can go to `https://<your rancher server>/v1-telemetry` in your installation to see the current data.

 If Telemetry is not enabled, the process that collects the data is not running, so there is nothing being collected to look at.

-### How do I turn it on or off?
+## How do I turn it on or off?

 After initial setup, an administrator can go to the `Settings` page in the `Global` section of the UI and click Edit to change the `telemetry-opt` setting to either `in` or `out`.
@@ -12,7 +12,7 @@ These instructions assume you have already followed the instructions for a Kuber

 :::

-### Rancher Helm Upgrade Options
+## Rancher Helm Upgrade Options

 To upgrade with Helm, apply the same options that you used when installing Rancher. Refer to the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.

@@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases
 :::

 ```
-# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
+# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
 kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml

 # Add the Jetstack Helm repository
@@ -161,7 +161,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --set installCRDs=true
+  --set crds.enabled=true
 ```

 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -49,7 +49,7 @@ See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanu
 ### Step 2: Restore the Backup and Bring Up Rancher

 At this point, there should be no Rancher-related resources on the upstream cluster. Therefore, the next step will be the same as if you were migrating Rancher to a new cluster that contains no Rancher resources.
-/home/btat/rancher-docs/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md
+
 Follow these [instructions](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) to install the Rancher-Backup Helm chart and restore Rancher to its previous state.
 Please keep in mind that:
 1. Step 3 can be skipped, because the Cert-Manager app should still exist on the upstream (local) cluster if it was installed before.
@@ -49,7 +49,6 @@ For [air-gapped installs only,](../other-installation-methods/air-gapped-helm-cl

 Follow the steps to upgrade Rancher server:

-
 ### 1. Back up Your Kubernetes Cluster that is Running Rancher Server

 Use the [backup application](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) to back up Rancher.
@@ -119,7 +118,6 @@ If you are installing Rancher in an air-gapped environment, skip the rest of thi

 :::

-
 Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.

 ```
@@ -22,7 +22,7 @@ Starting with version 1.24, the above defaults to true.

 For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher going forward.

-### FAQ
+## FAQ

 <br/>

@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D

 Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?

-A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
+A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).

 <br/>
@@ -28,7 +28,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher

 Choose from the following options:

-### Option A: Default Self-Signed Certificate
+## Option A: Default Self-Signed Certificate

 <details id="option-a">
  <summary>Click to expand</summary>
@@ -55,7 +55,7 @@ docker run -d --restart=unless-stopped \

 </details>

-### Option B: Bring Your Own Certificate: Self-Signed
+## Option B: Bring Your Own Certificate: Self-Signed

 <details id="option-b">
  <summary>Click to expand</summary>
@@ -98,7 +98,7 @@ docker run -d --restart=unless-stopped \

 </details>

-### Option C: Bring Your Own Certificate: Signed by Recognized CA
+## Option C: Bring Your Own Certificate: Signed by Recognized CA

 <details id="option-c">
  <summary>Click to expand</summary>
@@ -143,8 +143,6 @@ docker run -d --restart=unless-stopped \

 </details>

-
-
 :::note

 If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login.
@@ -25,7 +25,7 @@ We recommend setting up the following infrastructure for a high-availability ins
 - **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
 - **A private image registry** to distribute container images to your machines.

-### 1. Set up Linux Nodes
+## 1. Set up Linux Nodes

 These hosts will be disconnected from the internet, but require being able to connect with your private registry.

@@ -33,7 +33,7 @@ Make sure that your nodes fulfill the general installation requirements for [OS,

 For an example of one way to set up Linux nodes, refer to this [tutorial](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md) for setting up nodes as instances in Amazon EC2.

-### 2. Set up External Datastore
+## 2. Set up External Datastore

 The ability to run Kubernetes using a datastore other than etcd sets K3s apart from other Kubernetes distributions. This feature provides flexibility to Kubernetes operators. The available options allow you to select a datastore that best fits your use case.

@@ -49,7 +49,7 @@ For an example of one way to set up the database, refer to this [tutorial](../..

 For the complete list of options that are available for configuring a K3s cluster datastore, refer to the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/datastore/)

-### 3. Set up the Load Balancer
+## 3. Set up the Load Balancer

 You will also need to set up a load balancer to direct traffic to the Rancher replica on both nodes. That will prevent an outage of any single node from taking down communications to the Rancher management server.

@@ -72,7 +72,7 @@ Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance

 :::

-### 4. Set up the DNS Record
+## 4. Set up the DNS Record

 Once you have set up your load balancer, you will need to create a DNS record to send traffic to this load balancer.

@@ -82,7 +82,7 @@ You will need to specify this hostname in a later step when you install Rancher,

 For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)

-### 5. Set up a Private Image Registry
+## 5. Set up a Private Image Registry

 Rancher supports air gap installs using a private registry. You must have your own private registry or other means of distributing container images to your machines.

@@ -106,13 +106,13 @@ To install the Rancher management server on a high-availability RKE cluster, we

 These nodes must be in the same region/data center. You may place these servers in separate availability zones.

-### Why three nodes?
+## Why Three Nodes?

 In an RKE cluster, Rancher server data is stored on etcd. This etcd database runs on all three nodes.

 The etcd database requires an odd number of nodes so that it can always elect a leader with a majority of the etcd cluster. If the etcd database cannot elect a leader, etcd can suffer from [split brain](https://www.quora.com/What-is-split-brain-in-distributed-systems), requiring the cluster to be restored from backup. If one of the three etcd nodes fails, the two remaining nodes can elect a leader because they have the majority of the total number of etcd nodes.

-### 1. Set up Linux Nodes
+## 1. Set up Linux Nodes

 These hosts will be disconnected from the internet, but require being able to connect with your private registry.

@@ -120,7 +120,7 @@ Make sure that your nodes fulfill the general installation requirements for [OS,

 For an example of one way to set up Linux nodes, refer to this [tutorial](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md) for setting up nodes as instances in Amazon EC2.

-### 2. Set up the Load Balancer
+## 2. Set up the Load Balancer

 You will also need to set up a load balancer to direct traffic to the Rancher replica on both nodes. That will prevent an outage of any single node from taking down communications to the Rancher management server.

@@ -143,7 +143,7 @@ Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance

 :::

-### 3. Set up the DNS Record
+## 3. Set up the DNS Record

 Once you have set up your load balancer, you will need to create a DNS record to send traffic to this load balancer.

@@ -153,7 +153,7 @@ You will need to specify this hostname in a later step when you install Rancher,

 For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)

-### 4. Set up a Private Image Registry
+## 4. Set up a Private Image Registry

 Rancher supports air gap installs using a secure private registry. You must have your own private registry or other means of distributing container images to your machines.

@@ -176,7 +176,7 @@ If you need to create a private registry, refer to the documentation pages for y

 :::

-### 1. Set up a Linux Node
+## 1. Set up a Linux Node

 This host will be disconnected from the Internet, but needs to be able to connect to your private registry.

@@ -184,7 +184,7 @@ Make sure that your node fulfills the general installation requirements for [OS,

 For an example of one way to set up Linux nodes, refer to this [tutorial](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md) for setting up nodes as instances in Amazon EC2.

-### 2. Set up a Private Docker Registry
+## 2. Set up a Private Docker Registry

 Rancher supports air gap installs using a private registry on your bastion server. You must have your own private registry or other means of distributing container images to your machines.

@@ -193,4 +193,4 @@ If you need help with creating a private registry, please refer to the [official
 </TabItem>
 </Tabs>

-### [Next: Collect and Publish Images to your Private Registry](publish-images.md)
+## [Next: Collect and Publish Images to your Private Registry](publish-images.md)
@@ -23,14 +23,15 @@ The steps to set up an air-gapped Kubernetes cluster on RKE, RKE2, or K3s are sh

 In this guide, we are assuming you have created your nodes in your air gapped environment and have a secure Docker private registry on your bastion server.

-### Installation Outline
+## Installation Outline

 1. [Prepare Images Directory](#1-prepare-images-directory)
 2. [Create Registry YAML](#2-create-registry-yaml)
 3. [Install K3s](#3-install-k3s)
 4. [Save and Start Using the kubeconfig File](#4-save-and-start-using-the-kubeconfig-file)

-### 1. Prepare Images Directory
+## 1. Prepare Images Directory
+
 Obtain the images tar file for your architecture from the [releases](https://github.com/k3s-io/k3s/releases) page for the version of K3s you will be running.

 Place the tar file in the `images` directory before starting K3s on each node, for example:
@@ -40,7 +41,8 @@ sudo mkdir -p /var/lib/rancher/k3s/agent/images/
 sudo cp ./k3s-airgap-images-$ARCH.tar /var/lib/rancher/k3s/agent/images/
 ```

-### 2. Create Registry YAML
+## 2. Create Registry YAML
+
 Create the registries.yaml file at `/etc/rancher/k3s/registries.yaml`. This will tell K3s the necessary details to connect to your private registry.

 The registries.yaml file should look like this before plugging in the necessary information:
@@ -66,7 +68,7 @@ Note, at this time only secure registries are supported with K3s (SSL with custo

 For more information on private registries configuration file for K3s, refer to the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/private-registry/)

-### 3. Install K3s
+## 3. Install K3s

 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 [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).

@@ -98,7 +100,7 @@ K3s additionally provides a `--resolv-conf` flag for kubelets, which may help wi

 :::

-### 4. Save and Start Using the kubeconfig File
+## 4. Save and Start Using the kubeconfig File

 When you installed K3s on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/k3s/k3s.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.

@@ -138,7 +140,7 @@ kubectl --kubeconfig ~/.kube/config/k3s.yaml get pods --all-namespaces

 For more information about the `kubeconfig` file, refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/cluster-access/) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.

-### Note on Upgrading
+## Note on Upgrading

 Upgrading an air-gap environment can be accomplished in the following manner:

@@ -151,14 +153,15 @@ Upgrading an air-gap environment can be accomplished in the following manner:

 In this guide, we are assuming you have created your nodes in your air-gapped environment and have a secure Docker private registry on your bastion server.

-### Installation Outline
+## Installation Outline

 1. [Create RKE2 configuration](#1-create-rke2-configuration)
 2. [Create Registry YAML](#2-create-registry-yaml)
 3. [Install RKE2](#3-install-rke2)
 4. [Save and Start Using the kubeconfig File](#4-save-and-start-using-the-kubeconfig-file)

-### 1. Create RKE2 configuration
+## 1. Create RKE2 configuration
+
 Create the config.yaml file at `/etc/rancher/rke2/config.yaml`. This will contain all the configuration options necessary to create a highly available RKE2 cluster.

 On the first server the minimum config is:
@@ -186,7 +189,8 @@ RKE2 additionally provides a `resolv-conf` option for kubelets, which may help w

 :::

-### 2. Create Registry YAML
+## 2. Create Registry YAML
+
 Create the registries.yaml file at `/etc/rancher/rke2/registries.yaml`. This will tell RKE2 the necessary details to connect to your private registry.

 The registries.yaml file should look like this before plugging in the necessary information:
@@ -210,7 +214,7 @@ configs:

 For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)

-### 3. Install RKE2
+## 3. Install RKE2

 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/)

@@ -239,7 +243,7 @@ systemctl start rke2-server.service

 For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/airgap).

-### 4. Save and Start Using the kubeconfig File
+## 4. 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.

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

-### Note on Upgrading
+## Note on Upgrading

 Upgrading an air-gap environment can be accomplished in the following manner:

@@ -291,7 +295,7 @@ Upgrading an air-gap environment can be accomplished in the following manner:
 <TabItem value="RKE">
 We will create a Kubernetes cluster using Rancher Kubernetes Engine (RKE). Before being able to start your Kubernetes cluster, you’ll need to install RKE and create a RKE config file.

-### 1. Install RKE
+## 1. Install RKE

 Install RKE by following the instructions in the [RKE documentation.](https://rancher.com/docs/rke/latest/en/installation/)

@@ -301,7 +305,7 @@ Certified version(s) of RKE based on the Rancher version can be found in the [Ra

 :::

-### 2. Create an RKE Config File
+## 2. Create an RKE Config File

 From a system that can access ports 22/TCP and 6443/TCP on the Linux host node(s) that you set up in a previous step, use the sample below to create a new file named `rancher-cluster.yml`.

@@ -352,7 +356,7 @@ private_registries:
    is_default: true
 ```

-### 3. Run RKE
+## 3. Run RKE

 After configuring `rancher-cluster.yml`, bring up your Kubernetes cluster:

@@ -360,7 +364,7 @@ After configuring `rancher-cluster.yml`, bring up your Kubernetes cluster:
 rke up --config ./rancher-cluster.yml
 ```

-### 4. Save Your Files
+## 4. Save Your Files

 :::note Important:

@@ -383,8 +387,8 @@ The "rancher-cluster" parts of the two latter file names are dependent on how yo

 :::

-### Issues or errors?
+## Issues or Errors?

 See the [Troubleshooting](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md) page.

-### [Next: Install Rancher](install-rancher-ha.md)
+## [Next: Install Rancher](install-rancher-ha.md)
@@ -8,7 +8,7 @@ title: 4. Install Rancher

 This section is about how to deploy Rancher for your air gapped environment in a high-availability Kubernetes installation. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy.

-### Privileged Access for Rancher
+## Privileged Access for Rancher

 When the Rancher server is deployed in the Docker container, a local Kubernetes cluster is installed within the container for Rancher to use. Because many features of Rancher run as deployments, and privileged mode is required to run containers within containers, you will need to install Rancher with the `--privileged` option.

@@ -92,7 +92,7 @@ Recent changes to cert-manager require an upgrade. If you are upgrading Rancher

 :::

-##### 1. Add the cert-manager repo
+##### 1. Add the cert-manager Repo

 From a system connected to the internet, add the cert-manager repo to Helm:

@@ -101,7 +101,7 @@ helm repo add jetstack https://charts.jetstack.io
 helm repo update
 ```

-##### 2. Fetch the cert-manager chart
+##### 2. Fetch the cert-manager Chart

 Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).

@@ -109,7 +109,7 @@ Fetch the latest cert-manager chart available from the [Helm chart repository](h
 helm fetch jetstack/cert-manager --version v1.11.0
 ```

-##### 3. Retrieve the Cert-Manager CRDs
+##### 3. Retrieve the cert-manager CRDs

 Download the required CRD file for cert-manager:
   ```plain
@@ -120,7 +120,7 @@ Download the required CRD file for cert-manager:

 Copy the fetched charts to a system that has access to the Rancher server cluster to complete installation.

-##### 1. Install Cert-Manager
+#### 1. Install cert-manager

 Install cert-manager with the same options you would use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry.

@@ -160,7 +160,8 @@ If you are using self-signed certificates, install cert-manager:

 </details>

-##### 2. Install Rancher
+#### 2. Install Rancher
+
 First, refer to [Adding TLS Secrets](../../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them.

 Then, create the namespace for Rancher using kubectl:
@@ -192,9 +193,9 @@ Placeholder | Description

 **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
+#### Option B: Certificates From Files Using Kubernetes Secrets

-##### 1. Create secrets
+##### 1. Create Secrets

 Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher.

@@ -27,7 +27,7 @@ First configure the HTTP proxy settings on the K3s systemd service, so that K3s'
 ```
 cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```
@@ -71,7 +71,7 @@ Then you have to configure the HTTP proxy settings on the RKE2 systemd service,
 ```
 cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```
@@ -36,7 +36,7 @@ Administrators might configure the RKE metadata settings to do the following:
 - Change the metadata URL that Rancher uses to sync the metadata, which is useful for air gap setups if you need to sync Rancher locally instead of with GitHub
 - Prevent Rancher from auto-syncing the metadata, which is one way to prevent new and unsupported Kubernetes versions from being available in Rancher

-### Refresh Kubernetes Metadata
+## Refresh Kubernetes Metadata

 The option to refresh the Kubernetes metadata is available for administrators by default, or for any user who has the **Manage Cluster Drivers** [global role.](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)

@@ -74,7 +74,7 @@ If you don't have an air gap setup, you don't need to specify the URL where Ranc

 However, if you have an [air gap setup,](#air-gap-setups) you will need to mirror the Kubernetes metadata repository in a location available to Rancher. Then you need to change the URL to point to the new location of the JSON file.

-### Air Gap Setups
+## Air Gap Setups

 Rancher relies on a periodic refresh of the `rke-metadata-config` to download new Kubernetes version metadata if it is supported with the current version of the Rancher server. For a table of compatible Kubernetes and Rancher versions, refer to the [service terms section.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.2.8/)

@@ -57,7 +57,7 @@ The AWS module just creates an EC2 KeyPair, an EC2 SecurityGroup and an EC2 inst

    - `aws_access_key` - Amazon AWS Access Key
    - `aws_secret_key` - Amazon AWS Secret Key
-    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.

 5. **Optional:** Modify optional variables within `terraform.tfvars`. See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) for more information.
 Suggestions include:
@@ -43,7 +43,7 @@ Deploying to Microsoft Azure will incur charges.
    - `azure_client_id` - Microsoft Azure Client ID
    - `azure_client_secret` - Microsoft Azure Client Secret
    - `azure_tenant_id` - Microsoft Azure Tenant ID
-    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.

 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) for more information. Suggestions include:
@@ -38,7 +38,7 @@ Deploying to DigitalOcean will incur charges.

 4. Edit `terraform.tfvars` and customize the following variables:
    - `do_token` - DigitalOcean access key
-    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.

 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) for more information. Suggestions include:
@@ -39,7 +39,7 @@ Deploying to Google GCP will incur charges.

 4. Edit `terraform.tfvars` and customize the following variables:
    - `gcp_account_json` - GCP service account file path and file name
-    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.

 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp) for more information.
@@ -130,7 +130,7 @@ To install a specific Rancher version, use the `--version` flag (e.g., `--versio

 For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.

-See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
+See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.

 ```
 helm install rancher rancher-latest/rancher \
@@ -38,7 +38,7 @@ Deploying to Hetzner Cloud will incur charges.

 4. Edit `terraform.tfvars` and customize the following variables:
    - `hcloud_token` - Hetzner API access key
-    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.

 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Hetzner Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/hcloud) for more information.
@@ -38,7 +38,7 @@ Deploying to Linode will incur charges.

 4. Edit `terraform.tfvars` and customize the following variables:
    - `linode_token` - The Linode Personal Access Token mentioned above.
-    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.

 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Linode Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/linode) for more information. Suggestions include:
@@ -39,7 +39,7 @@ Deploying to Outscale will incur charges.
 4. Edit `terraform.tfvars` and customize the following variables:
    - `access_key_id` - Outscale access key
    - `secret_key_id` - Outscale secret key
-    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.

 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Outscale Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/outscale) for more information.
@@ -80,11 +80,11 @@ If you use a certificate signed by a recognized CA, installing your certificate

 1.  Enter the following command.

-        ```
-        docker run -d --restart=unless-stopped \
-        -p 80:80 -p 443:443 \
-        rancher/rancher:latest --no-cacerts
-        ```
+    ```
+    docker run -d --restart=unless-stopped \
+      -p 80:80 -p 443:443 \
+      rancher/rancher:latest --no-cacerts
+    ```

 </details>

@@ -10,7 +10,7 @@ When Rancher is used to manage [a large infrastructure](../../getting-started/in

 The etcd data set is automatically cleaned up on a five minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.5/op-guide/maintenance/#space-quota) setting on the etcd servers.

-### Example: This snippet of the RKE cluster.yml file increases the keyspace size to 5GB
+## Example: This Snippet of the RKE Cluster.yml file Increases the Keyspace Size to 5GB

 ```yaml
 # RKE cluster.yml
@@ -21,7 +21,7 @@ services:
      quota-backend-bytes: 5368709120
 ```

-## Scaling etcd disk performance
+## Scaling etcd Disk Performance

 You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.5/tuning/#disk) on how to tune the disk priority on the host.

@@ -16,11 +16,11 @@ Want to provide a user with access to _all_ projects within a cluster? See [Addi

 :::

-### Adding Members to a New Project
+## Adding Members to a New Project

 You can add members to a project as you create it (recommended if possible). For details on creating a new project, refer to the [cluster administration section.](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md)

-### Adding Members to an Existing Project
+## Adding Members to an Existing Project

 Following project creation, you can add users as project members so that they can access its resources.

@@ -35,7 +35,7 @@ There are several other hosted Kubernetes cloud providers that are disabled by d

 ### Node Drivers

-Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). The availability of which node driver to display when creating node templates is defined based on the node driver's status. Only `active` node drivers will be displayed as an option for creating node templates. By default, Rancher is packaged with many existing Docker Machine drivers, but you can also create custom node drivers to add to Rancher.
+Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. A node driver is the same as a [Docker Machine driver](https://github.com/docker/docs/blob/vnext-engine/machine/drivers/index.md). The availability of which node driver to display when creating node templates is defined based on the node driver's status. Only `active` node drivers will be displayed as an option for creating node templates. By default, Rancher is packaged with many existing Docker Machine drivers, but you can also create custom node drivers to add to Rancher.

 If there are specific node drivers that you don't want to show to your users, you would need to de-activate these node drivers.

@@ -6,7 +6,7 @@ title: Node Drivers
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers"/>
 </head>

-A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. By default, Rancher is packaged with many node drivers, but you can also create and add custom node drivers to Rancher.
+A node driver is the same as a [Docker Machine driver](https://github.com/docker/docs/blob/vnext-engine/machine/drivers/index.md). Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. By default, Rancher is packaged with many node drivers, but you can also create and add custom node drivers to Rancher.

 Only `Active` node drivers are displayed in the Rancher UI when you create node templates. If there are specific node drivers that you don't want to show your users, you must deactivate these node drivers.

@@ -60,4 +60,4 @@ To convert an existing cluster to use an RKE template,

 - A new RKE template is created.
 - The cluster is converted to use the new template.
- New clusters can be [created from the new template.](apply-templates.md#creating-a-cluster-from-an-rke-template)
+- New clusters can be [created from the new template.](#creating-a-cluster-from-an-rke-template)
@@ -35,6 +35,7 @@ If you have an existing configuration using the SAML protocol and want to switch
    `Name` | `Groups Mapper`
    `Mapper Type` | `Group Membership`
    `Token Claim Name` | `groups`
+    `Full group path` | `OFF`
    `Add to ID token` | `OFF`
    `Add to access token` | `OFF`
    `Add to user info` | `ON`
@@ -46,6 +47,7 @@ If you have an existing configuration using the SAML protocol and want to switch
    `Name` | `Client Audience`
    `Mapper Type` | `Audience`
    `Included Client Audience` | &lt;CLIENT_NAME>
+    `Add to ID token` | `OFF`
    `Add to access token` | `ON`

  - Create a new "Groups Path" with the settings below.
@@ -56,8 +58,15 @@ If you have an existing configuration using the SAML protocol and want to switch
    `Mapper Type` | `Group Membership`
    `Token Claim Name` | `full_group_path`
    `Full group path` | `ON`
+    `Add to ID token` | `ON`
+    `Add to access token` | `ON`
    `Add to user info` | `ON`

+- Go to **Role Mappings > Client Roles >  realm-management** and add the following Role Mappings to all users or groups that need to query the Keycloak users.
+  - query-users
+  - query-groups
+  - view-users
+
 ## Configuring Keycloak in Rancher

 1. In the Rancher UI, click **☰ > Users & Authentication**.
@@ -54,8 +54,20 @@ Since the private registry cannot be configured after the cluster is created, yo
 1. Select **☰ > Cluster Management**.
 1. On the **Clusters** page, click **Create**.
 1. Choose a cluster type.
-1. In the **Cluster Configuration** go to the **Registries** tab and select **Pull images for Rancher from a private registry**.
-1. Enter the registry hostname and credentials.
+1. In the **Cluster Configuration** go to the **Registries** tab.
+1. Check the box next to **Enable cluster scoped container registry for Rancher system container images**.
+1. Enter the registry hostname.
+1. Under **Authentication** select **Create a HTTP Basic Auth Secret** and fill in the credential fields.
 1. Click **Create**.

 **Result:** The new cluster pulls images from the private registry.
+
+### Working with Private Registry Credentials
+
+When working with private registries, it is important to ensure that any secrets created for these registries are properly backed up. When you add a private registry credential secret through the Rancher GUI and select **Create a HTTP Basic Auth Secret**, the secret is included in backup operations using Rancher Backups.
+
+However, if you create a credential secret outside of the Rancher GUI, such as by using kubectl or Terraform, you must add the `fleet.cattle.io/managed=true` label to indicate that the secret should be included in backups created by Rancher Backups.
+
+For example, if you have a custom private registry named "my-private-registry" and create a secret called "my-reg-creds" for it, apply the `fleet.cattle.io/managed=true` label to this secret. This ensures that your backup process captures the secret, providing easy restoration if needed.
+
+By following this guidance, you can ensure that all of your private registry credentials are backed up and easily accessible in the event of a restore or migration.
@@ -69,7 +69,7 @@ To view Helm charts in the OCI-based Helm chart repository after it achieves an

 Rancher automatically refreshes the OCI-based Helm chart repository every 6 hours. 

-If you need to update immediately, you can [perform a manual refresh](../helm-charts-in-rancher/helm-charts-in-rancher.md#refresh-chart-repositories).
+If you need to update immediately, you can [perform a manual refresh](./helm-charts-in-rancher.md#refresh-chart-repositories).

 ## Update an OCI-Based Helm Chart Repository Configuration

@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
 To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:

 - **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
- **A load balancer** to direct traffic to the two nodes.
+- **A load balancer** to direct traffic to the nodes.
 - **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.

 ### 1. Set up Linux Nodes
@@ -51,7 +51,7 @@ Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance

 :::

-### 4. Set up the DNS Record
+### 3. Set up the DNS Record

 Once you have set up your load balancer, you will need to create a DNS record to send traffic to this load balancer.

@@ -59,4 +59,4 @@ Depending on your environment, this may be an A record pointing to the load bala

 You will need to specify this hostname in a later step when you install Rancher, and it is not possible to change it later. Make sure that your decision is a final one.

-For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
+For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
@@ -37,7 +37,7 @@ Rancher uses the [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/

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

-These nodes can be dynamically provisioned through Rancher's UI, which calls [Docker Machine](https://docs.docker.com/machine/) to launch nodes on various cloud providers.
+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.

 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.

@@ -134,6 +134,7 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeAccountAttributes",
                "ec2:DeleteTags",
+                "ec2:DeleteLaunchTemplateVersions",
                "ec2:DeleteLaunchTemplate",
                "ec2:DeleteSecurityGroup",
                "ec2:DeleteKeyPair",
@@ -321,7 +322,7 @@ These are permissions that are needed by Rancher to create a Virtual Private Clo

 ### EBS CSI Driver addon Permissions

-Permissions required for Rancher to install the Amazon EBS CSI Driver add-on.
+The following are the required permissions for installing the Amazon EBS CSI Driver add-on.

 ```json
 {
@@ -6,32 +6,21 @@ title: Launching Kubernetes on Windows Clusters
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters"/>
 </head>

-When provisioning a [custom cluster](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md) using Rancher, Rancher uses RKE (the Rancher Kubernetes Engine) to install Kubernetes on your existing nodes.
+When provisioning a [custom cluster](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md) Rancher uses RKE2 to install Kubernetes on your existing nodes.

 In a Windows cluster provisioned with Rancher, the cluster must contain both Linux and Windows nodes. The Kubernetes controlplane can only run on Linux nodes, and the Windows nodes can only have the worker role. Windows nodes can only be used for deploying workloads.

-Some other requirements for Windows clusters include:
-
- You can only add Windows nodes to a cluster if Windows support is enabled when the cluster is created. Windows support cannot be enabled for existing clusters.
- Kubernetes 1.15+ is required.
- The Flannel network provider must be used.
- Windows nodes must have 50 GB of disk space.
-
-For the full list of requirements, see [this section.](#requirements-for-windows-clusters)
-
 For a summary of Kubernetes features supported in Windows, see the Kubernetes documentation on [supported functionality and limitations for using Kubernetes with Windows](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#supported-functionality-and-limitations) or the [guide for scheduling Windows containers in Kubernetes](https://kubernetes.io/docs/setup/production-environment/windows/user-guide-windows-containers/).

-### RKE2 Windows
+### RKE2 Features for Windows Clusters

-The RKE2 provisioning feature also includes installing RKE2 on Windows clusters. Windows features for RKE2 include:
+Listed below are the primary RKE2 features for Windows cluster provisioning:

 - Windows Containers with RKE2 powered by containerd
 - Added provisioning of Windows RKE2 custom clusters directly from the Rancher UI
 - Calico CNI for Windows RKE2 custom clusters
 - SAC releases of Windows Server (2004 and 20H2) are included in the technical preview

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

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

 - HostProcess containers in Windows RKE2 are supported in Kubernetes v1.24.1 and up. See [the upstream documentation](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/) for more information.

-## Requirements for Windows Clusters
+## General Requirements

-The general node requirements for networking, operating systems, and Docker are the same as the node requirements for a [Rancher installation](../../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md).
+The general networking and operating system requirements for Windows nodes are the same as for other [Rancher installations](../../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md).

-### OS and Docker Requirements
+### OS Requirements

 Our support for Windows Server and Windows containers match the Microsoft official lifecycle for LTSC (Long-Term Servicing Channel) and SAC (Semi-Annual Channel).

@@ -52,9 +41,7 @@ For the support lifecycle dates for Windows Server, see the [Microsoft Documenta

 ### Kubernetes Version

-Kubernetes v1.15+ is required.
-
-If you are using Kubernetes v1.21 with Windows Server 20H2 Standard Core, the patch "2019-08 Servicing Stack Update for Windows Server" must be installed on the node.
+For more information regarding Kubernetes component versions, see the [support matrices for RKE2 versions](https://www.suse.com/suse-rke2/support-matrix/all-supported-versions/).

 ### Node Requirements

@@ -70,13 +57,7 @@ Rancher will not provision the node if the node does not meet these requirements

 Before provisioning a new cluster, be sure that you have already installed Rancher on a device that accepts inbound network traffic. This is required in order for the cluster nodes to communicate with Rancher. If you have not already installed Rancher, please refer to the [installation documentation](../../../../getting-started/installation-and-upgrade/installation-and-upgrade.md) before proceeding with this guide.

-Rancher only supports Windows using Flannel as the network provider.
-
-There are two network options: [**Host Gateway (L2bridge)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) and [**VXLAN (Overlay)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan). The default option is **VXLAN (Overlay)** mode.
-
-For **Host Gateway (L2bridge)** networking, it's best to use the same Layer 2 network for all nodes. Otherwise, you need to configure the route rules for them. For details, refer to the [documentation on configuring cloud-hosted VM routes.](network-requirements-for-host-gateway.md#cloud-hosted-vm-routes-configuration) You will also need to [disable private IP address checks](network-requirements-for-host-gateway.md#disabling-private-ip-address-checks) if you are using Amazon EC2, Google GCE, or Azure VM.
-
-For **VXLAN (Overlay)** networking, the [KB4489899](https://support.microsoft.com/en-us/help/4489899) hotfix must be installed. Most cloud-hosted VMs already have this hotfix.
+Rancher supports Windows using Calico as the network provider.

 If you are configuring DHCP options sets for an AWS virtual private cloud, note that in the `domain-name` option field, only one domain name can be specified. According to the DHCP options [documentation:](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)

@@ -134,7 +115,7 @@ Windows requires that containers must be built on the same Windows Server versio

 ### Cloud Provider Specific Requirements

-If you set a Kubernetes cloud provider in your cluster, some additional steps are required. You might want to set a cloud provider if you want to want to leverage a cloud provider's capabilities, for example, to automatically provision storage, load balancers, or other infrastructure for your cluster. Refer to [this page](../set-up-cloud-providers/set-up-cloud-providers.md) for details on how to configure a cloud provider cluster of nodes that meet the prerequisites.
+If you set a Kubernetes cloud provider in your cluster, some additional steps are required. You may wish to setup a cloud provider to leverage capabilities to automatically provision storage, load balancers, or other infrastructure for your cluster. Refer to [this page](../set-up-cloud-providers/set-up-cloud-providers.md) for details on how to configure a cloud provider cluster of nodes that meet the prerequisites.

 If you are using the GCE (Google Compute Engine) cloud provider, you must do the following:

@@ -145,11 +126,10 @@ If you are using the GCE (Google Compute Engine) cloud provider, you must do the

 This tutorial describes how to create a Rancher-provisioned cluster with the three nodes in the [recommended architecture.](#recommended-architecture)

-When you provision a cluster with Rancher on existing nodes, you will add nodes to the cluster by installing the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) on each one. When you create or edit your cluster from the Rancher UI, you will see a **Customize Node Run Command** that you can run on each server to add it to your cluster.
+When you provision a cluster with Rancher on existing nodes, you add nodes to the cluster by installing the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) on each one. To create or edit your cluster from the Rancher UI, run the **Registration Command** on each server to add it to your cluster.

 To set up a cluster with support for Windows nodes and containers, you will need to complete the tasks below.

-
 ### 1. Provision Hosts

 To begin provisioning a cluster on existing nodes with Windows support, prepare your hosts.
@@ -182,18 +162,10 @@ The instructions for creating a Windows cluster on existing nodes are very simil
 1. On the **Clusters** page, click **Create**.
 1. Click **Custom**.
 1. Enter a name for your cluster in the **Cluster Name** field.
-1. In the **Kubernetes Version** dropdown menu, select v1.19 or above.
-1. In the **Network Provider** field, select **Flannel**.
-1. In the **Windows Support** section, click **Enabled**.
-1. Optional: After you enable Windows support, you will be able to choose the Flannel backend. There are two network options: [**Host Gateway (L2bridge)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) and [**VXLAN (Overlay)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan). The default option is **VXLAN (Overlay)** mode.
+1. In the **Kubernetes Version** dropdown menu, select a supported Kubernetes version.
+1. In the **Container Network** field, select **Calico**.
 1. Click **Next**.

-:::note Important:
-
-For <b>Host Gateway (L2bridge)</b> networking, it's best to use the same Layer 2 network for all nodes. Otherwise, you need to configure the route rules for them. For details, refer to the [documentation on configuring cloud-hosted VM routes.](network-requirements-for-host-gateway.md#cloud-hosted-vm-routes-configuration) You will also need to [disable private IP address checks](network-requirements-for-host-gateway.md#disabling-private-ip-address-checks) if you are using Amazon EC2, Google GCE, or Azure VM.
-
-:::
-
 ### 3. Add Nodes to the Cluster

 This section describes how to register your Linux and Worker nodes to your cluster. You will run a command on each node, which will install the Rancher agent and allow Rancher to manage each node.
@@ -202,14 +174,13 @@ This section describes how to register your Linux and Worker nodes to your clust

 In this section, we fill out a form on the Rancher UI to get a custom command to install the Rancher agent on the Linux master node. Then we will copy the command and run it on our Linux master node to register the node in the cluster.

-The first node in your cluster should be a Linux host has both the **Control Plane** and **etcd** roles. At a minimum, both of these roles must be enabled for this node, and this node must be added to your cluster before you can add Windows hosts.
+The first node in your cluster should be a Linux host that has both the **Control Plane** and **etcd** roles. At a minimum, both of these roles must be enabled for this node, and this node must be added to your cluster before you can add Windows hosts.

-1. In the **Node Operating System** section, click **Linux**.
-1. In the **Node Role** section, choose at least **etcd** and **Control Plane**. We recommend selecting all three.
+1. After cluster creation, navigate to the **Registration** tab.
+1. In **Step 1** under the **Node Role** section, select at least **etcd** and **Control Plane**. We recommend selecting all three.
 1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
-1. Copy the command displayed on the screen to your clipboard.
+1. In **Step 2**, under the **Registration** section, copy the command displayed on the screen to your clipboard.
 1. SSH into your Linux host and run the command that you copied to your clipboard.
-1. When you are finished provisioning your Linux node(s), select **Done**.

 **Result:**

@@ -222,22 +193,19 @@ You can access your cluster after its state is updated to **Active**.
 - `Default`, containing the `default` namespace
 - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces

-
 It may take a few minutes for the node to be registered in your cluster.

 #### Add Linux Worker Node

 In this section, we run a command to register the Linux worker node to the cluster.

-After the initial provisioning of your cluster, your cluster only has a single Linux host. Next, we add another Linux `worker` host, which will be used to support _Rancher cluster agent_, _Metrics server_, _DNS_ and _Ingress_ for your cluster.
+After the initial provisioning of your cluster, your cluster only has a single Linux host. Add another Linux `worker` host to support the _Rancher cluster agent_, _Metrics server_, _DNS_ and _Ingress_ for your cluster.

-1. In the upper left corner, click **☰ > Cluster Management**.
-1. Go to the cluster that you created and click **⋮ > Edit Config**.
-1. Scroll down to **Node Operating System**. Choose **Linux**.
-1. In the **Customize Node Run Command** section, go to the **Node Options** and select the **Worker** role.
-1. Copy the command displayed on screen to your clipboard.
-1. Log in to your Linux host using a remote Terminal connection. Run the command copied to your clipboard.
-1. From **Rancher**, click **Save**.
+1. After cluster creation, navigate to the **Registration** tab.
+1. In **Step 1** under the **Node Role** section, select **Worker**.
+1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
+1. In **Step 2**, under the **Registration** section, copy the command displayed on the screen to your clipboard.
+1. SSH into your Linux host and run the command that you copied to your clipboard.

 **Result:** The **Worker** role is installed on your Linux host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster.

@@ -257,14 +225,15 @@ For each Linux worker node added into the cluster, the following taints will be

 In this section, we run a command to register the Windows worker node to the cluster.

-You can add Windows hosts to the cluster by editing the cluster and choosing the **Windows** option.
+:::note
+The registration command to add the Windows workers only appears after the cluster is running with Linux etcd, control plane, and worker nodes.
+:::

-1. In the upper left corner, click **☰ > Cluster Management**.
-1. Go to the cluster that you created and click **⋮ > Edit Config**.
-1. Scroll down to **Node Operating System**. Choose **Windows**. Note: You will see that the **worker** role is the only available role.
-1. Copy the command displayed on screen to your clipboard.
+1. After cluster creation, navigate to the **Registration** tab.
+1. In **Step 1** under the **Node Role** section, select **Worker**.
+1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
+1. In **Step 2**, under the **Registration** section, copy the command for Windows workers displayed on the screen to your clipboard.
 1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **Command Prompt (CMD)**.
-1. From Rancher, click **Save**.
 1. Optional: Repeat these instructions if you want to add more Windows nodes to your cluster.

 **Result:** The **Worker** role is installed on your Windows host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster. You now have a Windows Kubernetes cluster.
@@ -21,7 +21,7 @@ The available cloud providers to create a node template are decided based on act

 ### 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://docs.docker.com/machine/) to provision these nodes. The available cloud providers to create node templates are based on the active node drivers in Rancher.
+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.

@@ -23,7 +23,7 @@ You need a separate kubeconfig file for each cluster that you have access to in

 After you download the kubeconfig file, you are able to use the kubeconfig file and its Kubernetes [contexts](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-context-and-configuration) to access your downstream cluster.

-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](./authorized-cluster-endpoint.md) to be present in your PATH.
+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

@@ -19,7 +19,7 @@ To provision new storage for your workloads, follow these steps:
 1. [Add a storage class and configure it to use your storage.](#1-add-a-storage-class-and-configure-it-to-use-your-storage)
 2. [Use the Storage Class for Pods Deployed with a StatefulSet.](#2-use-the-storage-class-for-pods-deployed-with-a-statefulset)

-### Prerequisites
+## Prerequisites

 - To set up persistent storage, the `Manage Volumes` [role](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference) is required.
 - If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.
@@ -42,7 +42,7 @@ hostPath | `host-path`

 To use a storage provisioner that is not on the above list, you will need to use a [feature flag to enable unsupported storage drivers.](../../../../advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)

-### 1. Add a storage class and configure it to use your storage
+## 1. Add a storage class and configure it to use your storage

 These steps describe how to set up a storage class at the cluster level.

@@ -59,7 +59,7 @@ These steps describe how to set up a storage class at the cluster level.

 For full information about the storage class parameters, refer to the official [Kubernetes documentation.](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters).

-### 2. Use the Storage Class for Pods Deployed with a StatefulSet
+## 2. Use the Storage Class for Pods Deployed with a StatefulSet

 StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the StorageClass that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound to dynamically provisioned storage using the StorageClass defined in its PersistentVolumeClaim.

@@ -88,4 +88,4 @@ To attach the PVC to an existing workload,
 1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
 1. Click **Save**.

-**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC. If not, Rancher will provision new persistent storage.
+**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC. If not, Rancher will provision new persistent storage.
@@ -20,12 +20,12 @@ To set up storage, follow these steps:
 2. [Add a PersistentVolume that refers to the persistent storage.](#2-add-a-persistentvolume-that-refers-to-the-persistent-storage)
 3. [Use the Storage Class for Pods Deployed with a StatefulSet.](#3-use-the-storage-class-for-pods-deployed-with-a-statefulset)

-### Prerequisites
+## Prerequisites

 - To create a persistent volume as a Kubernetes resource, you must have the `Manage Volumes` [role.](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference)
 - If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.

-### 1. Set up persistent storage
+## 1. Set up persistent storage

 Creating a persistent volume in Rancher will not create a storage volume. It only creates a Kubernetes resource that maps to an existing volume. Therefore, before you can create a persistent volume as a Kubernetes resource, you must have storage provisioned.

@@ -33,7 +33,7 @@ The steps to set up a persistent storage device will differ based on your infras

 If you have a pool of block storage, and you don't want to use a cloud provider, Longhorn could help you provide persistent storage to your Kubernetes cluster. For more information, see [Cloud Native Storage with Longhorn](../../../../../integrations-in-rancher/longhorn/longhorn.md).

-### 2. Add a PersistentVolume that refers to the persistent storage
+## 2. Add a PersistentVolume that refers to the persistent storage

 These steps describe how to set up a PersistentVolume at the cluster level in Kubernetes.

@@ -52,7 +52,7 @@ These steps describe how to set up a PersistentVolume at the cluster level in Ku
 **Result:** Your new persistent volume is created.


-### 3. Use the Storage Class for Pods Deployed with a StatefulSet
+## 3. Use the Storage Class for Pods Deployed with a StatefulSet

 StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the PersistentVolume that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound a PersistentVolume as defined in its PersistentVolumeClaim.

@@ -86,4 +86,4 @@ The following steps describe how to assign persistent storage to an existing wor
 1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
 1. Click **Launch**.

-**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
+**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
@@ -173,12 +173,12 @@ To add members:

 ### 4. Optional: Add Resource Quotas

-Resource quotas limit the resources that a project (and its namespaces) can consume. For more information, see [Resource Quotas](projects-and-namespaces.md).
+Resource quotas limit the resources that a project (and its namespaces) can consume. For more information, see [Resource Quotas](../../advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md).

 To add a resource quota,

 1. In the **Resource Quotas** tab, click **Add Resource**.
-1. Select a **Resource Type**. For more information, see [Resource Quotas.](projects-and-namespaces.md).
+1. Select a **Resource Type**. For more information, see [Resource Quotas.](../../advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md).
 1. Enter values for the **Project Limit** and the **Namespace Default Limit**.
 1. **Optional:** Specify **Container Default Resource Limit**, which will be applied to every container started in the project. The parameter is recommended if you have CPU or Memory limits set by the Resource Quota. It can be overridden on per an individual namespace or a container level. For more information, see [Container Default Resource Limit](../../advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md)
 1. Click **Create**.
@@ -25,11 +25,11 @@ To manage permissions in a vanilla Kubernetes cluster, cluster admins configure

 :::note

-If you create a namespace with `kubectl`, it may be unusable because `kubectl` doesn't require your new namespace to be scoped within a project that you have access to. If your permissions are restricted to the project level, it is better to [create a namespace through Rancher](manage-namespaces.md) to ensure that you will have permission to access the namespace.
+If you create a namespace with `kubectl`, it may be unusable because `kubectl` doesn't require your new namespace to be scoped within a project that you have access to. If your permissions are restricted to the project level, it is better to [create a namespace through Rancher](#creating-namespaces) to ensure that you will have permission to access the namespace.

 :::

-### Creating Namespaces
+## Creating Namespaces

 Create a new namespace to isolate apps and resources in a project.

@@ -50,7 +50,7 @@ When working with project resources that you can assign to a namespace (i.e., [w

 **Result:** Your namespace is added to the project. You can begin assigning cluster resources to the namespace.

-### Moving Namespaces to Another Project
+## Moving Namespaces to Another Project

 Cluster admins and members may occasionally need to move a namespace to another project, such as when you want a different team to start using the application.

@@ -71,7 +71,7 @@ Cluster admins and members may occasionally need to move a namespace to another

 **Result:** Your namespace is moved to a different project (or is unattached from all projects). If any project resources are attached to the namespace, the namespace releases them and then attached resources from the new project.

-### Editing Namespace Resource Quotas
+## Editing Namespace Resource Quotas

 You can always override the namespace default limit to provide a specific namespace with access to more (or less) project resources.

@@ -14,7 +14,7 @@ To configure the custom resources, go to the **Cluster Dashboard** To configure
 1. On the **Clusters** page, go to the cluster where you want to configure CIS scans and click **Explore**.
 1. In the left navigation bar, click **CIS Benchmark**.

-### Scans
+## Scans

 A scan is created to trigger a CIS scan on the cluster based on the defined profile. A report is created after the scan is completed.

@@ -31,7 +31,7 @@ spec:
  scanProfileName: rke-profile-hardened
 ```

-### Profiles
+## Profiles

 A profile contains the configuration for the CIS scan, which includes the benchmark version to use and any specific tests to skip in that benchmark.

@@ -66,7 +66,7 @@ spec:
    - "1.1.21"
 ```

-### Benchmark Versions
+## Benchmark Versions

 A benchmark version is the name of benchmark to run using `kube-bench`, as well as the valid configuration parameters for that benchmark.

@@ -17,7 +17,7 @@ When a cluster scan is run, you need to select a Profile which points to a speci

 Follow all the steps below to add a custom Benchmark Version and run a scan using it.

-### 1. Prepare the Custom Benchmark Version ConfigMap
+## 1. Prepare the Custom Benchmark Version ConfigMap

 To create a custom benchmark version, first you need to create a ConfigMap containing the benchmark version's config files and upload it to your Kubernetes cluster where you want to run the scan.

@@ -42,7 +42,7 @@ To prepare a custom benchmark version ConfigMap, suppose we want to add a custom
    kubectl create configmap -n <namespace> foo --from-file=<path to directory foo>
    ```

-### 2. Add a Custom Benchmark Version to a Cluster
+## 2. Add a Custom Benchmark Version to a Cluster

 1. In the upper left corner, click **☰ > Cluster Management**.
 1. On the **Clusters** page, go to the cluster where you want to add a custom benchmark and click **Explore**.
@@ -54,7 +54,7 @@ To prepare a custom benchmark version ConfigMap, suppose we want to add a custom
 1. Add the minimum and maximum Kubernetes version limits applicable, if any.
 1. Click **Create**.

-### 3. Create a New Profile for the Custom Benchmark Version
+## 3. Create a New Profile for the Custom Benchmark Version

 To run a scan using your custom benchmark version, you need to add a new Profile pointing to this benchmark version.

@@ -66,7 +66,7 @@ To run a scan using your custom benchmark version, you need to add a new Profile
 1. Choose the Benchmark Version from the dropdown.
 1. Click **Create**.

-### 4. Run a Scan Using the Custom Benchmark Version
+## 4. Run a Scan Using the Custom Benchmark Version

 Once the Profile pointing to your custom benchmark version `foo` has been created, you can create a new Scan to run the custom test configs in the Benchmark Version.

@@ -18,8 +18,11 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
 :::

 | Rancher Version | Adapter Version  |
-|-----------------|:----------------:|
-| v2.9.0          | v104.0.0+up4.0.0  |
+|-----------------|------------------|
+| v2.9.3          | v104.0.0+up4.0.0 |
+| v2.9.2          | v104.0.0+up4.0.0 |
+| v2.9.1          | v104.0.0+up4.0.0 |
+| v2.9.0          | v104.0.0+up4.0.0 |

 ### 1. Gain Access to the Local Cluster

@@ -1,5 +1,5 @@
 ---
-title: Supportconfig bundle
+title: Supportconfig Bundle
 ---

 <head>
@@ -12,7 +12,7 @@ These bundles can be created through Rancher or through direct access to the clu

 > **Note:** Only admin users can generate/download supportconfig bundles, regardless of method.

-### Accessing through Rancher
+## Accessing Through Rancher

 First, click on the hamburger menu. Then click the `Get Support` button.

@@ -24,7 +24,7 @@ In the next page, click on the `Generate Support Config` button.

 ![Get Support](/img/generate-support-config.png)

-### Accessing without rancher
+## Accessing Without Rancher

 First, generate a kubeconfig for the cluster that Rancher is installed on.

@@ -6,7 +6,7 @@ title: Cluster API (CAPI) with Rancher Turtles
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cluster-api"/>
 </head>

-[Rancher Turtles](https://turtles.docs.rancher.com/) is a [Rancher extension](../rancher-extensions.md) that manages the lifecycle of provisioned Kubernetes clusters, by providing integration between your Cluster API (CAPI) and Rancher. With Rancher Turtles, you can:
+[Rancher Turtles](https://turtles.docs.rancher.com/) is a [Kubernetes Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/#operators-in-kubernetes) that manages the lifecycle of provisioned Kubernetes clusters, by providing integration between your Cluster API (CAPI) and Rancher. With Rancher Turtles, you can:

 - Import CAPI clusters into Rancher, by installing the Rancher Cluster Agent in CAPI provisioned clusters.
 - Configure the [CAPI Operator](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values#cluster-api-operator-values).
@@ -8,7 +8,7 @@ title: Overview

 Introduced in Rancher v2.6.1, [Harvester](https://docs.harvesterhci.io/) is an open-source hyper-converged infrastructure (HCI) software built on Kubernetes. Harvester installs on bare metal servers and provides integrated virtualization and distributed storage capabilities. Although Harvester operates using Kubernetes, it does not require users to know Kubernetes concepts, making it a more user-friendly application.

-### Feature Flag
+## Feature Flag

 The Harvester feature flag is used to manage access to the Virtualization Management (VM) page in Rancher where users can navigate directly to Harvester clusters and access the Harvester UI. The Harvester feature flag is enabled by default. Click [here](../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md) for more information on feature flags in Rancher.

@@ -22,7 +22,7 @@ To navigate to the Harvester cluster, click **☰ > Virtualization Management**.

 * Users may import a Harvester cluster only on the Virtualization Management page. Importing a cluster on the Cluster Management page is not supported, and a warning will advise you to return to the VM page to do so.

-### Harvester Node Driver
+## Harvester Node Driver

 The [Harvester node driver](https://docs.harvesterhci.io/v1.1/rancher/node/node-driver/) is generally available for RKE and RKE2 options in Rancher. The node driver is available whether or not the Harvester feature flag is enabled. Note that the node driver is off by default. Users may create RKE or RKE2 clusters on Harvester only from the Cluster Management page.

@@ -30,7 +30,7 @@ Harvester allows `.ISO` images to be uploaded and displayed through the Harveste

 See [Provisioning Drivers](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/about-provisioning-drivers.md#node-drivers) for more information on node drivers in Rancher.

-### Port Requirements
+## Port Requirements

 The port requirements for the Harvester cluster can be found [here](https://docs.harvesterhci.io/v1.1/install/requirements#networking).

@@ -15,4 +15,4 @@ To learn more and get started with Rancher Prime, please visit [this page](https
 import DocCardList from '@theme/DocCardList';
 import { useCurrentSidebarCategory } from '@docusaurus/theme-common/internal';

-<DocCardList items={useCurrentSidebarCategory().items.slice(0,8)} />
+<DocCardList items={useCurrentSidebarCategory().items.slice(0,9)} />
@@ -45,7 +45,7 @@ To configure the resources allocated to an Istio component,
 1. In the left navigation bar, click **Apps**.
 1. Click **Installed Apps**.
 1. Go to the `istio-system` namespace. In one of the Istio workloads, such as `rancher-istio`, click **⋮ > Edit/Upgrade**.
-1. Click **Upgrade** to edit the base components via changes to the values.yaml or add an [overlay file](configuration-options/configuration-options.md#overlay-file). For more information about editing the overlay file, see [this section.](cpu-and-memory-allocations.md#editing-the-overlay-file)
+1. Click **Upgrade** to edit the base components via changes to the values.yaml or add an [overlay file](configuration-options/configuration-options.md#overlay-file). For more information about editing the overlay file, see [this section.](#editing-the-overlay-file)
 1. Change the CPU or memory allocations, the nodes where each component will be scheduled to, or the node tolerations.
 1. Click **Upgrade**. to rollout changes

@@ -10,7 +10,7 @@ This section summarizes the architecture of the Rancher logging application.

 For more details about how the Logging operator works, see the [official documentation.](https://kube-logging.github.io/docs/#architecture)

-### How the Logging Operator Works
+## How the Logging Operator Works

 The Logging operator automates the deployment and configuration of a Kubernetes logging pipeline. It deploys and configures a Fluent Bit DaemonSet on every node to collect container and application logs from the node file system.

@@ -6,7 +6,7 @@ title: rancher-logging Helm Chart Options
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/logging/logging-helm-chart-options"/>
 </head>

-### Enable/Disable Windows Node Logging
+## Enable/Disable Windows Node Logging

 You can enable or disable Windows node logging by setting `global.cattle.windows.enabled` to either `true` or `false` in the `values.yaml`.

@@ -21,7 +21,7 @@ Currently an [issue](https://github.com/rancher/rancher/issues/32325) exists whe

 :::

-### Working with a Custom Docker Root Directory
+## Working with a Custom Docker Root Directory

 If using a custom Docker root directory, you can set `global.dockerRootDirectory` in `values.yaml`.

@@ -31,11 +31,11 @@ Note that this only affects Linux nodes.

 If there are any Windows nodes in the cluster, the change will not be applicable to those nodes.

-### Adding NodeSelector Settings and Tolerations for Custom Taints
+## Adding NodeSelector Settings and Tolerations for Custom Taints

 You can add your own `nodeSelector` settings and add `tolerations` for additional taints by editing the logging Helm chart values. For details, see [this page.](taints-and-tolerations.md)

-### Enabling the Logging Application to Work with SELinux
+## Enabling the Logging Application to Work with SELinux

 :::note Requirements:

@@ -49,7 +49,7 @@ To use Logging v2 with SELinux, we recommend installing the `rancher-selinux` RP

 Then, when installing the logging application, configure the chart to be SELinux aware by changing `global.seLinux.enabled` to `true` in the `values.yaml`.

-### Additional Logging Sources
+## Additional Logging Sources

 By default, Rancher collects logs for [control plane components](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) and [node components](https://kubernetes.io/docs/concepts/overview/components/#node-components) for all cluster types.

@@ -72,7 +72,7 @@ When enabled, Rancher collects all additional node and control plane logs the pr

 If you're already using a cloud provider's own logging solution such as AWS CloudWatch or Google Cloud operations suite (formerly Stackdriver), it is not necessary to enable this option as the native solution will have unrestricted access to all logs.

-### Systemd Configuration
+## Systemd Configuration

 In Rancher logging, `SystemdLogPath` must be configured for K3s and RKE2 Kubernetes distributions.

@@ -87,7 +87,7 @@ K3s and RKE2 Kubernetes distributions log to journald, which is the subsystem of
  * If `/var/log/journal` exists, then use `/var/log/journal`.
  * If `/var/log/journal` does not exist, then use `/run/log/journal`.

-:::note Notes:
+:::note

 If any value not described above is returned, Rancher Logging will not be able to collect control plane logs. To address this issue, you will need to perform the following actions on every control plane node:

@@ -95,4 +95,4 @@ If any value not described above is returned, Rancher Logging will not be able t
 * Reboot your machine.
 * Set `systemdLogPath` to `/run/log/journal`.

-:::
+:::
@@ -20,7 +20,7 @@ Both provide choice for the what node(s) the pod will run on.
 - [Adding NodeSelector Settings and Tolerations for Custom Taints](#adding-nodeselector-settings-and-tolerations-for-custom-taints)


-### Default Implementation in Rancher's Logging Stack
+## Default Implementation in Rancher's Logging Stack

 By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
 The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
@@ -47,7 +47,7 @@ In the above example, we ensure that our pod only runs on Linux nodes, and we ad

 You can do the same with Rancher's existing taints, or with your own custom ones.

-### Adding NodeSelector Settings and Tolerations for Custom Taints
+## Adding NodeSelector Settings and Tolerations for Custom Taints

 If you would like to add your own `nodeSelector` settings, or if you would like to add `tolerations` for additional taints, you can pass the following to the chart's values.

@@ -25,7 +25,7 @@ With Longhorn, you can:

 ![Longhorn Dashboard](/img/longhorn-screenshot.png)

-### Installing Longhorn with Rancher
+## Installing Longhorn with Rancher

 1. Fulfill all [Installation Requirements.](https://longhorn.io/docs/latest/deploy/install/#installation-requirements)
 1. Go to the cluster where you want to install Longhorn.
@@ -37,14 +37,14 @@ With Longhorn, you can:

 **Result:** Longhorn is deployed in the Kubernetes cluster.

-### Accessing Longhorn from the Rancher UI
+## Accessing Longhorn from the Rancher UI

 1. Go to the cluster where Longhorn is installed. In the left navigation menu, click **Longhorn**.
 1. On this page, you can edit Kubernetes resources managed by Longhorn. To view the Longhorn UI, click the **Longhorn** button in the **Overview** section.

 **Result:** You will be taken to the Longhorn UI, where you can manage your Longhorn volumes and their replicas in the Kubernetes cluster, as well as secondary backups of your Longhorn storage that may exist in another Kubernetes cluster or in S3.

-### Uninstalling Longhorn from the Rancher UI
+## Uninstalling Longhorn from the Rancher UI

 1. Go to the cluster where Longhorn is installed and click **Apps**.
 1. Click **Installed Apps**.
@@ -53,15 +53,15 @@ With Longhorn, you can:

 **Result:** Longhorn is uninstalled.

-### GitHub Repository
+## GitHub Repository

 The Longhorn project is available [here.](https://github.com/longhorn/longhorn)

-### Documentation
+## Documentation

 The Longhorn documentation is [here.](https://longhorn.io/docs/)

-### Architecture
+## Architecture

 Longhorn creates a dedicated storage controller for each volume and synchronously replicates the volume across multiple replicas stored on multiple nodes.

@@ -15,7 +15,7 @@ For information on V1 monitoring and alerting, available in Rancher v2.2 up to v

 Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster.

-### Features
+## Features

 Prometheus lets you view metrics from your Rancher and Kubernetes objects. Using timestamps, Prometheus lets you query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or Grafana, which is an analytics viewing platform deployed along with Prometheus.

@@ -97,7 +97,6 @@ To be able to fully deploy Monitoring V2 for Windows, all of your Windows hosts

 For more details on how to upgrade wins on existing Windows hosts, see [Windows cluster support for Monitoring V2.](windows-support.md).

-
 ## Known Issues

 There is a [known issue](https://github.com/rancher/rancher/issues/28787#issuecomment-693611821) that K3s clusters require more than the allotted default memory. If you enable monitoring on a K3s cluster, set `prometheus.prometheusSpec.resources.memory.limit` to 2500 Mi and `prometheus.prometheusSpec.resources.memory.request` to 1750 Mi.
@@ -6,13 +6,11 @@ title: Overview
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/neuvector/overview"/>
 </head>

-### NeuVector Integration in Rancher
-
 [NeuVector 5.x](https://open-docs.neuvector.com/) is an open-source container-centric security platform that is integrated with Rancher. NeuVector offers real-time compliance, visibility, and protection for critical applications and data during runtime. NeuVector provides a firewall, container process/file system monitoring, security auditing with CIS benchmarks, and vulnerability scanning. For more information on Rancher security, please see the [security documentation](../../reference-guides/rancher-security/rancher-security.md).

 NeuVector can be enabled through a Helm chart that may be installed either through **Apps** or through the **Cluster Tools** button in the Rancher UI. Once the Helm chart is installed, users can easily [deploy and manage NeuVector clusters within Rancher](https://open-docs.neuvector.com/deploying/rancher#deploy-and-manage-neuvector-through-rancher-apps-marketplace).

-### Installing NeuVector with Rancher
+## Installing NeuVector with Rancher

 The Harvester Helm Chart is used to manage access to the NeuVector UI in Rancher where users can navigate directly to deploy and manage their NeuVector clusters.

@@ -44,12 +42,12 @@ Some examples are as follows:
 1. Click on **Cluster Tools** at the bottom of the left navigation bar.
 1. Repeat step 4 above to select your container runtime accordingly, then click **Install** again.

-### Accessing NeuVector from the Rancher UI
+## Accessing NeuVector from the Rancher UI

 1. Navigate to the cluster explorer of the cluster where NeuVector is installed. In the left navigation bar, click **NeuVector**.
 1. Click the external link to go to the NeuVector UI. Once the link is selected, users must accept the `END USER LICENSE AGREEMENT` to access the NeuVector UI.

-### Uninstalling NeuVector from the Rancher UI
+## Uninstalling NeuVector from the Rancher UI

 **To uninstall from Apps:**

@@ -62,15 +60,15 @@ Some examples are as follows:
 1. Click **☰ > Cluster Management**.
 1. Click on **Cluster Tools** at the bottom-left of the screen, then click on the trash can icon under the NeuVector chart. Select `Delete the CRD associated with this app` if desired, then click **Delete**.

-### GitHub Repository
+## GitHub Repository

 The NeuVector project is available [here](https://github.com/neuvector/neuvector).

-### Documentation
+## Documentation

 The NeuVector documentation is [here](https://open-docs.neuvector.com/).

-### Architecture
+## Architecture

 The NeuVector security solution contains four types of security containers: Controllers, Enforcers, Managers, and Scanners. A special container called an All-in-One is also provided to combine the Controller, Enforcer, and Manager functions all in one container, primarily for Docker-native deployments. There is also an Updater which, when run, will update the CVE database.

@@ -91,7 +89,7 @@ The NeuVector security solution contains four types of security containers: Cont

 To learn more about NeuVector's architecture, please refer [here](https://open-docs.neuvector.com/basics/overview#architecture).

-### CPU and Memory Allocations
+## CPU and Memory Allocations

 Below are the minimum recommended computing resources for the NeuVector chart installation in a default deployment. Note that the resource limit is not set.

@@ -105,7 +103,7 @@ Below are the minimum recommended computing resources for the NeuVector chart in
 \* Minimum 1GB of memory total required for Controller, Manager, and Scanner containers combined.


-### Hardened Cluster Support - Calico and Canal
+## Hardened Cluster Support - Calico and Canal

 <Tabs>
 <TabItem value="RKE1">
@@ -162,7 +160,7 @@ Below are the minimum recommended computing resources for the NeuVector chart in
 </Tabs>


-### SELinux-enabled Cluster Support - Calico and Canal
+## SELinux-enabled Cluster Support - Calico and Canal

 To enable SELinux on RKE2 clusters, follow the steps below:

@@ -179,12 +177,11 @@ kubectl patch deploy neuvector-scanner-pod -n cattle-neuvector-system --patch '{
 kubectl patch cronjob neuvector-updater-pod -n cattle-neuvector-system --patch '{"spec":{"jobTemplate":{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}}}'
 ```

-### Cluster Support in an Air-Gapped Environment
+## Cluster Support in an Air-Gapped Environment

 - All NeuVector components are deployable on a cluster in an air-gapped environment without any additional configuration needed.

-
-### Support Limitations
+## Support Limitations

 * Only admins and cluster owners are currently supported.

@@ -192,12 +189,10 @@ kubectl patch cronjob neuvector-updater-pod -n cattle-neuvector-system --patch '

 * NeuVector is not supported on a Windows cluster.

-
-### Other Limitations
+## Other Limitations

 * Currently, NeuVector feature chart installation fails when a NeuVector partner chart already exists. To work around this issue, uninstall the NeuVector partner chart and reinstall the NeuVector feature chart.

 * Sometimes when the controllers are not ready, the NeuVector UI is not accessible from the Rancher UI. During this time, controllers will try to restart, and it takes a few minutes for the controllers to be active.

 * Container runtime is not auto-detected for different cluster types when installing the NeuVector chart. To work around this, you can specify the runtime manually.
-
@@ -0,0 +1,21 @@
+---
+title: SUSE Observability
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/suse-observability"/>
+</head>
+
+SUSE Observability is a complete observability solution that provides deep insights into the health of your clusters and nodes, and the workloads running on them. Designed to give you clear visibility into your entire Kubernetes environment, SUSE Observability’s full-stack approach allows you to seamlessly explore everything from services to infrastructure within a single platform, eliminating the need for multiple observability tools.
+
+SUSE Observability securely collects and correlates data, offering actionable insights into both existing and potential issues in your cluster. This helps you address current problems swiftly and take preventative measures against future challenges.
+
+The intuitive dashboards highlight problem areas and offer remediation steps, guiding you from issue identification to root cause analysis, and ultimately to resolution, in the quickest possible time.
+
+For more information and to set up SUSE Observability in your SUSE Rancher-managed Kubernetes cluster, please refer to the [documentation](https://docs.stackstate.com/).
+
+:::note 
+
+The documentation portal for SUSE Observability is currently under development. In the coming months, the portal will be rolled out featuring comprehensive guides, tutorials, and references to support you on your SUSE Observability journey. Stay tuned!
+
+:::
@@ -9,7 +9,7 @@ description: Interact with Rancher using command line interface (CLI) tools from

 The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.

-### Download Rancher CLI
+## Download Rancher CLI

 The binary can be downloaded directly from the UI.

@@ -17,14 +17,14 @@ The binary can be downloaded directly from the UI.
 1. At the bottom of the navigation sidebar menu, click **About**.
 1. Under the **CLI Downloads section**, there are links to download the binaries for Windows, Mac, and Linux. You can also check the [releases page for our CLI](https://github.com/rancher/cli/releases) for direct downloads of the binary.

-### Requirements
+## Requirements

 After you download the Rancher CLI, you need to make a few configurations. Rancher CLI requires:

 - Your Rancher Server URL, which is used to connect to Rancher Server.
 - An API Bearer Token, which is used to authenticate with Rancher. For more information about obtaining a Bearer Token, see [Creating an API Key](../user-settings/api-keys.md).

-### CLI Authentication
+## CLI Authentication

 Before you can use Rancher CLI to control your Rancher Server, you must authenticate using an API Bearer Token. Log in using the following command (replace `<BEARER_TOKEN>` and `<SERVER_URL>` with your information):

@@ -34,7 +34,7 @@ $ ./rancher login https://<SERVER_URL> --token <BEARER_TOKEN>

 If Rancher Server uses a self-signed certificate, Rancher CLI prompts you to continue with the connection.

-### Project Selection
+## Project Selection

 Before you can perform any commands, you must select a Rancher project to perform those commands against. To select a [project](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md) to work on, use the command `./rancher context switch`. When you enter this command, a list of available projects displays. Enter a number to choose your project.

@@ -58,7 +58,7 @@ INFO[0005] Saving config to /Users/markbishop/.ranchcli2.json

 Ensure you can run `rancher kubectl get pods` successfully.

-### Commands
+## Commands

 The following commands are available for use in Rancher CLI.

@@ -86,12 +86,12 @@ The following commands are available for use in Rancher CLI.
 | `token`  | Authenticates and generates new kubeconfig token.  |
 | `help, [h]`  | Shows a list of commands or help for one command.  |

-### Rancher CLI Help
+## Rancher CLI Help

 Once logged into Rancher Server using the CLI, enter `./rancher --help` for a list of commands.

 All commands accept the `--help` flag, which documents each command's usage.

-### Limitations
+## Limitations

 The Rancher CLI **cannot** be used to install [dashboard apps or Rancher feature charts](../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md).
@@ -10,7 +10,7 @@ After you provision a Kubernetes cluster using Rancher, you can still edit optio

 For information on editing cluster membership, go to [this page.](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md)

-### Cluster Configuration References
+## Cluster Configuration References

 The cluster configuration options depend on the type of Kubernetes cluster:

@@ -21,7 +21,7 @@ The cluster configuration options depend on the type of Kubernetes cluster:
 - [GKE Cluster Configuration](rancher-server-configuration/gke-cluster-configuration/gke-cluster-configuration.md)
 - [AKS Cluster Configuration](rancher-server-configuration/aks-cluster-configuration.md)

-### Cluster Management Capabilities by Cluster Type
+## Cluster Management Capabilities by Cluster Type

 The options and settings available for an existing cluster change based on the method that you used to provision it.

@@ -8,11 +8,11 @@ title: DigitalOcean Node Template Configuration

 Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.

-### Droplet Options
+## Droplet Options

 The **Droplet Options** provision your cluster's geographical region and specifications.

-### Docker Daemon
+## Docker Daemon

 If you use Docker, the [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-daemon) configuration options include:

@@ -8,11 +8,11 @@ title: Private Clusters

 In GKE, [private clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/private-cluster-concept) are clusters whose nodes are isolated from inbound and outbound traffic by assigning them internal IP addresses only. Private clusters in GKE have the option of exposing the control plane endpoint as a publicly accessible address or as a private address. This is different from other Kubernetes providers, which may refer to clusters with private control plane endpoints as "private clusters" but still allow traffic to and from nodes. You may want to create a cluster with private nodes, with or without a public control plane endpoint, depending on your organization's networking and security requirements. A GKE cluster provisioned from Rancher can use isolated nodes by selecting "Private Cluster" in the Cluster Options (under "Show advanced options"). The control plane endpoint can optionally be made private by selecting "Enable Private Endpoint".

-### Private Nodes
+## Private Nodes

 Because the nodes in a private cluster only have internal IP addresses, they will not be able to install the cluster agent and Rancher will not be able to fully manage the cluster. This can be overcome in a few ways.

-#### Cloud NAT
+### Cloud NAT

 :::caution

@@ -22,7 +22,7 @@ Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).

 If restricting outgoing internet access is not a concern for your organization, use Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service to allow nodes in the private network to access the internet, enabling them to download the required images from Docker Hub and contact the Rancher management server. This is the simplest solution.

-#### Private registry
+### Private Registry

 :::caution

@@ -32,11 +32,11 @@ This scenario is not officially supported, but is described for cases in which u

 If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](../../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.

-### Private Control Plane Endpoint
+## Private Control Plane Endpoint

 If the cluster has a public endpoint exposed, Rancher will be able to reach the cluster, and no additional steps need to be taken. However, if the cluster has no public endpoint, then considerations must be made to ensure Rancher can access the cluster.

-#### Cloud NAT
+### Cloud NAT

 :::caution

@@ -47,7 +47,7 @@ Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).
 As above, if restricting outgoing internet access to the nodes is not a concern, then Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service can be used to allow the nodes to access the internet. While the cluster is provisioning, Rancher will provide a registration command to run on the cluster. Download the [kubeconfig](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl) for the new cluster and run the provided kubectl command on the cluster. Gaining access
 to the cluster in order to run this command can be done by creating a temporary node or using an existing node in the VPC, or by logging on to or creating an SSH tunnel through one of the cluster nodes.

-#### Direct access
+### Direct Access

 If the Rancher server is run on the same VPC as the cluster's control plane, it will have direct access to the control plane's private endpoint. The cluster nodes will need to have access to a [private registry](#private-registry) to download images as described above.

@@ -6,15 +6,15 @@ title: Monitoring Configuration Examples
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/examples"/>
 </head>

-### ServiceMonitor
+## ServiceMonitor

 See the official prometheus-operator GitHub repo for an example [ServiceMonitor](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml) YAML.

-### PodMonitor
+## PodMonitor

 See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/user-guides/getting-started/#using-podmonitors) for an example PodMonitor and an example Prometheus resource that refers to a PodMonitor.

-### PrometheusRule
+## PrometheusRule

 A PrometheusRule contains the alerting and recording rules that you would usually place in a [Prometheus rule file](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/).

@@ -22,6 +22,6 @@ For a more fine-grained approach, the `ruleSelector` field on a Prometheus resou

 See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/user-guides/alerting/) for an example PrometheusRule.

-### Alertmanager Config
+## Alertmanager Config

 See the Rancher docs page on Receivers for an example [Alertmanager config](./receivers.md#example-alertmanager-configs).
@@ -29,6 +29,9 @@ This section assumes familiarity with how monitoring components work together. F

 1. Go to the cluster where you want to create receivers. Click **Monitoring -> Alerting -> AlertManagerConfigs**.
 1. Click **Create**.
+1. Enter a **Name** for the new AlertmanagerConfig. 
+1. Click **Create**.
+1. After creating the AlertManagerConfig, click it to add a receiver.
 1. Click **Add Receiver**.
 1. Enter a **Name** for the receiver.
 1. Configure one or more providers for the receiver. For help filling out the forms, refer to the configuration options below.
@@ -55,11 +58,11 @@ The notification integrations are configured with the `receiver`, which is expla

 By default, AlertManager provides native integration with some receivers, which are listed in [this section.](https://prometheus.io/docs/alerting/latest/configuration/#receiver) All natively supported receivers are configurable through the Rancher UI.

-For notification mechanisms not natively supported by AlertManager, integration is achieved using the [webhook receiver.](https://prometheus.io/docs/alerting/latest/configuration/#webhook_config) A list of third-party drivers providing such integrations can be found [here.](https://prometheus.io/docs/operating/integrations/#alertmanager-webhook-receiver) Access to these drivers, and their associated integrations, is provided through the Alerting Drivers app. Once enabled, configuring non-native receivers can also be done through the Rancher UI.
+For notification mechanisms, such as Telegram, that are not natively supported by AlertManager, integration is achieved using the [webhook receiver.](https://prometheus.io/docs/alerting/latest/configuration/#webhook_config) A list of third-party drivers providing such integrations can be found [here.](https://prometheus.io/docs/operating/integrations/#alertmanager-webhook-receiver) Access to these drivers, and their associated integrations, is provided through the Alerting Drivers app. Once enabled, configuring non-native receivers can also be done through the Rancher UI.

 Currently the Rancher Alerting Drivers app provides access to the following integrations:
- Microsoft Teams, based on the [prom2teams](https://github.com/idealista/prom2teams) driver
- SMS, based on the [Sachet](https://github.com/messagebird/sachet) driver
+- Microsoft Teams, based on the [prom2teams](https://github.com/idealista/prom2teams) driver.
+- Telegram, based on the [Sachet](https://github.com/messagebird/sachet) driver.

 The following types of receivers can be configured in the Rancher UI:

@@ -71,6 +74,7 @@ The following types of receivers can be configured in the Rancher UI:
 - <a href="#custom">Custom</a>
 - <a href="#teams">Teams</a>
 - <a href="#sms">SMS</a>
+- <a href="#telegram">Telegram</a>

 The custom receiver option can be used to configure any receiver in YAML that cannot be configured by filling out the other forms in the Rancher UI.

@@ -132,8 +136,6 @@ Opsgenie Responders:
 | Proxy URL | Proxy for the webhook notification. |
 | Enable Send Resolved Alerts | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage).    |

-<!-- TODO add info on webhook for teams and sms and link to them -->
-
 ## Custom

 The YAML provided here will be directly appended to your receiver within the Alertmanager Config Secret.
@@ -211,6 +213,87 @@ url http://rancher-alerting-drivers-sachet.ns-1.svc:9876/alert

 <!-- https://github.com/messagebird/sachet -->

+## Telegram
+
+### Enabling the Telegram Receiver for Rancher Managed Clusters
+
+The Telegram receiver is not a native receiver. You must enable it before it can be used. You can enable the Telegram receiver for a Rancher-managed cluster by going to the **Apps** page and installing the `rancher-alerting-drivers` app with the **Telegram** option selected:
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to install `rancher-alerting-drivers` and click **Explore**.
+1. In the left navigation bar, click on **Apps**.
+1. Click the **Alerting Drivers** app.
+1. Click on **Install**.
+1. In the page that opens next, make sure that **Enable SMS** checkbox is selected. Telegram notifications require you to enable SMS.
+1. Take note of the namespace used as it will be required in a later step.
+
+### Test the Configuration by Configuring a PrometheusRule
+
+To test your Telegram setup, create a **PrometheusRule** that continuously raises alerts. 
+
+:::caution NOTE
+This rule is intended only to test if Telegram alerts work as expected. Do not leave it on after testing is completed.
+:::
+
+1. In the left navigation menu, click **Monitoring**.
+1. Click **Advanced**.
+1. Click **PrometheusRules > Create**.
+1. Select a namespace to place the rule in and name the rule appropriately. 
+1. Set the group name to `test`. Use this value later when you create a **Route** in the **AlertManagerConfig**.
+1. Under **Alerting Rules** click **Add**.
+1. Set an appropriate **Alert Name**.
+1. To trigger the alert immediately and continuously, enter the following PromQL Expression: `vector(1)`.
+1. Under **Labels**, click **Add Label**. Enter the key `test` and value `alert`. This key-value pair will also be used later.
+
+#### Configure an AlertManagerConfig
+
+Configure an **AlertManagerConfig** to contain the **Receiver** and **Route** configuration for the **PrometheusRule** created above:
+1. Click **Monitoring > Alerting**, and open **AlertManagerConfigs**.
+1. Click **Create**
+
+#### Create a Receiver in AlertManagerConfig
+
+1. Choose a namespace from the dropdown and set an appropriate name. 
+1. Click **Create**.
+1. Open the newly created **AlertManagerConfig** and click **⋮ > Edit Config**.
+1. Click **Add Receiver**.
+1. Select **Webhook** from the list on the **Create Receiver in AlertmanagerConfig** page. 
+1. Name the webhook, and click **Add Webhook**. 
+1. In the **Select Webhook Type** dropdown, select **SMS**. This will automatically populate the **Target** field as `http://rancher-alerting-drivers-sachet.cattle-monitoring-system.svc:9876/alert`. If you installed the **Alerting Drivers** in a namespace other than `cattle-monitoring-system`, the target URL will reflect that. 
+1. Click **Create**.
+
+#### Create a Route in AlertManagerConfig
+
+1. Click **⋮ > Edit Config**.
+1. Click **Route**.
+1. In the dropdown, select the **Receiver** you just created.
+1. In the **Labels to Group Alerts By** field, type `test`.
+1. Under **Waiting and Intervals**, set **Group Wait** to `1s` and **Group Interval** to `10s`. This triggers frequent alerts. Change the values as appropriate.
+1. Under **Matchers** click **Add Matcher**. Enter `test` in the **Name** field and `alert` in the **Value** field. From the **Match Type** dropdown, select `MatchEqual`.
+1. Click **Save**.
+
+### Configuring the Telegram Receiver
+
+You can configure the Telegram receiver by updating the `rancher-alerting-drivers-sachet` ConfigMap in the `cattle-monitoring-system` namespace. For example, the following is a minimal Telegram receiver configuration:
+
+```yaml
+providers:
+  telegram:
+    token: <your-token-from-telegram>
+
+receivers:
+- name: 'cattle-monitoring-system/test-amc/prom2tel'
+  provider: 'telegram'
+  to:
+    - '123456789'
+```
+
+To obtain a Telegram token, setup a Telegram bot. Refer to the [official Telegram guide](https://core.telegram.org/bots/tutorial) for details.
+After you finish configuring the receiver, [add](#creating-receivers-in-the-rancher-ui) it. 
+
+Name the receiver `<namespace>/<alertmanagerconfig-name>/<receiver-name>`. Enter `123456789` as a placeholder for the Telegram user ID to send the notifications to. To find your Telegram ID, check [the Telegram userinfo bot](https://telegram.me/userinfobot).
+
+You should now receive Telegram notifications to the user ID. If you don't receive notifications, please check if there are any errors reported in the Pod for the Deployment `rancher-alerting-drivers-sachet` under the `cattle-monitoring-system` namespace.

 ## Configuring Multiple Receivers

@@ -18,7 +18,7 @@ This section assumes familiarity with how monitoring components work together. F

 :::

-### ServiceMonitors
+## ServiceMonitors

 This pseudo-CRD maps to a section of the Prometheus custom resource configuration. It declaratively specifies how groups of Kubernetes services should be monitored.

@@ -28,7 +28,7 @@ Any Services in your cluster that match the labels located within the ServiceMon

 For more information about how ServiceMonitors work, refer to the [Prometheus Operator documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/running-exporters.md)

-### PodMonitors
+## PodMonitors

 This pseudo-CRD maps to a section of the Prometheus custom resource configuration. It declaratively specifies how group of pods should be monitored.

@@ -26,18 +26,18 @@ Prometheus Federator is designed to be deployed alongside an existing Prometheus
 2. On seeing each ProjectHelmChartCR, the operator will automatically deploy a Project Prometheus stack on the Project Owner's behalf in the **Project Release Namespace (`cattle-project-<id>-monitoring`)** based on a HelmChart CR and a HelmRelease CR automatically created by the ProjectHelmChart controller in the **Operator / System Namespace**.
 3. RBAC will automatically be assigned in the Project Release Namespace to allow users to view the Prometheus, Alertmanager, and Grafana UIs of the Project Monitoring Stack deployed; this will be based on RBAC defined on the Project Registration Namespace against the [default Kubernetes user-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles). For more information, see the section on [configuring RBAC](rbac.md).

-### What is a Project?
+## What is a Project?

 In Prometheus Federator, a Project is a group of namespaces that can be identified by a `metav1.LabelSelector`. By default, the label used to identify projects is `field.cattle.io/projectId`, the label used to identify namespaces that are contained within a given Rancher Project.

-### Configuring the Helm release created by a ProjectHelmChart
+## Configuring the Helm release created by a ProjectHelmChart

 The `spec.values` of this ProjectHelmChart's resources will correspond to the `values.yaml` override to be supplied to the underlying Helm chart deployed by the operator on the user's behalf; to see the underlying chart's `values.yaml` spec, either:

 - View the chart's definition located at [`rancher/prometheus-federator` under `charts/rancher-project-monitoring`](https://github.com/rancher/prometheus-federator/blob/main/charts/rancher-project-monitoring) (where the chart version will be tied to the version of this operator).
 - Look for the ConfigMap named `monitoring.cattle.io.v1alpha1` that is automatically created in each Project Registration Namespace, which will contain both the `values.yaml` and `questions.yaml` that was used to configure the chart (which was embedded directly into the `prometheus-federator` binary).

-### Namespaces
+## Namespaces

 As a Project Operator based on [rancher/helm-project-operator](https://github.com/rancher/helm-project-operator), Prometheus Federator has three different classifications of namespaces that the operator looks out for:

@@ -65,7 +65,7 @@ As a Project Operator based on [rancher/helm-project-operator](https://github.co

    :::

-### Helm Resources (HelmChart, HelmRelease)
+## Helm Resources (HelmChart, HelmRelease)

 On deploying a ProjectHelmChart, the Prometheus Federator will automatically create and manage two child custom resources that manage the underlying Helm resources in turn:

@@ -103,6 +103,6 @@ For more information on advanced configurations, refer to [this page](https://gi
 |`helmProjectOperator.hardenedNamespaces.configuration`| The configuration to be supplied to the default ServiceAccount or auto-generated NetworkPolicy on managing a namespace. |
 -->

-### Prometheus Federator on the Local Cluster
+## Prometheus Federator on the Local Cluster

 Prometheus Federator is a resource intensive application. Installing it to the local cluster is possible, but **not recommended**.
@@ -21,7 +21,7 @@ The following descriptions correspond to the numbers in the diagram above:
 3. [Node Agents](#3-node-agents)
 4. [Authorized Cluster Endpoint](#4-authorized-cluster-endpoint)

-### 1. The Authentication Proxy
+## 1. The Authentication Proxy

 In this diagram, a user named Bob wants to see all pods running on a downstream user cluster called User Cluster 1. From within Rancher, he can run a `kubectl` command to see
 the pods. Bob is authenticated through Rancher's authentication proxy.
@@ -32,7 +32,7 @@ Rancher communicates with Kubernetes clusters using a [service account](https://

 By default, Rancher generates a [kubeconfig file](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster.

-### 2. Cluster Controllers and Cluster Agents
+## 2. Cluster Controllers and Cluster Agents

 Each downstream user cluster has a cluster agent, which opens a tunnel to the corresponding cluster controller within the Rancher server.

@@ -52,13 +52,13 @@ The cluster agent, also called `cattle-cluster-agent`, is a component that runs
 -  Applies the roles and bindings defined in each cluster's global policies
 - Communicates between the cluster and Rancher server (through a tunnel to the cluster controller) about events, stats, node info, and health

-### 3. Node Agents
+## 3. Node Agents

 If the cluster agent (also called `cattle-cluster-agent`) is not available, one of the node agents creates a tunnel to the cluster controller to communicate with Rancher.

 The `cattle-node-agent` is deployed using a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) resource to make sure it runs on every node in a Rancher-launched Kubernetes cluster. It is used to interact with the nodes when performing cluster operations. Examples of cluster operations include upgrading the Kubernetes version and creating or restoring etcd snapshots.

-### 4. Authorized Cluster Endpoint
+## 4. Authorized Cluster Endpoint

 An authorized cluster endpoint (ACE) allows users to connect to the Kubernetes API server of a downstream cluster without having to route their requests through the Rancher authentication proxy.

@@ -89,6 +89,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can

 ## Impersonation

+:::caution Known Issue
+
+Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
+
+:::
+
 Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.

 When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
@@ -6,7 +6,7 @@ title: Kubernetes Security Best Practices
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/kubernetes-security-best-practices"/>
 </head>

-### Restricting cloud metadata API access
+## Restricting Cloud Metadata API Access

 Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.

@@ -27,11 +27,11 @@ Security is at the heart of all Rancher features. From integrating with all the

 On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters.

-### NeuVector Integration with Rancher
+## NeuVector Integration with Rancher

 NeuVector is an open-source, container-focused security application that is now integrated into Rancher. NeuVector provides production security, DevOps vulnerability protection, and a container firewall, et al. Please see the [Rancher docs](../../integrations-in-rancher/neuvector/neuvector.md) and the [NeuVector docs](https://open-docs.neuvector.com/) for more information.

-### Running a CIS Security Scan on a Kubernetes Cluster
+## Running a CIS Security Scan on a Kubernetes Cluster

 Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the [CIS](https://www.cisecurity.org/cis-benchmarks/) (Center for Internet Security) Kubernetes Benchmark.

@@ -47,13 +47,13 @@ When Rancher runs a CIS security scan on a cluster, it generates a report showin

 For details, refer to the section on [security scans](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md).

-### SELinux RPM
+## SELinux RPM

 [Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.

 We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).

-### Rancher Hardening Guide
+## Rancher Hardening Guide

 The Rancher Hardening Guide is based on controls and best practices found in the <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a> from the Center for Internet Security.

@@ -63,7 +63,7 @@ The hardening guides provide prescriptive guidance for hardening a production in

 Each version of the hardening guide is intended to be used with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher.

-### The CIS Benchmark and Self-Assessment
+## The CIS Benchmark and Self-Assessment

 The benchmark self-assessment is a companion to the Rancher security hardening guide. While the hardening guide shows you how to harden the cluster, the benchmark guide is meant to help you evaluate the level of security of the hardened cluster.

@@ -71,7 +71,7 @@ Because Rancher and RKE install Kubernetes services as Docker containers, many o

 Each version of Rancher's self-assessment guide corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark.

-### Third-party Penetration Test Reports
+## Third-party Penetration Test Reports

 Rancher periodically hires third parties to perform security audits and penetration tests of the Rancher software stack. The environments under test follow the Rancher provided hardening guides at the time of the testing. Previous penetration test reports are available below.

@@ -82,14 +82,14 @@ Results:

 Please note that new reports are no longer shared or made publicly available.

-### Rancher Security Advisories and CVEs
+## Rancher Security Advisories and CVEs

 Rancher is committed to informing the community of security issues in our products. For the list of CVEs (Common Vulnerabilities and Exposures) for issues we have resolved, refer to [this page.](security-advisories-and-cves.md)

-### Kubernetes Security Best Practices
+## Kubernetes Security Best Practices

 For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](kubernetes-security-best-practices.md) guide.

-### Rancher Security Best Practices
+## Rancher Security Best Practices

 For recommendations on securing your Rancher Manager deployments, refer to the [Rancher Security Best Practices](rancher-security-best-practices.md) guide.
@@ -10,11 +10,11 @@ Rancher is committed to informing the community of security issues in our produc

 | ID | Description | Date | Resolution |
 |----|-------------|------|------------|
+[CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the `server-url` of the Rancher cluster). | 19 Sep 2024 | Rancher [v2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2), [v2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) and [v2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) |
 | [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
 | [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
 | [CVE-2023-22650](https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where Rancher did not have a user retention process for when external authentication providers are used, that could be configured to run periodically and disable and/or delete inactive users. The new user retention process added in Rancher v2.8.5 and Rancher v2.7.14 is disabled by default. If enabled, a user becomes subject to the retention process if they don't log in for a configurable period of time. It's possible to set overrides for user accounts that are primarily intended for programmatic access (e.g. CI, scripts, etc.) so that they don't become subject to the retention process for a longer period of time or at all. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
 | [CVE-2023-32191](https://github.com/rancher/rke/security/advisories/GHSA-6gr4-52w6-vmqx) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, in which supported RKE versions store credentials inside a ConfigMap that can be accessible by non-administrative users in Rancher. This vulnerability only affects an RKE-provisioned cluster. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
-| [CVE-2024-22030](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-22030) | A vulnerability was discovered in Rancher's and Fleet's agents, currently deemed a medium to high severity CVE, that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker would need to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the server-url of the Rancher cluster). At the moment there is no fix available and it affects all supported versions of Rancher. Customers and users are advised to follow the recommendations and best practices described in our [blog post](https://www.suse.com/c/rancher-security-update/). | 16 Feb 2024 | Pending |
 | [CVE-2023-32193](https://github.com/rancher/norman/security/advisories/GHSA-r8f4-hv23-6qp6) | An issue was discovered in Rancher versions up to and including 2.6.13, 2.7.9 and 2.8.1, where multiple Cross-Site Scripting (XSS) vulnerabilities can be exploited via the Rancher UI (Norman). | 8 Feb 2024 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2), [v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) and [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
 | [CVE-2023-32192](https://github.com/rancher/apiserver/security/advisories/GHSA-833m-37f7-jq55) | An issue was discovered in Rancher versions up to and including 2.6.13, 2.7.9 and 2.8.1, where multiple Cross-Site Scripting (XSS) vulnerabilities can be exploited via the Rancher UI (Apiserver). | 8 Feb 2024 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2), [v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) and [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
 | [CVE-2023-22649](https://github.com/rancher/rancher/security/advisories/GHSA-xfj7-qf8w-2gcr) | An issue was discovered in Rancher versions up to and including 2.6.13, 2.7.9 and 2.8.1, in which sensitive data may be leaked into Rancher's audit logs. | 8 Feb 2024 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2), [v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) and [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
@@ -20,6 +20,9 @@ Each Rancher version is designed to be compatible with a single version of the w

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
+| v2.9.3          |     v0.5.3      | &check;               | &check;                   |
+| v2.9.2          |     v0.5.2      | &check;               | &check;                   |
+| v2.9.1          |     v0.5.1      | &check;               | &check;                   |
 | v2.9.0          |     v0.5.0      | &cross;               | &check;                   |

 ## Why Do We Need It?
@@ -124,6 +127,8 @@ The webhook provides extra validations on [namespaces](https://github.com/ranche
 - A user account with the proper permissions can pre-create the namespace with the appropriate configuration.
  - This option depends on the ability of the application to handle existing resources.

+Another one of these validations ensures that the user has the proper permissions to update the `field.cattle.io/projectId` annotation on a namespace. This is the `manage-namespaces` permission for `projects` in `management.cattle.io`.
+
 ## Issues on Specific Versions

 **Note:** The following is an incomplete list of high-severity issues affecting specific Rancher/webhook versions. In most cases, these issues can be resolved by upgrading to a more recent Rancher version.
@@ -6,7 +6,7 @@ title: Advanced Options for Docker Installs
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/single-node-rancher-in-docker/advanced-options"/>
 </head>

-### Custom CA Certificate
+## Custom CA Certificate

 If you want to configure Rancher to use a CA root certificate to be used when validating services, you would start the Rancher container sharing the directory that contains the CA root certificate.

@@ -30,7 +30,7 @@ docker run -d --restart=unless-stopped \
  rancher/rancher:latest
 ```

-### API Audit Log
+## API Audit Log

 The API Audit Log records all the user and system transactions made through Rancher server.

@@ -49,7 +49,7 @@ docker run -d --restart=unless-stopped \
  rancher/rancher:latest
 ```

-### TLS settings
+## TLS settings

 To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` and `CATTLE_TLS_CIPHERS` environment variables. For example, to configure TLS 1.0 as minimum accepted TLS version:

@@ -65,7 +65,7 @@ Privileged access is [required.](../../getting-started/installation-and-upgrade/

 See [TLS settings](../../getting-started/installation-and-upgrade/installation-references/tls-settings.md) for more information and options.

-### Air Gap
+## Air Gap

 If you are visiting this page to complete an air gap installation, you must prepend your private registry URL to the server tag when running the installation command in the option that you choose. Add `<REGISTRY.DOMAIN.COM:PORT>` with your private registry URL in front of `rancher/rancher:latest`.

@@ -73,7 +73,7 @@ If you are visiting this page to complete an air gap installation, you must prep

     <REGISTRY.DOMAIN.COM:PORT>/rancher/rancher:latest

-### Persistent Data
+## Persistent Data

 Rancher uses etcd as a datastore. When Rancher is installed with Docker, the embedded etcd is being used. The persistent data is at the following path in the container: `/var/lib/rancher`.

@@ -89,7 +89,7 @@ docker run -d --restart=unless-stopped \

 Privileged access is [required.](../../getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)

-### Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node
+## Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node

 In the situation where you want to use a single node to run Rancher and to be able to add the same node to a cluster, you have to adjust the host ports mapped for the `rancher/rancher` container.

@@ -12,7 +12,7 @@ Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG

 Before running the DNS checks, check the [default DNS provider](../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#default-dns-provider) for your cluster and make sure that [the overlay network is functioning correctly](networking.md#check-if-overlay-network-is-functioning-correctly) as this can also be the reason why DNS resolution (partly) fails.

-### Check if DNS pods are running
+## Check if DNS pods are running

 ```
 kubectl -n kube-system get pods -l k8s-app=kube-dns
@@ -30,7 +30,7 @@ NAME                        READY   STATUS    RESTARTS   AGE
 kube-dns-5fd74c7488-h6f7n   3/3     Running   0          4m13s
 ```

-### Check if the DNS service is present with the correct cluster-ip
+## Check if the DNS service is present with the correct cluster-ip

 ```
 kubectl -n kube-system get svc -l k8s-app=kube-dns
@@ -41,7 +41,7 @@ NAME               TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
 service/kube-dns   ClusterIP   10.43.0.10   <none>        53/UDP,53/TCP   4m13s
 ```

-### Check if domain names are resolving
+## Check if domain names are resolving

 Check if internal cluster names are resolving (in this example, `kubernetes.default`), the IP shown after `Server:` should be the same as the `CLUSTER-IP` from the `kube-dns` service.

@@ -132,15 +132,15 @@ command terminated with exit code 1

 Cleanup the alpine DaemonSet by running `kubectl delete ds/dnstest`.

-### CoreDNS specific
+## CoreDNS specific

-#### Check CoreDNS logging
+### Check CoreDNS logging

 ```
 kubectl -n kube-system logs -l k8s-app=kube-dns
 ```

-#### Check configuration
+### Check configuration

 CoreDNS configuration is stored in the configmap `coredns` in the `kube-system` namespace.

@@ -148,7 +148,7 @@ CoreDNS configuration is stored in the configmap `coredns` in the `kube-system`
 kubectl -n kube-system get configmap coredns -o go-template={{.data.Corefile}}
 ```

-#### Check upstream nameservers in resolv.conf
+### Check upstream nameservers in resolv.conf

 By default, the configured nameservers on the host (in `/etc/resolv.conf`) will be used as upstream nameservers for CoreDNS. You can check this file on the host or run the following Pod with `dnsPolicy` set to `Default`, which will inherit the `/etc/resolv.conf` from the host it is running on.

@@ -156,7 +156,7 @@ By default, the configured nameservers on the host (in `/etc/resolv.conf`) will
 kubectl run -i --restart=Never --rm test-${RANDOM} --image=ubuntu --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"dnsPolicy":"Default"}}' -- sh -c 'cat /etc/resolv.conf'
 ```

-#### Enable query logging
+### Enable query logging

 Enabling query logging can be done by enabling the [log plugin](https://coredns.io/plugins/log/) in the Corefile configuration in the configmap `coredns`. You can do so by using `kubectl -n kube-system edit configmap coredns` or use the command below to replace the configuration in place:

@@ -166,9 +166,9 @@ kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log

 All queries will now be logged and can be checked using the command in [Check CoreDNS logging](#check-coredns-logging).

-### kube-dns specific
+## kube-dns specific

-#### Check upstream nameservers in kubedns container
+### Check upstream nameservers in kubedns container

 By default, the configured nameservers on the host (in `/etc/resolv.conf`) will be used as upstream nameservers for kube-dns. Sometimes the host will run a local caching DNS nameserver, which means the address in `/etc/resolv.conf` will point to an address in the loopback range (`127.0.0.0/8`) which will be unreachable by the container. In case of Ubuntu 18.04, this is done by `systemd-resolved`. We detect if `systemd-resolved` is running, and will automatically use the `/etc/resolv.conf` file with the correct upstream nameservers (which is located at `/run/systemd/resolve/resolv.conf`).

@@ -10,14 +10,15 @@ For Rancher versions that have `rancher-webhook` installed, certain versions cre

 In Rancher v2.6.3 and up, rancher-webhook deployments will automatically renew their TLS certificate when it is within 30 or fewer days of its expiration date. If you are using v2.6.2 or below, there are two methods to work around this issue:

-##### 1. Users with cluster access, run the following commands:
+## 1. Users with Cluster Access, Run the Following Commands:
+
 ```
 kubectl delete secret -n cattle-system cattle-webhook-tls
 kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io --ignore-not-found=true rancher.cattle.io
 kubectl delete pod -n cattle-system -l app=rancher-webhook
 ```

-##### 2. Users with no cluster access via `kubectl`:
+## 2. Users with No Cluster Access Via `kubectl`:

 1. Delete the `cattle-webhook-tls` secret in the `cattle-system` namespace in the local cluster.

@@ -10,11 +10,12 @@ The commands/steps listed on this page can be used to check networking related i

 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 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 overlay network is functioning correctly
+
+## 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.

@@ -98,7 +99,7 @@ The `swiss-army-knife` container does not support Windows nodes. It also [does n
 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
+### 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:

@@ -10,7 +10,7 @@ The commands/steps listed on this page can be used to check your Rancher Kuberne

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml`).

-### Check Rancher pods
+## Check Rancher Pods

 Rancher pods are deployed as a Deployment in the `cattle-system` namespace.

@@ -31,25 +31,25 @@ rancher-7dbd7875f7-qw7wb   1/1     Running   0          8m    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
+### Pod Details

 ```
 kubectl -n cattle-system describe pods -l app=rancher
 ```

-#### Pod container logs
+### Pod Container Logs

 ```
 kubectl -n cattle-system logs -l app=rancher
 ```

-#### Namespace events
+### Namespace Events

 ```
 kubectl -n cattle-system get events
 ```

-### Check ingress
+## Check Ingress

 Ingress should have the correct `HOSTS` (showing the configured FQDN) and `ADDRESS` (host address(es) it will be routed to).

@@ -64,7 +64,7 @@ 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
+## 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:

@@ -72,7 +72,7 @@ When accessing your configured Rancher FQDN does not show you the UI, check the
 kubectl -n ingress-nginx logs -l app=ingress-nginx
 ```

-### Leader election
+## 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`).

@@ -87,7 +87,7 @@ NAME                 HOLDER                    AGE
 cattle-controllers   rancher-dbc7ff869-gvg6k   6h10m
 ```

-#### Configuration
+### Configuration

 _Available as of Rancher 2.8.3_

@@ -10,13 +10,13 @@ The commands/steps listed on this page can be used to check clusters that you ar

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kubeconfig_from_imported_cluster.yml`)

-### Rancher agents
+## Rancher Agents

 Communication to the cluster (Kubernetes API via cattle-cluster-agent) and communication to the nodes is done through Rancher agents.

 If the cattle-cluster-agent cannot connect to the configured `server-url`, the cluster will remain in **Pending** state, showing `Waiting for full cluster configuration`.

-#### cattle-node-agent
+### cattle-node-agent

 :::note

@@ -49,7 +49,7 @@ 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
+### 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:

@@ -20,7 +20,7 @@ Now with this feature, a downstream cluster admin should be able to look at the
 If the audit logs are shipped off of the cluster, a user of the logging system should be able to identify the user in the external Identity Provider system.
 A Rancher Admin should now be able to view Rancher audit logs and follow through to the Kubernetes audit log by using the external Identity Provider username.

-### Feature Description
+## Feature Description

 - When Kubernetes Audit logs are enabled on the downstream cluster, in each event that is logged, the external Identity Provider's username is now logged for each request, at the "metadata" level.
 - When Rancher API Audit logs are enabled on the Rancher installation, the external Identity Provider's username is also logged now at the `auditLog.level=1` for each request that hits the Rancher API server, including the login requests.
@@ -185,9 +185,9 @@ module.exports = {
              label: 'Latest',
            },
            2.9: {
-              label: 'v2.9 (Preview)',
+              label: 'v2.9',
              path: 'v2.9',
-              banner: 'unreleased'
+              banner: 'none'
            },
            2.8: {
              label: 'v2.8',
@@ -2394,6 +2394,19 @@ module.exports = {
            to: '/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods',
            from: '/pages-for-subheaders/workloads-and-pods'
          }, // Redirects for pages-for-subheaders removal [latest] (end)
+
+          { // Redirects for dashboard#12040 (start)
+            to: '/v2.9/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-google-oauth',
+            from: '/v2.9/admin-settings/authentication/google',
+          },
+          {
+            to: '/v2.9/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides',
+            from: '/v2.9/monitoring-alerting/configuration',
+          }, 
+          {
+            to: '/v2.9/integrations-in-rancher/monitoring-and-alerting',
+            from: '/v2.9/monitoring-alerting',
+          }, // Redirects for dashboard#12040 (end)
          { // Redirects for dashboard#9970
            to: '/v2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/rke1-vs-rke2-differences',
            from: '/v2.8/cluster-provisioning/rke-clusters/behavior-differences-between-rke1-and-rke2/'
@@ -6,7 +6,7 @@ title: API 令牌

 要停用 API 令牌，你可以删除令牌或停用用户账号。

-### 删除令牌
+## 删除令牌
 要删除令牌：

 1. 转到 `https://<Rancher-Server-IP>/v3/tokens`，在 Rancher API 视图中查看包含所有令牌的列表。
@@ -28,7 +28,7 @@ title: API 令牌
 | `drain-node-*` | 用于清空的令牌（由于没有原生 Kubernetes API，我们使用 `kubectl` 来清空） |


-### 在 Kubeconfig 令牌上设置 TTL
+## 在 Kubeconfig 令牌上设置 TTL

 管理员可以在 Kubeconfig 令牌上设置全局存活时间 (time-to-live，TTL)。如需更改默认 kubeconfig TTL，你可以导航到全局设置并将 [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) 设置为所需的持续时间（单位：分钟）。[`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) 的默认值为 0，表示令牌永不过期。

@@ -38,17 +38,17 @@ title: API 令牌

 :::

-### 在生成的 Kubeconfig 中禁用令牌
+## 在生成的 Kubeconfig 中禁用令牌

-1. 将 `kubeconfig-generate-token` 设置为 `false`。此设置让 Rancher 不再在用户单击下载 kubeconfig 文件时自动生成令牌。如果停用此设置，生成的 kubeconfig 将引用 [Rancher CLI](../cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌进行-ttl-认证) 来检索集群的短期令牌。当这个 kubeconfig 在客户端（例如 `kubectl`）中使用时，你需要安装 Rancher CLI 来完成登录请求。
+1. 将 `kubeconfig-generate-token` 设置为 `false`。此设置让 Rancher 不再在用户单击下载 kubeconfig 文件时自动生成令牌。如果停用此设置，生成的 kubeconfig 将引用 [Rancher CLI](../reference-guides/cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌进行-ttl-认证) 来检索集群的短期令牌。当这个 kubeconfig 在客户端（例如 `kubectl`）中使用时，你需要安装 Rancher CLI 来完成登录请求。

 2. 将 `kubeconfig-token-ttl-minutes` 设置为所需的时长（单位：分钟）。`kubeconfig-token-ttl-minutes` 默认设置为 960（即 16 小时）。

-### 令牌哈希
+## 令牌哈希

 你可以启用令牌哈希，令牌将使用 SHA256 算法进行单向哈希。这是一个不可逆的操作，一旦启用，此功能将无法禁用。在启用功能或在测试环境中评估之前，建议你先进行备份。

-要启用令牌哈希，请参阅[本节](../../pages-for-subheaders/enable-experimental-features.md)。
+要启用令牌哈希，请参阅[本节](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。

 此功能将影响所有令牌，包括但不限于以下内容：

@@ -56,7 +56,8 @@ title: API 令牌
 - 持有者令牌 API 密钥/调用
 - 内部操作使用的令牌

-### 令牌设置
+## 令牌设置
+
 以下全局设置会影响 Rancher 令牌的行为：

 | 设置 | 描述 |
@@ -67,20 +68,20 @@ title: API 令牌
 | [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) | 除了由 [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) 控制的令牌外，所有令牌的最大 TTL。 |
 | [`kubeconfig-generate-token`](#kubeconfig-generate-token) | 如果为 true，则在用户下载 kubeconfig 时自动生成令牌。 |

-#### auth-user-session-ttl-minutes
+### auth-user-session-ttl-minutes
 存活时间（TTL）（单位：分钟），用于确定用户身份验证会话令牌的到期时间。过期后，用户将需要登录并获取新令牌。此设置不受 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的影响。会话令牌是在用户登录 Rancher 时创建的。

-#### kubeconfig-default-token-TTL-minutes
+### kubeconfig-default-token-TTL-minutes
 存活时间（TTL）（单位：分钟），用于确定 kubeconfig 令牌的到期时间。令牌过期后，API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。此设置适用于在请求的 kubeconfig 文件中生成的令牌，不包括[由 Rancher CLI 生成的](#在生成的-kubeconfig-中禁用令牌)令牌。
 **此设置从 2.6.6 版本开始引入**。

-#### kubeconfig-token-ttl-minutes
+### kubeconfig-token-ttl-minutes
 存活时间（TTL）（单位：分钟），用于确定由 CLI 生成的 kubeconfig 令牌的到期时间。当 [`kubeconfig-generate-token`](#kubeconfig-generate-token) 设为 false 时，则由 CLI 生成令牌。令牌过期后，API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。
 **自版本 2.6.6 起已弃用，并将在 2.8.0 中删除。请知悉，此设置将被 [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) 的值替换**。

-#### auth-token-max-ttl-minutes
+### auth-token-max-ttl-minutes
 身份验证令牌的最大生存时间 (TTL)（单位：分钟）。如果用户尝试创建一个 TTL 大于 `auth-token-max-ttl-minutes` 的令牌，Rancher 会将令牌 TTL 设置为 `auth-token-max-ttl-minutes` 的值。身份验证令牌是为验证 API 请求而创建的。
 **2.6.6 版本更改：适用于所有 kubeconfig 令牌和 API 令牌。**

-#### kubeconfig-generate-token
-如果设置为 true，则通过 UI 请求的 kubeconfig 将包含一个有效的令牌。如果设置为 false，kubeconfig 将包含一个使用 Rancher CLI 提示用户登录的命令。然后，[CLI 将为用户检索和缓存令牌](../cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌进行-ttl-认证)。
+### kubeconfig-generate-token
+如果设置为 true，则通过 UI 请求的 kubeconfig 将包含一个有效的令牌。如果设置为 false，kubeconfig 将包含一个使用 Rancher CLI 提示用户登录的命令。然后，[CLI 将为用户检索和缓存令牌](../reference-guides/cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌进行-ttl-认证)。
@@ -27,7 +27,7 @@ API 有自己的用户界面，你可以从 Web 浏览器访问它。这是查

 ## 认证

-API 请求必须包含认证信息。认证是通过 [API 密钥](../user-settings/api-keys.md)使用 HTTP 基本认证完成的。API 密钥可以创建新集群并通过 `/v3/clusters/` 访问多个集群。[集群和项目角色](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)会应用于这些键，并限制账号可以查看的集群和项目以及可以执行的操作。
+API 请求必须包含认证信息。认证是通过 [API 密钥](../reference-guides/user-settings/api-keys.md)使用 HTTP 基本认证完成的。API 密钥可以创建新集群并通过 `/v3/clusters/` 访问多个集群。[集群和项目角色](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)会应用于这些键，并限制账号可以查看的集群和项目以及可以执行的操作。

 默认情况下，某些集群级别的 API 令牌是使用无限期 TTL（`ttl=0`）生成的。换言之，除非你让令牌失效，否则 `ttl=0` 的 API 令牌永远不会过期。有关如何使 API 令牌失效的详细信息，请参阅 [API 令牌](api-tokens.md)。

@@ -2,11 +2,11 @@
 title: Rancher 弃用的功能
 ---

-### Rancher 的弃用策略是什么？
+## Rancher 的弃用策略是什么？

 我们在支持[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方弃用策略。

-### 在哪里可以找到 Rancher 已弃用的功能？
+## 在哪里可以找到 Rancher 已弃用的功能？

 Rancher 会在 GitHub 上的[发行说明](https://github.com/rancher/rancher/releases)中公布已弃用的功能。请参阅以下补丁版本了解已弃用的功能：

@@ -20,7 +20,6 @@ Rancher 会在 GitHub 上的[发行说明](https://github.com/rancher/rancher/re
 | [2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) | 2022 年 5 月 12 日 |
 | [2.6.6](https://github.com/rancher/rancher/releases/tag/v2.6.6) | 2022 年 6 月 30 日 |

+## 如果某个功能标记为弃用，我要怎么做？

-### 如果某个功能标记为弃用，我要怎么做？
-
-如果某个发行版将某功能标记为"Deprecated"（已弃用），该功能仍然可用并受支持，从而允许用户按照常规流程进行升级。在升级到该功能被标记为"已删除"的发行版前，用户/管理员应该计划剥离该功能。对于新部署，我们建议不要使用已弃用的功能。
+如果某个发行版将某功能标记为"Deprecated"（已弃用），该功能仍然可用并受支持，从而允许用户按照常规流程进行升级。在升级到该功能被标记为"已删除"的发行版前，用户/管理员应该计划剥离该功能。对于新部署，我们建议不要使用已弃用的功能。
@@ -6,11 +6,11 @@ title: Rancher 中已弃用的功能
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/deprecated-features"/>
 </head>

-### Rancher 的弃用策略是什么？
+## Rancher 的弃用策略是什么？

 我们已经在支持的[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方的弃用策略。

-### 在哪里可以了解 Rancher 中已弃用哪些功能？
+## 在哪里可以了解 Rancher 中已弃用哪些功能？

 Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能，请参阅以下的补丁版本：

@@ -21,6 +21,6 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/
 | [2.8.1](https://github.com/rancher/rancher/releases/tag/v2.8.1) | 2024 年 1 月 22 日 |
 | [2.8.0](https://github.com/rancher/rancher/releases/tag/v2.8.0) | 2023 年 12 月 6 日 |

-### 当一个功能被标记为弃用我可以得到什么样的预期？
+## 当一个功能被标记为弃用我可以得到什么样的预期？

 当功能被标记为“已弃用”时，它依然可用并得到支持，允许按照常规的流程进行升级。一旦升级完成，用户/管理员应开始计划在升级到标记为已移除的版本之前放弃使用已弃用的功能。对于新的部署，建议不要使用已弃用的功能。
@@ -14,19 +14,19 @@ enable_cri_dockerd: true

 如果你想使用其他容器运行时，Rancher 也提供使用 Containerd 作为默认运行时的，以边缘为中心的 K3s，和以数据中心为中心的 RKE2 Kubernetes 发行版。即使在 Kubernetes 1.24 删除了树内 Dockershim 之后，你也可以通过 Rancher 升级和管理导入的 RKE2 和 K3s Kubernetes 集群。

-### 常见问题
+## 常见问题

 <br/>

-Q. 如果要获得 Rancher 对上游 Dockershim 的支持，我需要升级 Rancher 吗？
+Q: 如果要获得 Rancher 对上游 Dockershim 的支持，我需要升级 Rancher 吗？

 对于 RKE，Dockershim 的上游支持从 Kubernetes 1.21 开始。你需要使用 Rancher 2.6 或更高版本才能获取使用 Kubernetes 1.21 的 RKE 的支持。详情请参阅我们的[支持矩阵](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/)。

 <br/>

-Q. 我目前的 RKE 使用 Kubernetes 1.20。为了避免出现不再支持 Dockershim 的情况，我是否需要尽早将 RKE 升级到 Kubernetes 1.21？
+Q: 我目前的 RKE 使用 Kubernetes 1.20。为了避免出现不再支持 Dockershim 的情况，我是否需要尽早将 RKE 升级到 Kubernetes 1.21？

-A. 在使用 Kubernetes 1.20 的 RKE 中，Dockershim 版本依然可用，而且在 Kubernetes 1.24 之前不会在上游弃用。Kubernetes 会发出弃用 Dockershim 的警告，而 Rancher 在使用 Kubernetes 1.21 的 RKE 中已经缓解了这个问题。你可以按照计划正常升级到 Kubernetes 1.21，但也应该考虑在升级到 Kubernetes 1.22 时启用外部 Dockershim。在升级到 Kubernetes 1.24 之前，你需要启用外部 Dockershim，此时现有的实现都会被删除。
+A: 在使用 Kubernetes 1.20 的 RKE 中，Dockershim 版本依然可用，而且在 Kubernetes 1.24 之前不会在上游弃用。Kubernetes 会发出弃用 Dockershim 的警告，而 Rancher 在使用 Kubernetes 1.21 的 RKE 中已经缓解了这个问题。你可以按照计划正常升级到 Kubernetes 1.21，但也应该考虑在升级到 Kubernetes 1.22 时启用外部 Dockershim。在升级到 Kubernetes 1.24 之前，你需要启用外部 Dockershim，此时现有的实现都会被删除。

 有关此移除的更多信息以及时间线，请参见 [Kubernetes Dockershim 弃用相关的常见问题](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed)。

@@ -16,7 +16,7 @@ title: 一般常见问题解答

 ## 是否可以使用 Rancher 2.x 管理 Azure Kubernetes 服务？

-是的。请参阅我们的[集群管理]((../how-to-guides/new-user-guides/manage-clusters/manage-clusters.md))指南，了解 AKS 上可用的 Rancher 功能，以及相关的 [AKS 的文档](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md)
+是的。请参阅我们的[集群管理](../how-to-guides/new-user-guides/manage-clusters/manage-clusters.md)指南，了解 AKS 上可用的 Rancher 功能，以及相关的 [AKS 的文档](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md)

 ## Rancher 是否支持 Windows？

@@ -24,7 +24,7 @@ Rancher 支持 Windows Server 1809 容器。有关如何使用 Windows Worker

 ## Rancher 是否支持 Istio？

-Rancher 支持 [Istio](../pages-for-subheaders/istio.md)。
+Rancher 支持 [Istio](../integrations-in-rancher/istio/istio.md)。

 ## Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文？

@@ -4,11 +4,11 @@ title: 安装和配置 kubectl

 `kubectl` 是一个 CLI 工具，用于运行 Kubernetes 集群相关的命令。Rancher 2.x 中的许多维护和管理任务都需要它。

-### 安装
+## 安装

 请参阅 [kubectl 安装](https://kubernetes.io/docs/tasks/tools/install-kubectl/)将 kubectl 安装到你的操作系统上。

-### 配置
+## 配置

 使用 RKE 创建 Kubernetes 集群时，RKE 会在本地目录中创建一个 `kube_config_cluster.yml`，该文件包含使用 `kubectl` 或 `helm` 等工具连接到新集群的凭证。

@@ -4,20 +4,19 @@ title: 卸载 Rancher

 本文介绍了如果你不再需要 Rancher、不想再由 Rancher 管理集群、或想删除 Rancher Server 需要怎么做。

-
-### 如果 Rancher Server 被删除，下游集群中的工作负载会怎样？
+## 如果 Rancher Server 被删除，下游集群中的工作负载会怎样？

 如果 Rancher 删除了或无法恢复，Rancher 管理的下游 Kubernetes 集群中的所有工作负载将继续正常运行。

-### 如果删除了 Rancher Server，该如何访问下游集群？
+## 如果删除了 Rancher Server，该如何访问下游集群？

 如果删除了 Rancher，访问下游集群的方式取决于集群的类型和集群的创建方式。总而言之：

 - **注册集群**：集群不受影响，你可以注册集群前的方法访问该集群。
 - **托管的 Kubernetes 集群**：如果你在 Kubernetes 云提供商（例如 EKS、GKE 或 AKS）中创建集群，你可以继续使用提供商的云凭证来管理集群。
- **RKE 集群**：要访问 [RKE 集群](../pages-for-subheaders/launch-kubernetes-with-rancher.md)，集群必须启用了[授权集群端点（authorized cluster endpoint，ACE）](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-授权集群端点)，而且你必须从 Rancher UI 下载了集群的 kubeconfig 文件。RKE 集群默认启用授权集群端点。通过使用此端点，你可以直接使用 kubectl 访问你的集群，而不用通过 Rancher Server 的[认证代理](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-认证代理)进行通信。有关配置 kubectl 以使用授权集群端点的说明，请参阅[使用 kubectl 和 kubeconfig 文件直接访问集群](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#直接使用下游集群进行身份验证)。这些集群将使用删除 Rancher 时配置的身份验证快照。
+- **RKE 集群**：要访问 [RKE 集群](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)，集群必须启用了[授权集群端点（authorized cluster endpoint，ACE）](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-授权集群端点)，而且你必须从 Rancher UI 下载了集群的 kubeconfig 文件。RKE 集群默认启用授权集群端点。通过使用此端点，你可以直接使用 kubectl 访问你的集群，而不用通过 Rancher Server 的[认证代理](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-认证代理)进行通信。有关配置 kubectl 以使用授权集群端点的说明，请参阅[使用 kubectl 和 kubeconfig 文件直接访问集群](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#直接使用下游集群进行身份验证)。这些集群将使用删除 Rancher 时配置的身份验证快照。

-### 如果我不想再使用 Rancher 了该怎么做？
+## 如果我不想再使用 Rancher 了该怎么做？

 :::note

@@ -25,7 +24,7 @@ title: 卸载 Rancher

 :::

-如果你[在 Kubernetes 集群上安装了 Rancher](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md)，你可以使用 [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) 工具删除 Rancher。
+如果你[在 Kubernetes 集群上安装了 Rancher](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)，你可以使用 [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) 工具删除 Rancher。

 在高可用 (HA) 模式下卸载 Rancher 还将删除所有 `helm-operation-*` Pod 和以下应用程序：

@@ -40,7 +39,7 @@ title: 卸载 Rancher

 移除 Rancher 不会影响导入的集群。有关其他集群类型，请参考[移除 Rancher 后访问下游集群](#如果删除了-rancher-server该如何访问下游集群)。

-### 如果我不想 Rancher 管理我的注册集群该怎么办？
+## 如果我不想 Rancher 管理我的注册集群该怎么办？

 如果你在 Rancher UI 中删除了已注册的集群，则该集群将与 Rancher 分离，集群不会发生改变，你可以使用注册集群之前的方法访问该集群。

@@ -52,7 +51,7 @@ title: 卸载 Rancher

 **结果**：注册的集群已与 Rancher 分离，并在 Rancher 外正常运行。

-### 如果我不想 Rancher 管理我的 RKE 集群或托管的 Kubernetes 集群该怎么办？
+## 如果我不想 Rancher 管理我的 RKE 集群或托管的 Kubernetes 集群该怎么办？

 目前，我们没有将这些集群从 Rancher 中分离出来的功能。在这种情况下，“分离”指的是将 Rancher 组件移除出集群，并独立于 Rancher 管理对集群的访问。

@@ -5,10 +5,10 @@ title: 安全

 **是否有强化指南？**

-强化指南现在位于[安全](../pages-for-subheaders/rancher-security.md)部分。
+强化指南现在位于[安全](../reference-guides/rancher-security/rancher-security.md)部分。

 <br/>

 **Rancher Kubernetes 集群 CIS Benchmark 测试的结果是什么？**

-我们已经针对强化的 Rancher Kubernetes 集群运行了 CIS Kubernetes Benchmark 测试。你可以在[安全](../pages-for-subheaders/rancher-security.md)中找到该评估的结果。
+我们已经针对强化的 Rancher Kubernetes 集群运行了 CIS Kubernetes Benchmark 测试。你可以在[安全](../reference-guides/rancher-security/rancher-security.md)中找到该评估的结果。
--- a/Show More
+++ b/Show More