Merge pull request #1445 from rancher/release/v2.9

Merge release/v2.9 into main
Merge pull request #1447 from sunilarjun/v2.9.1-impersonation
2026-09-29 14:38:50 +00:00 · 2024-08-26 13:25:37 -07:00 · 2024-08-26 12:41:04 -07:00 · 2024-08-26 11:32:52 -07:00 · 2024-08-26 11:29:54 -07:00 · 2024-08-26 10:56:17 -07:00
400 changed files with 3728 additions and 3025 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:
+    paths-ignore:
-      - main
+      - '**/README.md'
 jobs:
  test-deploy:
@@ -5,7 +5,10 @@
 # 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]
+on:
  pull_request:
    paths-ignore:
      - '**/README.md'
 jobs:
  vale-lint:
@@ -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>
@@ -1,9 +0,0 @@
 ---
 title: RKE Cluster Configuration
 ---
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration"/>
 </head>
 This page has moved [here.](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)
@@ -16,12 +16,8 @@ Rancher will publish deprecated features as part of the [release notes](https://
 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) | June 17, 2024 |
+| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 |
-| [2.8.4](https://github.com/rancher/rancher/releases/tag/v2.8.4) | May 16, 2024  |
+| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 |
 | [2.8.3](https://github.com/rancher/rancher/releases/tag/v2.8.3) | Mar 28, 2024  |
 | [2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2) | Feb 8, 2024   |
 | [2.8.1](https://github.com/rancher/rancher/releases/tag/v2.8.1) | Jan 22, 2024  |
 | [2.8.0](https://github.com/rancher/rancher/releases/tag/v2.8.0) | Dec 6, 2023   |
 ### What can I expect when a feature is marked for deprecation?
@@ -107,15 +107,15 @@ The Rancher management server is designed to be secure by default and requires S
 :::note
-If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer](../installation-references/helm-chart-options.md#external-tls-termination).
+If you want to externally terminate SSL/TLS, see [TLS termination on an External Load Balancer](../installation-references/helm-chart-options.md#external-tls-termination). As outlined on that page, this option does have additional requirements for TLS verification.
 :::
 There are three recommended options for the source of the certificate used for TLS termination at the Rancher server:
- **Rancher-generated TLS certificate:** In this case, you will need to install `cert-manager` into the cluster. Rancher utilizes `cert-manager` to issue and maintain its certificates. Rancher will generate a CA certificate of its own, and sign a cert using that CA. `cert-manager` is then responsible for managing that certificate.
+- **Rancher-generated TLS certificate:** In this case, you will need to install `cert-manager` into the cluster. Rancher utilizes `cert-manager` to issue and maintain its certificates. Rancher will generate a CA certificate of its own, and sign a cert using that CA. `cert-manager` is then responsible for managing that certificate. No extra action is needed when `agent-tls-mode` is set to strict. More information can be found on this setting in [Agent TLS Enforcement](../installation-references/tls-settings.md#agent-tls-enforcement).
- **Let's Encrypt:** The Let's Encrypt option also uses `cert-manager`. However, in this case, cert-manager is combined with a special Issuer for Let's Encrypt that performs all actions (including request and validation) necessary for getting a Let's Encrypt issued cert. This configuration uses HTTP validation (`HTTP-01`), so the load balancer must have a public DNS record and be accessible from the internet.
+- **Let's Encrypt:** The Let's Encrypt option also uses `cert-manager`. However, in this case, cert-manager is combined with a special Issuer for Let's Encrypt that performs all actions (including request and validation) necessary for getting a Let's Encrypt issued cert. This configuration uses HTTP validation (`HTTP-01`), so the load balancer must have a public DNS record and be accessible from the internet. When setting `agent-tls-mode` to `strict`, you must also specify `--privateCA=true` and upload the Let's Encrypt CA as described in [Adding TLS Secrets](../resources/add-tls-secrets.md). More information can be found on this setting in [Agent TLS Enforcement](../installation-references/tls-settings.md#agent-tls-enforcement).
- **Bring your own certificate:** This option allows you to bring your own public- or private-CA signed certificate. Rancher will use that certificate to secure websocket and HTTPS traffic. In this case, you must upload this certificate (and associated key) as PEM-encoded files with the name `tls.crt` and `tls.key`. If you are using a private CA, you must also upload that certificate. This is due to the fact that this private CA may not be trusted by your nodes. Rancher will take that CA certificate, and generate a checksum from it, which the various Rancher components will use to validate their connection to Rancher.
+- **Bring your own certificate:** This option allows you to bring your own public- or private-CA signed certificate. Rancher will use that certificate to secure websocket and HTTPS traffic. In this case, you must upload this certificate (and associated key) as PEM-encoded files with the name `tls.crt` and `tls.key`. If you are using a private CA, you must also upload that certificate. This is due to the fact that this private CA may not be trusted by your nodes. Rancher will take that CA certificate, and generate a checksum from it, which the various Rancher components will use to validate their connection to Rancher. If `agent-tls-mode` is set to `strict`, the CA must be uploaded, so that downstream clusters can successfully connect. More information can be found on this setting in [Agent TLS Enforcement](../installation-references/tls-settings.md#agent-tls-enforcement).
 | Configuration                  | Helm Chart Option           | Requires cert-manager                 |
@@ -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:
@@ -242,6 +242,12 @@ In the following command,
 - Set `letsEncrypt.ingress.class` to whatever your ingress controller is, e.g., `traefik`, `nginx`, `haproxy`, etc.
 - 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.
 :::warning
 When `agent-tls-mode` is set to `strict` (the default value for new installs of Rancher starting from v2.9.0), you must supply the `privateCA=true` chart value (e.x. through `--set privateCA=true`) and upload the Let's Encrypt Certificate Authority as outlined in [Adding TLS Secrets](../resources/add-tls-secrets.md). Information on identifying the Let's Encrypt Root CA can be found in the Let's Encrypt [docs](https://letsencrypt.org/certificates/). If you don't upload the CA, then Rancher may fail to connect to new or existing downstream clusters.
 :::
 ```
 helm install rancher rancher-<CHART_REPO>/rancher \
  --namespace cattle-system \
@@ -190,3 +190,19 @@ If you want to use encrypted private keys, you should use `ssh-agent` to load yo
 ### Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
 The node is not reachable on the configured `address` and `port`.
 ### Agent reports TLS errors 
 When using Rancher, you may encounter error messages from the `fleet-agent`, `system-agent`, or `cluster-agent`, such as the message below:
 ```
 tls: failed to verify certificate: x509: failed to load system roots and no roots provided; readdirent /dev/null: not a directory
 ```
 This occurs when Rancher was configured with `agent-tls-mode` set to `strict`, but couldn't find cacerts in the `cacert` setting. To resolve the issue, set the `agent-tls-mode` to `system-store`, or upload the CA for Rancher as described in [Adding TLS Secrets](../resources/add-tls-secrets.md).
 ### New Cluster Deployment is stuck in "Waiting for Agent to check in"
 When Rancher has `agent-tls-mode` set to `strict`, new clusters may fail to provision and report a generic "Waiting for Agent to check in" error message. The root cause of this is similar to the above case of TLS errors - Rancher's agent can't determine which CA Rancher is using (or can't verify that Rancher's cert is actually signed by the specified certificate authority).  
 To resolve the issue, set the `agent-tls-mode` to `system-store` or upload the CA for Rancher as described in [Adding TLS Secrets](../resources/add-tls-secrets.md).
@@ -19,7 +19,6 @@ Some feature flags require a restart of the Rancher container. Features that req
 The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)):
 - `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
 - `external-rules`: This flag is enabled by default. Only admin users can enable/disable the flag, and note that `escalate` permissions on `RoleTemplates` are required to create external `RoleTemplates` with `ExternalRules`. Restricted admin users can only enable the flag. If enabled, external `RoleTemplates` can be created only if the backing `ClusterRole` exists in the local cluster or the `ExternalRules` is set. For context, the backing `ClusterRole` holds cluster rules and privileges, and shares the same `metadata.name` used in the `RoleTemplate` in your respective cluster referenced by the `ClusterRoleTemplateBinding/ProjectRoleTemplateBinding`. Previous external `RoleTemplates` that don’t have a backing `ClusterRole` won’t be granted or modifiable unless a backing `ClusterRole` is created or the `ExternalRules` field is set. If disabled, external `RoleTemplates` with `.context=project` or `.context=””` can be created even if the backing `ClusterRole` does not exist.
 - `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) for more information.
 - `harvester`: Manages access to the Virtualization Management page, where users can navigate directly to Harvester clusters and access the Harvester UI. See [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md) for more information.
 - `istio-virtual-service-ui`: Enables a [visual interface](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md) to create, read, update, and delete Istio virtual services and destination rules, which are Istio traffic management features.
@@ -28,17 +27,23 @@ The following is a list of feature flags available in Rancher. If you've upgrade
 - `rke1-custom-node-cleanup`: Enables cleanup of deleted RKE1 custom nodes. We recommend that you keep this flag enabled, to prevent removed nodes from attempting to rejoin the cluster.
 - `rke2`: Enables provisioning RKE2 clusters. This flag is enabled by default.
 - `token-hashing`: Enables token hashing. Once enabled, existing tokens will be hashed and all new tokens will be hashed automatically with the SHA256 algorithm. Once a token is hashed it can't be undone. This flag can't be disabled after its enabled. See [API Tokens](../../../api/api-tokens.md#token-hashing) for more information.
 - `uiextension`: Enables UI extensions. This flag is enabled by default. Enabling or disabling the flag forces the Rancher pod to restart. The first time this flag is set to `true`, it creates a CRD and enables the controllers and endpoints necessary for the feature to work. If set to `false`, it disables the previously mentioned controllers and endpoints. Setting `uiextension` to `false` has no effect on the CRD -- it does not create a CRD if it does not yet exist, nor does it delete the CRD if it already exists. 
 - `unsupported-storage-drivers`: Enables types for storage providers and provisioners that aren't enabled by default. See [Allow Unsupported Storage Drivers](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md) for more information.
 - `ui-sql-cache`: Enables a SQLite-based cache for UI tables. See [UI Server-Side Pagination](../../../how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination.md) for more information.
 The following table shows the availability and default values for some feature flags in Rancher. Features marked "GA" are generally available:
-| Feature Flag Name             | Default Value | Status       | Available As Of |
+| Feature Flag Name             | Default Value | Status       | Available As Of | Additional Information |
-| ----------------------------- | ------------- | ------------ | --------------- |
+| ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
-| `continuous-delivery` | `true` | GA | v2.6.0 |
+| `continuous-delivery` | `true` | GA | v2.6.0 | |
-| `fleet`  | `true` | Can no longer be disabled | v2.6.0 |
+| `external-rules` | v2.7.14: `false`, v2.8.5: `true` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
-| `fleet`  | `true` | GA | v2.5.0 |
+| `fleet`  | `true` | Can no longer be disabled | v2.6.0 | |
-| `harvester` | `true` | Experimental | v2.6.1 |
+| `fleet`  | `true` | GA | v2.5.0 | |
-| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 |
+| `harvester` | `true` | Experimental | v2.6.1 | |
-| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 |
+| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
-| `rke2` | `true` | Experimental | v2.6.0 |
+| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 | |
-| `token-hashing` | `false` for new installs, `true` for upgrades | GA | v2.6.0 |
+| `rke2` | `true` | Experimental | v2.6.0 | |
 | `token-hashing` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
 | `uiextension` | `true` | GA | v2.9.0 |
 | `ui-sql-cache` | `false` | Highly experimental | v2.9.0 |
@@ -32,6 +32,7 @@ For information on enabling experimental features, refer to [this page.](../../.
 | ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `additionalTrustedCAs`         | false                                                 | `bool` - See [Additional Trusted CAs](#additional-trusted-cas)                                                                                    |
 | `addLocal`                     | "true"                                                | `string` - Have Rancher detect and import the "local" (upstream) Rancher server cluster.  _Note: This option is no longer available in v2.5.0. Consider using the `restrictedAdmin` option to prevent users from modifying the local cluster._              |
 | `agentTLSMode`                 | ""                                                    | `string` - either `system-store` or `strict`. See [Agent TLS Enforcement](./tls-settings.md#agent-tls-enforcement) |
 | `antiAffinity`                 | "preferred"                                           | `string` - AntiAffinity rule for Rancher pods - "preferred, required"                                                                             |
 | `auditLog.destination`         | "sidecar"                                             | `string` - Stream to sidecar container console or hostPath volume - "sidecar, hostPath"                                                           |
 | `auditLog.hostPath`            | "/var/log/rancher/audit"                              | `string` - log file destination on host (only applies when `auditLog.destination` is set to `hostPath`)                                           |
@@ -206,7 +207,7 @@ You may terminate the SSL/TLS on a L7 load balancer external to the Rancher clus
 :::note
-If you are using a Private CA signed certificate, add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate](../../../getting-started/installation-and-upgrade/resources/add-tls-secrets.md) to add the CA cert for Rancher.
+If you are using a Private CA signed certificate (or if `agent-tls-mode` is set to `strict`), add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate](../../../getting-started/installation-and-upgrade/resources/add-tls-secrets.md) to add the CA cert for Rancher. 
 :::
@@ -23,3 +23,82 @@ The default TLS configuration only accepts TLS 1.2 and secure TLS cipher suites.
 |-----|-----|-----|-----|
 | `CATTLE_TLS_MIN_VERSION` | Minimum TLS version | `1.2` | `1.0`, `1.1`, `1.2`, `1.3` |
 | `CATTLE_TLS_CIPHERS` | Allowed TLS cipher suites | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`,<br/>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | See [Golang tls constants](https://golang.org/pkg/crypto/tls/#pkg-constants) |
 ## Agent TLS Enforcement
 The `agent-tls-mode` setting controls how Rancher's agents (`cluster-agent`, `fleet-agent`, and `system-agent`) validate Rancher's certificate.
 When the value is set to `strict`, Rancher's agents only trust certificates generated by the Certificate Authority contained in the `cacerts` setting. 
 When the value is set to `system-store`, Rancher's agents trust any certificate generated by a public Certificate Authority contained in the operating system's trust store including those signed by authorities such as Let's Encrypt. This can be a security risk, since any certificate generated by these external authorities, which are outside the user's control, are considered valid in this state.
 While the `strict` option enables a higher level of security, it requires Rancher to have access to the CA which generated the certificate visible to the agents. In the case of certain certificate configurations (notably, external certificates), this is not automatic, and extra configuration is needed. See the [installation guide](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md#3-choose-your-ssl-configuration) for more information on which scenarios require extra configuration.
 In Rancher v2.9.0 and later, this setting defaults to `strict` on new installs. For users installing or upgrading from a prior Rancher version, it is set to `system-store`.
 ### Preparing for the Setting Change
 Each cluster contains a condition in the status field called `AgentTlsStrictCheck`. If `AgentTlsStrictCheck` is set to `"True"`, this indicates that the agents for the cluster are ready to operate in `strict` mode. You can manually inspect each cluster to see if they are ready using the Rancher UI or a kubectl command such as the following:
 ```bash
 ## the below command skips ouputs $CLUSTER_NAME,$STATUS for all non-local clusters
 kubectl get cluster.management.cattle.io -o jsonpath='{range .items[?(@.metadata.name!="local")]}{.metadata.name},{.status.conditions[?(@.type=="AgentTlsStrictCheck")].status}{"\n"}{end}'
 ```
 ### Changing the Setting
 You can change the setting using the Rancher UI or the `agentTLSMode` [helm chart option](./helm-chart-options.md).
 :::note
 If you specify the value through the Helm chart, you may only modify the value with Helm.
 :::
 :::warning
 Depending on your cert setup, additional action may be required, such as uploading the Certificate Authority which signed your certs. Review the [installation guide](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md#3-choose-your-ssl-configuration) before changing the setting to see if any additional requirements apply to your setup.
 :::
 To change the setting's value through the UI, navigate to the **Global Settings** page, and find the `agent-tls-mode` setting near the bottom of the page. When you change the setting through the UI, Rancher first checks that all downstream clusters have the condition `AgentTlsStrictCheck` set to `"True"` before allowing the request. This prevents outages from a certificate mismatch.
 #### Overriding the Setting Validation Checks
 In some cases, you may want to override the check ensuring all agents can accept the new TLS configuration:
 :::warning
 Rancher checks the status of all downstream clusters to prevent outages. Overriding this check is not recommended, and should be done with great caution.
 :::
 1. As an admin, generate a kubeconfig for the local cluster. In the below examples, this was saved to the `local_kubeconfig.yaml` file.
 2. Retrieve the current setting and save it to `setting.yaml`:
 ```bash
 kubectl get setting agent-tls-mode -o yaml --kubeconfig=local_kubeconfig.yaml > setting.yaml
 ```
 3. Update the `setting.yaml` file, replacing `value` with `strict`. Adding the `cattle.io/force: "true"` annotation overrides the cluster condition check, and should only be done with great care:
 :::warning
 Including the `cattle.io/force` annotation with any value (including, for example `"false"`) overrides the cluster condition check.
 :::
 ```yaml
 apiVersion: management.cattle.io/v3
 customized: false
 default: strict
 kind: Setting
 metadata:
  name: agent-tls-mode
  annotations:
    cattle.io/force: "true"
 source: ""
 value: strict
 ```
 4. Apply the new version of the setting:
 ```bash
 kubectl apply -f setting.yaml --kubeconfig=local_kubeconfig.yaml
 ```
@@ -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/>
@@ -216,6 +216,14 @@ Each node used should have a static IP configured, regardless of whether you are
 To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes. [Port Requirements](port-requirements.md) lists all the necessary ports for Rancher and Downstream Clusters for the different cluster types.
 ### Load Balancer Requirements
 If you use a load balancer, it should be be HTTP/2 compatible. 
 To receive help from SUSE Support, Rancher Prime customers who use load balancers (or any other middleboxes such as firewalls), must use one that is HTTP/2 compatible.
 When HTTP/2 is not available, Rancher falls back to HTTP/1.1. However, since HTTP/2 offers improved web application performance, using HTTP/1.1 can create performance issues. 
 ## Dockershim Support
 For more information on Dockershim support, refer to [this page](dockershim.md).
@@ -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
 ```
@@ -109,7 +109,7 @@ Rancher Server is distributed as a Docker image, which have tags attached to the
 | -------------------------- | ------ |
 | `rancher/rancher:latest`   | Our latest development release. These builds are validated through our CI automation framework. These releases are not recommended for production environments. |
 | `rancher/rancher:stable`   | Our newest stable release. This tag is recommended for production.                                                                                              |
-| `rancher/rancher:<v2.X.X>` | You can install specific versions of Rancher by using the tag from a previous release. See what's available at DockerHub.                                       |
+| `rancher/rancher:<v2.X.X>` | You can install specific versions of Rancher by using the tag from a previous release. See what's available at Docker Hub.                                       |
 :::note
@@ -102,8 +102,6 @@ There is a [known issue](https://github.com/rancher/rancher/issues/25478) in whi
 ### Maintaining Availability for Applications During Upgrades
 _Available as of RKE v1.1.0_
 In [this section of the RKE documentation,](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability/) you'll learn the requirements to prevent downtime for your applications when upgrading the cluster.
 ### Configuring the Upgrade Strategy in the cluster.yml
@@ -0,0 +1,41 @@
 ---
 title: UI Server-Side Pagination
 ---
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination"/>
 </head>
 :::caution
 UI server-side pagination is not intended for use in production at this time. This feature is considered highly experimental. SUSE customers should consult SUSE Support before activating this feature.
 :::
 UI server-side pagination caching provides an optional SQLite-backed cache of Kubernetes objects to improve performance. This unlocks sorting, filtering and pagination features used by the UI to restrict the amount of resources it fetches and stores in browser memory. These features are primarily used to improve list performance for resources with high counts.
 This feature creates file system based caches in the `rancher` pods of the upstream cluster, and in the `cattle-cluster-agent` pods of the downstream clusters. In most environments, disk usage and I/O should not be significant. However, you should monitor activity after you enable caching.
 SQLite-backed caching persists copies of any cached Kubernetes objects to disk. See [Encrypting SQLite-backed Caching](#encrypting-sqlite-backed-caches) if this is a security concern.
 ## Enabling UI Server-Side Pagination
 1. In the upper left corner, click **☰ > Global Settings > Feature Flags**.
 1. Find **`ui-sql-cache`** and select **⋮ > Activate > Activate**.
 1. Wait for Rancher to restart. This also restarts agents on all downstream clusters.
 1. In the upper left corner, click **☰ > Global Settings > Performance**.
 1. Go to **Server-side Pagination** and check the **Enable Server-side Pagination** option.
 1. Click **Apply**.
 1. Reload the page with the browser button (or the equivalent keyboard combination, typically `CTRL + R` on Windows and Linux, and `⌘ + R` on macOS).
 ## Encrypting SQLite-backed Caches
 UI server-side pagination persists copies of any cached Kubernetes objects to disk. If you're concerned about the safety of this data, you can encrypt all objects before they are persisted to disk, by setting the environment variable `CATTLE_ENCRYPT_CACHE_ALL` to `true` in `rancher` pods in the upstream cluster and `cattle-cluster-agent` pods in the downstream clusters.
 Secrets and security Tokens are always encrypted regardless of the above setting.
 ## Known Limitations of UI Server-Side Pagination
 This initial release improves the performance of Pods, Secrets, Nodes and ConfigMaps in the Cluster Explorer pages, and most resources in the Explorer's **More Resources** section.
 Pages can't be automatically refreshed. You can manually refresh table contents by clicking the **Refresh** button.
@@ -6,19 +6,21 @@ title: Generate and View Traffic from Istio
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/generate-and-view-traffic"/>
 </head>
 This section describes how to view the traffic that is being managed by Istio.
 ## The Kiali Traffic Graph
-The Istio overview page provides a link to the Kiali dashboard. From the Kiali dashboard, you are able to view graphs for each namespace. The Kiali graph provides a powerful way to visualize the topology of your Istio service mesh. It shows you which services communicate with each other.
+The Istio overview page provides a link to the Kiali dashboard. From the Kiali dashboard, you can view graphs for each namespace. The Kiali graph provides a powerful way to visualize the topology of your Istio service mesh. It shows you which services communicate with each other.
-:::note Prerequisites:
+## Prerequisites
-To enable traffic to show up in the graph, ensure you have prometheus installed in the cluster. Rancher-istio installs Kiali configured by default to work with the rancher-monitoring chart. You can use rancher-monitoring or install your own monitoring solution. Optional: you can change configuration on how data scraping occurs by setting the [Selectors & Scrape Configs](../../../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md) options.
+To enable traffic to show up in the graph, ensure that you have Prometheus installed in the cluster. `Rancher-istio` installs Kiali, and configures it by default to work with the `rancher-monitoring` chart. You can use `rancher-monitoring` or install your own monitoring solution.
-:::
+Additionally, for Istio installations version `103.1.0+up1.19.6` and later, Kiali uses a token value for its authentication strategy. If you are trying to generate or retrieve the token (e.g. for login), note that the name of the Kiali service account in Rancher is `kiali`. For more information, refer to the [Kiali token authentication FAQ](https://kiali.io/docs/faq/authentication/).
-To see the traffic graph,
+Optional: You can configure which namespaces data scraping occurs in by setting the Helm chart options described in [Selectors & Scrape Configs](../../../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md).
 ## Traffic Visualization
 To see the traffic graph follow the steps below:
 1. In the cluster where Istio is installed, click **Istio** in the left navigation bar.
 1. Click the **Kiali** link.
@@ -111,7 +111,7 @@ Profiling data (such as advanced memory or CPU analysis) is not present as it is
 To enable the Rancher Performance Dashboard:
-<Tabs groupid="UIorCLI">
+<Tabs groupId="UIorCLI">
 <TabItem value="Helm">
 Use the following options with the Helm CLI:
@@ -8,7 +8,7 @@ title: Tuning etcd for Large Installations
 When Rancher is used to manage [a large infrastructure](../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md) it is recommended to increase the default keyspace for etcd from the default 2 GB. The maximum setting is 8 GB and the host should have enough RAM to keep the entire dataset in memory. When increasing this value you should also increase the size of the host. The keyspace size can also be adjusted in smaller installations if you anticipate a high rate of change of pods during the garbage collection interval.
-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.4.0/op-guide/maintenance/#space-quota) setting on the etcd servers.
+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
@@ -23,7 +23,7 @@ services:
 ## Scaling etcd disk performance
-You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.4.0/tuning/#disk) on how to tune the disk priority on the host.
+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.
 Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use striping RAID configurations to increase available IOPS.
@@ -21,20 +21,21 @@ The account used to enable the external provider will be granted admin permissio
 The Rancher authentication proxy integrates with the following external authentication services.
-| Auth Service                                                                                     |
+| Auth Service                                                                                                           |
-| ------------------------------------------------------------------------------------------------ |
+|------------------------------------------------------------------------------------------------------------------------|
-| [Microsoft Active Directory](configure-active-directory.md)  |
+| [Microsoft Active Directory](configure-active-directory.md)                                                            |
-| [GitHub](configure-github.md)                  |
+| [GitHub](configure-github.md)                                                                                          |
-| [Microsoft Azure AD](configure-azure-ad.md)    |
+| [Microsoft Azure AD](configure-azure-ad.md)                                                                            |
-| [FreeIPA](configure-freeipa.md)                |
+| [FreeIPA](configure-freeipa.md)                                                                                        |
-| [OpenLDAP](../configure-openldap/configure-openldap.md)              |
+| [OpenLDAP](../configure-openldap/configure-openldap.md)                                                                |
 | [Microsoft AD FS](../configure-microsoft-ad-federation-service-saml/configure-microsoft-ad-federation-service-saml.md) |
-| [PingIdentity](configure-pingidentity.md)     |
+| [PingIdentity](configure-pingidentity.md)                                                                              |
-| [Keycloak (OIDC)](configure-keycloak-oidc.md)  |
+| [Keycloak (OIDC)](configure-keycloak-oidc.md)                                                                          |
-| [Keycloak (SAML)](configure-keycloak-saml.md)  |
+| [Keycloak (SAML)](configure-keycloak-saml.md)                                                                          |
-| [Okta](configure-okta-saml.md)                      |
+| [Okta](configure-okta-saml.md)                                                                                         |
-| [Google OAuth](configure-google-oauth.md)            |
+| [Google OAuth](configure-google-oauth.md)                                                                              |
-| [Shibboleth](../configure-shibboleth-saml/configure-shibboleth-saml.md)           |
+| [Shibboleth](../configure-shibboleth-saml/configure-shibboleth-saml.md)                                                |
 | [Generic (OIDC)](configure-generic-oidc.md)                                                                            |
 However, Rancher also provides [local authentication](create-local-users.md).
@@ -62,6 +63,12 @@ After you configure Rancher to allow sign on using an external authentication se
 | Allow members of Clusters, Projects, plus Authorized Users and Organizations | Any user in the authorization service and any group added as a **Cluster Member** or **Project Member** can log in to Rancher. Additionally, any user in the authentication service or group you add to the **Authorized Users and Organizations** list may log in to Rancher. |
 | Restrict access to only Authorized Users and Organizations | Only users in the authentication service or groups added to the Authorized Users and Organizations can log in to Rancher. |
 :::warning 
 Only trusted admin-level users should have access to the local cluster, which manages all of the other clusters in a Rancher instance. Rancher is directly installed on the local cluster, and Rancher's management features allow admins on the local cluster to provision, modify, connect to, and view details about downstream clusters. Since the local cluster is key to a Rancher instance's architecture, inappropriate access carries security risks.
 :::
 To set the Rancher access level for users in the authorization service, follow these steps:
 1. In the upper left corner, click **☰ > Users & Authentication**.
@@ -133,7 +133,17 @@ Here are a few examples of permission combinations that satisfy Rancher's needs:
 :::
-#### 4. Copy Azure Application Data
+#### 4. Allow Public Client Flows
 To login from Rancher CLI you must allow public client flows:
 1. From the left navigation menu, select **Authentication**.
 1. Under **Advanced Settings**, select **Yes** on the toggle next to **Allow public client flows**.
    ![Allow Public Client Flows](/img/azure-public-client-flows.png)
 #### 5. Copy Azure Application Data
 ![Application ID](/img/app-configuration.png)
@@ -167,7 +177,7 @@ Custom Endpoints are not tested or fully supported by Rancher.
 You'll also need to manually enter the Graph, Token, and Auth Endpoints.
- From <b>App registrations</b>, click <b>Endpoints</b>:
+- From **App registrations**, click **Endpoints**:
 ![Click Endpoints](/img/endpoints.png)
@@ -176,7 +186,7 @@ You'll also need to manually enter the Graph, Token, and Auth Endpoints.
  - **OAuth 2.0 token endpoint (v1)** (Token Endpoint)
  - **OAuth 2.0 authorization endpoint (v1)** (Auth Endpoint)
-#### 5. Configure Azure AD in Rancher
+#### 6. Configure Azure AD in Rancher
 To complete configuration, enter information about your AD instance in the Rancher UI.
@@ -188,7 +198,7 @@ To complete configuration, enter information about your AD instance in the Ranch
 1. Click **AzureAD**.
-1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#4-copy-azure-application-data).
+1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#5-copy-azure-application-data).
    :::caution
@@ -221,6 +231,8 @@ To complete configuration, enter information about your AD instance in the Ranch
    <code>http<span>s://g</span>raph.microsoft.com<del>/abb5adde-bee8-4821-8b03-e63efdc7701c</del></code>
 1. (Optional) In Rancher v2.9.0 and later, you can filter users' group memberships in Azure AD to reduce the amount of log data generated. See steps 4–5 of [Filtering Users by Azure AD Auth Group Memberships](#filtering-users-by-azure-ad-auth-group-memberships) for full instructions.
 1. Click **Enable**.
 **Result:** Azure Active Directory authentication is configured.
@@ -314,6 +326,29 @@ Endpoint         | https://login.partner.microsoftonline.cn/
 Graph Endpoint   | https://microsoftgraph.chinacloudapi.cn
 Token Endpoint   | https://login.partner.microsoftonline.cn/{tenantID}/oauth2/v2.0/token
 ## Filtering Users by Azure AD Auth Group Memberships
 In Rancher v2.9.0 and later, you can filter users' group memberships from Azure AD to reduce the amount of log data generated. If you did not filter group memberships during initial setup, you can still add filters on an existing Azure AD configuration.
 :::warning
 Filtering out a user group membership affects more than just logging. 
 Since the filter prevents Rancher from seeing that the user belongs to an excluded group, it also does not see any permissions from that group. This means that excluding a group from the filter can have the side effect of denying users permissions they should have.
 :::
 1. In Rancher, in the top left corner, click **☰ > Users & Authentication**.
 1. In the left navigation menu, click **Auth Provider**.
 1. Click **AzureAD**.
 1. Click the checkbox next to **Limit users by group membership**.
 1. Enter an [OData filter clause](https://learn.microsoft.com/en-us/odata/concepts/queryoptions-overview#filter) into the **Group Membership Filter** field. For example, if you want to limit logging to group memberships whose name starts with `test`, click the checkbox and enter `startswith(displayName,'test')`.
 ![Adding a group membership filter to Azure AD](/img/auth-setup-azure-ad-filter.png)
 ## Deprecated Azure AD Graph API
@@ -328,4 +363,3 @@ Token Endpoint   | https://login.partner.microsoftonline.cn/{tenantID}/oauth2/v2
 >- If you don't wish to upgrade to v2.7.0+ after the Azure AD Graph API is retired, you'll need to either:
    - Use the built-in Rancher auth or
    - Use another third-party auth system and set that up in Rancher. Please see the [authentication docs](authentication-config.md) to learn how to configure other open authentication providers.
@@ -0,0 +1,110 @@
 ---
 title: Configure Generic OIDC
 description: Create an OpenID Connect (OIDC) client and configure Rancher to work with your authentication provider. Your users can then sign into Rancher using their login from the authentication provider.
 ---
 <head> 
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-generic-oidc"/>
 </head>
 If your organization uses an OIDC provider for user authentication, you can configure Rancher to allow login using Identity Provider (IdP) credentials. Rancher supports integration with the OpenID Connect (OIDC) protocol and the SAML protocol. Both implementations are functionally equivalent when used with Rancher. The following instructions describe how to configure Rancher to work using the OIDC protocol.
 ## Prerequisites
 - In Rancher:
  - Generic OIDC is disabled.
 :::note
 Consult the documentation for your specific IdP to complete the listed prerequisites.
 :::
 - In your IdP:
  - Create a new client with the settings below:
    Setting | Value
    ------------|------------
    `Client ID` | <CLIENT_ID> (e.g. `rancher`)
    `Name` | <CLIENT_NAME> (e.g. `rancher`)
    `Client Protocol` | `openid-connect`
    `Access Type` | `confidential`
    `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth`
  - In the new OIDC client, create mappers to expose the users fields.
    - Create a new Groups Mapper with the settings below:
      Setting | Value
      ------------|------------
      `Name` | `Groups Mapper`
      `Mapper Type` | `Group Membership`
      `Token Claim Name` | `groups`
      `Add to ID token` | `OFF`
      `Add to access token` | `OFF`
      `Add to user info` | `ON`
    - Create a new Client Audience with the settings below:
      Setting | Value
      ------------|------------
      `Name` | `Client Audience`
      `Mapper Type` | `Audience`
      `Included Client Audience` | <CLIENT_NAME>
      `Add to access token` | `ON`
    - Create a new "Groups Path" with the settings below.
      Setting | Value
      ------------|------------
      `Name` | `Group Path`
      `Mapper Type` | `Group Membership`
      `Token Claim Name` | `full_group_path`
      `Full group path` | `ON`
      `Add to user info` | `ON`
 - Important:  Rancher will use the value received in the "sub" claim to form the PrincipalID which is the unique identifier in Rancher.  It is important to make this a value that will be unique and immutable.
 ## Configuring Generic OIDC in Rancher
 1. In the upper left corner of the Rancher UI, click **☰ > Users & Authentication**.
 1. In the left navigation bar, click **Auth Provider**.
 1. Select **Generic OIDC**.
 1. Complete the **Configure an OIDC account** form. For help with filling the form, see the [configuration reference](#configuration-reference).
 1. Click **Enable**.
   Rancher will redirect you to the IdP login page. Enter your IdP credentials to validate your Rancher Keycloak configuration.
   :::note
   You may need to disable your popup blocker to see the IdP login page.
   :::
 **Result:** Rancher is configured to work with your provider using the OIDC protocol. Your users can now sign into Rancher using their IdP logins.
 ## Configuration Reference
 | Field                     | Description                                                                                                                                        |
 | ------------------------- |----------------------------------------------------------------------------------------------------------------------------------------------------|
 | Client ID                 | The Client ID of your OIDC client.                                                                                                               |
 | Client Secret             | The generated Secret of your OIDC client.                                                                                                        |
 | Private Key/Certificate | A key/certificate pair to create a secure shell between Rancher and your IdP. Required if HTTPS/SSL is enabled on your OIDC server.                |
 | Endpoints                 | Choose whether to use the generated values for the Rancher URL, Issue, and Auth Endpoint fields or to provide manual overrides if incorrect. |
 | Rancher URL               | The URL for your Rancher Server.                                                                                                                   |
 | Issuer                    | The URL of your IdP.  If your provider has discovery enabled, Rancher uses the Issuer URL to fetch all of the required URLs.                   |
 | Auth Endpoint             | The URL where users are redirected to authenticate.                                                                                                |
 ## Troubleshooting
 If you are experiencing issues while testing the connection to the OIDC server, first double-check the configuration options of your OIDC client. You can also inspect the Rancher logs to help pinpoint what's causing issues. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
 All Generic OIDC related log entries are prepended with either `[generic oidc]` or `[oidc]`.
 ### You are not redirected to your authentication provider
 If you fill out the **Configure a Generic OIDC account** form and click on **Enable**, and you are not redirected to your IdP, verify your OIDC client configuration.
 ### The generated `Issuer` and `Auth Endpoint` are incorrect
 If the `Issuer` and `Auth Endpoint` are generated incorrectly, open the **Configure an OIDC account** form, change **Endpoints** to `Specify (advanced)` and override the `Issuer` value.
 ### Error: "Invalid grant_type"
 In some cases, the "Invalid grant_type" error message may be misleading and is actually caused by setting the `Valid Redirect URI` incorrectly.
@@ -23,7 +23,7 @@ This option replaces "Rancher" with the value you provide in most places. Files
 ### Support Links
-Use a url address to send new "File an Issue" reports instead of sending users to the Github issues page. Optionally show Rancher community support links.
+Use a url address to send new "File an Issue" reports instead of sending users to the GitHub issues page. Optionally show Rancher community support links.
 ### Logo
@@ -0,0 +1,17 @@
 ---
 title: JSON Web Token (JWT) Authentication
 ---
 <head> 
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/jwt-authentication"/>
 </head>
 Many 3rd party integrations available for Kubernetes, such as GitLab and HashiCorp Vault, involve giving an external process access to the Kubernetes API using a native Kubernetes Service Account token for authentication.
 In Rancher v2.9.0 and later, service accounts on downstream clusters can now authenticate through a JSON web token (JWT) using the Rancher authentication proxy. In Rancher versions earlier than  v2.9.0, only Rancher-issued tokens were supported.
 To enable this feature, follow these steps:
 1. In the upper left corner, click **☰ > Cluster Management**.
 1. Click **Advanced** to open the dropdown menu.
 1. Select **JWT Authentication**.
 1. Click the checkbox for the cluster you want to enable JWT authentication for, and click **Enable**. Alternatively, you can click **⋮** > **Enable**.
@@ -238,3 +238,9 @@ When you revoke the cluster membership for a standard user that's explicitly ass
 - Exercise any [individual project roles](#project-role-reference) they are assigned.
 If you want to completely revoke a user's access within a cluster, revoke both their cluster and project memberships.
 ### External `RoleTemplate` Behavior
 In Rancher v2.9.0 and later, external `RoleTemplate` objects can only be created if the backing `ClusterRole` exists in the local cluster or the `ExternalRules` is set in your configuration.
 For context, the backing `ClusterRole` holds cluster rules and privileges, and shares the same `metadata.name` used in the `RoleTemplate` in your respective cluster referenced by the `ClusterRoleTemplateBinding/ProjectRoleTemplateBinding`. Additionally, note that `escalate` permissions on `RoleTemplates` are required to create external `RoleTemplates` with `ExternalRules`.
@@ -62,21 +62,6 @@ Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-o
 ### 2. Restore from backup using a Restore custom resource
 :::note Important:
 Kubernetes v1.22, available as an experimental feature of v2.6.3, does not support restoring from backup files containing CRDs with the apiVersion `apiextensions.k8s.io/v1beta1`. In v1.22, the default `resourceSet` in the rancher-backup app is updated to collect only CRDs that use `apiextensions.k8s.io/v1`. There are currently two ways to work around this issue:
 1. Update the default `resourceSet` to collect the CRDs with the apiVersion v1.
 1. Update the default `resourceSet` and the client to use the new APIs internally, with `apiextensions.k8s.io/v1` as the replacement.
    :::note
    When making or restoring backups for v1.22, the Rancher version and the local cluster's Kubernetes version should be the same. The Kubernetes version should be considered when restoring a backup since the supported apiVersion in the cluster and in the backup file could be different.
    :::
 :::
 1. When using S3 object storage as the backup source for a restore that requires credentials, create a `Secret` object in this cluster to add the S3 credentials. The secret data must have two keys - `accessKey`, and `secretKey`, that contain the S3 credentials.
   The secret can be created in any namespace, this example uses the default namespace.
@@ -58,7 +58,7 @@ To display prerelease versions:
 | rancher-logging | 100.0.0+up3.12.0 | 100.1.2+up3.17.4 |
 | rancher-longhorn | 100.0.0+up1.1.2 | 100.1.2+up1.2.4 |
 | rancher-monitoring | 100.0.0+up16.6.0 | 100.1.2+up19.0.3 |
-| rancher-sriov (experimental) | 100.0.0+up0.1.0 | 100.0.3+up0.1.0 |
+| rancher-sriov<sup>[1](#sriov-chart-deprecation-and-migration)</sup> | 100.0.0+up0.1.0 | 100.0.3+up0.1.0 |
 | rancher-vsphere-cpi | 100.3.0+up1.2.1 | 100.3.0+up1.2.1 |
 | rancher-vsphere-csi | 100.3.0+up2.5.1-rancher1 | 100.3.0+up2.5.1-rancher1 |
 | rancher-wins-upgrader | 0.0.100 | 100.0.1+up0.0.1 |
@@ -163,6 +163,16 @@ spec:
 :::
 ### Add Custom OCI Chart Repositories
 :::caution
 This feature is currently experimental and is not officially supported in Rancher.
 :::
 Helm v3 introduced storing Helm charts as [Open Container Initiative (OCI)](https://opencontainers.org/about/overview/) artifacts in container registries. With Rancher v2.9.0, you can add [OCI-based Helm chart repositories](https://helm.sh/docs/topics/registries/) alongside HTTP-based and Git-based repositories. This means you can deploy apps that are stored as OCI artifacts. For more information, see [Using OCI Helm Chart Repositories](./oci-repositories.md).
 ### Helm Compatibility
 Only Helm 3 compatible charts are supported.
@@ -229,6 +239,31 @@ To upgrade legacy multi-cluster apps:
 1. Click **☰**. 
 1. Under **Legacy Apps**, click **Multi-cluster Apps**.
 ### Chart-Specific Information
 #### sriov Chart Deprecation and Migration
 The `sriov` (SR-IOV network operator) chart from the Rancher Charts repository is deprecated and will be removed in Rancher v2.10. Please migrate to the `sriov-network-operator` chart from the SUSE Edge repository (https://github.com/suse-edge/charts) instead.
 To migrate, follow these steps:
 1. Add the SUSE Edge repository to your cluster by following the steps in [Add Custom Git Repositories](#add-custom-git-repositories).
 1. For the **Git Repo URL** field, enter `https://github.com/suse-edge/charts`.
 1. Click **Create**.
 1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
 1. Find the `sriov-network-operator` chart and click on it.
 1. Click **Install**.
 1. In the **Name** field, enter the same name you used for your existing `sriov` chart installation.
 1. Click **Next**.
 1. Click **Install**.
 **Result:** Rancher redirects to the **Installed Apps** page where your existing installation enters the **Updating** state. The migration is complete when it enters the **Deployed** state.
 ## Limitations
-Dashboard apps or Rancher feature charts can't be installed using the Rancher CLI.
+- Dashboard apps or Rancher feature charts can't be installed using the Rancher CLI.
 - When determining the most recent version to display for the **Upgradable** column on the **Apps > Installed Apps** page, rather than only considering versions of the Helm chart from the repository it was installed from, Rancher considers versions of the Helm chart from all repositories on the cluster.
  For example, suppose you install `cert-manager` v1.13.0 from repository A, where v1.14.0 is now the most recent version available. In this case, you expect **Upgradable** to display v1.14.0. However, if the cluster also has access to repository B where v1.15.0 of `cert-manager` is available, then **Upgradable** displays v1.15.0 even though the original installation used repository A.
@@ -0,0 +1,115 @@
 ---
 title: Using OCI-Based Helm Chart Repositories
 ---
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher/oci-registries"/>
 </head>
 :::caution
 This feature is currently experimental and is not officially supported in Rancher.
 :::
 Helm v3 introduced storing Helm charts as [Open Container Initiative (OCI)](https://opencontainers.org/about/overview/) artifacts in container registries. With Rancher v2.9.0, you can add [OCI-based Helm chart repositories](https://helm.sh/docs/topics/registries/) alongside HTTP-based and Git-based repositories. This means that you can deploy apps that are stored as OCI artifacts.
 ## Add an OCI-Based Helm Chart Repository
 To add an OCI-based Helm chart repository through the Rancher UI:
 1. Click **☰ > Cluster Management**.
 2. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
 3. In the left navigation bar, select **Apps > Repositories**.
 4. Click **Create**.
 5. Enter a **Name** for the registry. Select **OCI Repository** as the target.
 6. Enter the **OCI Repository Host URL** for the registry. The registry endpoint must not contain anything besides OCI Helm Chart artifacts. The artifacts should all have unique names. If you attempt to add an endpoint that contains any other kinds of files or artifacts, the OCI repository will not be added. 
  :::note
  You can use the **OCI URL** field to fine-tune how many charts from the registry are available for installation on Rancher. More generic endpoints target more charts, as the following examples demonstrate:
    - `oci://<registry-host>`: Every chart in the registry becomes available for installation, regardless of namespace or tag.
    - `oci://<registry-host>/<namespace>`: Every chart in the specified namespace within the registry becomes available for installation.
    - `oci://<registry-host>/<namespace>/<chart-name>`: Only the specified chart and any associated tags or versions of that chart become available for installation.
    - `oci://<registry-host>/<namespace>/<chart-name>:<tag>`: Only the chart with the specified tag becomes available for installation.
  :::
 7. Set up authentication. Select **Basicauth** from the authentication field and enter a username and password as required. Otherwise, create or select an **Authentication** secret. See [Authentication](#authentication-for-oci-based-helm-chart-repositories) for a full description.
 8. (optional) Enter a base64 encoded DER certificate in the **CA Cert Bundle** field. This field is for cases where you have a private OCI-based Helm chart repository and need Rancher to trust its certificates.   
 9. (optional) To allow insecure connections without performing an SSL check, select **Skip TLS Verification**. To force Rancher to use HTTP instead of HTTPS to send requests to the repository, select **Insecure Plain Http**.
 10. (optional) If your repository has a rate limiting policy and may respond with status code `429 Too Many Requests`, you may want to fill out the fields under **Exponential Back Off**:
    - **Min Wait**: The minimum duration in seconds that Rancher should wait before retrying. The default is 1 second.
    - **Max Wait**: The maximum duration in seconds that Rancher should wait before retrying. The default is 5 second.
    - **Max Number of Retries**: The default is 5 retries.
    Once these values are set, Rancher responds to the `429` status code by staggering requests based on the minimum and maximum wait values. The wait time between retries increases exponentially, until Rancher has sent the maximum number of retries set. See [Rate Limiting](#rate-limiting-of-oci-based-helm-chart-repositories) for more details.
 11. Add any labels and annotations.
 12. Click **Create**.
 It may take some time for the OCI repository to activate. This is particularly true if the OCI endpoint contains multiple namespaces. 
 ## Authentication for OCI-Based Helm Chart Repositories
 Rancher supports BasicAuth for OCI registries. You must create a [**BasicAuth** Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/#basic-authentication-secret). You can also [create the secret through the Rancher UI](../kubernetes-resources-setup/secrets.md). 
 The CRD that is linked to the OCI-based Helm repository is `ClusterRepo`.
 ## View Helm Charts in OCI-Based Helm Chart Repositories
 To view Helm charts in the OCI-based Helm chart repository after it achieves an `Active` state:
 1. Click **☰**. Under **Explore Cluster** in the left navigation menu, select a cluster.
 1. Click **Apps > Charts**.
 1. Select the OCI-based Helm chart repository from the dropdown.
 ## Refresh an OCI-Based Helm Chart Repository
 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).
 ## Update an OCI-Based Helm Chart Repository Configuration
 1. Click **☰ > Cluster Management**.
 1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
 1. In the left navigation bar, select **Apps > Repositories**.
 1. Find the row associated with the OCI-based Helm chart repository, and click **⋮**.
 1. From the submenu, select **Edit Config**.
 ## Delete an OCI-Based Helm Chart Repository
 1. Click **☰ > Cluster Management**.
 1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
 1. In the left navigation bar, select **Apps > Repositories**.
 1. Select the row associated with the OCI-based Helm chart repository, and click **Delete**.
 ## Size Limitations of OCI-Based Helm Chart Repositories in Rancher
 Due to security concerns, there are limitations on how large of a Helm chart you can deploy through an OCI-based repository, and how much metadata you can use to describe the Helm charts within a single OCI endpoint.
 Rancher can deploy OCI Helm charts up to 20 MB in size.
 ## Rate Limiting of OCI-Based Helm Chart Repositories
 Different OCI registries implement rate limiting in different ways. 
 Most servers return a `Retry-After` header, indicating how long to wait before rate limiting is lifted. 
 Docker Hub returns a `429` status code when it completes all allocated requests. It also returns a `RateLimit-Remaining` header which describes the rate limiting policy. 
 Rancher currently checks for the `Retry-After` header. It also handles Docker Hub-style responses (status code `429` and the `RateLimit-Remaining` header) and automatically waits before making a new request. When handling `Retry-After` or Docker Hub-style responses, Rancher ignores `ExponentialBackOff` values. 
 If you have an OCI-based Helm chart repository which doesn't implement the `Retry-After` or `RateLimit-Remaining` headers, and think you may be rate-limited at some point, fill out the fields under **Exponential Back Off** when you add the repository. 
 For example, if you have an OCI-based Helm chart repository that doesn't return a `Retry-After` header, but you know that the server allows 50 requests in 24 hours, you can provide Rancher a **Min Wait** value of **86400** seconds, a **Max Wait** value of **90000** seconds, and a **Max Number of Retries** value of **1**. Then, if Rancher gets rate limited by the server, Rancher will wait for 24 hours before trying again. The request should succeed as Rancher hasn't sent any other requests in the previous 24 hours.
 ## Troubleshooting OCI-based Helm Registries
 - To enhance logging information, [enable the debug option](../../../troubleshooting/other-troubleshooting-tips/logging.md#kubernetes-install) while deploying Rancher.
 - If there is any discrepancy between the repository contents and Rancher, you should refresh the cluster repository as a first resort. If the discrepancy persists, delete the OCI-based Helm chart repository from Rancher and add it again. Deleting the repository won't delete any Helm charts that are already installed.
 - Apps installed through OCI-based Helm chart repositories are subject to a known issue with how Rancher displays upgradeable version information. See the [Limitations](./helm-charts-in-rancher.md#limitations) section of **Helm Charts and Apps** for more details.
@@ -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
@@ -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)
@@ -49,5 +49,5 @@ number of nodes for each Kubernetes role, refer to the section on [recommended a
 ### Networking
-* Minimize network latency. Rancher recommends minimizing latency between the etcd nodes. The default setting for `heartbeat-interval` is `500`, and the default setting for `election-timeout` is `5000`. These [settings for etcd tuning](https://coreos.com/etcd/docs/latest/tuning.html) allow etcd to run in most networks (except really high latency networks).
+* Minimize network latency. Rancher recommends minimizing latency between the etcd nodes. The default setting for `heartbeat-interval` is `500`, and the default setting for `election-timeout` is `5000`. These [settings for etcd tuning](https://etcd.io/docs/v3.5/tuning/) allow etcd to run in most networks (except really high latency networks).
 * Cluster nodes should be located within a single region. Most cloud providers provide multiple availability zones within a region, which can be used to create higher availability for your cluster. Using multiple availability zones is fine for nodes with any role. If you are using [Kubernetes Cloud Provider](../set-up-cloud-providers/set-up-cloud-providers.md) resources, consult the documentation for any restrictions (i.e. zone storage restrictions).
@@ -57,7 +57,7 @@ The number of nodes that you can lose at once while maintaining cluster availabi
 References:
-* [Official etcd documentation on optimal etcd cluster size](https://etcd.io/docs/v3.4.0/faq/#what-is-failure-tolerance)
+* [Official etcd documentation on optimal etcd cluster size](https://etcd.io/docs/v3.5/faq/#what-is-failure-tolerance)
 * [Official Kubernetes documentation on operating etcd clusters for Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/)
 ### Number of Worker Nodes
@@ -0,0 +1,211 @@
 ---
 title: Migrating Azure In-tree to Out-of-tree
 ---
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-azure"/>
 </head>
 Kubernetes is moving away from maintaining cloud providers in-tree.
 Starting with Kubernetes 1.29, in-tree cloud providers have been disabled. You must disable `DisableCloudProviders` and `DisableKubeletCloudCredentialProvider` to use the in-tree Azure cloud provider or migrate from in-tree cloud provider to out-of-tree provider. You can disable the required feature gates by setting `feature-gates=DisableCloudProviders=false` as an additional argument for the cluster's Kubelet, Controller Manager, and API Server in the advanced cluster configuration. Additionally, set `DisableKubeletCloudCredentialProvider=false` in the Kubelet's arguments to enable in-tree functionality for authenticating to Azure container registries for image pull credentials. See [upstream docs](https://github.com/kubernetes/kubernetes/pull/117503) for more details.
 In Kubernetes v1.30 and later, the in-tree cloud providers have been removed. Rancher allows you to upgrade to Kubernetes v1.30 when you migrate from an in-tree to out-of-tree provider.
 To migrate from the in-tree cloud provider to the out-of-tree Azure cloud provider, you must stop the existing cluster's kube controller manager and install the Azure cloud controller manager.
 If it's acceptable to have some downtime during migration, follow the instructions to [set up an external cloud provider](../set-up-cloud-providers/azure.md#using-the-out-of-tree-azure-cloud-provider). These instructions outline how to configure the out-of-tree cloud provider for a newly provisioned cluster. During set up, there will be some downtime, as there is a time gap between when the old cloud provider stops running and when the new cloud provider starts to run.
 If your setup can't tolerate any control plane downtime, you must enable leader migration. This facilitates a smooth transition from the controllers in the kube controller manager to their counterparts in the cloud controller manager.
 :::note Important:
 The Kubernetes [cloud controller migration documentation](https://kubernetes.io/docs/tasks/administer-cluster/controller-manager-leader-migration/#before-you-begin) states that it's possible to migrate with the same Kubernetes version, but assumes that the migration is part of a Kubernetes upgrade. Refer to the Kubernetes documentation on [migrating to use the cloud controller manager](https://kubernetes.io/docs/tasks/administer-cluster/controller-manager-leader-migration/) to see if you need to customize your setup before migrating. Confirm your [migration configuration values](https://kubernetes.io/docs/tasks/administer-cluster/controller-manager-leader-migration/#default-configuration). If your cloud provider provides an implementation of the Node IPAM controller, you also need to [migrate the IPAM controller](https://kubernetes.io/docs/tasks/administer-cluster/controller-manager-leader-migration/#node-ipam-controller-migration).
 Starting with Kubernetes v1.26, in-tree persistent volume types `kubernetes.io/azure-disk` and `kubernetes.io/azure-file` are deprecated and no longer supported. There are no plans to remove these drivers following their deprecation, however you should migrate to the corresponding CSI drivers, `disk.csi.azure.com` and `file.csi.azure.com`. To review the migration options for your storage classes and upgrade your cluster to use Azure Disks and Azure Files CSI drivers, see [Migrate from in-tree to CSI drivers](https://learn.microsoft.com/en-us/azure/aks/csi-migrate-in-tree-volumes).
 :::
 <Tabs groupId="k8s-distro">
 <TabItem value="RKE2">
 1. Update the cluster config to enable leader migration:
 ```yaml
 spec:
  rkeConfig:
    machineSelectorConfig:
      - config:
          kube-controller-manager-arg:
            - enable-leader-migration
        machineLabelSelector:
          matchExpressions:
            - key: rke.cattle.io/control-plane-role
              operator: In
              values:
                - 'true'
 ```
 Note that the cloud provider is still `azure` at this step:
 ```yaml
 spec:
  rkeConfig:
    machineGlobalConfig:
      cloud-provider-name: azure
 ```
 2. Cordon control plane nodes so that Azure cloud controller pods run on nodes only after upgrading to the external cloud provider:
 ```shell
 kubectl cordon -l "node-role.kubernetes.io/control-plane=true"
 ```
 3. To deploy the Azure cloud controller manager, use any of the available options: 
 - UI: Follow steps 1-10 of [Helm chart installation from UI](../set-up-cloud-providers/azure.md#helm-chart-installation-from-ui) to install the cloud controller manager chart.
 - CLI: Follow steps 1-4 of [Helm chart installation from CLI](../set-up-cloud-providers/azure.md#helm-chart-installation-from-cli).
 - Update the cluster's additional manifest: Follow steps 2-3 to [install the cloud controller manager chart](../set-up-cloud-providers/azure.md#using-the-out-of-tree-azure-cloud-provider).
 Confirm that the chart is installed but that the new pods aren't running yet due to cordoned controlplane nodes.
 4. To enable leader migration, add `--enable-leader-migration` to the container arguments of `cloud-controller-manager`:
 ```shell 
 kubectl -n kube-system patch deployment cloud-controller-manager \
 --type=json \
 -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-leader-migration"}]'
 ```
 5. Update the provisioning cluster to change the cloud provider and remove leader migration args from the kube controller manager.
   If upgrading the Kubernetes version, set the Kubernetes version as well in the `spec.kubernetesVersion` section of the cluster YAML file.
 ```yaml
 spec:
  rkeConfig:
    machineGlobalConfig:
      cloud-provider-name: external
 ```
 Remove `enable-leader-migration` from the kube controller manager:
 ```yaml
 spec:
  rkeConfig:
    machineSelectorConfig:
      - config:
          kube-controller-manager-arg:
            - enable-leader-migration
        machineLabelSelector:
          matchExpressions:
            - key: rke.cattle.io/control-plane-role
              operator: In
              values:
                - 'true'
 ```
 6. Uncordon control plane nodes so that Azure cloud controller pods now run on nodes:
 ```shell
 kubectl uncordon -l "node-role.kubernetes.io/control-plane=true"
 ```
 7. Update the cluster. The `cloud-controller-manager` pods should now be running.
 ```shell
 kubectl rollout status deployment -n kube-system cloud-controller-manager
 kubectl rollout status daemonset -n kube-system cloud-node-manager
 ```
 8. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
 ```shell
 kubectl describe nodes | grep "ProviderID"
 ```
 9. (Optional) You can also disable leader migration after the upgrade, as leader migration is not required with only one cloud-controller-manager.
    Update the `cloud-controller-manager` deployment to remove leader migration from the container arguments:
 ```yaml
 - --enable-leader-migration=true 
 ```
 </TabItem>
 <TabItem value="RKE">
 1. Update the cluster config to enable leader migration in `cluster.yml`:
 ```yaml
 services:
  kube-controller:
    extra_args:
      enable-leader-migration: "true"
 ```
 Note that the cloud provider is still `azure` at this step:
 ```yaml
 cloud_provider:
  name: azure
 ```
 2. Cordon the control plane nodes, so that Azure cloud controller pods run on nodes only after upgrading to the external cloud provider:
 ```shell
 kubectl cordon -l "node-role.kubernetes.io/controlplane=true"
 ```
 3. To install the Azure cloud controller manager, follow the same steps as when installing Azure cloud provider on a new cluster:
 - UI: Follow steps 1-10 of [Helm chart installation from UI](../set-up-cloud-providers/azure.md#helm-chart-installation-from-ui) to install the cloud controller manager chart.
 - CLI: Follow steps 1-4 of [Helm chart installation from CLI](../set-up-cloud-providers/azure.md#helm-chart-installation-from-cli) to install the cloud controller manager chart.
 4. Confirm that the chart is installed but that the new pods aren't running yet due to cordoned controlplane nodes. After updating the cluster in the next step, RKE will upgrade and uncordon each node, and schedule `cloud-controller-manager` pods.
 5. To enable leader migration, add `--enable-leader-migration` to the container arguments of `cloud-controller-manager`:
 ```shell 
 kubectl -n kube-system patch deployment cloud-controller-manager \
 --type=json \
 -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-leader-migration"}]'
 ```
 6. Update `cluster.yml` to change the cloud provider to `external` and remove the leader migration arguments from the kube-controller.
 ```yaml
 rancher_kubernetes_engine_config:
  cloud_provider:
    name: external
 ```
 Remove `enable-leader-migration` if you don't want it enabled in your cluster:
 ```yaml
 services:
  kube-controller:
    extra_args:
      enable-leader-migration: "true"
 ```
 7. If you're upgrading the cluster's Kubernetes version, set the Kubernetes version as well.
 8. Update the cluster. The `cloud-controller-manager` pods should now be running. 
 ```shell
 kubectl rollout status deployment -n kube-system cloud-controller-manager
 kubectl rollout status daemonset -n kube-system cloud-node-manager
 ```
 9. The cloud provider is responsible for setting the ProviderID of the node. Verify that all nodes are initialized with the ProviderID:
 ```shell
 kubectl describe nodes | grep "ProviderID"
 ```
 10. (Optional) You can also disable leader migration after the upgrade, as leader migration is not required with only one cloud-controller-manager.
    Update the `cloud-controller-manager` deployment to remove leader migration from the container arguments:
 ```yaml
 - --enable-leader-migration=true 
 ```
 </TabItem>
 </Tabs>
@@ -108,7 +108,7 @@ Regarding CPU and memory, it is recommended that the different planes of Kuberne
 For hardware recommendations for large Kubernetes clusters, refer to the official Kubernetes documentation on [building large clusters.](https://kubernetes.io/docs/setup/best-practices/cluster-large/)
-For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation.](https://etcd.io/docs/v3.4.0/op-guide/hardware/)
+For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation.](https://etcd.io/docs/v3.5/op-guide/hardware/)
 ## Networking Requirements
@@ -184,9 +184,7 @@ To prevent issues when upgrading, the [Kubernetes upgrade best practices](https:
 ## Authorized Cluster Endpoint Support for RKE2 and K3s Clusters
-_Available as of v2.6.3_
+Rancher supports Authorized Cluster Endpoints (ACE) for registered RKE2 and K3s clusters. This support includes manual steps you will perform on the downstream cluster to enable the ACE. For additional information on the authorized cluster endpoint, click [here](../manage-clusters/access-clusters/authorized-cluster-endpoint.md).
 Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and K3s clusters. This support includes manual steps you will perform on the downstream cluster to enable the ACE. For additional information on the authorized cluster endpoint, click [here](../manage-clusters/access-clusters/authorized-cluster-endpoint.md).
 :::note Notes:
@@ -332,7 +332,7 @@ Refer to the offical AWS upstream documentation for the [cloud controller manage
 <Tabs groupId="k8s-distro">
 <TabItem value="RKE2">
-Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on Github.
+Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on GitHub.
 1. Add the Helm repository:
@@ -465,7 +465,7 @@ kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
 <TabItem value="RKE">
-Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on Github.
+Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on GitHub.
 1. Add the Helm repository:
@@ -737,7 +737,7 @@ nodeSelector:
 10. Install the chart and confirm that the Daemonset `aws-cloud-controller-manager` deploys successfully:
 ```shell
-kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
+kubectl rollout status deployment -n kube-system aws-cloud-controller-manager
 ```
 </TabItem>
@@ -6,6 +6,17 @@ title: Setting up the Azure Cloud Provider
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure"/>
 </head>
 :::note Important:
 In Kubernetes 1.30 and later, you must use an out-of-tree Azure cloud provider. The Azure cloud provider has been [removed completely](https://github.com/kubernetes/kubernetes/pull/122857), and won't work after an upgrade to Kubernetes 1.30. The steps listed below are still required to set up an Azure cloud provider. You can [set up an out-of-tree cloud provider](#using-the-out-of-tree-azure-cloud-provider) after completing the prerequisites for Azure.
 You can also [migrate from an in-tree to an out-of-tree Azure cloud provider](../migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-azure.md) on Kubernetes 1.29 and earlier. All existing clusters must migrate prior to upgrading to v1.30 in order to stay functional.
 Starting with Kubernetes 1.29, in-tree cloud providers have been disabled. You must disable `DisableCloudProviders` and `DisableKubeletCloudCredentialProvider` to use the in-tree Azure cloud provider. You can do this by setting `feature-gates=DisableCloudProviders=false` as an additional argument for the cluster's Kubelet, Controller Manager, and API Server in the advanced cluster configuration. Additionally, set `DisableKubeletCloudCredentialProvider=false` in the Kubelet's arguments to enable in-tree functionality for authenticating to Azure container registries for image pull credentials. See [upstream docs](https://github.com/kubernetes/kubernetes/pull/117503) for more details.
 Starting with Kubernetes version 1.26, in-tree persistent volume types `kubernetes.io/azure-disk` and `kubernetes.io/azure-file` are deprecated and will no longer be supported. For new clusters, [install the CSI drivers](#installing-csi-drivers), or migrate to the corresponding CSI drivers `disk.csi.azure.com` and `file.csi.azure.com` by following the [upstream migration documentation](https://learn.microsoft.com/en-us/azure/aks/csi-migrate-in-tree-volumes).
 :::
 When using the `Azure` cloud provider, you can leverage the following capabilities:
 - **Load Balancers:** Launches an Azure Load Balancer within a specific Network Security Group.
@@ -76,12 +87,15 @@ Only hosts expected to be load balancer back ends need to be in this group.
 ## RKE2 Cluster Set-up in Rancher
 :::note Important: 
 This section is valid only for creating clusters with the in-tree cloud provider. 
 ::: 
 1. Choose "Azure" from the Cloud Provider drop-down in the Cluster Configuration section.
-1. * Supply the Cloud Provider Configuration. Note that Rancher will automatically create a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster.
+2. Supply the Cloud Provider Configuration. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.
-   * You can click on "Show Advanced" to see more of these automatically generated names and update them if
+   * Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
-   necessary. Your Cloud Provider Configuration **must** match the fields in the Machine Pools section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
+   * An example is provided below. Modify it as needed.
   * An example is provided below. You will modify it as needed.
   <details id="v2.6.0-cloud-provider-config-file">
     <summary>Example Cloud Provider Config</summary>
@@ -110,6 +124,492 @@ Only hosts expected to be load balancer back ends need to be in this group.
    </details>
-1. Under the **Cluster Configuration > Advanced** section, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`
+3. Under the **Cluster Configuration > Advanced** section, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`
-1. Click the **Create** button to submit the form and create the cluster.
+4. Click **Create** to submit the form and create the cluster.
 ## Cloud Provider Configuration
 Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster. You can check **RKE1 Node Templates** or **RKE2 Machine Pools** to view or edit these automatically generated names.
 **Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).**
 :::note 
 1. `useInstanceMetadata` must be set to `true` for the cloud provider to correctly configure `providerID`.
 2. `excludeMasterFromStandardLB` must be set to `false` if you need to add nodes labeled `node-role.kubernetes.io/master` to the backend of the Azure Load Balancer (ALB).
 3. `loadBalancerSku` can be set to `basic` or `standard`. Basic SKU will be deprecated in September 2025. Refer to the [Azure upstream docs](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-basic-upgrade-guidance#basic-sku-vs-standard-sku) for more information.
 :::
 Azure supports reading the cloud config from Kubernetes secrets. The secret is a serialized version of the azure.json file. When the secret is changed, the cloud controller manager reconstructs itself without restarting the pod. It is recommended for the Helm chart to read the Cloud Provider Config from the secret.
 Note that the chart reads the Cloud Provider Config from a given secret name in the `kube-system` namespace. Since Azure reads Kubernetes secrets, RBAC also needs to be configured. An example secret for the Cloud Provider Config is shown below. Modify it as needed and create the secret.
  ```yaml
 # azure-cloud-config.yaml
 apiVersion: v1
 kind: Secret
 metadata:
  name: azure-cloud-config
  namespace: kube-system
 type: Opaque
 stringData:
  cloud-config: |-
    {
      "cloud": "AzurePublicCloud",
      "tenantId": "<tenant-id>",
      "subscriptionId": "<subscription-id>",
      "aadClientId": "<client-id>",
      "aadClientSecret": "<tenant-id>",
      "resourceGroup": "docker-machine",
      "location": "westus",
      "subnetName": "docker-machine",  
      "securityGroupName": "rancher-managed-kqmtsjgJ",
      "securityGroupResourceGroup": "docker-machine",
      "vnetName": "docker-machine-vnet",
      "vnetResourceGroup": "docker-machine",
      "primaryAvailabilitySetName": "docker-machine",  
      "routeTableResourceGroup": "docker-machine",
      "cloudProviderBackoff": false,
      "useManagedIdentityExtension": false,
      "useInstanceMetadata": true,
      "loadBalancerSku": "standard",
      "excludeMasterFromStandardLB": false,
    }
 ---
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: ClusterRole
 metadata:
  labels:
    kubernetes.io/cluster-service: "true"
  name: system:azure-cloud-provider-secret-getter
 rules:
  - apiGroups: [""]
 resources: ["secrets"]
 resourceNames: ["azure-cloud-config"]
 verbs:
  - get
 ---
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: ClusterRoleBinding
 metadata:
  labels:
    kubernetes.io/cluster-service: "true"
  name: system:azure-cloud-provider-secret-getter
 roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:azure-cloud-provider-secret-getter
  subjects:
    - kind: ServiceAccount
      name: azure-cloud-config
      namespace: kube-system
   ``` 
 ## Using the Out-of-tree Azure Cloud Provider
 <Tabs groupId="k8s-distro">
 <TabItem value="RKE2">
 1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section.
 2. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.
  - Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
 3. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. 
 Note that the chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below. Modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).
  ```yaml
 apiVersion: helm.cattle.io/v1
 kind: HelmChart
 metadata:
  name: azure-cloud-controller-manager
  namespace: kube-system
 spec:
  chart: cloud-provider-azure
  repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
  targetNamespace: kube-system
  bootstrap: true
  valuesContent: |-
    infra:
      clusterName: <cluster-name>
    cloudControllerManager:
      cloudConfigSecretName: azure-cloud-config
      cloudConfig: null
      clusterCIDR: null
      enableDynamicReloading: 'true'
      nodeSelector: 
        node-role.kubernetes.io/control-plane: 'true'
      allocateNodeCidrs: 'false' 
      hostNetworking: true
      caCertDir: /etc/ssl
      configureCloudRoutes: 'false'
      enabled: true
      tolerations:
        - effect: NoSchedule
          key: node-role.kubernetes.io/master
        - effect: NoSchedule
          key: node-role.kubernetes.io/control-plane
          value: 'true'
        - effect: NoSchedule
          key: node.cloudprovider.kubernetes.io/uninitialized
          value: 'true'
 ---
 apiVersion: v1
 kind: Secret
 metadata:
  name: azure-cloud-config
  namespace: kube-system
 type: Opaque
 stringData:
  cloud-config: |-
    {
      "cloud": "AzurePublicCloud",
      "tenantId": "<tenant-id>",
      "subscriptionId": "<subscription-id>",
      "aadClientId": "<client-id>",
      "aadClientSecret": "<tenant-id>",
      "resourceGroup": "docker-machine",
      "location": "westus",
      "subnetName": "docker-machine",
      "securityGroupName": "rancher-managed-kqmtsjgJ",
      "securityGroupResourceGroup": "docker-machine",
      "vnetName": "docker-machine-vnet",
      "vnetResourceGroup": "docker-machine",
      "primaryAvailabilitySetName": "docker-machine",  
      "routeTableResourceGroup": "docker-machine",
      "cloudProviderBackoff": false,
      "useManagedIdentityExtension": false,
      "useInstanceMetadata": true,
      "loadBalancerSku": "standard",
      "excludeMasterFromStandardLB": false,
    }
 ---
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: ClusterRole
 metadata:
  labels:
    kubernetes.io/cluster-service: "true"
  name: system:azure-cloud-provider-secret-getter
 rules:
  - apiGroups: [""]
 resources: ["secrets"]
 resourceNames: ["azure-cloud-config"]
 verbs:
  - get
 ---
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: ClusterRoleBinding
 metadata:
  labels:
    kubernetes.io/cluster-service: "true"
  name: system:azure-cloud-provider-secret-getter
 roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:azure-cloud-provider-secret-getter
  subjects:
    - kind: ServiceAccount
      name: azure-cloud-config
      namespace: kube-system
  ```
 4. Click **Create** to submit the form and create the cluster.
 </TabItem>
 <TabItem value="RKE1">
 1. Choose **External** from the **Cloud Provider** drop-down in the **Cluster Options** section. This sets `--cloud-provider=external` for Kubernetes components.
 2. Install the `cloud-provider-azure` chart after the cluster finishes provisioning. Note that the cluster is not successfully provisioned and nodes are still in an `uninitialized` state until you deploy the cloud controller manager. This can be done [manually using CLI](#helm-chart-installation-from-cli), or via [Helm charts in UI](#helm-chart-installation-from-ui).
 Refer to the [official Azure upstream documentation](https://cloud-provider-azure.sigs.k8s.io/install/azure-ccm/) for more details on deploying the Cloud Controller Manager.
 </TabItem>
 </Tabs>
 ### Helm Chart Installation from CLI
 Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/cloud-provider-azure/tree/master/helm/cloud-provider-azure) can be found on Github.
 1. Create a `azure-cloud-config` secret with the required [cloud provider config](#cloud-provider-configuration). 
 ```shell 
 kubectl apply -f azure-cloud-config.yaml
 ```
 2. Add the Helm repository:
 ```shell
 helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
 helm repo update
 ```
 3. Create a `values.yaml` file with the following contents to override the default `values.yaml`:
 <Tabs groupId="k8s-distro">
 <TabItem value="RKE2">
 ```yaml
 # values.yaml
 infra:
  clusterName: <cluster-name>
 cloudControllerManager:
  cloudConfigSecretName: azure-cloud-config
  cloudConfig: null
  clusterCIDR: null
  enableDynamicReloading: 'true'
  configureCloudRoutes: 'false'
  allocateNodeCidrs: 'false'
  caCertDir: /etc/ssl
  enabled: true
  replicas: 1
  hostNetworking: true
  nodeSelector:
    node-role.kubernetes.io/control-plane: 'true'
  tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/master
    - effect: NoSchedule
      key: node-role.kubernetes.io/control-plane
      value: 'true'
    - effect: NoSchedule
      key: node.cloudprovider.kubernetes.io/uninitialized
      value: 'true'
 ```
 </TabItem>
 <TabItem value="RKE">
 ```yaml
 # values.yaml
 cloudControllerManager:
  cloudConfigSecretName: azure-cloud-config
  cloudConfig: null
  clusterCIDR: null  
  enableDynamicReloading: 'true'
  configureCloudRoutes: 'false'
  allocateNodeCidrs: 'false'
  caCertDir: /etc/ssl
  enabled: true
  replicas: 1
  hostNetworking: true
  nodeSelector:
    node-role.kubernetes.io/controlplane: 'true'
    node-role.kubernetes.io/control-plane: null
  tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/controlplane
      value: 'true'
    - effect: NoSchedule
      key: node.cloudprovider.kubernetes.io/uninitialized
      value: 'true'
 infra:
  clusterName: <cluster-name>
 ```
 </TabItem>
 </Tabs>
 4. Install the Helm chart:
 ```shell
 helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yaml
 ```
 Verify that the Helm chart installed successfully:
 ```shell
 helm status cloud-provider-azure -n kube-system
 ```
 5. (Optional) Verify that the cloud controller manager update succeeded:
 ```shell
 kubectl rollout status deployment -n kube-system cloud-controller-manager
 kubectl rollout status daemonset -n kube-system cloud-node-manager
 ```
 6. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
 ```shell
 kubectl describe nodes | grep "ProviderID"
 ```
 ### Helm Chart Installation from UI
 1. Click **☰**, then select the name of the cluster from the left navigation.
 2. Select **Apps** > **Repositories**.
 3. Click the **Create** button.
 4. Enter `https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo` in the **Index URL** field.
 5. Select **Apps** > **Charts** from the left navigation and install **cloud-provider-azure** chart.
 6. Select the namespace, `kube-system`, and enable **Customize Helm options before install**.
 7. Replace `cloudConfig: /etc/kubernetes/azure.json` to read from the Cloud Config Secret and enable dynamic reloading:
 ```yaml
  cloudConfigSecretName: azure-cloud-config
  enableDynamicReloading: 'true'
 ```
 8. Update the following fields as required:
 ```yaml 
  allocateNodeCidrs: 'false'
  configureCloudRoutes: 'false'
  clusterCIDR: null
 ```
 <Tabs groupId="k8s-distro">
 <TabItem value="RKE2">
 9. Rancher-provisioned RKE2 nodes have the selector `node-role.kubernetes.io/control-plane` set to `true`. Update the nodeSelector:
 ```yaml
 nodeSelector:
  node-role.kubernetes.io/control-plane: 'true'
 ```
 </TabItem>
 <TabItem value="RKE">
 10. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector:
 ```yaml
 tolerations:
  - effect: NoSchedule
    key: node.cloudprovider.kubernetes.io/uninitialized
    value: 'true'
  - effect: NoSchedule
    value: 'true'
    key: node-role.kubernetes.io/controlplane
 ```
 ```yaml
 nodeSelector:
  node-role.kubernetes.io/controlplane: 'true'
 ```
 </TabItem>
 </Tabs>
 11. Install the chart and confirm that the cloud controller and cloud node manager deployed successfully:
 ```shell
 kubectl rollout status deployment -n kube-system cloud-controller-manager
 kubectl rollout status daemonset -n kube-system cloud-node-manager
 ```
 12. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
 ```shell
 kubectl describe nodes | grep "ProviderID"
 ```
 ### Installing CSI Drivers
 Install [Azure Disk CSI driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver) or [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) to access [Azure Disk](https://azure.microsoft.com/en-us/services/storage/disks/) or [Azure File](https://azure.microsoft.com/en-us/services/storage/disks/) volumes respectively.
 The steps to install the Azure Disk CSI driver are shown below. You can install the Azure File CSI Driver in a similar manner by following the [helm installation documentation](https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/charts/README.md).
 ::: note Important: 
 Clusters must be provisioned using `Managed Disk` to use Azure Disk. You can configure this when creating **RKE1 Node Templates** or **RKE2 Machine Pools*. 
 ::: 
 Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md) can be found on Github.
 1. Add and update the helm repository:
 ```shell 
 helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts
 helm repo update azuredisk-csi-driver
 ``` 
 1. Install the chart as shown below, updating the --version argument as needed. Refer to the full list of latest chart configurations in the [upstream docs](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md#latest-chart-configuration).
 ```shell
 helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver --namespace kube-system --version v1.30.1 --set controller.cloudConfigSecretName=azure-cloud-config --set controller.cloudConfigSecretNamespace=kube-system --set controller.runOnControlPlane=true
 ``` 
 2. (Optional) Verify that the azuredisk-csi-driver installation succeeded: 
 ```shell 
 kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch 
 ``` 
 3. Provision an example Storage Class: 
 ```shell
 cat <<EOF | kubectl create -f -
 kind: StorageClass
 apiVersion: storage.k8s.io/v1
 metadata:
  name: standard
 provisioner: kubernetes.io/azure-disk
 parameters:
  storageaccounttype: Standard_LRS
  kind: Managed
 EOF
 ```
 Verify that the storage class has been provisioned: 
 ```shell 
 kubectl get storageclasses
 ```
 4. Create a PersistentVolumeClaim:
 ```shell 
 cat <<EOF | kubectl create -f -
 kind: PersistentVolumeClaim
 apiVersion: v1
 metadata:
  name: azure-disk-pvc
 spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
 EOF
 ```
 Verify that the PersistentVolumeClaim and PersistentVolume have been created: 
 ```shell
 kubectl get persistentvolumeclaim 
 kubectl get persistentvolume
 ```
 5. Attach the new Azure Disk: 
 You can now mount the Kubernetes PersistentVolume into a Kubernetes Pod. The disk can be consumed by any Kubernetes object type, including a Deployment, DaemonSet, or StatefulSet. However, the following example simply mounts the PersistentVolume into a standalone Pod. 
 ```shell
 cat <<EOF | kubectl create -f -
 kind: Pod
 apiVersion: v1
 metadata:
  name: mypod-dynamic-azuredisk
 spec:
  containers:
    - name: mypod
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: storage
  volumes:
    - name: storage
      persistentVolumeClaim:
        claimName: azure-disk-pvc
 EOF
 ```
@@ -95,10 +95,15 @@ This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-ra
 These are the minimum set of permissions necessary to access the full functionality of Rancher's EKS driver. You'll need additional permissions for Rancher to provision the `Service Role` and `VPC` resources. If you create these resources **before** you create the cluster, they'll be available when you configure the cluster.
 :::note
 In EKS v1.23 and above, you must use the out-of-tree drivers for EBS-backed volumes. You need [specific permissions](#ebs-csi-driver-addon-permissions) to enable this add-on.
 :::
 Resource | Description
 ---------|------------
 Service Role | Provides permissions that allow Kubernetes to manage resources on your behalf. Rancher can create the service role with the following [Service Role Permissions](#service-role-permissions).
 VPC | Provides isolated network resources utilised by EKS and worker nodes. Rancher can create the VPC resources with the following [VPC Permissions](#vpc-permissions).
 EBS CSI Driver add-on | Provides permissions that allow Kubernetes to interact with EBS and configure the cluster to enable the add-on (required for EKS v1.23 and above). Rancher can install the add-on with the following [EBS CSI Driver addon Permissions](#ebs-csi-driver-addon-permissions).
 Resource targeting uses `*` as the ARN of many of the resources created cannot be known before creating the EKS cluster in Rancher.
@@ -314,6 +319,43 @@ 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.
 ```json
 {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRole",
                "eks:DescribeAddonConfiguration",
                "eks:UpdateAddon",
                "eks:ListAddons",
                "iam:CreateRole",
                "iam:AttachRolePolicy",
                "eks:DescribeAddon",
                "iam:CreateOpenIDConnectProvider",
                "iam:PassRole",
                "eks:DescribeIdentityProviderConfig",
                "eks:DeleteAddon",
                "iam:ListOpenIDConnectProviders",
                "iam:ListAttachedRolePolicies",
                "eks:CreateAddon",
                "eks:DescribeCluster",
                "eks:DescribeAddonVersions",
                "sts:AssumeRoleWithWebIdentity",
                "eks:AssociateIdentityProviderConfig",
                "eks:ListIdentityProviderConfigs"
            ],
            "Resource": "*"
        }
    ]
 }
 ```
 ## Syncing
 The EKS provisioner can synchronize the state of an EKS cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md)
@@ -46,7 +46,7 @@ If you need to create a private registry, refer to the documentation pages for y
    :::
 1. Select a namespace for the registry.
-1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use DockerHub, provide your DockerHub username and password.
+1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use Docker Hub, provide your Docker Hub username and password.
 1. Click **Save**.
 **Result:**
@@ -89,7 +89,7 @@ Before v2.6, secrets were required to be in a project scope. Projects are no lon
    :::
 1. Select a namespace for the registry.
-1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use DockerHub, provide your DockerHub username and password.
+1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use Docker Hub, provide your Docker Hub username and password.
 1. Click **Save**.
 **Result:**
@@ -0,0 +1,65 @@
 ---
 title: Graceful Shutdown for VMware vSphere Virtual Machines
 ---
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/shutdown-vm"/>
 </head>
 In Rancher v2.8.3 and later, you can configure the graceful shutdown of virtual machines (VMs) for VMware vSphere node driver clusters. Graceful shutdown introduces a delay before the VM is forcibly deleted, which allows time for terminating any running processes and open connections.
 In RKE2/K3s, you can set up graceful shutdown when you create the cluster, or edit the cluster configuration to add it afterward. 
 In RKE, you can edit node templates to similar results.
 :::note 
 Since Rancher can't detect the platform of an imported cluster, you cannot enable graceful shutdown on VMware vSphere clusters you have imported.
 :::
 ## Enable Graceful Shutdown During VMware vSphere Cluster Creation 
 <Tabs>
 <TabItem value="RKE2/K3s">
 In RKE2/K3s, you can configure new VMware vSphere clusters with graceful shutdown for VMs:
 1. Click **☰ > Cluster Management**.
 1. Click **Create** and select **VMware vSphere** to provision a new cluster.
 1. Under **Machine Pools > Scheduling**, in the **Graceful Shutdown Timeout** field, enter an integer value greater than 0. The value you enter is the amount of time in seconds Rancher waits before deleting VMs on the cluster. If the value is set to `0`, graceful shutdown is disabled.
 </TabItem>
 <TabItem value="RKE">
 In RKE, you can't directly configure a new cluster with graceful shutdown. However, you can configure node templates which automatically create node pools with graceful shutdown enabled. The node template can then be used to provision new VMware vSphere clusters that have a graceful shutdown delay. 
 1. Click **☰ > Cluster Management**.
 1. From the left navigation, select **RKE1 Configuration > Node Templates**.
 1. Click **Add Template** and select **vSphere** to create a node template.
 1. Under **2. Scheduling**, in the **Graceful Shutdown Timeout** field, enter an integer value greater than 0. The value you enter is the amount of time in seconds Rancher waits before deleting VMs on the cluster. If the value is set to `0`, graceful shutdown is disabled.
 When you [use the newly-created node template to create node pools](../use-new-nodes-in-an-infra-provider.md), the nodes will gracefully shutdown of VMs according to the **Graceful Shutdown Timeout** value you have set.
 </TabItem>
 </Tabs>
 ## Enable Graceful Shutdown in Existing RKE2/K3s Clusters
 In RKE2/K3s, you can edit the configuration of an existing VMware vSphere cluster to enable graceful shutdown, which adds a delay before deleting VMs.
 1. Click **☰ > Cluster Management**.
 1. On the **Clusters** page, find the VMware vSphere hosted cluster you want to edit. Click **⋮** at the end of the row associated with the cluster. Select **Edit Config**.
 1. Under **Machine Pools > Scheduling**, in the **Graceful Shutdown Timeout** field, enter an integer value greater than 0. The value you enter is the amount of time in seconds Rancher waits before deleting VMs on the cluster. If the value is set to `0`, graceful shutdown is disabled.
 ## Enable Graceful Shutdown in Existing RKE Clusters
 In RKE, you can't directly edit an existing cluster's configuration to add graceful shutdown to existing VMware vSphere clusters. However, you can edit the configuration of existing node templates. As noted in [Updating a Node Template](../../../../../reference-guides/user-settings/manage-node-templates.md#updating-a-node-template), all node pools using the node template automatically use the updated information when new nodes are added to the cluster.
 To edit an existing node template to enable graceful shutdown:
 1. Click **☰ > Cluster Management**.
 1. From the left navigation, select **RKE1 Configuration > Node Templates**.
 1. Find the VMware vSphere node template you want to edit. Click **⋮** at the end of the row associated with the template. Select **Edit**.
 1. Under **2. Scheduling**, in the **Graceful Shutdown Timeout** field, enter an integer value greater than 0. The value you enter is the amount of time in seconds Rancher waits before deleting VMs on the cluster. If the value is set to `0`, graceful shutdown is disabled.
 1. Click **Save**.
@@ -15,9 +15,9 @@ Rancher can provision nodes in vSphere and install Kubernetes on them. When crea
 A vSphere cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role.
-## VMware vSphere Enhancements in Rancher v2.3
+## VMware vSphere Enhancements
-The vSphere node templates have been updated, allowing you to bring cloud operations on-premises with the following enhancements:
+The vSphere node templates allow you to bring cloud operations on-premises with the following enhancements:
 ### Self-healing Node Pools
@@ -39,12 +39,6 @@ For the fields to be populated, your setup needs to fulfill the [prerequisites.]
 You can provision VMs with any operating system that supports `cloud-init`. Only YAML format is supported for the [cloud config.](https://cloudinit.readthedocs.io/en/latest/topics/examples.html)
 ### Video Walkthrough of v2.3.3 Node Template Features
 In this YouTube video, we demonstrate how to set up a node template with the new features designed to help you bring cloud operations to on-premises clusters.
 <YouTube id="dPIwg6x1AlU"/>
 ## Creating a VMware vSphere Cluster
 In [this section,](provision-kubernetes-clusters-in-vsphere.md) you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in vSphere.
@@ -122,7 +122,7 @@ Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
 ## Cleaning up Nodes
-<Tabs>
+<Tabs groupId="k8s-distro" queryString>
 <TabItem value="RKE1">
 Before you run the following commands, first remove the node through the Rancher UI.
@@ -19,12 +19,8 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
 | Rancher Version | Adapter Version  |
 |-----------------|:----------------:|
-| v2.8.5          | v103.0.1+up3.0.1 |
+| v2.9.1          | v104.0.0+up4.0.0 |
-| v2.8.4          | v103.0.1+up3.0.1 |
+| v2.9.0          | v104.0.0+up4.0.0 |
 | v2.8.3          | v103.0.1+up3.0.1 |
 | v2.8.2          | v103.0.0+up3.0.0 |
 | v2.8.1          | v103.0.0+up3.0.0 |
 | v2.8.0          | v103.0.0+up3.0.0 |
 ### 1. Gain Access to the Local Cluster
@@ -63,6 +63,8 @@ The Helm chart in the git repository must include its dependencies in the charts
 - **Temporary Workaround**: By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow).
 -  **Debug logging**: To enable debug logging of Fleet components, create a new **fleet** entry in the existing **rancher-config** ConfigMap in the **cattle-system** namespace with the value `{"debug": 1, "debugLevel": 1}`. The Fleet application restarts after you save the ConfigMap.
 ## Documentation
-The Fleet documentation is at https://fleet.rancher.io/.
+See the [official Fleet documentation](https://fleet.rancher.io/) to learn more.
@@ -30,7 +30,20 @@ When adding Fleet agent environment variables for the proxy, replace <PROXY_IP>
 ## Setting Environment Variables in the Rancher UI
-To add the environment variable to an existing cluster,
+To add the environment variable to an existing cluster:
 <Tabs groupId="k8s-distro">
 <TabItem value="RKE2/K3s" default>
 1. Click **☰ > Cluster Management**.
 1. Go to the cluster where you want to add environment variables and click **⋮ > Edit Config**.
 1. Click **Agent Environment Vars** under **Cluster configuration**.
 1. Click **Add**.
 1. Enter the [required environment variables](#required-environment-variables)
 1. Click **Save**.
 </TabItem>
 <TabItem value="RKE">
 1. Click **☰ > Cluster Management**.
 1. Go to the cluster where you want to add environment variables and click **⋮ > Edit Config**.
@@ -39,6 +52,9 @@ To add the environment variable to an existing cluster,
 1. Enter the [required environment variables](#required-environment-variables)
 1. Click **Save**.
 </TabItem>
 </Tabs>
 **Result:** The Fleet agent works behind a proxy.
 ## Setting Environment Variables on Private Nodes
@@ -55,4 +71,4 @@ export HTTP_PROXY=http://${proxy_private_ip}:8888
 export HTTPS_PROXY=http://${proxy_private_ip}:8888
 export NO_PROXY=127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
-```
+```
@@ -0,0 +1,18 @@
 ---
 title: Integrations in Rancher
 ---
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher"/>
 </head>
 Prime is the Rancher ecosystem’s enterprise offering, with additional security, extended lifecycles, and access to Prime-exclusive documentation. Rancher Prime installation assets are hosted on a trusted SUSE registry, owned and managed by Rancher. The trusted Prime registry includes only stable releases that have been community-tested. 
 Prime also offers options for production support, as well as add-ons to your subscription that tailor to your commercial needs.
 To learn more and get started with Rancher Prime, please visit [this page](https://www.rancher.com/quick-start). 
 import DocCardList from '@theme/DocCardList';
 import { useCurrentSidebarCategory } from '@docusaurus/theme-common/internal';
 <DocCardList items={useCurrentSidebarCategory().items.slice(0,8)} />
@@ -1,54 +0,0 @@
 ---
 title: Integrations in Rancher
 ---
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher"/>
 </head>
 import {Card, CardSection} from '@site/src/components/CardComponents';
 import {RocketRegular} from '@fluentui/react-icons';
 Prime is the Rancher ecosystem’s enterprise offering, with additional security, extended lifecycles, and access to Prime-exclusive documentation. Rancher Prime installation assets are hosted on a trusted SUSE registry, owned and managed by Rancher. The trusted Prime registry includes only stable releases that have been community-tested. 
 Prime also offers options for production support, as well as add-ons to your subscription that tailor to your commercial needs.
 To learn more and get started with Rancher Prime, please visit [this page](https://www.rancher.com/quick-start). 
 <CardSection
    id="Gettingstarted"
    icon={<RocketRegular />}
 >
    <Card
        title="Kubernetes Distributions"
        to="./integrations-in-rancher/kubernetes-distributions"
    />
    <Card
        title="Virtualization on Kubernetes with Harvester"
        to="./integrations-in-rancher/harvester"
    />
    <Card
        title="Cloud Native Storage with Longhorn"
        to="./integrations-in-rancher/longhorn"
    />
    <Card
        title="Container Security with NeuVector"
        to="./integrations-in-rancher/neuvector"
    />
    <Card
        title="Advanced Policy Management with Kubewarden"
        to="./integrations-in-rancher/kubewarden"
    />
    <Card
        title="Operating System Management with Elemental"
        to="./integrations-in-rancher/elemental"
    />
    <Card
        title="Continuous Delivery with Fleet"
        to="./integrations-in-rancher/fleet"
    />
    <Card
        title="Kubernetes on the Desktop"
        to="./integrations-in-rancher/rancher-desktop"
    />
 </CardSection>
@@ -43,10 +43,14 @@ It also includes the following:
 ### Kiali
-Kiali is a comprehensive visualization aid used for graphing traffic flow throughout the service mesh. It allows you to see how they are connected, including the traffic rates and latencies between them.
+[Kiali](https://kiali.io/) is a comprehensive visualization aid used for graphing traffic flow throughout the service mesh. It allows you to see how they are connected, including the traffic rates and latencies between them.
 You can check the health of the service mesh, or drill down to see the incoming and outgoing requests to a single component.
 :::note
 For Istio installations `103.1.0+up1.19.6` and later, Kiali uses a token value for its authentication strategy. The name of the Kiali service account in Rancher is `kiali`. Use this name if you are writing commands that require you to enter the name of the Kiali service account (for example, if you are trying to generate or retrieve a session token). For more information, refer to the [Kiali token authentication FAQ](https://kiali.io/docs/faq/authentication/).
 :::
 ### Jaeger
 Our Istio installer includes a quick-start, all-in-one installation of [Jaeger,](https://www.jaegertracing.io/) a tool used for tracing distributed systems.
@@ -71,6 +75,10 @@ To remove Istio components from a cluster, namespace, or workload, refer to the
 > By default, only cluster-admins have access to Kiali. For instructions on how to allow admin, edit or views roles to access them, see [this section.](rbac-for-istio.md)
 :::note
 For Istio installations version `103.1.0+up1.19.6` and later, Kiali uses a token value for its authentication strategy. The name of the Kiali service account in Rancher is `kiali`. Use this name if you are writing commands that require you to enter the name of the Kiali service account (for example, if you are trying to generate or retrieve a session token). For more information, refer to the [Kiali token authentication FAQ](https://kiali.io/docs/faq/authentication/).
 :::
 After Istio is set up in a cluster, Grafana, Prometheus, and Kiali are available in the Rancher UI.
 To access the Grafana and Prometheus visualizations,
@@ -112,7 +112,7 @@ Monitoring also creates additional `ClusterRoles` that aren't assigned to users
 | Role | Purpose  |
 | ------------------------------| ---------------------------|
-| monitoring-ui-view | _Available as of Monitoring v2 14.5.100+_ This ClusterRole allows users with write access to the project to view metrics graphs for the specified cluster in the Rancher UI. This is done by granting Read-only access to external Monitoring UIs. Users with this role have permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Alertmanager, and Grafana UIs through the Rancher proxy. <br/> <br/> This role doesn't grant access to monitoring endpoints. As a result, users with this role won't be able to view cluster monitoring graphs and dashboards in the Rancher UI; however, they are able to access the monitoring Grafana, Prometheus, and Alertmanager UIs if provided those links. |
+| monitoring-ui-view | This ClusterRole allows users with write access to the project to view metrics graphs for the specified cluster in the Rancher UI. This is done by granting Read-only access to external Monitoring UIs. Users with this role have permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Alertmanager, and Grafana UIs through the Rancher proxy. <br/> <br/> This role doesn't grant access to monitoring endpoints. As a result, users with this role won't be able to view cluster monitoring graphs and dashboards in the Rancher UI; however, they are able to access the monitoring Grafana, Prometheus, and Alertmanager UIs if provided those links. |
 :::note
@@ -6,9 +6,7 @@ title: Windows Cluster Support for Monitoring V2
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/monitoring-and-alerting/windows-support"/>
 </head>
-_Available as of v2.5.8_
+Monitoring V2 can be deployed on a Windows cluster to scrape metrics from Windows nodes using [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter) (previously named `wmi_exporter`).
 Starting at Monitoring V2 14.5.100 (used by default in Rancher 2.5.8), Monitoring V2 can now be deployed on a Windows cluster and will scrape metrics from Windows nodes using [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter) (previously named `wmi_exporter`).
 ## Cluster Requirements
@@ -18,7 +18,7 @@ When you set up your high-availability Rancher installation, consider the follow
 Don't run other workloads or microservices in the Kubernetes cluster that Rancher is installed on.
 ### Make sure nodes are configured correctly for Kubernetes
-It's important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node, checking that all correct ports are opened, and deploying with ssd backed etcd. More details can be found in the [kubernetes docs](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) and [etcd's performance op guide](https://etcd.io/docs/v3.4/op-guide/performance/).
+It's important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node, checking that all correct ports are opened, and deploying with ssd backed etcd. More details can be found in the [kubernetes docs](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) and [etcd's performance op guide](https://etcd.io/docs/v3.5/op-guide/performance/).
 ### When using RKE: Back up the Statefile
 RKE keeps record of the cluster state in a file called `cluster.rkestate`. This file is important for the recovery of a cluster and/or the continued maintenance of the cluster through RKE. Because this file contains certificate material, we strongly recommend encrypting this file before backing up. After each run of `rke up` you should backup the state file.
@@ -88,7 +88,7 @@ An [Authorized Cluster Endpoint](../../../reference-guides/rancher-manager-archi
 ### Reducing Event Handler Executions
-The bulk of Rancher's logic occurs on event handlers. These event handlers run on an object whenever the object is updated, and when Rancher is started. Additionally, they run every 15 hours when Rancher syncs caches. In scaled setups these scheduled runs come with huge performance costs because every handler is being run on every applicable object. However, the scheduled handler execution can be disabled with the `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` environment variable. If resource allocation spikes are seen every 15 hours, this setting can help.
+The bulk of Rancher's logic occurs on event handlers. These event handlers run on an object whenever the object is updated, and when Rancher is started. Additionally, they run every 10 hours when Rancher syncs caches. In scaled setups these scheduled runs come with huge performance costs because every handler is being run on every applicable object. However, the scheduled handler execution can be disabled with the `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` environment variable. If resource allocation spikes are seen every 10 hours, this setting can help.
 The value for `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` can be a comma separated list of the following options. The values refer to types of handlers and controllers (the structures that contain and run handlers). Adding the controller types to the variable disables that set of controllers from running their handlers as part of cache resyncing.
@@ -96,7 +96,7 @@ The value for `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` can be a comma separated list o
 * `user` refers to user controllers which run for every cluster. Some of these run on the same node as management controllers, while others run in the downstream cluster. This option targets the former.
 * `scaled` refers to scaled controllers which run on every Rancher node. You should avoid setting this value, as the scaled handlers are responsible for critical functions and changes may disrupt cluster stability.
-In short, if you notice CPU usage peaks every 15 hours, add the `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` environment variable to your Rancher deployment (in the `spec.containers.env` list) with the value `mgmt,user`
+In short, if you notice CPU usage peaks every 10 hours, add the `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` environment variable to your Rancher deployment (in the `spec.containers.env` list) with the value `mgmt,user`
 ## Optimizations Outside of Rancher
@@ -126,7 +126,7 @@ You should keep the local Kubernetes cluster up to date. This will ensure that y
 Etcd is the backend database for Kubernetes and for Rancher. It plays a very important role in Rancher performance.
-The two main bottlenecks to [etcd performance](https://etcd.io/docs/v3.4/op-guide/performance/) are disk and network speed. Etcd should run on dedicated nodes with a fast network setup and with SSDs that have high input/output operations per second (IOPS). For more information regarding etcd performance, see [Slow etcd performance (performance testing and optimization)](https://www.suse.com/support/kb/doc/?id=000020100) and [Tuning etcd for Large Installations](../../../how-to-guides/advanced-user-guides/tune-etcd-for-large-installs.md). Information on disks can also be found in the [Installation Requirements](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md#disks).
+The two main bottlenecks to [etcd performance](https://etcd.io/docs/v3.5/op-guide/performance/) are disk and network speed. Etcd should run on dedicated nodes with a fast network setup and with SSDs that have high input/output operations per second (IOPS). For more information regarding etcd performance, see [Slow etcd performance (performance testing and optimization)](https://www.suse.com/support/kb/doc/?id=000020100) and [Tuning etcd for Large Installations](../../../how-to-guides/advanced-user-guides/tune-etcd-for-large-installs.md). Information on disks can also be found in the [Installation Requirements](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md#disks).
 It's best to run etcd on exactly three nodes, as adding more nodes will reduce operation speed. This may be counter-intuitive to common scaling approaches, but it's due to etcd's [replication mechanisms](https://etcd.io/docs/v3.5/faq/#what-is-maximum-cluster-size).
@@ -32,5 +32,6 @@ This feature enables kubectl to authenticate with the Rancher server and get a n
 3. FreeIPA
 4. OpenLDAP
 5. SAML providers: Ping, Okta, ADFS, Keycloak, Shibboleth
 6. Azure AD
 When you first run kubectl, for example, `kubectl get pods`, you are prompted to pick an auth provider and log in with the Rancher server. The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../../api/api-tokens.md#disable-tokens-in-generated-kubeconfigs), or [gets deleted from the Rancher server](../../api/api-tokens.md#deleting-tokens). Upon expiration, you must log in with the Rancher server again to run the `kubectl get pods` command.
@@ -33,6 +33,7 @@ The fields in the **Scheduling** section should auto-populate with the data cent
 | Data Store | * | If you have a data store cluster, you can toggle the **Data Store** field. This lets you select a data store cluster where your VM will be scheduled to. If the field is not toggled, you can select an individual disk. |
 | Folder |    |  Name of a folder in the datacenter to create the VMs in. Must already exist. The VM folders in this dropdown menu directly correspond to your VM folders in vSphere. The folder name should be prefaced with `vm/` in your vSphere config file. |
 | Host |  | The IP of the host system to schedule VMs in. Leave this field blank for a standalone ESXi or for a cluster with DRS (Distributed Resource Scheduler). If specified, the host system's pool will be used and the **Resource Pool** parameter will be ignored.   |
 | Graceful Shutdown Timeout | | The amount of time, in seconds, that Rancher waits before deleting virtual machines on a cluster. If set to `0`, graceful shutdown is disabled. Only accepts integer values. |
 ## Instance Options
@@ -6,13 +6,6 @@ title: AKS Cluster Configuration Reference
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration"/>
 </head>
 ## Changes in Rancher v2.6
 - Support for adding more than one node pool
 - Support for private clusters
 - Enabled autoscaling node pools
 - The AKS permissions are now configured in cloud credentials
 ## Role-based Access Control
 When provisioning an AKS cluster in the Rancher UI, RBAC cannot be disabled. If role-based access control is disabled for the cluster in AKS, the cluster cannot be registered or imported into Rancher.
@@ -6,12 +6,6 @@ title: GKE Cluster Configuration Reference
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration"/>
 </head>
 ## Changes in Rancher v2.6
 - Support for additional configuration options:
  - Project network isolation
  - Network tags
 ## Cluster Location
 | Value | Description |
@@ -20,7 +20,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 Dockerhub and contact the Rancher management server. This is the simplest solution.
+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
@@ -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).
@@ -10,6 +10,10 @@ Rancher is committed to informing the community of security issues in our produc
 | ID | Description | Date | Resolution |
 |----|-------------|------|------------|
 | [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) |
@@ -8,7 +8,8 @@ title: Rancher Webhook
 Rancher-Webhook is an essential component of Rancher that works in conjunction with Kubernetes to enhance security and enable critical features for Rancher-managed clusters. 
-It integrates with Kubernetes' extensible admission controllers, as described in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), which allows Rancher-Webhook to inspect specific requests sent to the Kubernetes API server, and add custom, Rancher-specific validation and mutations to the requests that are specific to Rancher. Rancher-Webhook manages the resources to be validated using the `rancher.cattle.io` `ValidatingWebhookConfiguration` and the `rancher.cattle.io` `MutatingWebhookConfiguration`, and will override any manual edits.
+It integrates with Kubernetes' extensible admission controllers, as described in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), which allows Rancher-Webhook to inspect specific requests sent to the Kubernetes API server, and add custom validations and mutations to the requests that are specific to Rancher. Rancher-Webhook manages the resources to be validated using the `rancher.cattle.io` `ValidatingWebhookConfiguration` and the `rancher.cattle.io` `MutatingWebhookConfiguration` objects, and will override any manual edits.
 Rancher deploys Rancher-Webhook as a separate deployment and service in both local and downstream clusters. Rancher manages Rancher-Webhook using Helm. It's important to note that Rancher may override modifications made by users to the Helm release. To safely modify these values see [Customizing Rancher-Webhook Configuration](#customizing-rancher-webhook-configuration).
 Each Rancher version is designed to be compatible with a single version of the webhook. The compatible versions are provided below for convenience.
@@ -19,12 +20,8 @@ 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.8.5          |     v0.4.7      | &check;               | &check;                   |
+| v2.9.1          |     v0.5.1      | &check;               | &check;                   |
-| v2.8.4          |     v0.4.5      | &check;               | &check;                   |
+| v2.9.0          |     v0.5.0      | &cross;               | &check;                   |
 | v2.8.3          |     v0.4.3      | &check;               | &check;                   |
 | v2.8.2          |     v0.4.2      | &check;               | &check;                   |
 | v2.8.1          |     v0.4.2      | &check;               | &check;                   |
 | v2.8.0          |     v0.4.2      | &cross;               | &check;                   |
 ## Why Do We Need It?
@@ -55,6 +52,7 @@ kubectl create -f example.yaml --as=system:serviceaccount:cattle-system:rancher-
 ## Customizing Rancher-Webhook Configuration
 You can add custom Helm values when you install Rancher-Webhook via Helm. During a Helm install of the Rancher-Webhook chart, Rancher checks for custom Helm values. These custom values must be defined in a ConfigMap named `rancher-config`, in the `cattle-system` namespace, under the data key, `rancher-webhook`. The value of this key must be valid YAML.
 ``` yaml
 apiVersion: v1
 kind: ConfigMap
@@ -73,6 +71,7 @@ Rancher redeploys the Rancher-Webhook chart when changes to the ConfigMap values
 ### Customizing Rancher-Webhook During Rancher Installation
 When you use Helm to install the Rancher chart, you can add custom Helm values to the Rancher-Webhook of the local cluster. All values in the Rancher-Webhook chart are accessible as nested variables under the `webhook` name.
 These values are synced to the `rancher-config` ConfigMap during installation.
 ```bash
@@ -137,11 +136,3 @@ The webhook provides extra validations on [namespaces](https://github.com/ranche
 If you roll back to Rancher v2.7.5 or earlier, you may see webhook versions that are too recent to be compatible with downstream clusters running pre-v2.7.5 version of Rancher. This may cause various incompatibility issues. For example, project members may be unable to create namespaces. In addition, when you roll back to versions before the webhook was installed in downstream clusters, the webhook may remain installed, which can result in similar incompatibility issues.
 To help alleviate these issues, you can run the [adjust-downstream-webhook](https://github.com/rancherlabs/support-tools/tree/master/adjust-downstream-webhook) shell script after roll back. This script selects and installs the proper webhook version (or removes the webhook entirely) for the corresponding Rancher version. 
 ### Project Users Can't Create Namespaces 
 **Note:** The following affects Rancher v2.7.2 - v2.7.4.
 Project users may not be able to create namespaces in projects. This includes project owners. This issue is caused by Rancher automatically upgrading the webhook to a version compatible with a more recent version of Rancher than the one currently installed. 
 To help alleviate these issues, you can run the [adjust-downstream-webhook](https://github.com/rancherlabs/support-tools/tree/master/adjust-downstream-webhook) shell script after roll back. This script selects and installs the proper webhook version (or removes the webhook entirely) for the corresponding Rancher version. 
@@ -41,8 +41,6 @@ Choose how certain information is displayed:
 ## Confirmation Setting
 _Available as of v2.7.2_
 Choose whether to ask for confirmation when scaling down node pools.
 ## Advanced Features
@@ -1,9 +0,0 @@
 ---
 title: Security Scans
 ---
 <head>
  https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides
 </head>
 The documentation about CIS security scans has moved [here.](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md)
@@ -86,3 +86,27 @@ Example output:
 NAME                 HOLDER                    AGE
 cattle-controllers   rancher-dbc7ff869-gvg6k   6h10m
 ```
 #### Configuration
 _Available as of Rancher 2.8.3_
 If the Kubernetes API experiences latency, the Rancher replica holding the leader lock may not be able to renew the lease before the lease becomes invalid, which can be observed in the Rancher logs:
 ```
 E0629 04:13:07.293461      34 leaderelection.go:364] Failed to update lock: Put "https://172.17.0.1:443/apis/coordination.k8s.io/v1/namespaces/kube-system/leases/cattle-controllers?timeout=15m0s": context deadline exceeded
 I0629 04:13:07.293594      34 leaderelection.go:280] failed to renew lease kube-system/cattle-controllers: timed out waiting for the condition
 ...
 2024/06/29 04:13:10 [FATAL] leaderelection lost for cattle-controllers
 ```
 To mitigate this, you can set environment variables in the `rancher` Deployment to modify the default parameters for leader election:
 - `CATTLE_ELECTION_LEASE_DURATION`: The [lease duration](https://pkg.go.dev/k8s.io/client-go/tools/leaderelection#LeaderElectionConfig.LeaseDuration). The default value is 45s.
 - `CATTLE_ELECTION_RENEW_DEADLINE`: The [renew deadline](https://pkg.go.dev/k8s.io/client-go/tools/leaderelection#LeaderElectionConfig.RenewDeadline). The default value is 30s.
 - `CATTLE_ELECTION_RETRY_PERIOD`: The [retry period](https://pkg.go.dev/k8s.io/client-go/tools/leaderelection#LeaderElectionConfig.RetryPeriod). The default value is 2s.
 Example:
 ```
 kubectl -n cattle-system set env deploy/rancher CATTLE_ELECTION_LEASE_DURATION=2m CATTLE_ELECTION_RENEW_DEADLINE=90s CATTLE_ELECTION_RETRY_PERIOD=10s
 ```
 This will temporarily increase the lease duration, renew deadline and retry period to 120, 90 and 10 seconds respectively.
 Alternatively, in order to make such changes permanent, these environment variables can be set by [using Helm values](../../getting-started/installation-and-upgrade/installation-references/helm-chart-options.md#setting-extra-environment-variables) instead.
@@ -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',
@@ -1,6 +0,0 @@
 ---
 title: 备份和恢复 Docker 安装的 Rancher
 ---
 - [备份](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md)
 - [还原](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md)
@@ -1,5 +0,0 @@
 ---
 title: RKE 集群配置
 ---
 本文已迁移到[此处](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。
@@ -15,7 +15,7 @@ title: 功能开关
 以下是 Rancher 中可用的功能开关列表。如果你是从旧 Rancher 版本升级的，你可能会在 Rancher UI 中看到其他功能，例如 `proxy` 或 `dashboard`（均[已中断](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)）：
 - `continuous-delivery`：允许从 Fleet 中单独禁用 Fleet GitOps。有关详细信息，请参阅[持续交付](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md)。
- `fleet`：v2.6 及更高版本的 Rancher 配置框架需要 Fleet。即使你在旧 Rancher 版本中禁用了该标志，该标志也将在升级时自动启用。有关详细信息，请参阅 [Fleet - GitOps at Scale](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)。
+- `fleet`：v2.6 及更高版本的 Rancher 配置框架需要 Fleet。即使你在旧 Rancher 版本中禁用了该标志，该标志也将在升级时自动启用。有关详细信息，请参阅 [Fleet - GitOps at Scale](../../../integrations-in-rancher/fleet/fleet.md)。
 - `harvester`：管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。有关详细信息，请参阅 [Harvester 集成](../../../integrations-in-rancher/harvester/overview.md)。
 - `istio-virtual-service-ui`：启用[可视界面](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md)来创建、读取、更新和删除 Istio 虚拟服务和目标规则，这些都是 Istio 流量管理功能。
 - `legacy`：启用 2.5.x 及更早版本的一组功能，这些功能正逐渐被新的实现淘汰。它们是已弃用以及后续可用于新版本的功能组合。新的 Rancher 安装会默认禁用此标志。如果你从以前版本的 Rancher 升级，此标志会启用。
@@ -176,7 +176,7 @@ kubectl edit -n cattle-system deployment/cattle-cluster-agent
 ### 5. 强制更新 Fleet 集群，从而将 fleet-agent 重新连接到 Rancher
-在 Rancher UI 的[持续交付](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#在-rancher-ui-中访问-fleet)中，为集群选择“强制更新”，来允许下游集群中的 fleet-agent 成功连接到 Rancher。
+在 Rancher UI 的[持续交付](../../../integrations-in-rancher/fleet/overview.md#在-rancher-ui-中访问-fleet)中，为集群选择“强制更新”，来允许下游集群中的 fleet-agent 成功连接到 Rancher。
 #### 为什么要执行这一步骤？
@@ -256,7 +256,7 @@ helm ls -n cattle-system
 ### 5. 强制更新 Fleet 集群，从而将 fleet-agent 重新连接到 Rancher
-在 Rancher UI 的[持续交付](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#在-rancher-ui-中访问-fleet)中，为集群选择“强制更新”，来允许下游集群中的 fleet-agent 成功连接到 Rancher。
+在 Rancher UI 的[持续交付](../../../integrations-in-rancher/fleet/overview.md#在-rancher-ui-中访问-fleet)中，为集群选择“强制更新”，来允许下游集群中的 fleet-agent 成功连接到 Rancher。
 #### 为什么要执行这一步骤？
@@ -2,7 +2,7 @@
 title: 持续交付
 ---
-Rancher 中预装的 [Fleet](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) 无法完全禁用。但是，你可以使用 `continuous-delivery` 功能开关来禁用 GitOps 持续交付的 Fleet 功能。
+Rancher 中预装的 [Fleet](../../../integrations-in-rancher/fleet/fleet.md) 无法完全禁用。但是，你可以使用 `continuous-delivery` 功能开关来禁用 GitOps 持续交付的 Fleet 功能。
 如需启用或禁用此功能，请参见[启用实验功能主页](../../../pages-for-subheaders/enable-experimental-features.md)中的说明。
@@ -4,7 +4,7 @@ title: 为大型安装进行 etcd 调优
 当你运行具有 15 个或更多集群的大型 Rancher 安装时，我们建议你扩大 etcd 的默认 keyspace（默认为 2GB）。你最大可以将它设置为 8GB。此外，请确保主机有足够的 RAM 来保存整个数据集。如果需要增加这个值，你还需要同步增加主机的大小。如果你预计在垃圾回收间隔期间 Pod 的变化率很高，你也可以在较小的安装中调整 Keyspace 大小。
-Kubernetes 每隔五分钟会自动清理 etcd 数据集。在某些情况下（例如发生部署抖动），在垃圾回收发生并进行清理之前会有大量事件写入 etcd 并删除，从而导致 Keyspace 填满。如果你在 etcd 日志或 Kubernetes API Server 日志中看到 `mvcc: database space exceeded` 错误，你可以在 etcd 服务器上设置 [quota-backend-bytes](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota) 来增加 Keyspace 的大小。
+Kubernetes 每隔五分钟会自动清理 etcd 数据集。在某些情况下（例如发生部署抖动），在垃圾回收发生并进行清理之前会有大量事件写入 etcd 并删除，从而导致 Keyspace 填满。如果你在 etcd 日志或 Kubernetes API Server 日志中看到 `mvcc: database space exceeded` 错误，你可以在 etcd 服务器上设置 [quota-backend-bytes](https://etcd.io/docs/v3.5/op-guide/maintenance/#space-quota) 来增加 Keyspace 的大小。
 ### 示例：此 RKE cluster.yml 文件的代码片段将 Keyspace 的大小增加到 5GB
@@ -19,7 +19,7 @@ services:
 ## 扩展 etcd 磁盘性能
-你可以参见 [etcd 文档](https://etcd.io/docs/v3.4.0/tuning/#disk)中的建议，了解如何调整主机上的磁盘优先级。
+你可以参见 [etcd 文档](https://etcd.io/docs/v3.5/tuning/#disk)中的建议，了解如何调整主机上的磁盘优先级。
 此外，为了减少 etcd 磁盘上的 IO 争用，你可以为 data 和 wal 目录使用专用设备。etcd 最佳实践不建议配置 Mirror RAID（因为 etcd 在集群中的节点之间复制数据）。你可以使用 striping RAID 配置来增加可用的 IOPS。
@@ -21,7 +21,6 @@ Terraform 是一个服务器配置工具。它使用基础架构即代码，支
 Terraform 支持：
 - 定义几乎任何类型的基础架构即代码，包括服务器、数据库、负载均衡器、监控、防火墙设置和 SSL 证书
 - 使用应用商店应用和多集群应用
 - 跨多个平台（包括 Rancher 和主要云提供商）对基础设施进行编码
 - 将基础架构即代码提交到版本控制
 - 轻松重复使用基础设施的配置和设置
@@ -42,7 +42,7 @@ Rancher 认证代理可以与以下外部认证服务集成。
 ## 用户和组
-Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目、多集群应用以及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
+Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
 :::note
@@ -4,7 +4,7 @@ title: 用户和组
 Rancher 依赖用户和组来决定允许登录到 Rancher 的用户，以及他们可以访问哪些资源。你配置外部身份验证提供程序后，该提供程序的用户将能够登录到你的 Rancher Server。用户登录时，验证提供程序将向你的 Rancher Server 提供该用户所属的组列表。
-你可以通过向资源添加用户或组，来控制其对集群、项目、多集群应用、全局 DNS 提供程序和相关资源的访问。将组添加到资源时，身份验证提供程序中属于该组的所有用户都将能够使用组的权限访问该资源。有关角色和权限的更多信息，请参见 [RBAC](../../../../pages-for-subheaders/manage-role-based-access-control-rbac.md)。
+你可以通过向资源添加用户或组，来控制其对集群、项目、全局 DNS 提供程序和相关资源的访问。将组添加到资源时，身份验证提供程序中属于该组的所有用户都将能够使用组的权限访问该资源。有关角色和权限的更多信息，请参见 [RBAC](../../../../pages-for-subheaders/manage-role-based-access-control-rbac.md)。
 ## 管理成员
@@ -1,21 +0,0 @@
 ---
 title: 跨集群部署应用
 ---
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/deploy-apps-across-clusters"/>
 </head>
 不同版本的 Rancher 提供了几种不同的方式来部署跨集群应用。
 ## Fleet
 Rancher v2.5 及更高版本使用 Fleet 跨集群部署应用
 使用 Fleet 的持续交付是大规模的 GitOps。如需更多信息，请参阅 [Fleet](fleet.md)。
 ### 多集群应用
 在 v2.5 之前的 Rancher 中，多集群应用功能用于跨集群部署应用。多集群应用功能已弃用，但仍可作为旧版功能使用。
 详情请参阅[此文档](multi-cluster-apps.md)。
@@ -1,67 +0,0 @@
 ---
 title: 使用 Feet 进行持续交付
 ---
 使用 Fleet 的持续交付是大规模的 GitOps。你可以使用 Fleet 管理多达一百万个集群。Fleet 非常轻量，可以很好地用于[单个集群](https://fleet.rancher.io/installation#default-install)，但是在你达到[大规模](https://fleet.rancher.io/installation#configuration-for-multi-cluster)时，它能发挥更强的实力。此处的大规模指的是大量集群、大量部署、或组织中存在大量团队的情况。
 Fleet 是一个独立于 Rancher 的项目，你可以使用 Helm 将它安装在任何 Kubernetes 集群上。
 ## 架构
 有关 Fleet 工作原理的信息，请参阅[此页面](../../../integrations-in-rancher/fleet-gitops-at-scale/architecture.md)。
 ## 在 Rancher UI 中访问 Fleet
 Fleet 预装在 Rancher 中，通过 Rancher UI 中的**持续交付**选项管理。有关持续交付和 Fleet 故障排除技巧的更多信息，请参阅[此处](https://fleet.rancher.io/troubleshooting)。
 用户可以通过遵循 **gitops** 的实践，利用持续交付将应用部署到 git 仓库中的 Kubernetes 集群，而无需任何手动操作。
 按照以下步骤在 Rancher UI 中访问持续交付：
 1. 单击 **☰ > 持续交付**。
 1. 在菜单顶部选择你的命名空间，注意以下几点：
   - 默认情况下会选中 `fleet-default`，其中包括注册到 Rancher 的所有下游集群。
   - 你可以切换到仅包含 `local` 集群的 `fleet-local`，或者创建自己的工作空间，并将集群分配和移动到该工作空间。
   - 然后，你可以单击左侧导航栏上的**集群**来管理集群。
 1. 单击左侧导航栏上的 **Git 仓库**将 git 仓库部署到当前工作空间中的集群中。
 1. 选择你的 [git 仓库](https://fleet.rancher.io/gitrepo-add)和[目标集群/集群组](https://fleet.rancher.io/gitrepo-targets)。你还可以单击左侧导航栏中的**集群组**在 UI 中创建集群组。
 1. 部署 git 仓库后，你可以通过 Rancher UI 监控应用。
 ## Windows 支持
 有关对具有 Windows 节点的集群的支持的详细信息，请参阅[此页面](../../../integrations-in-rancher/fleet-gitops-at-scale/windows-support.md)。
 ## GitHub 仓库
 你可以单击此处获取 [Fleet Helm Chart](https://github.com/rancher/fleet/releases/latest)。
 ## 在代理后使用 Fleet
 有关在代理后使用 Fleet 的详细信息，请参阅[此页面](../../../integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md)。
 ## Helm Chart 依赖
 由于用户需要完成依赖列表，因此为了成功部署具有依赖项的 Helm Chart，你必须手动运行命令（如下所列）。如果你不这样做，并继续克隆仓库并运行 `helm install`，由于依赖项将丢失，因此你的安装将失败。
 git 仓库中的 Helm Chart 必须在 Chart 子目录中包含其依赖项。你必须手动运行 `helm dependencies update $chart`，或在本地运行 `helm dependencies build $chart`，然后将完整的 Chart 目录提交到你的 git 仓库。请注意，你需要使用适当的参数来修改命令。
 ## 故障排除
 ---
 * **已知问题**：Fleet git 仓库的 clientSecretName 和 helmSecretName 密文不包含在 [backup-restore-operator](../backup-restore-and-disaster-recovery/back-up-rancher.md#1-安装-rancher-backup-operator) 创建的备份或恢复中。如果我们有了永久的解决方案，我们将通知社区。
 * **临时解决方法：** <br/>
   默认情况下，用户定义的密文不会在 Fleet 中备份。如果执行灾难恢复或将 Rancher 迁移到新集群，则需要重新创建密文。要修改 resourceSet 以包含需要备份的其他资源，请参阅[此文档](https://github.com/rancher/backup-restore-operator#user-flow)。
 ---
 ## 文档
 Fleet 文档链接：[https://fleet.rancher.io/](https://fleet.rancher.io/)
@@ -1,175 +0,0 @@
 ---
 title: 多集群应用
 ---
 通常，大多数应用都部署在单个 Kubernetes 集群上，但有时你可能需要跨不同集群和/或项目部署同一应用的多个副本。在 Rancher 中，_多集群应用_ 指的是使用 Helm Chart 跨多个集群部署的应用。由于能够跨多个集群部署相同的应用，因此可以避免在每个集群上重复执行相同的应用配置操作而引入的人为错误。使用多集群应用，你可以通过自定义在所有项目/集群中使用相同的配置，并根据你的目标项目更改配置。由于多集群应用被视为单个应用，因此更容易管理和维护。
 全局应用商店中的任何 Helm Chart 都可用于部署和管理多集群应用。
 创建多集群应用后，你可以对全局 DNS 条目进行编程，以便更轻松地访问应用。
 ## 先决条件
 ### 权限
 要在 Rancher 中创建多集群应用，你至少需要具有以下权限之一：
 - 目标集群中的[项目成员角色](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)，能够创建、读取、更新和删除工作负载
 - 目标项目所在集群的[集群所有者角色](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#集群角色)
 ### 启用旧版功能
 由于 Rancher 2.5 已弃用多集群应用并使用 Fleet 取代它，你需要使用功能开关以启用多集群应用。
 1. 在左上角，单击 **☰ > 全局设置**。
 1. 单击**功能开关**。
 1. 转到 `Legacy` 功能开关并单击**激活**。
 ## 启动多集群应用
 1. 在左上角，单击**☰ > 多集群应用**。
 1. 点击**启动**。
 1. 找到要启动的应用。
 1. （可选）查看来自 Helm Chart `README` 的详细描述。
 1. 在**配置选项**下输入多集群应用的**名称**。默认情况下，此名称还用于在每个[目标项目](#目标)中为多集群应用创建一个 Kubernetes 命名空间。命名空间命名为 `<MULTI-CLUSTER_APPLICATION_NAME>-<PROJECT_ID>`。
 1. 选择一个**模板版本**。
 1. 完成[多集群应用配置选项](#多集群应用配置选项)以及[应用配置选项](#应用配置选项)。
 1. 选择可以[与多集群应用交互](#成员)的**成员**。
 1. 添加[自定义应用配置答案](#覆盖特定项目的应用配置选项)，这将更改默认应用配置答案中特定项目的配置。
 1. 查看**预览**中的文件。确认后，单击**启动**。
 **结果**：应用已部署到所选的命名空间。你可以从项目中查看应用状态。
 ## 多集群应用配置选项
 Rancher 将多集群应用的配置选项分为以下几个部分。
 ### 目标
 在**目标**部分中，选择用于部署应用的项目。项目列表仅显示你有权访问的项目。所选的每个项目都会被添加到列表中，其中显示了所选的集群名称和项目名称。要移除目标项目，单击 **-**。
 ### 升级
 在**升级**部分中，选择升级应用时需要使用的升级策略。
 * **滚动更新（批量）**：选择此升级策略时，每次升级的应用数量取决于选择的**批量大小**和**间隔**（多少秒后才开始下一批更新）。
 * **同时升级所有应用**：选择此升级策略时，所有项目的所有应用都将同时升级。
 ### 角色
 在**角色**中，你可以定义多集群应用的角色。通常，当用户[启动商店应用](../../../pages-for-subheaders/helm-charts-in-rancher.md)时，该用户的权限会用于创建应用所需的所有工作负载/资源。
 多集群应用由 _系统用户_ 部署，系统用户还被指定为所有底层资源的创建者。由于实际用户可以从某个目标项目中删除，因此使用 _系统用户_ 而不是实际用户。如果实际用户从其中一个项目中删除，则该用户将不再能够管理其他项目的应用。
 Rancher 允许你选择**项目**或**集群**的角色选项。Rancher 将允许你根据用户的权限使用其中一个角色进行创建。
 - **项目** - 相当于[项目成员](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)。如果你选择此角色，Rancher 将检查用户是否在所有目标项目中至少具有[项目成员](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)的角色。虽然用户可能没有被明确授予 _项目成员_ 角色，但如果用户是[管理员](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)、[集群所有者](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#集群角色)或[项目所有者](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)，则认为该用户具有所需的权限级别。
 - **集群** - 相当于[集群所有者](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#集群角色)。如果你选择此角色，Rancher 将检查用户是否在所有目标项目中至少具有[集群所有者](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)的角色。虽然用户可能没有被明确授予 _集群所有者_ 角色，但如果用户是[管理员](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)，则认为该用户具有所需的权限级别。
 在启动应用时，Rancher 会在启动应用之前确认你在目标项目中是否拥有这些权限。
 :::note
 某些应用（如 _Grafana_ 或 _Datadog_）需要访问特定集群级别的资源。这些应用将需要 _集群_ 角色。如果你之后发现应用需要集群角色，则可以升级多集群应用以更新角色。
 :::
 ## 应用配置选项
 对于每个 Helm Chart，你需要输入一个必须的答案列表才能成功部署 Chart。由于 Rancher 会将答案作为 `--set` 标志传递给 Helm，因此你必须按照[使用 Helm：–set 的格式和限制](https://helm.sh/docs/intro/using_helm/#the-format-and-limitations-of---set)中的语法规则来格式化这些答案。
 :::note 示例
 当输入的答案包含用逗号分隔的两个值（即 `abc, bcd`）时，你需要用双引号将值括起来（即 ``"abc, bcd" ``）。
 :::
 ### 使用 questions.yml 文件
 如果你部署的 Helm Chart 包含 `questions.yml` 文件，Rancher UI 会将此文件转换成易于使用的 UI 来收集问题的答案。
 ### 原生 Helm Chart 的键值对
 对于原生 Helm Chart（即来自 **Helm Stable** 或 **Helm Incubator** 应用商店或自定义 Helm Chart 仓库的 Chart），答案会在 **Answers** 中以键值对的形式提供。这些答案能覆盖默认值。
 ### 成员
 默认情况下，多集群应用只能由应用的创建者管理。你可以在**成员**中添加其他用户，以便这些用户管理或查看多集群应用。
 1. 在**成员**搜索框中键入成员的名称，查找要添加的用户。
 2. 为该成员选择**访问类型**。多集群项目有三种访问类型，请仔细阅读并了解这些访问类型的含义，以了解多集群应用权限的启用方式。
   - **所有者**：此访问类型可以管理多集群应用的任何配置，包括模板版本、[多集群应用配置选项](#多集群应用配置选项)，[应用配置选项](#应用配置选项)，可以与多集群应用交互的成员，以及[自定义应用配置答案](#覆盖特定项目的应用配置选项)。由于多集群应用的创建使用与用户不同的权限集，因此多集群应用的任何 _所有者_ 都可以管理/删除[目标项目](#目标)中的应用，而不需要显式授权访问这些项目。请仅为受信任的用户配置此访问类型。
   - **成员**：此访问类型只能修改模板版本、[应用配置选项](#应用配置选项)和[自定义应用配置答案](#覆盖特定项目的应用配置选项)。由于多集群应用的创建使用与用户不同的权限集，因此多集群应用的任何 _成员_ 都可以修改应用，而不需要显式授权访问这些项目。请仅为受信任的用户配置此访问类型。
   - **只读**：此访问类型不能修改多集群应用的任何配置选项。用户只能查看这些应用。
   :::caution
   请确保仅为受信任的用户授予 _所有者_ 或 _成员_ 访问权限，因为这些用户即使无法直接访问项目，也将自动能够管理为此多集群应用创建的应用。
   :::
 ### 覆盖特定项目的应用配置选项
 多集群应用的主要优势之一，是能够在多个集群/项目中使用相同配置部署相同的应用。在某些情况下，你可能需要为某个特定项目使用稍微不同的配置选项，但你依然希望统一管理该应用与其他匹配的应用。此时，你可以为该项目覆盖特定的[应用配置选项](#应用配置选项)，而不需要创建全新的应用。
 1. 在**答案覆盖**中，单击**添加覆盖**。
 2. 对于每个覆盖，你可以选择以下内容：
   - **范围**：在配置选项中选择要覆盖哪些目标项目的答案。
   - **问题**：选择要覆盖的问题。
   - **答案**：输入要使用的答案。
 ## 升级多集群应用角色和项目
 - **在现有的多集群应用上更改角色**
   多集群应用的创建者和任何具有“所有者”访问类型的用户都可以升级其**角色**。添加新角色时，我们会检查用户在所有当前目标项目中是否具有该角色。Rancher 会根据 `Roles` 字段的安装部分，相应地检查用户是否具有全局管理员、集群所有者或项目所有者的角色。
 - **添加/删除目标项目**
 1. 多集群应用的创建者和任何具有“所有者”访问类型的用户都添加或移除目标项目。添加新项目时，我们检查此请求的调用者是否具有多集群应用中定义的所有角色。Rancher 会检查用户是否具有全局管理员、集群所有者和项目所有者的角色。
 2. 删除目标项目时，我们不会进行这些成员资格检查。这是因为调用者的权限可能与目标项目有关，或者由于该项目已被删除导致调用者希望将该项目从目标列表中删除。
 ## 多集群应用管理
 与同一类型的多个单独应用相比，使用多集群应用的好处之一是易于管理。你可以克隆、升级或回滚多集群应用。
 :::note 先决条件：
 `Legacy` 功能开关已启用。
 :::
 1. 在左上角，单击**☰ > 多集群应用**。
 2. 选择要对其执行操作的多集群应用，然后单击 **⋮**。选择以下选项之一：
   * **克隆**：创建另一个具有相同配置的多集群应用。通过使用此选项，你可以轻松复制多集群应用。
   * **升级**：升级多集群应用以更改某些配置。在为多集群应用执行升级时，如果你有合适的[访问类型](#成员)，则可以修改[升级策略](#升级)。
   * **回滚**：将你的应用回滚到特定版本。如果你的一个或多个[目标](#目标)的多集群应用在升级后出现问题，你可以使用 Rancher 存储的多达 10 个多集群应用版本进行回滚。回滚多集群应用会恢复**所有**目标集群和项目的应用，而不仅仅是受升级问题影响的目标。
 ## 删除多集群应用
 :::note 先决条件：
 `Legacy` 功能开关已启用。
 :::
 1. 在左上角，单击**☰ > 多集群应用**。
 2. 选择要删除的多集群应用，然后单击**⋮ > 删除**。删除多集群应用会删除所有目标项目中的所有应用和命名空间。
   :::note
   不能独立删除在目标项目中为多集群应用创建的应用。只有删除多集群应用后才能删除这些应用。
   :::
@@ -48,5 +48,5 @@ title: 生产就绪集群检查清单
 ### 网络
-* 最小化网络延迟。Rancher 建议尽量减少 etcd 节点之间的延迟。`heartbeat-interval` 的默认设置是 `500`，`election-timeout` 的默认设置是 `5000`。这些 [etcd 调优设置](https://coreos.com/etcd/docs/latest/tuning.html) 允许 etcd 在大多数网络（网络延迟特别高的情况下除外）中运行。
+* 最小化网络延迟。Rancher 建议尽量减少 etcd 节点之间的延迟。`heartbeat-interval` 的默认设置是 `500`，`election-timeout` 的默认设置是 `5000`。这些 [etcd 调优设置](https://etcd.io/docs/v3.5/tuning/) 允许 etcd 在大多数网络（网络延迟特别高的情况下除外）中运行。
 * 集群节点应位于单个区域内。大多数云厂商在一个区域内提供多个可用区，这可以提高你集群的可用性。任何角色的节点都可以使用多个可用区。如果你使用 [Kubernetes Cloud Provider](../set-up-cloud-providers/set-up-cloud-providers.md) 资源，请查阅文档以了解限制（即区域存储限制）。
@@ -53,7 +53,7 @@ title: 推荐的集群架构
 参考：
-* [最佳 etcd 集群大小的官方 etcd 文档](https://etcd.io/docs/v3.4.0/faq/#what-is-failure-tolerance)
+* [最佳 etcd 集群大小的官方 etcd 文档](https://etcd.io/docs/v3.5/faq/#what-is-failure-tolerance)
 * [为 Kubernetes 操作 etcd 集群的官方 Kubernetes 文档](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/)
 ### Worker 节点数
@@ -104,7 +104,7 @@ Windows 节点只能用于 Worker 节点。请参阅[配置 Windows 自定义集
 有关大型 Kubernetes 集群的硬件建议，请参阅[构建大型集群](https://kubernetes.io/docs/setup/best-practices/cluster-large/)的官方 Kubernetes 文档。
-有关生产环境中 etcd 集群的硬件建议，请参阅官方 [etcd 文档](https://etcd.io/docs/v3.4.0/op-guide/hardware/)。
+有关生产环境中 etcd 集群的硬件建议，请参阅官方 [etcd 文档](https://etcd.io/docs/v3.5/op-guide/hardware/)。
 ## 网络要求
@@ -0,0 +1,18 @@
 ---
 title: Rancher 中的集成
 ---
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher"/>
 </head>
 Prime 是 Rancher 生态系统的企业级产品，具有更高的安全性、更长的生命周期和对 Prime 专有文档的访问权限。Rancher Prime 安装资产托管在受信任的 SUSE 注册表上，由 Rancher 拥有和管理。受信任的 Prime 注册表仅包括经过社区测试的稳定版本。
 Prime 还提供生产支持选项，以及根据你的商业需求定制的订阅附加组件。
 要了解更多信息并开始使用 Rancher Prime，请访问[本页](https://www.rancher.com/quick-start)。
 import DocCardList from '@theme/DocCardList';
 import { useCurrentSidebarCategory } from '@docusaurus/theme-common/internal';
 <DocCardList items={useCurrentSidebarCategory().items.slice(0,8)} />
@@ -1,51 +0,0 @@
 ---
 title: Rancher 中的集成
 ---
 <head>
  <link
    rel="canonical"
    href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher"
  />
 </head>
 import { Card, CardSection } from "@site/src/components/CardComponents";
 import { RocketRegular } from "@fluentui/react-icons";
 Prime 是 Rancher 生态系统的企业级产品，具有更高的安全性、更长的生命周期和对 Prime 专有文档的访问权限。Rancher Prime 安装资产托管在受信任的 SUSE 注册表上，由 Rancher 拥有和管理。受信任的 Prime 注册表仅包括经过社区测试的稳定版本。
 Prime 还提供生产支持选项，以及根据你的商业需求定制的订阅附加组件。
 要了解更多信息并开始使用 Rancher Prime，请访问[本页](https://www.rancher.com/quick-start)。
 <CardSection id="Gettingstarted" icon={<RocketRegular />}>
  <Card
    title="Kubernetes 发行版"
    to="./integrations-in-rancher/kubernetes-distributions"
  />
  <Card
    title="使用 Harvester 在 Kubernetes 上进行虚拟化"
    to="./integrations-in-rancher/harvester"
  />
  <Card
    title="使用 Longhorn 进行云原生存储"
    to="./integrations-in-rancher/longhorn"
  />
  <Card
    title="使用 NeuVector 实现容器安全"
    to="./integrations-in-rancher/neuvector"
  />
  <Card
    title="使用 Kubewalden 进行高级策略管理"
    to="./integrations-in-rancher/kubewarden"
  />
  <Card
    title="使用 Elemental 进行操作系统管理"
    to="./integrations-in-rancher/elemental"
  />
  <Card title="使用 Fleet 进行持续交付" to="./integrations-in-rancher/fleet" />
  <Card
    title="桌面上的 Kubernetes"
    to="./integrations-in-rancher/rancher-desktop"
  />
 </CardSection>
@@ -44,5 +44,5 @@ title: 生产就绪集群检查清单
 ### 网络
-* 最小化网络延迟。Rancher 建议尽量减少 etcd 节点之间的延迟。`heartbeat-interval` 的默认设置是 `500`，`election-timeout` 的默认设置是 `5000`。这些 [etcd 调优设置](https://coreos.com/etcd/docs/latest/tuning.html) 允许 etcd 在大多数网络（网络延迟特别高的情况下除外）中运行。
+* 最小化网络延迟。Rancher 建议尽量减少 etcd 节点之间的延迟。`heartbeat-interval` 的默认设置是 `500`，`election-timeout` 的默认设置是 `5000`。这些 [etcd 调优设置](https://etcd.io/docs/v3.5/tuning/) 允许 etcd 在大多数网络（网络延迟特别高的情况下除外）中运行。
 * 集群节点应位于单个区域内。大多数云厂商在一个区域内提供多个可用区，这可以提高你集群的可用性。任何角色的节点都可以使用多个可用区。如果你使用 [Kubernetes Cloud Provider](set-up-cloud-providers.md) 资源，请查阅文档以了解限制（即区域存储限制）。
@@ -1,14 +0,0 @@
 ---
 title: 跨集群部署应用
 ---
 Rancher 2.5 引入了 Fleet，这是一种跨集群部署应用的新方式。
 使用 Fleet 的持续交付是大规模的 GitOps。如需更多信息，请参阅 [Fleet](../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)。
 ### 多集群应用
 在 2.5 之前的 Rancher 版本中，多集群应用功能用于跨集群部署应用。我们已弃用多集群应用功能，但你仍然可以在 Rancher 2.5 中使用该功能。
 详情请参阅[此文档](../how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps.md)。
@@ -14,7 +14,7 @@ title: Rancher 运行技巧
 不要在安装了 Rancher 的 Kubernetes 集群上运行其他工作负载或微服务。
 ### 确保 Kubernetes 节点配置正确
-在部署节点时，请遵循 K8s 和 etcd 的最佳实践，其中包括禁用 swap，检查集群中的所有主机之间是否有良好的网络连接，为每个节点使用唯一的主机名、MAC 地址和 `product_uuids`，检查所需端口是否已经打开，并使用配置 SSD 的 etcd 进行部署。详情请参见 [kubernetes 官方文档](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin)和 [etcd 性能操作指南](https://etcd.io/docs/v3.4/op-guide/performance/)。
+在部署节点时，请遵循 K8s 和 etcd 的最佳实践，其中包括禁用 swap，检查集群中的所有主机之间是否有良好的网络连接，为每个节点使用唯一的主机名、MAC 地址和 `product_uuids`，检查所需端口是否已经打开，并使用配置 SSD 的 etcd 进行部署。详情请参见 [kubernetes 官方文档](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin)和 [etcd 性能操作指南](https://etcd.io/docs/v3.5/op-guide/performance/)。
 ### 使用 RKE 时：备份状态文件（Statefile）
 RKE 将集群状态记录在一个名为 `cluster.rkestate` 的文件中，该文件对集群的恢复和/或通过 RKE 维护集群非常重要。由于这个文件包含证书材料，我们强烈建议在备份前对该文件进行加密。请在每次运行 `rke up` 后备份状态文件。
@@ -56,6 +56,6 @@ Rancher 的大部分逻辑都发生在事件处理程序上。每当更新对象
 与 Rancher 版本类似，我们建议让你的 kubernetes 集群保持使用最新版本。这将确保你的集群能包含可用的性能增强或错误修复。
 ### 优化 ETCD
-[ETCD 性能](https://etcd.io/docs/v3.4/op-guide/performance/)的两个主要瓶颈是磁盘速度和网络速度。对任何一个进行优化都应该能提高性能。有关 ETCD 性能的信息，请参阅 [etcd 性能慢（性能测试和优化）](https://www.suse.com/support/kb/doc/?id=000020100)和[为大型安装调优 etcd](https://docs.ranchermanager.rancher.io/how-to-guides/advanced-user-guides/tune-etcd-for-large-installs)。有关磁盘的信息，你也可以参阅[我们的文档](https://docs.Ranchermanager.Rancher.io/v2.5/pages-for-subheaders/installation-requirements#disks)。
+[ETCD 性能](https://etcd.io/docs/v3.5/op-guide/performance/)的两个主要瓶颈是磁盘速度和网络速度。对任何一个进行优化都应该能提高性能。有关 ETCD 性能的信息，请参阅 [etcd 性能慢（性能测试和优化）](https://www.suse.com/support/kb/doc/?id=000020100)和[为大型安装调优 etcd](https://docs.ranchermanager.rancher.io/how-to-guides/advanced-user-guides/tune-etcd-for-large-installs)。有关磁盘的信息，你也可以参阅[我们的文档](https://docs.Ranchermanager.Rancher.io/v2.5/pages-for-subheaders/installation-requirements#disks)。
 理论上，ETCD 集群中的节点越多，由于复制要求 [source](https://etcd.io/docs/v3.3/faq)，它就会越慢。这可能与常见的缩放方法相悖。我们还可以推断，ETCD 的性能将受到节点间距离的反面影响，因为这将减慢网络通信。
@@ -110,7 +110,7 @@ Rancher 的大部分逻辑发生在 Event Handler 上。每当资源对象产生
 Etcd 是 Kubernetes 和 Rancher 的后端数据库，在 Rancher 性能中扮演重要的角色。
-[Etcd 性能](https://etcd.io/docs/v3.4/op-guide/performance/)的两个主要瓶颈是磁盘和网络速度。Etcd 应当在具有高速网络和高读写速度 (IOPS) SSD 硬盘的专用节点上运行。有关 etcd 性能的更多信息，请参阅 [etcd 性能缓慢（性能测试和优化）](https://www.suse.com/support/kb/doc/?id=000020100)和[为大型安装进行 etcd 调优](../../../how-to-guides/advanced-user-guides/tune-etcd-for-large-installs.md)。有关磁盘的信息可以在[安装要求](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md#磁盘)中找到。
+[Etcd 性能](https://etcd.io/docs/v3.5/op-guide/performance/)的两个主要瓶颈是磁盘和网络速度。Etcd 应当在具有高速网络和高读写速度 (IOPS) SSD 硬盘的专用节点上运行。有关 etcd 性能的更多信息，请参阅 [etcd 性能缓慢（性能测试和优化）](https://www.suse.com/support/kb/doc/?id=000020100)和[为大型安装进行 etcd 调优](../../../how-to-guides/advanced-user-guides/tune-etcd-for-large-installs.md)。有关磁盘的信息可以在[安装要求](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md#磁盘)中找到。
 根据 etcd 的[复制机制](https://etcd.io/docs/v3.5/faq/#what-is-maximum-cluster-size)，建议在三个节点上运行 etcd，运行在更多的节点上反而会降低速度。
@@ -31,7 +31,7 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
 | [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](../../pages-for-subheaders/about-rke1-templates.md)配置 [Weave](../../faq/container-network-interface-providers.md#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://github.com/weaveworks/weave/blob/master/site/tasks/manage/security-untrusted-networks.md)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
 | [CVE-2021-36784](https://github.com/rancher/rancher/security/advisories/GHSA-jwvr-vv7p-gpwq) | 在 Rancher 2.5.0 到 2.5.12 和 Rancher 2.6.0 到 2.6.3 中发现了一个漏洞，该漏洞允许能创建或更新[全局角色](../../pages-for-subheaders/manage-role-based-access-control-rbac.md)的用户将他们或其他用户升级为管理员。全局角色能授予用户 Rancher 级别的权限，例如能创建集群。在已识别的 Rancher 版本中，如果用户被授予了编辑或创建全局角色的权限，他们不仅仅能授予他们已经拥有的权限。此漏洞影响使用能够创建或编辑全局角色的非管理员用户的客户。此场景最常见的用例是 `restricted-admin` 角色。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
 | [CVE-2021-4200](https://github.com/rancher/rancher/security/advisories/GHSA-hx8w-ghh8-r4xf) | 此漏洞仅影响在 Rancher 中使用 `restricted-admin` 角色的客户。在 Rancher 2.5.0 到 2.5.12 和 2.6.0 到 2.6.3 中发现了一个漏洞，其中 `cattle-global-data` 命名空间中的 `global-data` 角色授予了应用商店的写权限。由于具有任何级别的应用商店访问权限的用户都会绑定到 `global-data` 角色，因此这些用户都能写入模板 `CatalogTemplates`) 和模板版本 (`CatalogTemplateVersions`)。在 Rancher 中创建的新用户默认分配到 `user` 角色（普通用户），该角色本不该具有写入应用商店的权限。此漏洞提升了能写入应用商店模板和应用商店模板版本资源的用户的权限。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
-| [GHSA-wm2r-rp98-8pmh](https://github.com/rancher/rancher/security/advisories/GHSA-wm2r-rp98-8pmh) | 此漏洞仅影响使用经过认证的 Git 和/或 Helm 仓库通过  [Fleet](../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) 进行持续交付的客户。在 [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) 之前版本中的 `go-getter` 库中发现了一个问题，错误消息中没有删除 Base64 编码的 SSH 私钥，导致该信息暴露。Rancher 中 [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9) 之前的 Fleet 版本使用了该库的漏洞版本。此问题影响 Rancher 2.5.0 到 2.5.12（包括 2.5.12）以及 2.6.0 到 2.6.3（包括 2.6.3）。该问题由 Raft Engineering 的 Dagan Henderson 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
+| [GHSA-wm2r-rp98-8pmh](https://github.com/rancher/rancher/security/advisories/GHSA-wm2r-rp98-8pmh) | 此漏洞仅影响使用经过认证的 Git 和/或 Helm 仓库通过  [Fleet](../../integrations-in-rancher/fleet/fleet.md) 进行持续交付的客户。在 [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) 之前版本中的 `go-getter` 库中发现了一个问题，错误消息中没有删除 Base64 编码的 SSH 私钥，导致该信息暴露。Rancher 中 [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9) 之前的 Fleet 版本使用了该库的漏洞版本。此问题影响 Rancher 2.5.0 到 2.5.12（包括 2.5.12）以及 2.6.0 到 2.6.3（包括 2.6.3）。该问题由 Raft Engineering 的 Dagan Henderson 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
 | [CVE-2021-36778](https://github.com/rancher/rancher/security/advisories/GHSA-4fc7-hc63-7fjg) | 在 Rancher 2.5.0 到 2.5.11 和 Rancher 2.6.0 到 2.6.2 中发现了一个漏洞，当从配置的私有仓库下载 Helm Chart 时，对同源策略的检查不足可能导致仓库凭证暴露给第三方提供商。仅当用户在 Rancher 的`应用 & 应用市场 > 仓库`中配置私有仓库的访问凭证时才会出现此问题。该问题由 Martin Andreas Ullrich 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) 和 [Rancher 2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) |
 | [GHSA-hwm2-4ph6-w6m5](https://github.com/rancher/rancher/security/advisories/GHSA-hwm2-4ph6-w6m5) | 在 Rancher 2.0 到 2.6.3 中发现了一个漏洞。Rancher 提供的 `restricted` Pod 安全策略（PSP）与 Kubernetes 提供的上游 `restricted` 策略有差别，因此 Rancher 的 PSP 将 `runAsUser` 设置为 `runAsAny`，而上游将 `runAsUser` 设置为 `MustRunAsNonRoot`。因此，即使 Rancher 的 `restricted` 策略是在项目或集群级别上强制执行的，容器也可以以任何用户身份运行，包括特权用户 (`root`)。 | 2022 年 3 月 31 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) |
 | [CVE-2021-36775](https://github.com/rancher/rancher/security/advisories/GHSA-28g7-896h-695v) | 在 Rancher 2.4.17、2.5.11 和 2.6.2 以及更高的版本中发现了一个漏洞。从项目中删除与某个组关联的`项目角色`后，能让这些使用者访问集群级别资源的绑定（Binding）不会被删除。导致问题的原因是不完整的授权逻辑检查。如果用户是受影响组中的成员，且能对 Rancher 进行认证访问，那么用户可以利用此漏洞访问他们不应该能访问的资源。暴露级别取决于受影响项目角色的原始权限级别。此漏洞仅影响在 Rancher 中基于组进行身份验证的客户。 | 2022 年 3 月 31 日 | [Rancher 2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3)、[Rancher 2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) 和 [Rancher 2.4.18](https://github.com/rancher/rancher/releases/tag/v2.4.18) |
@@ -1,5 +0,0 @@
 ---
 title: 安全扫描
 ---
 CIS 安全扫描的文档已移至[此处](../../pages-for-subheaders/cis-scan-guides.md)。
@@ -1,16 +0,0 @@
 ---
 title: v2.7
 description: Dummy file used to redirect to the base url
 ---
 <!-- Redirect plugin currently does not allow the final segment of a url (e.g. /v2.7/faq is valid, but /v2.7 is not)
     to contain a period so this method is used to to allow users to access baseurl/v2.7 and be redirected to baseurl
     releaseTask: when a new minor version is released, the name of this file and the title need to be updated.
 -->
 import {Redirect} from '@docusaurus/router';
 const Home = () => {
 return <Redirect to="/zh" />;
 };
@@ -1,6 +0,0 @@
 ---
 title: 备份和恢复 Docker 安装的 Rancher
 ---
 - [备份](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md)
 - [还原](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md)
@@ -1,5 +0,0 @@
 ---
 title: RKE 集群配置
 ---
 本文已迁移到[此处](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。
@@ -4,7 +4,7 @@ title: 为大型安装进行 etcd 调优
 当你运行具有 15 个或更多集群的大型 Rancher 安装时，我们建议你扩大 etcd 的默认 keyspace（默认为 2GB）。你最大可以将它设置为 8GB。此外，请确保主机有足够的 RAM 来保存整个数据集。如果需要增加这个值，你还需要同步增加主机的大小。如果你预计在垃圾回收间隔期间 Pod 的变化率很高，你也可以在较小的安装中调整 Keyspace 大小。
-Kubernetes 每隔五分钟会自动清理 etcd 数据集。在某些情况下（例如发生部署抖动），在垃圾回收发生并进行清理之前会有大量事件写入 etcd 并删除，从而导致 Keyspace 填满。如果你在 etcd 日志或 Kubernetes API Server 日志中看到 `mvcc: database space exceeded` 错误，你可以在 etcd 服务器上设置 [quota-backend-bytes](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota) 来增加 Keyspace 的大小。
+Kubernetes 每隔五分钟会自动清理 etcd 数据集。在某些情况下（例如发生部署抖动），在垃圾回收发生并进行清理之前会有大量事件写入 etcd 并删除，从而导致 Keyspace 填满。如果你在 etcd 日志或 Kubernetes API Server 日志中看到 `mvcc: database space exceeded` 错误，你可以在 etcd 服务器上设置 [quota-backend-bytes](https://etcd.io/docs/v3.4/op-guide/maintenance/#space-quota) 来增加 Keyspace 的大小。
 ### 示例：此 RKE cluster.yml 文件的代码片段将 Keyspace 的大小增加到 5GB
@@ -19,7 +19,7 @@ services:
 ## 扩展 etcd 磁盘性能
-你可以参见 [etcd 文档](https://etcd.io/docs/v3.4.0/tuning/#disk)中的建议，了解如何调整主机上的磁盘优先级。
+你可以参见 [etcd 文档](https://etcd.io/docs/v3.4/tuning/#disk)中的建议，了解如何调整主机上的磁盘优先级。
 此外，为了减少 etcd 磁盘上的 IO 争用，你可以为 data 和 wal 目录使用专用设备。etcd 最佳实践不建议配置 Mirror RAID（因为 etcd 在集群中的节点之间复制数据）。你可以使用 striping RAID 配置来增加可用的 IOPS。
@@ -48,5 +48,5 @@ title: 生产就绪集群检查清单
 ### 网络
-* 最小化网络延迟。Rancher 建议尽量减少 etcd 节点之间的延迟。`heartbeat-interval` 的默认设置是 `500`，`election-timeout` 的默认设置是 `5000`。这些 [etcd 调优设置](https://coreos.com/etcd/docs/latest/tuning.html) 允许 etcd 在大多数网络（网络延迟特别高的情况下除外）中运行。
+* 最小化网络延迟。Rancher 建议尽量减少 etcd 节点之间的延迟。`heartbeat-interval` 的默认设置是 `500`，`election-timeout` 的默认设置是 `5000`。这些 [etcd 调优设置](https://etcd.io/docs/v3.5/tuning/) 允许 etcd 在大多数网络（网络延迟特别高的情况下除外）中运行。
 * 集群节点应位于单个区域内。大多数云厂商在一个区域内提供多个可用区，这可以提高你集群的可用性。任何角色的节点都可以使用多个可用区。如果你使用 [Kubernetes Cloud Provider](../set-up-cloud-providers/set-up-cloud-providers.md) 资源，请查阅文档以了解限制（即区域存储限制）。
@@ -53,7 +53,7 @@ title: 推荐的集群架构
 参考：
-* [最佳 etcd 集群大小的官方 etcd 文档](https://etcd.io/docs/v3.4.0/faq/#what-is-failure-tolerance)
+* [最佳 etcd 集群大小的官方 etcd 文档](https://etcd.io/docs/v3.4/faq/#what-is-failure-tolerance)
 * [为 Kubernetes 操作 etcd 集群的官方 Kubernetes 文档](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/)
 ### Worker 节点数
@@ -104,7 +104,7 @@ Windows 节点只能用于 Worker 节点。请参阅[配置 Windows 自定义集
 有关大型 Kubernetes 集群的硬件建议，请参阅[构建大型集群](https://kubernetes.io/docs/setup/best-practices/cluster-large/)的官方 Kubernetes 文档。
-有关生产环境中 etcd 集群的硬件建议，请参阅官方 [etcd 文档](https://etcd.io/docs/v3.4.0/op-guide/hardware/)。
+有关生产环境中 etcd 集群的硬件建议，请参阅官方 [etcd 文档](https://etcd.io/docs/v3.4/op-guide/hardware/)。
 ## 网络要求
@@ -44,5 +44,5 @@ title: 生产就绪集群检查清单
 ### 网络
-* 最小化网络延迟。Rancher 建议尽量减少 etcd 节点之间的延迟。`heartbeat-interval` 的默认设置是 `500`，`election-timeout` 的默认设置是 `5000`。这些 [etcd 调优设置](https://coreos.com/etcd/docs/latest/tuning.html) 允许 etcd 在大多数网络（网络延迟特别高的情况下除外）中运行。
+* 最小化网络延迟。Rancher 建议尽量减少 etcd 节点之间的延迟。`heartbeat-interval` 的默认设置是 `500`，`election-timeout` 的默认设置是 `5000`。这些 [etcd 调优设置](https://etcd.io/docs/v3.5/tuning/) 允许 etcd 在大多数网络（网络延迟特别高的情况下除外）中运行。
 * 集群节点应位于单个区域内。大多数云厂商在一个区域内提供多个可用区，这可以提高你集群的可用性。任何角色的节点都可以使用多个可用区。如果你使用 [Kubernetes Cloud Provider](set-up-cloud-providers.md) 资源，请查阅文档以了解限制（即区域存储限制）。
--- a/Show More
+++ b/Show More