Merge pull request #2365 from btat/june-cves

Add June CVEs
2026-09-29 06:29:34 +00:00 · 2026-06-29 17:36:01 -07:00 · 2026-06-29 17:08:27 -07:00 · 2026-06-29 15:26:42 -07:00 · 2026-06-29 15:26:15 -07:00 · 2026-06-29 14:59:19 -07:00
337 changed files with 5470 additions and 3651 deletions
@@ -13,10 +13,10 @@ jobs:
    name: Build Docusaurus
    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
        with:
          fetch-depth: 0
-      - uses: actions/setup-node@v4
+      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4
        with:
          node-version: 18
          cache: yarn
@@ -29,7 +29,7 @@ jobs:
        run: yarn build --no-minify

      - name: Upload Build Artifact
-        uses: actions/upload-pages-artifact@v3
+        uses: actions/upload-pages-artifact@56afc609e74202658d3ffba0e8f6dda462b719fa # v3
        with:
          path: build

@@ -49,4 +49,4 @@ jobs:
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
-        uses: actions/deploy-pages@v4
+        uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4
@@ -11,10 +11,10 @@ jobs:
    name: Test deployment
    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
        with:
          fetch-depth: 0
-      - uses: actions/setup-node@v4
+      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4
        with:
          node-version: 18
          cache: yarn
@@ -28,4 +28,4 @@ jobs:
      - name: Test build website
        env:
          NODE_OPTIONS: "--max_old_space_size=10240"
-        run: yarn build --no-minify
+        run: yarn build --no-minify
@@ -6,6 +6,8 @@ title: Using API Tokens
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-tokens"/>
 </head>

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

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

+<v3APITokensDeprecationWarning />
+
 ## Token Resource

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

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

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

-In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
+In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
@@ -24,10 +24,15 @@ Follow the instructions from this page when:
 Alternative steps need to be performed for rollbacks in the following scenarios:
 - Rolling back from v2.6.4 and later to an earlier version of v2.6.x.
 - Rolling back from v2.7.7 and later to an earlier version of v2.7.x.
+- Rolling back from v2.14.0 and later to an earlier version of v2.13.x.

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

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

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

@@ -26,6 +26,31 @@ Review the list of known issues for each Rancher version, which can be found in

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

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

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

 The upgrade instructions assume you are using Helm 3.

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

 For [air-gapped installs only,](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version. Follow the guide to [populate your private registry](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
@@ -174,17 +195,17 @@ There will be more values that are listed with this command. This is just an exa

 :::

-:::tip 
+:::tip

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

 hostname: rancher.my.org
 ```

-::: 
+:::

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

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

 :::

-:::tip 
+:::tip

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

-::: 
+:::

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

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

-    
+
    ```
    helm upgrade rancher rancher-<CHART_REPO>/rancher \
      --namespace cattle-system \
@@ -239,14 +260,6 @@ Alternatively, it's possible to export the current values to a file and referenc

 Log into Rancher to confirm that the upgrade succeeded.

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

 A list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
@@ -243,15 +243,18 @@ When using the [AWS EC2 node driver](../../../how-to-guides/new-user-guides/laun
 | SSH             |   TCP    |     22      | 0.0.0.0/0 and ::/0     |  Inbound  |
 | HTTP            |   TCP    |     80      | 0.0.0.0/0 and ::/0     |  Inbound  |
 | Custom TCP Rule |   TCP    |     443     | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |    8443     | 0.0.0.0/0 and ::/0     |  Inbound  |
 | Custom TCP Rule |   TCP    |    2376     | 0.0.0.0/0 and ::/0     |  Inbound  |
 | Custom TCP Rule |   TCP    |    6443     | 0.0.0.0/0 and ::/0     |  Inbound  |
 | Custom TCP Rule |   TCP    |     179     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |    5473     | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom TCP Rule |   TCP    |    9345     | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom TCP Rule |   TCP    |  2379-2380  | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom TCP Rule |   TCP    | 10250-10252 | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom TCP Rule |   TCP    |    10256    | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom UDP Rule |   UDP    |    4789     | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom UDP Rule |   UDP    |    8472     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |    9796     | sg-xxx (rancher-nodes) |  Inbound  |
 | Custom TCP Rule |   TCP    | 30000-32767 | 0.0.0.0/0 and ::/0     |  Inbound  |
 | Custom UDP Rule |   UDP    | 30000-32767 | 0.0.0.0/0 and ::/0     |  Inbound  |
 | All traffic     |   All    |     All     | 0.0.0.0/0 and ::/0     | Outbound  |
@@ -42,7 +42,7 @@ If you will use ARM64 hosts, the registry must support manifests. As of April 20

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

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

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

 ### 3. Save the images to your workstation

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

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

 ### 4. Populate the private registry

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

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

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

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

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

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

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

 ### Install the Helm CLI

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

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

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

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

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

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

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

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

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

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

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

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

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

 ## Configuring the Upgrade Strategy

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

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

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

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

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

 :::

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

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

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

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

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

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

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

 ### Working with Cloud Infrastructure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-### Programmatically
+### Configuration Fields

-Create an `OIDCClient`:
+When defining your `OIDCClient` manifest, you must include specific fields to pass CRD validation:
+
+- `spec.tokenExpirationSeconds`: This field is strictly required and will cause a validation error if omitted. It defines the lifespan of the access token.
+- `spec.refreshTokenExpirationSeconds`: This field is also strictly required and will cause a validation error if omitted. It defines the lifespan of the refresh token.
+- `scopes` (Optional): This field allows you to restrict the scopes that a client can request. If not explicitly configured, the allowed scopes will default to `openid`, `profile`, and `offline_access`.
+
+### Example OIDC Client Manifest
+
+Below is an example of an `OIDCClient` configuration:
+
+:::note
+You must include the expiration fields to successfully apply the resource.
+:::

 ```yaml
 apiVersion: management.cattle.io/v3
 kind: OIDCClient
 metadata:
-  name: oidc-client-test
+  name: example-client
 spec:
-  tokenExpirationSeconds: 600 # expiration of the id_token and access_token
-  refreshTokenExpirationSeconds: 3600 # expiration of the refresh_token
-  redirectURIs:
-    - "https://myredirecturl.com" # replace with your redirect url
+  description: "Example OIDC Client"
+  redirectUris:
+    - "https://example-app.com/callback"
+  tokenExpirationSeconds: 3600
+  refreshTokenExpirationSeconds: 86400
+  # scopes:
+  #   - openid
+  #   - profile
+  #   - offline_access
+
 ```
-Rancher automatically generates a client ID and client secret for each `OIDCClient`.
-Once the resource is created, Rancher populates the status field with the client id:
+
+Save this configuration to a file (e.g., `oidcclient.yaml`) and apply it to your Rancher local cluster:
+
+```
+kubectl apply -f oidcclient.yaml
+```
+
+Rancher automatically generates a client ID and client secret for each `OIDCClient`. Once the resource is created, Rancher populates the status field with the client id:

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

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

 To retrieve the client secret:

@@ -61,14 +61,12 @@ metadata:
 ```
 In this example, if the project's quota does not include configMaps in its list of resources, then Rancher will ignore `configMaps` in this override.

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

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

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

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

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

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

 <sup>Namespace Default Limit Override</sup>

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

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

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

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

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

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

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

    :::note

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

    :::note

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


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

 ### Node Templates

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

 ### Terraform

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

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

 <ConfigureSLOOidc />
@@ -139,6 +139,10 @@ For example, if your IdP sends `groups` in a claim called `custom_roles`, enter
 | Custom Email Claim | `email` | The name of the claim in the OIDC token that contains the user's email address. |
 | Custom Groups Claim | `groups` | The name of the claim in the OIDC token that contains the user's group memberships (used for RBAC). |

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

 <ConfigureSLOOidc />
@@ -168,6 +168,10 @@ After configuration is completed, Rancher user permissions need to be reapplied

 :::

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

 <ConfigureSLOOidc />
@@ -31,11 +31,17 @@ _Cluster roles_ are roles that you can assign to users, granting them access to

 - **Cluster Owner:**

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

 - **Cluster Member:**

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

 #### Custom Cluster Roles

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

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

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

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

 Notifications are categorized by severity and type:

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

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

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

 ### Assign a Template During Cluster Creation
 <Tabs>
@@ -234,7 +234,7 @@ docker stop <original-rancher-container>

 :::note

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

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


 ### Chart.yaml
+
 #### Annotations

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

-### Keywords
+#### Keywords

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

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

 ## Launching Kubernetes with Rancher

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

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

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

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

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

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

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

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

 ### Launching Kubernetes on Existing Custom Nodes

@@ -71,10 +65,10 @@ Registering EKS clusters now provides additional benefits. For the most part, re

 When you delete an EKS cluster that was created in Rancher, the cluster is destroyed. When you delete an EKS cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher.

-For more information, see [this page.](register-existing-clusters.md)
+For more information, refer to [Registering Existing Clusters](register-existing-clusters.md).

 ## Programmatically Creating Clusters

-The most common way to programmatically deploy Kubernetes clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
+The most common way to programmatically deploy Kubernetes clusters through Rancher is by using the Rancher2 Terraform provider. Refer to the documentation for [creating clusters with Terraform](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster).

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

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

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

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

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

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

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

 ### Requests

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

 To configure request values through the UI:

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

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

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

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

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

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

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

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

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

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

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

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

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

 ## RKE2 Clusters

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

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

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

 - At least three nodes with the role etcd to survive losing one node
@@ -25,21 +25,6 @@ After you download the kubeconfig file, you are able to use the kubeconfig file

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

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

 The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint). When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.
@@ -65,7 +65,8 @@ In clusters that store data on GlusterFS volumes, you may experience an issue wh
 In [Rancher Launched Kubernetes clusters](../../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) that store data on iSCSI volumes, you may experience an issue where kubelets fail to automatically connect with iSCSI volumes. For details on resolving this issue, refer to [this page.](manage-persistent-storage/install-iscsi-volumes.md)

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

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

@@ -1,12 +1,12 @@
 ---
-title: Nodes and Node Pools
+title: Nodes and Machine Pools
 ---

 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools"/>
 </head>

-After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab. 
+After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab.

 1. Click **☰** in the top left corner.
 1. Select **Cluster Management**.
@@ -47,13 +47,7 @@ The following table lists which node options are available for each type of clus

 ### Nodes Hosted by an Infrastructure Provider

-Node pools are available when you provision Rancher-launched Kubernetes clusters on nodes that are [hosted in an infrastructure provider.](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)
-
-Clusters provisioned using [one of the node pool options](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-pools) can be scaled up or down if the node pool is edited.
-
-A node pool can also automatically maintain the node scale that's set during the initial cluster provisioning if [node auto-replace is enabled.](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#about-node-auto-replace) This scale determines the number of active nodes that Rancher maintains for the cluster.
-
-Rancher uses [node templates](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) to replace nodes in the node pool. Each node template uses cloud provider credentials to allow Rancher to set up the node in the infrastructure provider.
+Machine pools are available when you provision Rancher-launched Kubernetes clusters on nodes that are [hosted in an infrastructure provider.](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)

 ### Nodes Provisioned by Hosted Kubernetes Providers

@@ -82,7 +76,7 @@ Select this option to view the node's [API endpoints](../../../api/quickstart.md

 Use **Delete** to remove defective nodes from the cloud provider.

-When you the delete a defective node, Rancher can automatically replace it with an identically provisioned node if the node is in a node pool and [node auto-replace is enabled.](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#about-node-auto-replace)
+When you delete a defective node, Rancher can automatically replace it with an identically provisioned node if the node is in a machine pool and [auto-replace is enabled](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md#auto-replace).

 :::tip

@@ -92,7 +86,7 @@ If your cluster is hosted by an infrastructure provider, and you want to scale y

 ## Scaling Nodes

-For nodes hosted by an infrastructure provider, you can scale the number of nodes in each [node pool](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-pools) by using the scale controls. This option isn't available for other cluster types.
+For nodes hosted by an infrastructure provider, you can scale the number of nodes in each machine pool by using the scale controls. This option isn't available for other cluster types.

 ## SSH into a Node Hosted by an Infrastructure Provider

@@ -24,7 +24,7 @@ The following steps can also be performed using the `kubectl` command line tool.
 :::

 1. Click **☰ > Cluster Management**.
-1. Choose the cluster you want to provide vSphere storage to and click **Exlpore**.
+1. Choose the cluster you want to provide vSphere storage to and click **Explore**.
 1. In the left navigation bar, select **Storage > StorageClasses**.
 1. Click **Create**.
 3. Enter a **Name** for the StorageClass.
@@ -19,10 +19,10 @@ In order to deploy and run the adapter successfully, you need to ensure its vers

 | Rancher Version | Adapter Version  |
 |-----------------|------------------|
-| v2.13.3         |  108.0.0+up8.0.0 |
-| v2.13.2         |  108.0.0+up8.0.0 |
-| v2.13.1         |  108.0.0+up8.0.0 |
-| v2.13.0         |  108.0.0+up8.0.0 |
+| v2.14.3         |  109.0.0+up9.0.0 |
+| v2.14.2         |  109.0.0+up9.0.0 |
+| v2.14.1         |  109.0.0+up9.0.0 |
+| v2.14.0         |  109.0.0+up9.0.0 |

 ### 1. Gain Access to the Local Cluster

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

 - Import CAPI clusters into Rancher, by installing the Rancher Cluster Agent in CAPI provisioned clusters.
- Configure the [CAPI Operator](https://turtles.docs.rancher.com/turtles/stable/en/operator/chart.html#_cluster_api_operator_values).
+- Manage the [CAPI Operator](https://cluster-api-operator.sigs.k8s.io/) using the [CAPIProvider](https://turtles.docs.rancher.com/turtles/stable/en/reference/capiprovider.html) resource.

 The [Overview](./overview.md) section outlines installation options, Rancher Turtles architecture, and a brief demo. For more details, see the [Rancher Turtles documentation](https://turtles.docs.rancher.com/).
@@ -20,51 +20,13 @@ Rancher Turtles meets [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3)

 ## Prerequisites

-Before installing Rancher Turtles in your Rancher environment, you must disable Rancher's `embedded-cluster-api` functionality. This also includes cleaning up Rancher-specific webhooks that otherwise would conflict with CAPI ones.
+:::important

-To simplify setting up Rancher for installing Rancher Turtles, the official Rancher Turtles Helm chart includes a `pre-install` hook that removes the following:
+Starting with Rancher v2.14.0, the built-in `embedded-cluster-api` functionality (also known as the `rancher-provisioning-capi` chart) has been removed. [Rancher Turtles](https://turtles.docs.rancher.com/) is now the only supported method for Cluster API integration with Rancher.

- Disables the `embedded-cluster-api` feature in Rancher.
- Deletes the `mutating-webhook-configuration` and `validating-webhook-configuration` webhooks, as they are no longer needed.
+If you are upgrading from a previous version of Rancher (v2.13.x or earlier), you no longer need to manually disable the `embedded-cluster-api` feature flag or clean up related webhooks before installing Rancher Turtles.

-These webhooks can be removed through the Rancher UI as well:
-
-1. In the upper left corner, click **☰** > **Cluster Management**.
-1. Select your local cluster.
-1. In the left-hand navigation menu, select **More Resources** > **Admission**.
-1. From the dropdown, select the Resource pages for `MutatingWebhookConfiguration` and `ValidatingWebhookConfiguration`.
-1. On the respective Resource pages, click the **⋮** that are attached to the `mutating-webhook-configuration` and `validating-webhook-configuration` webhooks and select the **Delete** option.
-
-The webhooks can also be accessed by entering the names of the webhooks into the **Resource Search** field.
-
-The following `kubectl` commands can manually remove the necessary webhooks:
-
-```console
-kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io mutating-webhook-configuration
-```
-
-```console
-kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io validating-webhook-configuration
-```
-
-Use the following example to disable the `embedded-cluster-api` feature from the console:
-
-1. Create a `feature.yaml` file, with `embedded-cluster-api` set to false:
-
-```yaml title="feature.yaml"
-apiVersion: management.cattle.io/v3
-kind: Feature
-metadata:
-  name: embedded-cluster-api
-spec:
-  value: false
-```
-
-2. Use `kubectl` to apply the `feature.yaml` file to the cluster:
-
-```bash
-kubectl apply -f feature.yaml
-```
+:::

 ## Installing the Rancher Turtles Operator

@@ -240,21 +202,3 @@ Remember that, if you use a different name for the installation or a different n

 :::

-After Rancher Turtles is uninstalled, Rancher's `embedded-cluster-api` feature must be re-enabled:
-
-1. Create a `feature.yaml` file, with `embedded-cluster-api` set to true:
-
-```yaml title="feature.yaml"
-apiVersion: management.cattle.io/v3
-kind: Feature
-metadata:
-  name: embedded-cluster-api
-spec:
-  value: true
-```
-
-2. Use `kubectl` to apply the `feature.yaml` file to the cluster:
-
-```bash
-kubectl apply -f feature.yaml
-```
@@ -116,6 +116,19 @@ By default, Rancher collects logs for control plane components and node componen

 ## Troubleshooting

+### Resource Exhaustion of `inotify` Watchers and File Descriptors
+
+When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
+
+This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
+
+Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
+
+```shell
+sysctl -w fs.inotify.max_user_instances=8192
+sysctl -w fs.inotify.max_user_watches=524288
+```
+
 ### The Logging Buffer Overloads Pods

 Depending on your configuration, the default buffer size may be too large and cause pod failures. One way to reduce the load is to lower the logger's flush interval. This prevents logs from overfilling the buffer. You can also add more flush threads to handle moments when many logs are attempting to fill the buffer at once.
@@ -14,64 +14,74 @@ Examples of built-in Rancher extensions are Fleet, Explorer, and Harvester. Exam

 ## Prerequisites

-> You must log in as an admin in order to view and interact with the extensions management page.
+> 1. You must log in as an administrator to view and interact with the extensions management page.
+> 2. You must enable extension support.
+
+## Enabling Extension Support in Rancher
+
+Rancher v2.9.0 and later includes extension support.
+
+You can confirm if extension support is enabled by checking the `uiextension` feature flag. Any changes to this feature flag cause the Rancher pod to restart.
+
+When you enable extension support for the first time, it creates resources, such as the CRDs, so that UI Extensions can work. When extension support is disabled, it disables the endpoints and does not cache any files. However, it does not remove any CRs or delete any extensions that were installed before. If re-enabled, it exposes the required endpoints again and creates CRDs as needed. The extensions that were already installed load after the Rancher pod restarts.
+
+### Caching Extension Files
+
+By default, Rancher caches every extension file in the file system. You can change that behavior by setting `plugin.noCache` to `true`.
+
+Rancher does have a cached file size limit of 30MB. If an extension has a file bigger than that, the cache is disabled and `plugin.noCache` is set to `true`, regardless of user input.
+

 ## Installing Extensions

 1. Click **☰ > Extensions** under **Configuration**.

-2. If not already installed in **Apps**, you must enable the extension operator by clicking the **Enable** button.
+2. On the **Extensions** page, select the **Available** tab to choose the extensions that you want to install.

-    - Click **OK** to add the Rancher extension repository if your installation is not air-gapped. Otherwise, uncheck the box to do so and click **OK**.
+3. If no extensions are listed as available, you can manually add the repos:

-    ![Rancher extension repository](/img/add-rancher-extension-repo.png)
+   3.1. On the upper right, click **⋮ > Manage Repositories > Create**.

-3. On the **Extensions** page, click on the **Available** tab to select which extensions you want to install.
+   3.2. Add the desired repo name, making sure to also specify the Git repo URL and the Git branch.

-4. If no extensions are showing as available, you may manually add repos as follows:
+   3.3. Click **Create** in the lower right again to complete.

-    4.1. On the upper right of screen, click on **⋮ > Manage Repositories > Create**.
+   ![Manage repositories](/img/manage-repos.png)

-    4.2. Add the desired repo name, making sure to also specify the Git Repo URL and the Git Branch.
+4. Under the **Available** tab, click **Install** on the desired extension and version, as in the example below. You can also update your extension from this screen. The button to **Update** appears on the extension card if an update is available.

-    4.3. Click **Create** in the lower right again to complete.
+   ![Install Kubewarden](/img/install-kubewarden.png)

-    ![Manage repositories](/img/manage-repos.png)
+5. Click **Reload** after your extension successfully installs to check its status. Updates to the UI aren't visible until you reload the page.

-5. Under the **Available** tab, click **Install** on the desired extension and version as in the example below. You can also update your extension from this screen, as the button to **Update** will appear on the extension if one is available.
-
-    ![Install Kubewarden](/img/install-kubewarden.png)
-
-6. Click the **Reload** page button that will appear after your extension successfully installs. Note that a logged-in user who has just installed an extension will not see a change to the UI **unless** they reload the page.
-
-    ![Reload button](/img/reload-button.png)
+   ![Reload button](/img/reload-button.png)

 ## Updating and Upgrading Extensions

 1. Click **☰ > Extensions** under **Configuration**.
-1. Select the **Updates** tab. 
-1. Click **Update**.
+2. Select the **Updates** tab.
+3. Click **Update**.

 If there is a new version of the extension, there will also be an **Update** button visible on the associated card for the extension in the **Available** tab.

 ## Deleting Extensions

 1. Click **☰**, then click on the name of your local cluster.
-1. From the sidebar, select **Apps > Installed Apps**.
-1. Find the name of the chart you want to delete and select the checkbox next to it. 
-1. Click **Delete**.
+2. From the sidebar, select **Apps > Installed Apps**.
+3. Find the name of the chart you want to delete and select the checkbox next to it.
+4. Click **Delete**.

 ## Deleting Extension Repositories

 1. Click **☰ > Extensions** under **Configuration**.
-1. On the top right, click **⋮ > Manage Repositories**.
-1. Find the name of the extension repository you want to delete. Select the checkbox next to the repository name, then click **Delete**.
+2. On the top right, click **⋮ > Manage Repositories**.
+3. Find the name of the extension repository you want to delete. Select the checkbox next to the repository name, then click **Delete**.

 ## Deleting Extension Repository Container Images

 1. Click **☰**, then select **Extensions**, under **Configuration**.
-1. On the top right, click **⋮ > Manage Extension Catalogs**.
-1. Find the name of the container image you want to delete, then click **⋮ > Uninstall**.
+2. On the top right, click **⋮ > Manage Extension Catalogs**.
+3. Find the name of the container image you want to delete, then click **⋮ > Uninstall**.

 ## Uninstalling Extensions

@@ -79,11 +89,11 @@ There are two ways to uninstall or disable an extension:

 1. Under the **Installed** tab, click the **Uninstall** button on the extension you wish to remove.

-    ![Uninstall extensions](/img/uninstall-extension.png)
+   ![Uninstall extensions](/img/uninstall-extension.png)

-1. On the extensions management page, click **⋮ > Disable Extension Support**. This will disable all installed extensions.
+2. On the extensions management page, click **⋮ > Disable Extension Support**. This will disable all installed extensions.

-    ![Disable extensions](/img/disable-extension-support.png)
+   ![Disable extensions](/img/disable-extension-support.png)

 :::caution

@@ -91,6 +101,12 @@ You must reload the page after disabling extensions or display issues may occur.

 :::

+## Enabling Unauthenticated Access to an Extension
+
+In Rancher v2.9.0 and later, you can allow unauthenticated access to an extension. You may want to enable unauthenticated access if the extension enables a new locale or adds custom branding. By default, all extensions require user authentication to load.
+
+To enable unauthenticated access to an extension, set `plugin.noAuth` to `true` in the CR used by the extension.
+
 ## Developing Extensions

 To learn how to develop your own extensions, refer to the official [Getting Started](https://rancher.github.io/dashboard/extensions/extensions-getting-started) guide.
@@ -173,8 +189,8 @@ After you successfully set up these resources, you can install the extensions fr
 1. Click **☰**, then select **Extensions**, under **Configuration**.
 1. On the top right, click **⋮ > Manage Extension Catalogs**.
 1. Select the **Import Extension Catalog** button.
-1. Enter the image address in the **Catalog Image Reference** field. 
-    * **(Optional)** If the container image is private, select the secret you just created from the **Pull Secrets** drop-down menu.
+1. Enter the image address in the **Catalog Image Reference** field.
+    - **(Optional)** If the container image is private, select the secret you just created from the **Pull Secrets** drop-down menu.
 1. Click **Load**. The extension will now be **Pending**.
 1. Return to the **Extensions** page.
 1. Select the **Available** tab, and click **Reload** to make sure that the list of extensions is up to date.
@@ -191,7 +207,7 @@ After you mirror the latest changes, follow these steps:
 1. Click **☰ > Local**.
 1. From the sidebar, select **Workloads > Deployments**.
 1. From the namespaces dropdown menu, select **cattle-ui-plugin-system**.
-1. Find the **cattle-ui-plugin-system** namespace. 
+1. Find the **cattle-ui-plugin-system** namespace.
 1. Select the `ui-plugin-catalog` deployment.
 1. Click **⋮ > Edit config**.
 1. Update the **Container Image** field within the deployment's container with the latest image.
@@ -71,7 +71,7 @@ The following commands are available for use in Rancher CLI.
 | `login, [l]`  | Logs into a Rancher Server. For an example, see [CLI Authentication](#cli-authentication).  |
 | `machines, [machine]`  | Performs operations on machines.  |
 | `namespaces, [namespace]`  | Performs operations on [namespaces](../../how-to-guides/new-user-guides/manage-namespaces.md).  |
-| `nodes, [node]`  | Performs operations on [nodes](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md).  |
+| `nodes, [node]`  | Performs operations on [nodes](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools.md).  |
 | `projects, [project]`  | Performs operations on [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md).  |
 | `ps`  | Displays [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md) in a project.  |
 | `server`  | Performs operations for the server.  |
@@ -8,7 +8,7 @@ title: Communicating with Downstream User Clusters

 This section describes how Rancher provisions and manages the downstream user clusters that run your apps and services.

-The below diagram shows how the cluster controllers, cluster agents, and node agents allow Rancher to control downstream clusters.
+The below diagram shows how the cluster controllers, cluster agents, and Rancher system agent allow Rancher to control downstream clusters.

 <figcaption>Communicating with Downstream Clusters</figcaption>

@@ -18,7 +18,7 @@ The following descriptions correspond to the numbers in the diagram above:

 1. [The Authentication Proxy](#1-the-authentication-proxy)
 2. [Cluster Controllers and Cluster Agents](#2-cluster-controllers-and-cluster-agents)
-3. [Node Agents](#3-node-agents)
+3. [Rancher System Agent](#3-rancher-system-agent)
 4. [Authorized Cluster Endpoint](#4-authorized-cluster-endpoint)

 ## 1. The Authentication Proxy
@@ -43,7 +43,7 @@ There is one cluster controller and one cluster agent for each downstream cluste
 -  Configures access control policies to clusters and projects
 -  Provisions clusters by calling the required Docker machine drivers and Kubernetes engines, such as GKE

-By default, to enable Rancher to communicate with a downstream cluster, the cluster controller connects to the cluster agent. If the cluster agent is not available, the cluster controller can connect to a [node agent](#3-node-agents) instead.
+By default, to enable Rancher to communicate with a downstream cluster, the cluster controller connects to the cluster agent. If the cluster agent is not available, the cluster controller can connect to a [Rancher system agent](#3-rancher-system-agent) instead.

 The cluster agent, also called `cattle-cluster-agent`, is a component that runs in a downstream user cluster. It performs the following tasks:

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

-## 3. Node Agents
+## 3. Rancher System Agent

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

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

 ## 4. Authorized Cluster Endpoint

@@ -104,7 +104,8 @@ Each self-assessment guide is accompanied by a hardening guide. These guides wer
 | Standalone RKE2 | Kubernetes v1.26 | CIS v1.8 | [Link](https://docs.rke2.io/security/cis_self_assessment18) | [Link](https://docs.rke2.io/security/hardening_guide) |
 | Standalone RKE2 | Kubernetes v1.27 | CIS v1.9 | [Link](https://docs.rke2.io/security/cis_self_assessment19) | [Link](https://docs.rke2.io/security/hardening_guide) |
 | Standalone RKE2 | Kubernetes v1.28 | CIS v1.10 | [Link](https://docs.rke2.io/security/cis_self_assessment110) | [Link](https://docs.rke2.io/security/hardening_guide) |
-| Standalone RKE2 | Kubernetes v1.29 and above | CIS v1.11 | [Link](https://docs.rke2.io/security/cis_self_assessment111) | [Link](https://docs.rke2.io/security/hardening_guide) |
+| Standalone RKE2 | Kubernetes v1.29 to v1.31 | CIS v1.11 | [Link](https://docs.rke2.io/security/cis_self_assessment111) | [Link](https://docs.rke2.io/security/hardening_guide) |
+| Standalone RKE2 | Kubernetes v1.32 and above | CIS v1.12 | [Link](https://docs.rke2.io/security/cis_self_assessment112) | [Link](https://docs.rke2.io/security/hardening_guide) |

 ### K3s Guides

@@ -113,4 +114,6 @@ Each self-assessment guide is accompanied by a hardening guide. These guides wer
 | Standalone K3s | Kubernetes v1.26 | CIS v1.8 | [Link](https://docs.k3s.io/security/self-assessment-1.8) | [Link](https://docs.k3s.io/security/hardening-guide) |
 | Standalone K3s | Kubernetes v1.27 | CIS v1.9 | [Link](https://docs.k3s.io/security/self-assessment-1.9) | [Link](https://docs.k3s.io/security/hardening-guide) |
 | Standalone K3s | Kubernetes v1.28 | CIS v1.10 | [Link](https://docs.k3s.io/security/self-assessment-1.10) | [Link](https://docs.k3s.io/security/hardening-guide) |
-| Standalone K3s | Kubernetes v1.29 and above | CIS v1.11 | [Link](https://docs.k3s.io/security/self-assessment-1.11) | [Link](https://docs.k3s.io/security/hardening-guide) |
+| Standalone K3s | Kubernetes v1.29 to v1.31 | CIS v1.11 | [Link](https://docs.k3s.io/security/self-assessment-1.11) | [Link](https://docs.k3s.io/security/hardening-guide) |
+| Standalone K3s | Kubernetes v1.32 and above | CIS v1.12 | [Link](https://docs.k3s.io/security/self-assessment-1.12) | [Link](https://docs.k3s.io/security/hardening-guide) |
+
@@ -10,6 +10,13 @@ Rancher is committed to informing the community of security issues in our produc

 | ID | Description | Date | Resolution |
 |----|-------------|------|------------|
+| [CVE-2026-44949](https://github.com/rancher/webhook/security/advisories/GHSA-h83p-cq95-vph4) | Fixed a security vulnerability in rancher-webhook where the FleetWorkspace mutating admission webhook performed side effects without authenticating requests, allowing a pod inside the cluster to create arbitrary namespaces and inject RBAC bindings. | 29 June 2026 | Rancher [v2.14.3](https://github.com/rancher/rancher/releases/tag/v2.14.3), Rancher [v2.13.7](https://github.com/rancher/rancher/releases/tag/v2.13.7), Rancher [v2.12.11](https://github.com/rancher/rancher/releases/tag/v2.12.11) and Rancher [v2.11.15](https://github.com/rancher/rancher/releases/tag/v2.11.15) |
+| [CVE-2026-44947](https://github.com/rancher/rancher/security/advisories/GHSA-c4rp-wgqc-mfhc) | Fixed a security vulnerability in Rancher's legacy PRTB reconciler where removing the `updatepsa` permission from a RoleTemplate did not clean up stale PSA ClusterRole and ClusterRoleBinding resources, allowing affected users to retain unauthorized Pod Security Admission access indefinitely. | 29 June 2026 | Rancher [v2.14.3](https://github.com/rancher/rancher/releases/tag/v2.14.3) and Rancher [v2.13.7](https://github.com/rancher/rancher/releases/tag/v2.13.7) |
+| [CVE-2026-44946](https://github.com/rancher/rancher/security/advisories/GHSA-c5jm-xcmq-9j95) | Fixed a security vulnerability in Rancher's SAML authentication handler where a valid signed SAML response could be replayed by an attacker who had also captured the victim's pre-authentication SAML state cookie, allowing the attacker to create a separate authenticated session with the victim's permissions. All SAML providers (Okta, Ping, ADFS, Keycloak, Shibboleth) were affected. | 29 June 2026 | Rancher [v2.14.3](https://github.com/rancher/rancher/releases/tag/v2.14.3), Rancher [v2.13.7](https://github.com/rancher/rancher/releases/tag/v2.13.7), Rancher [v2.12.11](https://github.com/rancher/rancher/releases/tag/v2.12.11) and Rancher [v2.11.15](https://github.com/rancher/rancher/releases/tag/v2.11.15) |
+| [CVE-2026-41053](https://github.com/rancher/rancher/security/advisories/GHSA-4j6x-2764-m8gh) | Fixed a security vulnerability in the GitHub App authentication provider where users incorrectly inherited permissions from all teams within their GitHub organization, rather than only the specific teams to which they belonged. Upon upgrading, Rancher automatically triggers a mandatory refresh of all affected user `principals` to remove these incorrectly assigned team memberships and restore proper access. | 27 May 2026 | Rancher [v2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2), Rancher [v2.13.6](https://github.com/rancher/rancher/releases/tag/v2.13.6) |
+| [CVE-2026-41052](https://github.com/rancher/rancher/security/advisories/GHSA-vx8h-4prv-g744) | Updated the permissions of the built-in `project-owner` role to no longer include the `updatepsa` verb. This prevents users with this role from bypassing restricted PSA policies or deploying privileged workloads within their projects. If your organization requires users to retain this capability, administrators must create a custom project role that explicitly grants the `updatepsa` verb for the project resource. | 27 May 2026 | Rancher [v2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2), Rancher [v2.13.6](https://github.com/rancher/rancher/releases/tag/v2.13.6), [v2.12.10](https://github.com/rancher/rancher/releases/tag/v2.12.10) |
+| [CVE-2026-44939](https://github.com/rancher/rancher/security/advisories/GHSA-mhc6-2gfq-xx62) | Rancher now validates the `authImage` parameter in cluster import manifests to prevent YAML injection attacks. | 27 May 2026 | Rancher [v2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2), Rancher [v2.13.6](https://github.com/rancher/rancher/releases/tag/v2.13.6), [v2.12.10](https://github.com/rancher/rancher/releases/tag/v2.12.10), [v2.11.14](https://github.com/rancher/rancher/releases/tag/v2.11.14), and [v2.10.12](https://github.com/rancher/rancher/releases/tag/v2.10.12) |
+| [CVE-2026-25705](https://github.com/rancher/rancher/security/advisories/GHSA-5v3h-x4wf-5c35) | Rancher now protects against arbitrary file access via path traversal in Rancher Extensions. Note by default only users with administrative permissions can deploy UI extensions unless explicit permission is granted to other users. | 30 Apr 2026 | Rancher [v2.14.1](https://github.com/rancher/rancher/releases/tag/v2.14.1), [v2.13.5](https://github.com/rancher/rancher/releases/tag/v2.13.5), [v2.12.9](https://github.com/rancher/rancher/releases/tag/v2.12.9), and [v2.11.13](https://github.com/rancher/rancher/releases/tag/v2.11.13) |
 | [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
 | [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
 | [CVE-2023-32199](https://github.com/rancher/rancher/security/advisories/GHSA-j4vr-pcmw-hx59) | Rancher now removes the corresponding ClusterRoleBindings whenever the admin GlobalRole or its GlobalRoleBindings are deleted. Previously orphaned ClusterRoleBindings were marked with the annotation `authz.cluster.cattle.io/admin-globalrole-missing=true`. | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) and [v2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) |
@@ -8,6 +8,12 @@ title: About rancher-selinux

 To allow Rancher to work with SELinux, some functionality has to be manually enabled for the SELinux nodes. To help with that, Rancher provides an SELinux RPM.

+:::tip Why SELinux?
+
+By assigning a dedicated SELinux type to each container, we ensure that containers are limited to their minimal needs and cannot pivot to other resources if compromised.
+
+:::
+
 The `rancher-selinux` RPM contains a set of SELinux policies designed to grant the necessary privileges to various Rancher components running on Linux systems with SELinux enabled.

 The `rancher-selinux` GitHub repository is [here.](https://github.com/rancher/rancher-selinux)
@@ -16,7 +22,7 @@ The `rancher-selinux` GitHub repository is [here.](https://github.com/rancher/ra

 :::note Requirement:

-The `rancher-selinux` RPM was tested on openSUSE Tumbleweed and RHEL-based distributions including Centos/RockyLinux 8 and 9. 
+The `rancher-selinux` RPM was tested on openSUSE MicroOS, Fedora 42, and RHEL-based distributions including CentOS/RockyLinux 8, 9, and 10.

 :::

@@ -50,6 +56,19 @@ gpgkey=https://rpm.rancher.io/public.key
 EOF
 ```

+In order to use the RPM repository, on a CentOS 10 or RHEL 10 system, run the following bash snippet:
+
+```
+# cat << EOF > /etc/yum.repos.d/rancher.repo 
+[rancher] 
+name=Rancher 
+baseurl=https://rpm.rancher.io/rancher/production/centos/10/noarch
+enabled=1 
+gpgcheck=1 
+gpgkey=https://rpm.rancher.io/public.key 
+EOF
+```
+
 ### 2. Installing the RPM

 Install the RPM:
@@ -58,14 +77,16 @@ Install the RPM:
 yum -y install rancher-selinux
 ```

-## Configuring the Logging and Monitoring Applications to Work with SELinux
+## Configuring Applications to Work with SELinux

 :::note Requirement:

-Logging v2 and Monitoring v2 were tested with SELinux on RHEL/CentOS 8, 9, and Tumbleweed.
+Logging v2, Monitoring v2, and Rancher AI were tested with SELinux on RHEL/CentOS 8, 9, 10, and Tumbleweed.

 :::

-Applications do not automatically work once the `rancher-selinux` RPM is installed on the host. They need to be configured to run in an allowed SELinux container domain provided by the RPM. 
+The `rancher-selinux` RPM currently covers the following charts: **Logging**, **Monitoring**, and **Rancher AI**.

-To configure the `rancher-logging` or the `rancher-monitoring` chart to be SELinux aware, change `global.seLinux.enabled` to true in the `values.yaml` when installing the charts.
+Applications do not automatically work once the `rancher-selinux` RPM is installed on the host. They need to be configured to run in an allowed SELinux container domain provided by the RPM.
+
+To configure these charts to be SELinux aware, change `global.seLinux.enabled` to true in the `values.yaml` when installing the charts.
@@ -20,10 +20,10 @@ 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.13.3         |     v0.9.3      | &check;               | &check;                   |
-| v2.13.2         |     v0.9.2      | &check;               | &check;                   |
-| v2.13.1         |     v0.9.1      | &check;               | &check;                   |
-| v2.13.0         |     v0.9.0      | &cross;               | &check;                   |
+| v2.14.3         |    v0.10.7      | &check;               | &check;                   |
+| v2.14.2         |    v0.10.6      | &check;               | &check;                   |
+| v2.14.1         |    v0.10.4      | &check;               | &check;                   |
+| v2.14.0         |    v0.10.0      | &cross;               | &check;                   |

 ## Why Do We Need It?

@@ -6,6 +6,8 @@ title: API Keys
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/user-settings/api-keys"/>
 </head>

+<v3APITokensDeprecationWarning />
+
 ## API Keys and User Authentication

 If you want to access your Rancher clusters, projects, or other objects using external applications, you can do so using the Rancher API. However, before your application can access the API, you must provide the app with a key used to authenticate with Rancher. You can obtain a key using the Rancher UI.
@@ -6,20 +6,11 @@ title: Managing Cloud Credentials
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/user-settings/manage-cloud-credentials"/>
 </head>

-When you create a cluster [hosted by an infrastructure provider](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md), [node templates](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node.
-
-Node templates can use cloud credentials to access the credential information required to provision nodes in the infrastructure providers. The same cloud credential can be used by multiple node templates. By using a cloud credential, you do not have to re-enter access keys for the same cloud provider. Cloud credentials are stored as Kubernetes secrets.
-
-Cloud credentials are only used by node templates if there are fields marked as `password`. The default `active` node drivers have their account access fields marked as `password`, but there may be some `inactive` node drivers, which are not using them yet. These node drivers will not use cloud credentials.
-
-You can create cloud credentials in two contexts:
-
- [During creation of a node template](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) for a cluster.
- In the **User Settings**
+The creation or association of cloud credentials are part of the cluster creation process, the information below provides guidance on managing credentials in Rancher.

 Cloud credentials are bound to their creator's user profile. They **cannot** be shared between non-admin users. However, admins can view and manage the cloud credentials of other users.

-## Creating a Cloud Credential from User Settings
+## Creating a Cloud Credential

 1. Click **☰ > Cluster Management**.
 1. Click **Cloud Credentials**.
@@ -29,23 +20,19 @@ Cloud credentials are bound to their creator's user profile. They **cannot** be
 1. Based on the selected cloud credential type, enter the required values to authenticate with the infrastructure provider.
 1. Click **Create**.

-**Result:** The cloud credential is created and can immediately be used to [create node templates](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates).
+**Result:** The cloud credential is created.

 ## Updating a Cloud Credential

-When access credentials are changed or compromised, updating a cloud credential allows you to rotate those credentials while keeping the same node template.
-
 1. Click **☰ > Cluster Management**.
 1. Click **Cloud Credentials**.
 1. Choose the cloud credential you want to edit and click the **⋮ > Edit Config**.
 1. Update the credential information and click **Save**.

-**Result:** The cloud credential is updated with the new access credentials. All existing node templates using this cloud credential will automatically use the updated information whenever [new nodes are added](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).
+**Result:** The cloud credential is updated with the new access credentials.

 ## Deleting a Cloud Credential

-In order to delete cloud credentials, there must not be any node template associated with it. If you are unable to delete the cloud credential, [delete any node templates](manage-node-templates.md#deleting-a-node-template) that are still associated to that cloud credential.
-
 1. Click **☰ > Cluster Management**.
 1. Click **Cloud Credentials**.
 1. You can either individually delete a cloud credential or bulk delete.
@@ -1,58 +0,0 @@
---
-title: Managing Node Templates
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/user-settings/manage-node-templates"/>
-</head>
-
-When you provision a cluster [hosted by an infrastructure provider](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md), [node templates](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node. You can create node templates in two contexts:
-
- While [provisioning a node pool cluster](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).
- At any time, from your [user settings](user-settings.md).
-
-When you create a node template, it is bound to your user profile. Node templates cannot be shared among users. You can delete stale node templates that you no longer user from your user settings.
-
-## Creating a Node Template
-
-1. Click **☰ > Cluster Management**.
-1. Click **RKE1 Configuration > Node Templates**.
-1. Click **Add Template**.
-1. Select one of the cloud providers available. Then follow the instructions on screen to configure the template.
-
-**Result:** The template is configured. You can use the template later when you [provision a node pool cluster](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).
-
-## Updating a Node Template
-
-1. Click **☰ > Cluster Management**.
-1. Click **RKE1 Configuration > Node Templates**.
-1. Choose the node template that you want to edit and click the **⋮ > Edit**.
-
-    :::note
-
-    The default `active` [node drivers](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md) and any node driver, that has fields marked as `password`, are required to use [cloud credentials](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#cloud-credentials).
-
-    :::
-
-1. Edit the required information and click **Save**.
-
-**Result:** The node template is updated. All node pools using this node template will automatically use the updated information when new nodes are added.
-
-## Cloning Node Templates
-
-When creating new node templates from your user settings, you can clone an existing template and quickly update its settings rather than creating a new one from scratch. Cloning templates saves you the hassle of re-entering access keys for the cloud provider.
-
-1. Click **☰ > Cluster Management**.
-1. Click **RKE1 Configuration > Node Templates**.
-1. Find the template you want to clone. Then select **⋮ > Clone**.
-1. Complete the rest of the form.
-
-**Result:** The template is cloned and configured. You can use the template later when you [provision a node pool cluster](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).
-
-## Deleting a Node Template
-
-When you no longer use a node template, you can delete it from your user settings.
-
-1. Click **☰ > Cluster Management**.
-1. Click **RKE1 Configuration > Node Templates**.
-1. Select one or more template from the list. Then click **Delete**. Confirm the delete when prompted.
@@ -13,7 +13,6 @@ Within Rancher, each user has a number of settings associated with their login:
 The available user settings are:

 - [API & Keys](api-keys.md): If you want to interact with Rancher programmatically, you need an API key. Follow the directions in this section to obtain a key.
- [Cloud Credentials](manage-cloud-credentials.md): Manage cloud credentials [used by node templates](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) to [provision nodes for clusters](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
- [Node Templates](manage-node-templates.md): Manage templates [used by Rancher to provision nodes for clusters](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
+- [Cloud Credentials](manage-cloud-credentials.md): Manage cloud credentials used by machine pools to [provision nodes for clusters](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
 - [Preferences](user-preferences.md): Sets superficial preferences for the Rancher UI.
 - Log Out: Ends your user session.
@@ -3,7 +3,7 @@
 | [Using kubectl and a kubeconfig file to Access a Cluster](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) | ✓ | ✓ | ✓ | ✓ |
 | [Managing Cluster Members](../how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md) | ✓ | ✓ | ✓ | ✓ |
 | [Editing and Upgrading Clusters](../reference-guides/cluster-configuration/cluster-configuration.md) | ✓ | ✓ | ✓ | ✓<sup>2</sup> |
-| [Managing Nodes](../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md) | ✓ | ✓ | ✓ | ✓<sup>3</sup> |
+| [Managing Nodes](../how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools.md) | ✓ | ✓ | ✓ | ✓<sup>3</sup> |
 | [Managing Persistent Volumes and Storage Classes](../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) | ✓ | ✓ | ✓ | ✓ |
 | [Managing Projects, Namespaces and Workloads](../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md) | ✓ | ✓ | ✓ | ✓ |
 | [Using App Catalogs](../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md) | ✓ | ✓ | ✓ | ✓ |
@@ -6,31 +6,55 @@ title: Troubleshooting Controlplane Nodes
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/troubleshooting/kubernetes-components/troubleshooting-controlplane-nodes"/>
 </head>

-This section applies to nodes with the `controlplane` role.
+This section applies to nodes with the `controlplane` role in RKE2 and K3s clusters.

-## Check if the Controlplane Containers are Running
+## Prerequisites

-There are three specific containers launched on nodes with the `controlplane` role:
+As RKE2 and K3s rely on `containerd` as the container runtime, `crictl` replaces Docker for container management. Before proceeding with the troubleshooting commands, configure your environment by exporting the following variables:
+
+### RKE2
+
+```bash
+export PATH=$PATH:/var/lib/rancher/rke2/bin/
+export CRI_CONFIG_FILE=/var/lib/rancher/rke2/agent/etc/crictl.yaml
+```
+
+### K3s
+
+```bash
+export PATH=$PATH:/usr/local/bin
+export CRI_CONFIG_FILE=/var/lib/rancher/k3s/agent/etc/crictl.yaml
+```
+
+## Check if the Controlplane Components are Running
+
+**RKE2**: There are three specific containers launched on nodes with the `controlplane` role:

 * `kube-apiserver`
 * `kube-controller-manager`
 * `kube-scheduler`

-The containers should have status **Up**. The duration shown after **Up** is the time the container has been running.
+The containers should have state **Running**. You can check this using `crictl`:

-```
-docker ps -a -f=name='kube-apiserver|kube-controller-manager|kube-scheduler'
+```bash
+crictl ps | grep -E 'kube-apiserver|kube-controller-manager|kube-scheduler'
 ```

 Example output:
 ```
-CONTAINER ID        IMAGE                                COMMAND                  CREATED             STATUS              PORTS               NAMES
-26c7159abbcc        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."   3 hours ago         Up 3 hours                              kube-apiserver
-f3d287ca4549        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."   3 hours ago         Up 3 hours                              kube-scheduler
-bdf3898b8063        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."   3 hours ago         Up 3 hours                              kube-controller-manager
+CONTAINER           IMAGE               CREATED             STATE               NAME                            ATTEMPT             POD ID              POD                                     NAMESPACE
+deb8a96948594       138b1e685e151       11 days ago         Running             kube-controller-manager         0                   0996426295dc5       kube-controller-manager                 kube-system
+f5abb4c7846e4       138b1e685e151       11 days ago         Running             kube-scheduler                  0                   80cd9f30af0be       kube-scheduler                          kube-system
+ecd8a6991c22a       138b1e685e151       11 days ago         Running             kube-apiserver                  0                   58e042fabe78c       kube-apiserver                          kube-system
 ```

-## Controlplane Container Logging
+**K3s**: These components run as embedded processes within the K3s service. They do not run as separate containers, so their status is tied to the `k3s` systemd service:
+
+```bash
+systemctl status k3s
+```
+
+## Controlplane Logging

 :::note

@@ -38,18 +62,32 @@ If you added multiple nodes with the `controlplane` role, both `kube-controller-

 :::

-The logging of the containers can contain information on what the problem could be.
+The logs can contain information on what the problem could be.

-```
-docker logs kube-apiserver
-docker logs kube-controller-manager
-docker logs kube-scheduler
+**RKE2**:
+```bash
+crictl logs $(crictl ps --name kube-apiserver -q)
+crictl logs $(crictl ps --name kube-controller-manager -q)
+crictl logs $(crictl ps --name kube-scheduler -q)
 ```

-## RKE2 Server Logging
-
-If Rancher provisions an RKE2 cluster that can't communicate with Rancher, you can run this command on a server node in the downstream cluster to get the RKE2 server logs:
-
+**K3s**:
+```bash
+journalctl -u k3s | grep -i "kube-apiserver"
+journalctl -u k3s | grep -i "kube-controller-manager"
+journalctl -u k3s | grep -i "kube-scheduler"
 ```
+
+## RKE2/K3s Server Logging
+
+If Rancher provisions an RKE2 or K3s cluster that can't communicate with Rancher, you can run this command on a server node in the downstream cluster to get the server logs:
+
+**RKE2**:
+```bash
 journalctl -u rke2-server -f
+```
+
+**K3s**:
+```bash
+journalctl -u k3s -f
 ```
@@ -6,29 +6,63 @@ title: Troubleshooting etcd Nodes
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes"/>
 </head>

-This section contains commands and tips for troubleshooting nodes with the `etcd` role.
+This section contains commands and tips for troubleshooting nodes with the `etcd` role in RKE2 and K3s clusters.
+
+## Prerequisites
+
+As RKE2 and K3s rely on `containerd` as the container runtime, `crictl` replaces Docker for container management. Before proceeding with the troubleshooting commands, configure your environment by exporting the following variables:
+
+### RKE2
+
+```bash
+export PATH=$PATH:/var/lib/rancher/rke2/bin/
+export CRI_CONFIG_FILE=/var/lib/rancher/rke2/agent/etc/crictl.yaml
+etcdcontainer=$(crictl ps --name etcd --quiet)
+```
+
+### K3s
+
+> ### ⚠️ **Warning**
+> K3s does not include `etcdctl` in the system PATH. If you need to perform etcd troubleshooting on a K3s cluster, you may need to install it or locate it within the K3s data directory.
+
+```bash
+export PATH=$PATH:/usr/local/bin
+export CRI_CONFIG_FILE=/var/lib/rancher/k3s/agent/etc/crictl.yaml
+```


 ## Checking if the etcd Container is Running

-The container for etcd should have status **Up**. The duration shown after **Up** is the time the container has been running.
+**RKE2**: The container for etcd should be in the **Running**  state.

-```
-docker ps -a -f=name=etcd$
+```bash
+crictl ps --name etcd
 ```

 Example output:
 ```
-CONTAINER ID   IMAGE                                 COMMAND                  CREATED          STATUS          PORTS     NAMES
-d26adbd23643   rancher/mirrored-coreos-etcd:v3.5.7   "/usr/local/bin/etcd…"   30 minutes ago   Up 30 minutes             etcd
+CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID              POD                 NAMESPACE
+f1e289d202ed0       11ad16872a9cf       58 minutes ago      Running             etcd                0                   7b56aab8204ea       etcd-cluster1     kube-system
 ```

-## etcd Container Logging
-
-The logging of the container can contain information on what the problem could be.
+**K3s**: Etcd runs as an embedded process in the K3s service. Check the service status:

+```bash
+systemctl status k3s
 ```
-docker logs etcd
+
+## etcd Logging
+
+The logs can contain information on what the problem could be.
+
+**RKE2**:
+```bash
+crictl logs $etcdcontainer
+```
+
+**K3s**:
+```bash
+journalctl -u k3s | grep -i etcd
 ```
 | Log | Explanation |
 |-----|------------------|
@@ -46,18 +80,43 @@ The address where etcd is listening depends on the address configuration of the

 Output should contain all the nodes with the `etcd` role and the output should be identical on all nodes.

-Command:
+**RKE2**:
+Run the command inside the etcd container.
+
+```bash
+crictl exec $etcdcontainer etcdctl member list \
+  --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt \
+  --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key \
+  --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt
 ```
-docker exec etcd etcdctl member list
+
+**K3s**:
+```bash
+etcdctl member list \
+  --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt \
+  --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key \
+  --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
+```
+
+Example output:
+```
+1c424074df86e854, started, cluster-node1-f289ac71, https://IP:2380, https://IP:2379, false
+45c68c44c5a792ff, started, cluster-node2-67e3cf6f, https://IP:2380, https://IP:2379, false
+7c584f77c5180258, started, cluster-node3-e976bc00, https://IP:2380, https://IP:2379, false
 ```

 ### Check Endpoint Status

 The values for `RAFT TERM` should be equal and `RAFT INDEX` should be not be too far apart from each other.

-Command:
+**RKE2**:
+```bash
+crictl exec $etcdcontainer etcdctl endpoint status --write-out table --endpoints=$(crictl exec $etcdcontainer etcdctl member list --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt | cut -d, -f5 | sed -e 's/ //g' | paste -sd ',') --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt
 ```
-docker exec -e ETCDCTL_ENDPOINTS=$(docker exec etcd etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ',') etcd etcdctl endpoint status --write-out table
+
+**K3s**:
+```bash
+etcdctl endpoint status --write-out table --endpoints=$(etcdctl member list --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt | cut -d, -f5 | sed -e 's/ //g' | paste -sd ',') --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
 ```

 Example output:
@@ -65,17 +124,22 @@ Example output:
 +-----------------+------------------+---------+---------+-----------+-----------+------------+
 | ENDPOINT        |        ID        | VERSION | DB SIZE | IS LEADER | RAFT TERM | RAFT INDEX |
 +-----------------+------------------+---------+---------+-----------+-----------+------------+
-| https://IP:2379 | 333ef673fc4add56 |  3.5.7  |   24 MB |     false |        72 |      66887 |
-| https://IP:2379 | 5feed52d940ce4cf |  3.5.7  |   24 MB |      true |        72 |      66887 |
-| https://IP:2379 | db6b3bdb559a848d |  3.5.7  |   25 MB |     false |        72 |      66887 |
+| https://IP:2379 | 333ef673fc4add56 |  3.6.7  |   24 MB |     false |        72 |      66887 |
+| https://IP:2379 | 5feed52d940ce4cf |  3.6.7  |   24 MB |      true |        72 |      66887 |
+| https://IP:2379 | db6b3bdb559a848d |  3.6.7  |   25 MB |     false |        72 |      66887 |
 +-----------------+------------------+---------+---------+-----------+-----------+------------+
 ```

 ### Check Endpoint Health

-Command:
+**RKE2**:
+```bash
+crictl exec $etcdcontainer etcdctl endpoint health --endpoints=$(crictl exec $etcdcontainer etcdctl member list --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt | cut -d, -f5 | sed -e 's/ //g' | paste -sd ',') --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt
 ```
-docker exec -e ETCDCTL_ENDPOINTS=$(docker exec etcd etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ',') etcd etcdctl endpoint health
+
+**K3s**:
+```bash
+etcdctl endpoint health --endpoints=$(etcdctl member list --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt | cut -d, -f5 | sed -e 's/ //g' | paste -sd ',') --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
 ```

 Example output:
@@ -84,54 +148,104 @@ https://IP:2379 is healthy: successfully committed proposal: took = 2.113189ms
 https://IP:2379 is healthy: successfully committed proposal: took = 2.649963ms
 https://IP:2379 is healthy: successfully committed proposal: took = 2.451201ms
 ```
+### Check Connectivity on etcd Ports

-### Check Connectivity on Port TCP/2379
+> In modern versions of Kubernetes, the etcd database (versions 3.5 and newer) introduced significant architectural changes regarding network traffic handling. Previously, etcd permitted standard HTTP REST requests on its primary client port (`2379`). However, to enhance performance and security, etcd 3.5+ strictly enforces the gRPC protocol on this port.<br />
+If you attempt to use standard HTTP tools like `curl` to test connectivity on port `2379`, the etcd server will automatically terminate the connection or return an error. This behavior often leads administrators to misinterpret the result as a closed port or a node failure.

-Command:
+Since standard HTTP clients can no longer probe the primary etcd ports, the transport layer must be utilized for network troubleshooting. Using `openssl s_client` instead of `curl` bypasses the gRPC application requirement, allowing the raw TCP and TLS handshake to be tested directly.
+
+These script isolate the network and security infrastructure from the database application. A successful `Verify return code: 0 (ok)` explicitly confirms four critical infrastructure components:
+
+* **Network Path:** Routing is functional, and firewalls permit traffic on TCP port `2379` or `2380`.
+* **Process Availability:** The etcd service is running and actively listening on the designated port.
+* **Certificate Validity:** The TLS certificates are active, correctly formatted, and have not expired.
+* **Mutual Authentication (mTLS):** The node successfully authenticates against the cluster's specific Certificate Authority (CA).
+
+**How these tests differ from the `etcdctl endpoint health` test**:
+
+If `etcdctl endpoint health` test is failing, run these Connectivity Ports test scripts. If the scripts succeed, your network and certificates are intact, and the issue is likely confined to the etcd database itself. If these scripts fail, the issue is related to a firewall/network restriction, or certificate expiration.
+
+#### Port TCP/2379
+
+**RKE2**:
+```bash
+for endpoint in $(crictl exec $etcdcontainer etcdctl member list --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt | cut -d, -f5); do
+  echo "Validating connection to ${endpoint} (Client)";
+  echo | openssl s_client -connect ${endpoint#https://} \
+    -CAfile /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
+    -cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt \
+    -key /var/lib/rancher/rke2/server/tls/etcd/server-client.key 2>/dev/null | grep -E 'Verify return code' || echo "Connection Failed/Timeout"
+done
 ```
-for endpoint in $(docker exec etcd etcdctl member list | cut -d, -f5); do
-   echo "Validating connection to ${endpoint}/health"
-   docker run --net=host -v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -w "\n" --cacert $(docker inspect -f '{{range $index, $value := .Config.Env}}{{if eq (index (split $value "=") 0) "ETCDCTL_CACERT" }}{{range $i, $part := (split $value "=")}}{{if gt $i 1}}{{print "="}}{{end}}{{if gt $i 0}}{{print $part}}{{end}}{{end}}{{end}}{{end}}' etcd) --cert $(docker inspect -f '{{range $index, $value := .Config.Env}}{{if eq (index (split $value "=") 0) "ETCDCTL_CERT" }}{{range $i, $part := (split $value "=")}}{{if gt $i 1}}{{print "="}}{{end}}{{if gt $i 0}}{{print $part}}{{end}}{{end}}{{end}}{{end}}' etcd) --key $(docker inspect -f '{{range $index, $value := .Config.Env}}{{if eq (index (split $value "=") 0) "ETCDCTL_KEY" }}{{range $i, $part := (split $value "=")}}{{if gt $i 1}}{{print "="}}{{end}}{{if gt $i 0}}{{print $part}}{{end}}{{end}}{{end}}{{end}}' etcd) "${endpoint}/health"
+
+**K3s**:
+```bash
+for endpoint in $(etcdctl member list --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt | cut -d, -f5); do
+  echo "Validating connection to ${endpoint} (Client)";
+  echo | openssl s_client -connect ${endpoint#https://} \
+    -CAfile /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt \
+    -cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt \
+    -key /var/lib/rancher/k3s/server/tls/etcd/server-client.key 2>/dev/null | grep -E 'Verify return code' || echo "Connection Failed/Timeout"
 done
 ```

 Example output:
 ```
-Validating connection to https://IP:2379/health
-{"health": "true"}
-Validating connection to https://IP:2379/health
-{"health": "true"}
-Validating connection to https://IP:2379/health
-{"health": "true"}
+Validating connection to https://IP:2379/health (Client)
+Verify return code: 0 (ok)
+Validating connection to https://IP:2379/health (Client)
+Verify return code: 0 (ok)
+Validating connection to https://IP:2379/health (Client)
+Verify return code: 0 (ok)
 ```

-### Check Connectivity on Port TCP/2380
+#### Port TCP/2380

-Command:
+**RKE2**:
+```bash
+for endpoint in $(crictl exec $etcdcontainer etcdctl member list --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt | cut -d, -f4); do
+  echo "Validating connection to ${endpoint} (Peer)";
+  echo | openssl s_client -connect ${endpoint#https://} \
+    -CAfile /var/lib/rancher/rke2/server/tls/etcd/peer-ca.crt \
+    -cert /var/lib/rancher/rke2/server/tls/etcd/peer-server-client.crt \
+    -key /var/lib/rancher/rke2/server/tls/etcd/peer-server-client.key 2>/dev/null | grep -E 'Verify return code' || echo "Connection Failed/Timeout"
+done
 ```
-for endpoint in $(docker exec etcd etcdctl member list | cut -d, -f4); do
-  echo "Validating connection to ${endpoint}/version";
-  docker run --net=host -v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro appropriate/curl --http1.1 -s -w "\n" --cacert $(docker inspect -f '{{range $index, $value := .Config.Env}}{{if eq (index (split $value "=") 0) "ETCDCTL_CACERT" }}{{range $i, $part := (split $value "=")}}{{if gt $i 1}}{{print "="}}{{end}}{{if gt $i 0}}{{print $part}}{{end}}{{end}}{{end}}{{end}}' etcd) --cert $(docker inspect -f '{{range $index, $value := .Config.Env}}{{if eq (index (split $value "=") 0) "ETCDCTL_CERT" }}{{range $i, $part := (split $value "=")}}{{if gt $i 1}}{{print "="}}{{end}}{{if gt $i 0}}{{print $part}}{{end}}{{end}}{{end}}{{end}}' etcd) --key $(docker inspect -f '{{range $index, $value := .Config.Env}}{{if eq (index (split $value "=") 0) "ETCDCTL_KEY" }}{{range $i, $part := (split $value "=")}}{{if gt $i 1}}{{print "="}}{{end}}{{if gt $i 0}}{{print $part}}{{end}}{{end}}{{end}}{{end}}' etcd) "${endpoint}/version"
+
+**K3s**:
+```bash
+for endpoint in $(etcdctl member list --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt | cut -d, -f4); do
+  echo "Validating connection to ${endpoint} (Peer)";
+  echo | openssl s_client -connect ${endpoint#https://} \
+    -CAfile /var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt \
+    -cert /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.crt \
+    -key /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.key 2>/dev/null | grep -E 'Verify return code' || echo "Connection Failed/Timeout"
 done
 ```

 Example output:
 ```
-Validating connection to https://IP:2380/version
-{"etcdserver":"3.5.7","etcdcluster":"3.5.0"}
-Validating connection to https://IP:2380/version
-{"etcdserver":"3.5.7","etcdcluster":"3.5.0"}
-Validating connection to https://IP:2380/version
-{"etcdserver":"3.5.7","etcdcluster":"3.5.0"}
+Validating connection to https://IP:2380/version (Peer)
+Verify return code: 0 (ok)
+Validating connection to https://IP:2380/version (Peer)
+Verify return code: 0 (ok)
+Validating connection to https://IP:2380/version (Peer)
+Verify return code: 0 (ok)
 ```

 ## etcd Alarms

 etcd will trigger alarms, for instance when it runs out of space.

-Command:
+**RKE2**:
+```bash
+crictl exec $etcdcontainer etcdctl alarm list --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt
 ```
-docker exec etcd etcdctl alarm list
+
+**K3s**:
+```bash
+etcdctl alarm list --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
 ```

 Example output when NOSPACE alarm is triggered:
@@ -154,10 +268,16 @@ Resolutions:

 ### Compact the Keyspace

-Command:
+**RKE2**:
+```bash
+rev=$(crictl exec $etcdcontainer etcdctl endpoint status --write-out json --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt | egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*' | head -1)
+crictl exec $etcdcontainer etcdctl compact "$rev" --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt
 ```
-rev=$(docker exec etcd etcdctl endpoint status --write-out json | egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*')
-docker exec etcd etcdctl compact "$rev"
+
+**K3s**:
+```bash
+rev=$(etcdctl endpoint status --write-out json --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt | egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*' | head -1)
+etcdctl compact "$rev" --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
 ```

 Example output:
@@ -167,55 +287,39 @@ compacted revision xxx

 ### Defrag All etcd Members

-Command:
+**RKE2**:
+```bash
+crictl exec $etcdcontainer etcdctl defrag --endpoints=$(crictl exec $etcdcontainer etcdctl member list --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt | cut -d, -f5 | sed -e 's/ //g' | paste -sd ',') --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt
 ```
-docker exec -e ETCDCTL_ENDPOINTS=$(docker exec etcd etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ',') etcd etcdctl defrag
+
+**K3s**:
+```bash
+etcdctl defrag --endpoints=$(etcdctl member list --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt | cut -d, -f5 | sed -e 's/ //g' | paste -sd ',') --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
 ```

 Example output:
 ```
-Finished defragmenting etcd member[https://IP:2379]
-Finished defragmenting etcd member[https://IP:2379]
-Finished defragmenting etcd member[https://IP:2379]
-```
-
-### Check Endpoint Status
-
-Command:
-```
-docker exec -e ETCDCTL_ENDPOINTS=$(docker exec etcd etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ',') etcd etcdctl endpoint status --write-out table
-```
-
-Example output:
-```
-+-----------------+------------------+---------+---------+-----------+-----------+------------+
-| ENDPOINT        |        ID        | VERSION | DB SIZE | IS LEADER | RAFT TERM | RAFT INDEX |
-+-----------------+------------------+---------+---------+-----------+-----------+------------+
-| https://IP:2379 |  e973e4419737125 |  3.5.7  |  553 kB |     false |        32 |    2449410 |
-| https://IP:2379 | 4a509c997b26c206 |  3.5.7  |  553 kB |     false |        32 |    2449410 |
-| https://IP:2379 | b217e736575e9dd3 |  3.5.7  |  553 kB |      true |        32 |    2449410 |
-+-----------------+------------------+---------+---------+-----------+-----------+------------+
+Finished defragmenting etcd member[https://IP:2379]. took xx.xxxxxxms
+Finished defragmenting etcd member[https://IP:2379]. took xx.xxxxxxms
+Finished defragmenting etcd member[https://IP:2379]. took xx.xxxxxxms
 ```

 ### Disarm Alarm

 After verifying that the DB size went down after compaction and defragmenting, the alarm needs to be disarmed for etcd to allow writes again.

-Command:
-```
-docker exec etcd etcdctl alarm list
-docker exec etcd etcdctl alarm disarm
-docker exec etcd etcdctl alarm list
+**RKE2**:
+```bash
+crictl exec $etcdcontainer etcdctl alarm list --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt
+crictl exec $etcdcontainer etcdctl alarm disarm --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt
+crictl exec $etcdcontainer etcdctl alarm list --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt
 ```

-Example output:
-```
-docker exec etcd etcdctl alarm list
-memberID:x alarm:NOSPACE
-memberID:x alarm:NOSPACE
-memberID:x alarm:NOSPACE
-docker exec etcd etcdctl alarm disarm
-docker exec etcd etcdctl alarm list
+**K3s**:
+```bash
+etcdctl alarm list --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
+etcdctl alarm disarm --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
+etcdctl alarm list --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
 ```

 ## Configure Log Level
@@ -228,7 +332,7 @@ You can no longer dynamically change the log level in etcd v3.5 or later.

 ### etcd v3.5 And Later

-To configure the log level for etcd, edit the cluster YAML:
+To configure the log level for etcd, edit the cluster configuration YAML:

 ```
 services:
@@ -237,20 +341,7 @@ services:
      log-level: "debug"
 ```

-### etcd v3.4 And Earlier
-
-In earlier etcd versions, you can use the API to dynamically change the log level.  Configure debug logging using the commands below:
-
-```
-docker run --net=host -v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -XPUT -d '{"Level":"DEBUG"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) $(docker exec etcd printenv ETCDCTL_ENDPOINTS)/config/local/log
-```
-
-To reset the log level back to the default (`INFO`), you can use the following command.
-
-Command:
-```
-docker run --net=host -v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -XPUT -d '{"Level":"INFO"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) $(docker exec etcd printenv ETCDCTL_ENDPOINTS)/config/local/log
-```
+After modifying the configuration, restart the service (`systemctl restart rke2-server` or `systemctl restart k3s`) if you are configuring a stand-alone cluster.

 ## etcd Content

@@ -258,24 +349,40 @@ If you want to investigate the contents of your etcd, you can either watch strea

 ### Watch Streaming Events

-Command:
+**RKE2**:
+```bash
+crictl exec $etcdcontainer etcdctl watch --prefix /registry --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt
 ```
-docker exec etcd etcdctl watch --prefix /registry
+
+**K3s**:
+```bash
+etcdctl watch --prefix /registry --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
 ```

 If you only want to see the affected keys (and not the binary data), you can append `| grep -a ^/registry` to the command to filter for keys only.

 ### Query etcd Directly

-Command:
+**RKE2**:
+```bash
+crictl exec $etcdcontainer etcdctl get /registry --prefix=true --keys-only --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt
 ```
-docker exec etcd etcdctl get /registry --prefix=true --keys-only
+
+**K3s**:
+```bash
+etcdctl get /registry --prefix=true --keys-only --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
 ```

 You can process the data to get a summary of count per key, using the command below:

+**RKE2**:
+```bash
+crictl exec $etcdcontainer etcdctl get /registry --prefix=true --keys-only --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt | grep -v ^$ | awk -F'/' '{ if ($3 ~ /cattle.io/) {h[$3"/"$4]++} else { h[$3]++ }} END { for(k in h) print h[k], k }' | sort -nr
 ```
-docker exec etcd etcdctl get /registry --prefix=true --keys-only | grep -v ^$ | awk -F'/' '{ if ($3 ~ /cattle.io/) {h[$3"/"$4]++} else { h[$3]++ }} END { for(k in h) print h[k], k }' | sort -nr
+
+**K3s**:
+```bash
+etcdctl get /registry --prefix=true --keys-only --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt | grep -v ^$ | awk -F'/' '{ if ($3 ~ /cattle.io/) {h[$3"/"$4]++} else { h[$3]++ }} END { for(k in h) print h[k], k }' | sort -nr
 ```

 ## Replacing Unhealthy etcd Nodes
@@ -6,6 +6,14 @@ title: Troubleshooting nginx-proxy
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/troubleshooting/kubernetes-components/troubleshooting-nginx-proxy"/>
 </head>

+:::caution
+
+The `nginx-proxy` container is an RKE1-specific component. If you are using RKE2 or K3s, this container is not deployed, as load balancing to the API servers is handled internally by a client-side load balancer within the agent process itself.
+
+Additionally, please note that RKE1 has reached its [End of Life (EOL)](https://support.scc.suse.com/s/kb/RKE-EOL-what-when-why?language=en_US). Therefore, the information on this page is considered deprecated.
+
+:::
+
 The `nginx-proxy` container is deployed on every node that does not have the `controlplane` role. It provides access to all the nodes with the `controlplane` role by dynamically generating the NGINX configuration based on available nodes with the `controlplane` role.

 ## Check if the Container is Running
@@ -8,31 +8,85 @@ title: Troubleshooting Worker Nodes and Generic Components

 This section applies to every node as it includes components that run on nodes with any role.

-## Check if the Containers are Running
+## Prerequisites

-There are two specific containers launched on nodes with the `worker` role:
+Since RKE2 and K3s utilize `containerd` as the container runtime, `crictl` serves as the primary tool for container management, replacing the Docker CLI. To allow `crictl` to communicate with `containerd`, you must configure your environment by exporting the following variables:

-* kubelet
-* kube-proxy
-
-The containers should have status `Up`. The duration shown after `Up` is the time the container has been running.
+### RKE2

+```bash
+export PATH=$PATH:/var/lib/rancher/rke2/bin/
+export CRI_CONFIG_FILE=/var/lib/rancher/rke2/agent/etc/crictl.yaml
 ```
-docker ps -a -f=name='kubelet|kube-proxy'
+
+### K3s
+
+```bash
+export PATH=$PATH:/usr/local/bin
+export CRI_CONFIG_FILE=/var/lib/rancher/k3s/agent/etc/crictl.yaml
+```
+
+## Check if the Components are Running
+
+There are two specific components launched on nodes with the `worker` role:
+
+* `kubelet`
+* `kube-proxy`
+
+### RKE2
+
+The `kubelet` runs natively as part of the `rke2-agent` (or `rke2-server`) systemd process, while `kube-proxy` runs as a Static Pod managed by `containerd`.
+
+Check the status of the `kubelet` via the agent service:
+```bash
+systemctl status rke2-agent
+```
+:::note
+
+If you are checking a controlplane node, use `systemctl status rke2-server` instead.
+
+:::
+
+Check the status of `kube-proxy` using `crictl`:
+```bash
+crictl ps --name kube-proxy
 ```

 Example output:
 ```
-CONTAINER ID        IMAGE                                COMMAND                  CREATED             STATUS              PORTS               NAMES
-158d0dcc33a5        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."   3 hours ago         Up 3 hours                              kube-proxy
-a30717ecfb55        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."   3 hours ago         Up 3 hours                              kubelet
+CONTAINER           IMAGE                                                      CREATED             STATE               NAME                ATTEMPT             POD ID
+26c7159abbcc        rancher/hardened-kubernetes:v1.28.8-rke2r1-build20240404   3 hours ago         Running             kube-proxy          0                   1a2b3c4d5e6f7
 ```

-## Container Logging
+### K3s

-The logging of the containers can contain information on what the problem could be.
+Both `kubelet` and `kube-proxy` run as embedded processes inside the `k3s-agent` (or `k3s` server) systemd service. There are no separate containers for them.

+Check their status by checking the K3s service:
+```bash
+systemctl status k3s-agent
 ```
-docker logs kubelet
-docker logs kube-proxy
+:::note
+If you are checking a controlplane node, use `systemctl status k3s` instead.
+:::
+
+## Component Logging
+
+The logging of the components can contain information on what the problem could be.
+
+### RKE2
+
+```bash
+# kubelet logs are part of the systemd service
+journalctl -u rke2-agent -f | grep -i "kubelet"
+
+# kube-proxy logs are retrieved from containerd
+crictl logs $(crictl ps --name kube-proxy -q)
+```
+
+### K3s
+
+```bash
+# Both components log to the systemd service
+journalctl -u k3s-agent -f | grep -iE "kubelet|kube-proxy"
 ```
@@ -78,66 +78,137 @@ kubectl -n kube-system get endpoints kube-scheduler -o jsonpath='{.metadata.anno

 ## Ingress Controller

-The default Ingress Controller is Traefik and is deployed as a DaemonSet in the `traefik` namespace. The pods are only scheduled to nodes with the `worker` role.
+The default Ingress Controller is Traefik and is deployed as a DaemonSet in the `kube-system` namespace. The pods are only scheduled to nodes with the `worker` role.

 Check if the pods are running on all nodes:

 ```
-kubectl -n traefik get pods -o wide
+kubectl -n kube-system get pods -o wide
 ```

-Example output:
+Example RKE2 output:

 ```
-kubectl -n traefik get pods -o wide
+kubectl -n kube-system get pods -o wide
 NAME                                    READY     STATUS    RESTARTS   AGE       IP               NODE
-default-http-backend-797c5bc547-kwwlq   1/1       Running   0          17m       x.x.x.x          worker-1
-traefik-4qd64                           1/1       Running   0          14m       x.x.x.x          worker-1
-traefik-8wxhm                           1/1       Running   0          13m       x.x.x.x          worker-0
+local-path-provisioner-xxxxxxxxxx-xxxxx 1/1       Running   0          17m       x.x.x.x          worker-1
+rke2-traefik-xxxxxxxxxx-xxxxx           1/1       Running   0          14m       x.x.x.x          worker-1
+svclb-rke2-traefik-xxxxxxxx-xxxxx       1/1       Running   0          13m       x.x.x.x          worker-0
+...
+```
+
+Example K3s output:
+
+```
+kubectl -n kube-system get pods -o wide
+NAME                                    READY     STATUS    RESTARTS   AGE       IP               NODE
+local-path-provisioner-xxxxxxxxxx-xxxxx 1/1       Running   0          17m       x.x.x.x          worker-1
+traefik-xxxxxxxxxx-xxxxx                1/1       Running   0          14m       x.x.x.x          worker-1
+svclb-traefik-xxxxxxxx-xxxxx            1/1       Running   0          13m       x.x.x.x          worker-0
+...
 ```

 If a pod is unable to run (Status is not **Running**, Ready status is not showing `1/1` or you see a high count of Restarts), check the pod details, logs and namespace events.

 ### Pod details

+RKE2 example:
+
 ```
-kubectl -n traefik describe pods -l app=traefik
+kubectl -n kube-system describe pods -l app.kubernetes.io/name=rke2-traefik
+```
+
+K3s example:
+
+```
+kubectl -n kube-system describe pods -l app.kubernetes.io/name=traefik
 ```

 ### Pod container logs

-The below command can show the logs of all the pods labeled "app=traefik", but it will display only 10 lines of log because of the restrictions of the `kubectl logs` command. Refer to `--tail` of `kubectl logs -h` for more information.
+The below command can show the logs of all the pods labeled "app.kubernetes.io/name=rke2-traefik" if using RKE2 or "app.kubernetes.io/name=traefik" if using K3s, but it will display only 10 lines of log because of the restrictions of the `kubectl logs` command. Refer to `--tail` of `kubectl logs -h` for more information.
+
+RKE2 example:

 ```
-kubectl -n traefik logs -l app=traefik
+kubectl -n kube-system logs -l app.kubernetes.io/name=rke2-traefik
+```
+
+K3s example:
+
+```
+kubectl -n kube-system logs -l app.kubernetes.io/name=traefik
 ```

 If the full log is needed, specify the pod name in the trailing command:

 ```
-kubectl -n traefik logs <pod name>
+kubectl -n kube-system logs <pod name>
 ```

 ### Namespace events

 ```
-kubectl -n traefik get events
+kubectl -n kube-system get events
 ```

 ### Debug logging

 To enable debug logging:

+RKE2 example:
+
 ```
-kubectl -n traefik patch ds traefik --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--v=5"}]'
+cat <<EOF | kubectl apply -f -
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata:
+  name: rke2-traefik
+  namespace: kube-system
+spec:
+  valuesContent: |-
+    additionalArguments:
+      - "--log.level=DEBUG"
+EOF
+```
+
+K3s example:
+
+```
+cat <<EOF | kubectl apply -f -
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata:
+  name: traefik
+  namespace: kube-system
+spec:
+  valuesContent: |-
+    logs:
+      general:
+        level: "DEBUG"
+EOF
 ```

 ### Check configuration

 Retrieve generated configuration in each pod:

+RKE2 example for manual Traefik configuration file check:
+
 ```
-kubectl -n traefik get pods -l app=traefik --no-headers -o custom-columns=.NAME:.metadata.name | while read pod; do kubectl -n traefik exec $pod -- cat /etc/nginx/nginx.conf; done
+kubectl exec -n kube-system pod/traefik-xxxxxxxxx-xxxxx -- cat /var/lib/rancher/rke2/server/manifests/rke2-traefik-config.yaml
+```
+
+K3s example for manual Traefik configuration file check:
+
+```
+kubectl exec -n kube-system pod/traefik-xxxxxxxxx-xxxxx -- cat /var/lib/rancher/k3s/server/manifests/k3s-traefik-config.yaml
+```
+
+RKE2/K3s example for Traefik CLI argument configuration check:
+
+```
+kubectl get pod traefik-xxxxxxxxx-xxxxx -n kube-system -o jsonpath='{.spec.containers[0].args}'
 ```

 ## Rancher agents
@@ -14,6 +14,13 @@ Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG

 Double check if all the [required ports](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) are opened in your (host) firewall. The overlay network uses UDP in comparison to all other required ports which are TCP.

+## Check if your downstream node can communicate to Rancher Manager
+
+Rancher components with HTTP endpoints generally contain a `ping` liveness probe which you can use to test connectivity. Replace the `$RANCHER_URL` as appropriate and run the following from a node to check that it has connectivity to Rancher Manager's servers in the `local` cluster. If successful, it should return `pong`.
+
+```
+curl -k https://$RANCHER_URL/ping 
+```

 ## Check if Overlay Network is Functioning Correctly

@@ -185,9 +185,9 @@ module.exports = {
              label: "Latest",
            },
            "2.14": {
-              label: 'v2.14 (Preview)',
+              label: 'v2.14',
              path: 'v2.14',
-              banner: 'unreleased'
+              banner: 'none'
            },
            "2.13": {
              label: "v2.13",
@@ -891,8 +891,12 @@ module.exports = {
            ],
          },
          {
-            to: "/how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools",
-            from: "/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools",
+            to: "/v2.10/how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools",
+            from: "/v2.10/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools",
+          },
+          {
+            to: "/v2.11/how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools",
+            from: "/v2.11/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools",
          },
          {
            to: "/how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes",
@@ -1179,6 +1183,20 @@ module.exports = {
            from: "/integrations-in-rancher/cis-scans/custom-benchmark",
            to: "/integrations-in-rancher/compliance-scans/custom-benchmark",
          },
+          // Redirects for renaming nodes-and-machine-pools.md (start)
+          {
+            to: "/v2.12/how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools",
+            from: "/v2.12/how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools",
+          },
+          {
+            to: "/v2.13/how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools",
+            from: "/v2.13/how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools",
+          },
+          {
+            to: "/v2.14/how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools",
+            from: "/v2.14/how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools",
+          },
+          // Redirects for renaming nodes-and-machine-pools.md (end)
        ],
      },
    ],
@@ -2,6 +2,8 @@
 title: API 令牌
 ---

+<v3APITokensDeprecationWarning />
+
 默认情况下，某些集群级别的 API 令牌是使用无限期 TTL（`ttl=0`）生成的。换言之，除非你让令牌失效，否则 `ttl=0` 的 API 令牌永远不会过期。令牌不会因为更改密码而失效。

 要停用 API 令牌，你可以删除令牌或停用用户账号。
@@ -12,10 +12,9 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/

 | Patch 版本                                                         | 发布时间            |
 | ----------------------------------------------------------------- | ------------------ |
-| [2.13.3](https://github.com/rancher/rancher/releases/tag/v2.13.3) | 2026 年 02 月 25 日 |
-| [2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2) | 2026 年 01 月 29 日 |
-| [2.13.1](https://github.com/rancher/rancher/releases/tag/v2.13.1) | 2025 年 12 月 18 日 |
-| [2.13.0](https://github.com/rancher/rancher/releases/tag/v2.13.0) | 2025 年 11 月 25 日  |
+| [2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2) | 2026 年 05 月 28 日 |
+| [2.14.1](https://github.com/rancher/rancher/releases/tag/v2.14.1) | 2026 年 04 月 30 日 |
+| [2.14.0](https://github.com/rancher/rancher/releases/tag/v2.14.0) | 2026 年 03 月 25 日 |

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

@@ -236,19 +236,24 @@ import CommonPortsTable from '../../../shared-files/_common-ports-table.md';

 | 类型 | 协议 | 端口范围 | 源/目标 | 规则类型 |
 |-----------------|:--------:|:-----------:|------------------------|:---------:|
-| SSH | TCP | 22 | 0.0.0.0/0 | 入站 |
-| HTTP | TCP | 80 | 0.0.0.0/0 | 入站 |
-| 自定义 TCP 规则 | TCP | 443 | 0.0.0.0/0 | 入站 |
-| 自定义 TCP 规则 | TCP | 2376 | 0.0.0.0/0 | 入站 |
+| SSH | TCP | 22 | 0.0.0.0/0 and ::/0 | 入站 |
+| HTTP | TCP | 80 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 443 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 8443 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 2376 | 0.0.0.0/0 and ::/0 | 入站 |
 | 自定义 TCP 规则 | TCP | 2379-2380 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 UDP 规则 | UDP | 4789 | sg-xxx (rancher-nodes) | 入站 |
-| 自定义 TCP 规则 | TCP | 6443 | 0.0.0.0/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 6443 | 0.0.0.0/0 and ::/0 | 入站 |
 | 自定义 UDP 规则 | UDP | 8472 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 179 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 5473 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 9345 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 9796 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 TCP 规则 | TCP | 10250-10252 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 TCP 规则 | TCP | 10256 | sg-xxx (rancher-nodes) | 入站 |
-| 自定义 TCP 规则 | TCP | 30000-32767 | 0.0.0.0/0 | 入站 |
-| 自定义 UDP 规则 | UDP | 30000-32767 | 0.0.0.0/0 | 入站 |
-| 所有流量 | 全部 | 全部 | 0.0.0.0/0 | 出站 |
+| 自定义 TCP 规则 | TCP | 30000-32767 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 UDP 规则 | UDP | 30000-32767 | 0.0.0.0/0 and ::/0 | 入站 |
+| 所有流量 | 全部 | 全部 | 0.0.0.0/0 and ::/0 | 出站 |

 ### 打开 SUSE Linux 端口

@@ -2,13 +2,19 @@
 title: 资源配额类型参考
 ---

-创建资源配额相当于配置项目可用的资源池。你可以为以下资源类型设置资源配额：
+When you create a resource quota, you are configuring the pool of resources available to the project. Rancher supports the use of arbitrary resource references and their quotas. This allows you to utilize all upstream [Kubernetes `ResourceQuota`](https://kubernetes.io/docs/concepts/policy/resource-quotas/#types-of-resource-quota) types when managing project resource quotas.
+
+You can set resource limits for the following predefined resource types, where the `Custom` type enables specification of arbitrary resources and their quotas.
+
+:::note
+Support for arbitrary resource references using the `Custom` type does not cover resources in the `ext.cattle.io` API group.
+:::

 | 资源类型 | 描述 |
 | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | CPU 限制\* | 分配给项目/命名空间的最大 CPU 量（以[毫核](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)为单位）<sup>1</sup> |
 | CPU 预留\* | 预留给项目/命名空间的最小 CPU 量（以毫核为单位）<sup>1</sup> |
-| 内存限制\* | 分配给项目/命名空间的最大内存量（以字节为单位）<sup>1</sup> |
+| 内存限制\* | 分配给项目/命名空间的最大内存量（[以字节为单位](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory)）<sup>1</sup> |
 | 内存预留\* | 预留给项目/命名空间的最小内存量（以字节为单位）<sup>1</sup> |
 | 存储预留 | 预留给项目/命名空间的最小存储量（以千兆字节为单位） |
 | 服务负载均衡器 | 项目/命名空间中可以存在的负载均衡器服务的最大数量 |
@@ -19,9 +25,22 @@ title: 资源配额类型参考
 | 持久卷声明 | 项目/命名空间中可以存在的持久卷声明的最大数量 |
 | ReplicationController | 项目/命名空间中可以存在的最大 ReplicationController 数量 |
 | 密文 | 项目/命名空间中可以存在的最大密文数量 |
+| Custom\*\* | The specification of arbitrary resources and their quotas, beyond the resource types built into projects, as listed above. |

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

 在设置资源配额时，如果你在项目或命名空间上设置了任何与 CPU 或内存相关的内容（即限制或预留），所有容器都需要在创建期间设置各自的 CPU 或内存字段。你可以同时设置容器的默认资源限制，以避免为每个工作负载显式设置这些限制。详情请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits)。

-:::
+:::
+
+:::note **<sup>\*\*</sup>**
+
+For example:
+
+  - `requests.nvidia.com/gpu: 4`
+  - `gold.storageclass.storage.k8s.io/requests.storage: 500Gi`
+  - `count/podtemplates: 10`
+
+See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#quota-for-extended-resources) for many more examples.
+
+:::
@@ -6,130 +6,10 @@ title: 在云厂商的新节点上启动 Kubernetes
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider"/>
 </head>

-在 Rancher 中使用节点模板来创建 RKE 或 RKE2 集群时，每个生成的节点池都会显示在新的**主机池**选项卡中。你可以通过执行以下操作来查看主机池：
+在 Rancher 中使用节点模板来创建 RKE2 集群时，每个生成的节点池都会显示在新的**主机池**选项卡中。你可以通过执行以下操作来查看主机池：

 1. 点击**☰ > 集群管理**。
-1. 单击 RKE 或 RKE2 集群的名称。
-
-## RKE 集群
-
-使用 Rancher，你可以基于[节点模板](use-new-nodes-in-an-infra-provider.md#节点模板)创建节点池。此节点模板定义了要用于在基础设施提供商或云厂商中启动节点的参数。
-
-在托管在云厂商的节点池上安装 Kubernetes 的一个好处是，如果一个节点与集群断开连接，Rancher 可以自动创建另一个节点并将其加入集群，从而确保节点池的数量符合要求。
-
-可用于创建节点模板的云提供商是由[主机驱动](use-new-nodes-in-an-infra-provider.md#主机驱动)决定的。
-
-### 节点模板
-
-节点模板保存了用于在特定云提供商中配置节点时要使用的参数。这些节点可以从 UI 启动。Rancher 使用 [Docker Machine](https://github.com/docker/docs/blob/vnext-engine/machine/overview.md) 来配置这些节点。可用于创建节点模板的云提供商取决于 Rancher 中状态是 Active 的主机驱动。
-
-在 Rancher 中创建节点模板后，模板会被保存，以便你可以再次使用该模板来创建节点池。节点模板绑定到你的登录名。添加模板后，你可以将其从用户配置文件中删除。
-
-#### 节点标签
-
-你可以为每个节点模板添加[标签](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)，这样，使用节点模板创建的节点都会自动带有这些标签。
-
-无效标签会阻止升级，或阻止 Rancher 启动。有关标签语法的详细信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
-
-#### 节点污点
-
-你可以为每个节点模板添加[污点](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)，这样，使用节点模板创建的节点都会自动带有这些污点。
-
-由于污点可以同时添加到节点模板和节点池中，因此如果添加了相同键的污点效果没有冲突，则所有污点都将添加到节点中。如果存在具有相同键但不同效果的污点，则节点池中的污点将覆盖节点模板中的污点。
-
-#### 节点模板的管理员控制
-
-管理员可以控制所有节点模板。现在，管理员可以维护 Rancher 中的所有节点模板。当节点模板所有者不再使用 Rancher 时，他们创建的节点模板可以由管理员管理，以便继续更新和维护集群。
-
-要访问所有节点模板，管理员需要执行以下操作：
-
-1. 点击 **☰ > 集群管理**。
-1. 单击 **RKE1 配置 > 节点模板**。
-
-**结果**：列出所有节点模板。你可以通过单击 **⋮** 来编辑或克隆模板。
-
-### 节点池
-
-使用 Rancher，你可以基于[节点模板](#节点模板)创建节点池。
-
-节点模板定义了节点的配置，例如要使用的操作系统、CPU 数量和内存量。
-
-使用节点池的好处是，如果一个节点被销毁或删除，你可以增加 Active 节点的数量来补偿丢失的节点。节点池可以帮助你确保节点池的计数符合要求。
-
-每个节点池必须分配一个或多个节点角色。
-
-每个节点角色（即 etcd、controlplane 和 worker）都应分配给不同的节点池。虽然你可以将多个节点角色分配给同一个节点池，但不要在生产集群中执行此操作。
-
-推荐的设置：
-
- 具有 etcd 角色且计数为 3 的节点池
- 具有 controlplane 角色且计数至少为 2 的节点池
- 具有 worker 角色且计数至少为 2 的节点池
-
-**离线环境中的 RKE1 下游集群节点**：
-
-默认情况下，在配置 RKE1 下游集群节点时（例如在 vSphere 中），Rancher 会尝试运行 Docker 安装脚本。但是，Rancher Docker 安装脚本在离线环境中会运行失败。要解决此问题，如果 Docker 已预安装到 VM 镜像上，你可以选择在创建节点模板时跳过安装 Docker。为此，你可以在 Rancher UI **引擎选项**下的 `Docker 安装 URL` 下拉列表中选择 **无**。
-
-<figcaption>**引擎选项下拉列表**</figcaption>
-
-![引擎选项下拉列表](/img/node-template-engine-options-rke1.png)
-
-#### 节点池污点
-
-如果你没有在节点模板上定义[污点](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)，则可以为每个节点池添加污点。将污点添加到节点池的好处是你可以更改节点模板，而不需要先确保污点存在于新模板中。
-
-每个污点都将自动添加到节点池中已创建的节点。因此，如果你在已有节点的节点池中添加污点，污点不会应用到已有的节点，但是添加到该节点池中的新节点都将获得该污点。
-
-如果污点同时添加到节点模板和节点池中，且添加了相同键的污点效果没有冲突，则所有污点都将添加到节点中。如果存在具有相同键但不同效果的污点，则节点池中的污点将覆盖节点模板中的污点。
-
-#### 节点自动替换
-
-Rancher 可以自动替换节点池中无法访问的节点。如果节点在指定的时间中处于 Inactive 状态，Rancher 将使用该节点池的节点模板来重新创建节点。
-
-:::caution
-
-自我修复节点池的功能帮助你替换<b>无状态</b>应用的 worker 节点。不建议在 master 节点或连接了持久卷的节点的节点池上启用节点自动替换，因为虚拟机会被临时处理。节点池中的节点与集群断开连接时，其持久卷将被破坏，从而导致有状态应用的数据丢失。
-
-:::
-
-节点自动替换基于 Kubernetes 节点控制器工作。节点控制器定期检查所有节点的状态（可通过 `kube-controller` 的 `--node-monitor-period` 标志配置）。一个节点不可访问时，节点控制器将污染该节点。发生这种情况时，Rancher 将开始其删除倒计时。你可以配置 Rancher 等待删除节点的时间。如果在删除倒计时结束前污点没有被删除，Rancher 将继续删除该节点。Rancher 会根据节点池设置的数量来创建新的节点。
-
-#### 启用节点自动替换
-
-创建节点池时，你可以指定 Rancher 替换无响应节点的等待时间（以分钟为单位）。
-
-1. 在创建或编辑集群的表单中，转到**节点池**。
-1. 转到要启用节点自动替换的节点池。在 **Recreate Unreachable After** 字段中，输入 Rancher 在替换节点之前应该等待节点响应的分钟数。
-1. 填写表单的其余部分以创建或编辑集群。
-
-**结果** ：已为节点池启用节点自动替换。
-
-#### 禁用节点自动替换
-
-你可以执行以下步骤从 Rancher UI 禁用节点自动替换：
-
-1. 点击 **☰ > 集群管理**。
-1. 在**集群**页面上，转到要禁用节点自动替换的集群，然后单击 **⋮ > 编辑配置**。
-1. 在**节点池**部分中，转到要启用节点自动替换的节点池。在 **Recreate Unreachable After** 字段中，输入 0。
-1. 单击**保存**。
-
-**结果**：已禁用节点池的节点自动替换。
-
-### 云凭证
-
-节点模板可以使用云凭证，来存储用于在云提供商中启动节点的凭证，其优点是：
-
- 凭证会存储为更安全的 Kubernetes 密文，而且你无需每次都输入凭证便可编辑节点模板。
-
- 创建云凭证后，你可以重新使用该凭证来创建其他节点模板。
-
- 多个节点模板可以使用相同的云凭证来创建节点池。如果你的密钥被泄露或过期，则可以在一个位置更新云凭证，从而一次更新所有使用该凭证的节点模板。
-
-创建云凭证后，用户可以[管理创建的云凭证](../../../../reference-guides/user-settings/manage-cloud-credentials.md)。
-
-### 主机驱动
-
-如果你找不到想要的主机驱动，你可以在 Rancher 的[内置主机驱动](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#激活停用主机驱动)中查看并激活它，也可以[添加自定义主机驱动](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#添加自定义主机驱动)。
+1. Click the name of the RKE2 cluster.

 ## RKE2 集群

@@ -21,21 +21,6 @@ kubeconfig 文件及其内容特定于各个集群。你可以从 Rancher 的**

 如果管理员[关闭了 kubeconfig 令牌生成](../../../../api/api-tokens.md#在生成的-kubeconfig-中禁用令牌)，则 kubeconfig 文件要求 [Rancher CLI](../../../../reference-guides/cli-with-rancher/rancher-cli.md) 存在于你的 PATH 中。

-## RKE 集群的两种身份验证方法
-
-如果集群不是 [RKE 集群](../../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)，kubeconfig 文件只允许你以一种方式访问集群，即通过 Rancher Server 进行身份验证，然后 Rancher 允许你在集群上运行 kubectl 命令。
-
-对于 RKE 集群，kubeconfig 文件允许你通过两种方式进行身份验证：
-
- **通过 Rancher Server 身份验证代理**：Rancher 的身份验证代理会验证你的身份，然后将你连接到要访问的下游集群。
- **直接使用下游集群的 API Server**：RKE 集群默认启用授权集群端点。此端点允许你使用 kubectl CLI 和 kubeconfig 文件访问下游 Kubernetes 集群，且 RKE 集群默认启用该端点。在这种情况下，下游集群的 Kubernetes API server 通过调用 Rancher 设置的 webhook（`kube-api-auth` 微服务）对你进行身份验证。
-
-第二种方法（即直接连接到集群的 Kubernetes API server）非常重要，因为如果你无法连接到 Rancher，这种方法可以让你访问下游集群。
-
-要使用授权集群端点，你需要配置 kubectl，从而使用 Rancher 在创建 RKE 集群时生成的 kubeconfig 文件中的额外 kubectl 上下文。该文件可以从 Rancher UI 的**集群**视图中下载，配置 kubectl 的说明在[此页面](use-kubectl-and-kubeconfig.md#直接使用下游集群进行身份验证)。
-
-[架构介绍](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md)也详细解释了这些与下游 Kubernetes 集群通信的方法，并介绍了 Rancher 的工作原理以及 Rancher 如何与下游集群通信的详细信息。
-
 ## 关于 kube-api-auth 身份验证 Webhook

 `kube-api-auth` 微服务是为[授权集群端点](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-授权集群端点)提供用户认证功能而部署的。当你使用 `kubectl` 访问下游集群时，集群的 Kubernetes API server 会使用 `kube-api-auth` 服务作为 webhook 对你进行身份验证。
@@ -64,10 +64,6 @@ Rancher v2.5 简化了在 Rancher 管理的集群上安装 Longhorn 的过程。

 在将数据存储在 iSCSI 卷上的 [Rancher 启动的 Kubernetes 集群](../../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)中，你可能会遇到 kubelet 无法自动连接 iSCSI 卷的问题。有关解决此问题的详细信息，请参阅[此页面](manage-persistent-storage/install-iscsi-volumes.md)。

-## hostPath 卷
-
-在创建 hostPath 卷之前，你需要在集群配置中设置 [extra_bind](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/#extra-binds/)。这会将路径作为卷安装在你的 kubelet 中，可用于工作负载中的 hostPath 卷。
-
 ## 将 vSphere Cloud Provider 从树内迁移到树外

 Kubernetes 正在逐渐不在树内维护云提供商。vSphere 有一个树外云提供商，可通过安装 vSphere 云提供商和云存储插件来使用。
@@ -15,10 +15,9 @@ title: 安装 Adapter

 | Rancher 版本 | Adapter 版本 |
 |-----------------|------------------|
-| v2.13.3         |  108.0.0+up8.0.0 |
-| v2.13.2         |  108.0.0+up8.0.0 |
-| v2.13.1         |  108.0.0+up8.0.0 |
-| v2.13.0         |  108.0.0+up8.0.0 |
+| v2.14.2         |  109.0.0+up9.0.0 |
+| v2.14.1         |  109.0.0+up9.0.0 |
+| v2.14.0         |  109.0.0+up9.0.0 |

 ## 1. 获取对 Local 集群的访问权限

@@ -79,6 +79,19 @@ Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`

 ## 故障排除

+### Resource Exhaustion of `inotify` Watchers and File Descriptors
+
+When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
+
+This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
+
+Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
+
+```shell
+sysctl -w fs.inotify.max_user_instances=8192
+sysctl -w fs.inotify.max_user_watches=524288
+```
+
 ### 日志缓冲区导致 Pod 过载

 根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
@@ -10,6 +10,12 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已

 | ID | 描述 | 日期 | 解决 |
 |----|-------------|------|------------|
+| [CVE-2026-44949](https://github.com/rancher/webhook/security/advisories/GHSA-h83p-cq95-vph4) | Fixed a security vulnerability in rancher-webhook where the FleetWorkspace mutating admission webhook performed side effects without authenticating requests, allowing a pod inside the cluster to create arbitrary namespaces and inject RBAC bindings. | 29 June 2026 | Rancher [v2.14.3](https://github.com/rancher/rancher/releases/tag/v2.14.3), Rancher [v2.13.7](https://github.com/rancher/rancher/releases/tag/v2.13.7), Rancher [v2.12.11](https://github.com/rancher/rancher/releases/tag/v2.12.11) and Rancher [v2.11.15](https://github.com/rancher/rancher/releases/tag/v2.11.15) |
+| [CVE-2026-44947](https://github.com/rancher/rancher/security/advisories/GHSA-c4rp-wgqc-mfhc) | Fixed a security vulnerability in Rancher's legacy PRTB reconciler where removing the `updatepsa` permission from a RoleTemplate did not clean up stale PSA ClusterRole and ClusterRoleBinding resources, allowing affected users to retain unauthorized Pod Security Admission access indefinitely. | 29 June 2026 | Rancher [v2.14.3](https://github.com/rancher/rancher/releases/tag/v2.14.3) and Rancher [v2.13.7](https://github.com/rancher/rancher/releases/tag/v2.13.7) |
+| [CVE-2026-44946](https://github.com/rancher/rancher/security/advisories/GHSA-c5jm-xcmq-9j95) | Fixed a security vulnerability in Rancher's SAML authentication handler where a valid signed SAML response could be replayed by an attacker who had also captured the victim's pre-authentication SAML state cookie, allowing the attacker to create a separate authenticated session with the victim's permissions. All SAML providers (Okta, Ping, ADFS, Keycloak, Shibboleth) were affected. | 29 June 2026 | Rancher [v2.14.3](https://github.com/rancher/rancher/releases/tag/v2.14.3), Rancher [v2.13.7](https://github.com/rancher/rancher/releases/tag/v2.13.7), Rancher [v2.12.11](https://github.com/rancher/rancher/releases/tag/v2.12.11) and Rancher [v2.11.15](https://github.com/rancher/rancher/releases/tag/v2.11.15) |
+| [CVE-2026-41053](https://github.com/rancher/rancher/security/advisories/GHSA-4j6x-2764-m8gh) | Fixed a security vulnerability in the GitHub App authentication provider where users incorrectly inherited permissions from all teams within their GitHub organization, rather than only the specific teams to which they belonged. Upon upgrading, Rancher automatically triggers a mandatory refresh of all affected user `principals` to remove these incorrectly assigned team memberships and restore proper access. | 27 May 2026 | Rancher [v2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2), Rancher [v2.13.6](https://github.com/rancher/rancher/releases/tag/v2.13.6) |
+| [CVE-2026-41052](https://github.com/rancher/rancher/security/advisories/GHSA-vx8h-4prv-g744) | Updated the permissions of the built-in `project-owner` role to no longer include the `updatepsa` verb. This prevents users with this role from bypassing restricted PSA policies or deploying privileged workloads within their projects. If your organization requires users to retain this capability, administrators must create a custom project role that explicitly grants the `updatepsa` verb for the project resource. | 27 May 2026 | Rancher [v2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2), Rancher [v2.13.6](https://github.com/rancher/rancher/releases/tag/v2.13.6), [v2.12.10](https://github.com/rancher/rancher/releases/tag/v2.12.10) |
+| [CVE-2026-44939](https://github.com/rancher/rancher/security/advisories/GHSA-mhc6-2gfq-xx62) | Rancher now validates the `authImage` parameter in cluster import manifests to prevent YAML injection attacks. | 27 May 2026 | Rancher [v2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2), Rancher [v2.13.6](https://github.com/rancher/rancher/releases/tag/v2.13.6), [v2.12.10](https://github.com/rancher/rancher/releases/tag/v2.12.10), [v2.11.14](https://github.com/rancher/rancher/releases/tag/v2.11.14), and [v2.10.12](https://github.com/rancher/rancher/releases/tag/v2.10.12) |
 | [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
 | [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
 | [CVE-2023-32199](https://github.com/rancher/rancher/security/advisories/GHSA-j4vr-pcmw-hx59) | Rancher now removes the corresponding ClusterRoleBindings whenever the admin GlobalRole or its GlobalRoleBindings are deleted. Previously orphaned ClusterRoleBindings were marked with the annotation `authz.cluster.cattle.io/admin-globalrole-missing=true`. | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) and [v2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) |
@@ -20,10 +20,9 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
-| v2.13.3         |     v0.9.3      | &check;               | &check;                   |
-| v2.13.2         |     v0.9.2      | &check;               | &check;                   |
-| v2.13.1         |     v0.9.1      | &check;               | &check;                   |
-| v2.13.0         |     v0.9.0      | &cross;               | &check;                   |
+| v2.14.2         |    v0.10.5      | &check;               | &check;                   |
+| v2.14.1         |    v0.10.4      | &check;               | &check;                   |
+| v2.14.0         |    v0.10.0      | &cross;               | &check;                   |

 ## 为什么我们需要它？

@@ -2,6 +2,8 @@
 title: API 密钥
 ---

+<v3APITokensDeprecationWarning />
+
 ## API 密钥和用户身份验证

 如果你想通过外部应用程序来访问 Rancher 集群、项目或其他对象，你可以使用 Rancher API。但是，在你的应用程序可以访问 API 之前，你必须为应用程序提供用于向 Rancher 进行身份验证的密钥。你可以通过 Rancher UI 获取密钥。
@@ -12,6 +12,7 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/

 | Patch 版本                                                      | 发布时间              |
 | --------------------------------------------------------------- | -------------------- |
+| [2.10.12](https://github.com/rancher/rancher/releases/tag/v2.10.12) | 2026 年 05 月 27 日 |
 | [2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) | 2026 年 01 月 29 日 |
 | [2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10) | 2025 年 9 月 25 日 |
 | [2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) | 2025 年 8 月 27 日  |
@@ -284,19 +284,24 @@ import CommonPortsTable from '../../../shared-files/_common-ports-table.md';

 | 类型 | 协议 | 端口范围 | 源/目标 | 规则类型 |
 |-----------------|:--------:|:-----------:|------------------------|:---------:|
-| SSH | TCP | 22 | 0.0.0.0/0 | 入站 |
-| HTTP | TCP | 80 | 0.0.0.0/0 | 入站 |
-| 自定义 TCP 规则 | TCP | 443 | 0.0.0.0/0 | 入站 |
-| 自定义 TCP 规则 | TCP | 2376 | 0.0.0.0/0 | 入站 |
+| SSH | TCP | 22 | 0.0.0.0/0 and ::/0 | 入站 |
+| HTTP | TCP | 80 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 443 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 8443 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 2376 | 0.0.0.0/0 and ::/0 | 入站 |
 | 自定义 TCP 规则 | TCP | 2379-2380 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 UDP 规则 | UDP | 4789 | sg-xxx (rancher-nodes) | 入站 |
-| 自定义 TCP 规则 | TCP | 6443 | 0.0.0.0/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 6443 | 0.0.0.0/0 and ::/0 | 入站 |
 | 自定义 UDP 规则 | UDP | 8472 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 179 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 5473 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 9345 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 9796 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 TCP 规则 | TCP | 10250-10252 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 TCP 规则 | TCP | 10256 | sg-xxx (rancher-nodes) | 入站 |
-| 自定义 TCP 规则 | TCP | 30000-32767 | 0.0.0.0/0 | 入站 |
-| 自定义 UDP 规则 | UDP | 30000-32767 | 0.0.0.0/0 | 入站 |
-| 所有流量 | 全部 | 全部 | 0.0.0.0/0 | 出站 |
+| 自定义 TCP 规则 | TCP | 30000-32767 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 UDP 规则 | UDP | 30000-32767 | 0.0.0.0/0 and ::/0 | 入站 |
+| 所有流量 | 全部 | 全部 | 0.0.0.0/0 and ::/0 | 出站 |

 ### 打开 SUSE Linux 端口

@@ -15,6 +15,7 @@ title: 安装 Adapter

 | Rancher 版本 | Adapter 版本 |
 |-----------------|:----------------:|
+| v2.10.12        | v105.0.0+up5.0.1 |
 | v2.10.11        | v105.0.0+up5.0.1 |
 | v2.10.10        | v105.0.0+up5.0.1 |
 | v2.10.9         | v105.0.0+up5.0.1 |
@@ -79,6 +79,19 @@ Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`

 ## 故障排除

+### Resource Exhaustion of `inotify` Watchers and File Descriptors
+
+When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
+
+This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
+
+Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
+
+```shell
+sysctl -w fs.inotify.max_user_instances=8192
+sysctl -w fs.inotify.max_user_watches=524288
+```
+
 ### 日志缓冲区导致 Pod 过载

 根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
@@ -10,6 +10,7 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已

 | ID | 描述 | 日期 | 解决 |
 |----|-------------|------|------------|
+| [CVE-2026-44939](https://github.com/rancher/rancher/security/advisories/GHSA-mhc6-2gfq-xx62) | Rancher now validates the `authImage` parameter in cluster import manifests to prevent YAML injection attacks. | 27 May 2026 | Rancher [v2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2), Rancher [v2.13.6](https://github.com/rancher/rancher/releases/tag/v2.13.6), [v2.12.10](https://github.com/rancher/rancher/releases/tag/v2.12.10), [v2.11.14](https://github.com/rancher/rancher/releases/tag/v2.11.14), and [v2.10.12](https://github.com/rancher/rancher/releases/tag/v2.10.12) |
 | [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
 | [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
 | [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
@@ -20,6 +20,7 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 | --------------- | --------------- | --------------------- | ------------------------- |
+| v2.10.12        |     v0.6.12     | &check;               | &cross;                   |
 | v2.10.11        |     v0.6.12     | &check;               | &cross;                   |
 | v2.10.10        |     v0.6.11     | &check;               | &cross;                   |
 | v2.10.9         |     v0.6.10     | &check;               | &cross;                   |
@@ -12,6 +12,9 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/

 | Patch 版本                                                      | 发布时间           |
 | --------------------------------------------------------------- | ------------------ |
+| [2.11.15](https://github.com/rancher/rancher/releases/tag/v2.11.15) | 2026 年 06 月 29 日 |
+| [2.11.14](https://github.com/rancher/rancher/releases/tag/v2.11.14) | 2026 年 05 月 27 日 |
+| [2.11.13](https://github.com/rancher/rancher/releases/tag/v2.11.13) | 2026 年 04 月 30 日 |
 | [2.11.12](https://github.com/rancher/rancher/releases/tag/v2.11.12) | 2026 年 03 月 25 日 |
 | [2.11.11](https://github.com/rancher/rancher/releases/tag/v2.11.11) | 2026 年 02 月 25 日 |
 | [2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10) | 2026 年 01 月 29 日 |
@@ -284,19 +284,24 @@ import CommonPortsTable from '../../../shared-files/_common-ports-table.md';

 | 类型 | 协议 | 端口范围 | 源/目标 | 规则类型 |
 |-----------------|:--------:|:-----------:|------------------------|:---------:|
-| SSH | TCP | 22 | 0.0.0.0/0 | 入站 |
-| HTTP | TCP | 80 | 0.0.0.0/0 | 入站 |
-| 自定义 TCP 规则 | TCP | 443 | 0.0.0.0/0 | 入站 |
-| 自定义 TCP 规则 | TCP | 2376 | 0.0.0.0/0 | 入站 |
+| SSH | TCP | 22 | 0.0.0.0/0 and ::/0 | 入站 |
+| HTTP | TCP | 80 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 443 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 8443 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 2376 | 0.0.0.0/0 and ::/0 | 入站 |
 | 自定义 TCP 规则 | TCP | 2379-2380 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 UDP 规则 | UDP | 4789 | sg-xxx (rancher-nodes) | 入站 |
-| 自定义 TCP 规则 | TCP | 6443 | 0.0.0.0/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 6443 | 0.0.0.0/0 and ::/0 | 入站 |
 | 自定义 UDP 规则 | UDP | 8472 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 179 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 5473 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 9345 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 9796 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 TCP 规则 | TCP | 10250-10252 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 TCP 规则 | TCP | 10256 | sg-xxx (rancher-nodes) | 入站 |
-| 自定义 TCP 规则 | TCP | 30000-32767 | 0.0.0.0/0 | 入站 |
-| 自定义 UDP 规则 | UDP | 30000-32767 | 0.0.0.0/0 | 入站 |
-| 所有流量 | 全部 | 全部 | 0.0.0.0/0 | 出站 |
+| 自定义 TCP 规则 | TCP | 30000-32767 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 UDP 规则 | UDP | 30000-32767 | 0.0.0.0/0 and ::/0 | 入站 |
+| 所有流量 | 全部 | 全部 | 0.0.0.0/0 and ::/0 | 出站 |

 ### 打开 SUSE Linux 端口

@@ -15,6 +15,9 @@ title: 安装 Adapter

 | Rancher 版本 | Adapter 版本 |
 |-----------------|:----------------:|
+| v2.11.15        | v106.0.1+up6.0.1 |
+| v2.11.14        | v106.0.1+up6.0.1 |
+| v2.11.13        | v106.0.0+up6.0.0 |
 | v2.11.12        | v106.0.0+up6.0.0 |
 | v2.11.11        | v106.0.0+up6.0.0 |
 | v2.11.10        | v106.0.0+up6.0.0 |
@@ -79,6 +79,19 @@ Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`

 ## 故障排除

+### Resource Exhaustion of `inotify` Watchers and File Descriptors
+
+When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
+
+This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
+
+Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
+
+```shell
+sysctl -w fs.inotify.max_user_instances=8192
+sysctl -w fs.inotify.max_user_watches=524288
+```
+
 ### 日志缓冲区导致 Pod 过载

 根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
@@ -10,6 +10,9 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已

 | ID | 描述 | 日期 | 解决 |
 |----|-------------|------|------------|
+| [CVE-2026-44949](https://github.com/rancher/webhook/security/advisories/GHSA-h83p-cq95-vph4) | Fixed a security vulnerability in rancher-webhook where the FleetWorkspace mutating admission webhook performed side effects without authenticating requests, allowing a pod inside the cluster to create arbitrary namespaces and inject RBAC bindings. | 29 June 2026 | Rancher [v2.14.3](https://github.com/rancher/rancher/releases/tag/v2.14.3), Rancher [v2.13.7](https://github.com/rancher/rancher/releases/tag/v2.13.7), Rancher [v2.12.11](https://github.com/rancher/rancher/releases/tag/v2.12.11) and Rancher [v2.11.15](https://github.com/rancher/rancher/releases/tag/v2.11.15) |
+| [CVE-2026-44946](https://github.com/rancher/rancher/security/advisories/GHSA-c5jm-xcmq-9j95) | Fixed a security vulnerability in Rancher's SAML authentication handler where a valid signed SAML response could be replayed by an attacker who had also captured the victim's pre-authentication SAML state cookie, allowing the attacker to create a separate authenticated session with the victim's permissions. All SAML providers (Okta, Ping, ADFS, Keycloak, Shibboleth) were affected. | 29 June 2026 | Rancher [v2.14.3](https://github.com/rancher/rancher/releases/tag/v2.14.3), Rancher [v2.13.7](https://github.com/rancher/rancher/releases/tag/v2.13.7), Rancher [v2.12.11](https://github.com/rancher/rancher/releases/tag/v2.12.11) and Rancher [v2.11.15](https://github.com/rancher/rancher/releases/tag/v2.11.15) |
+| [CVE-2026-44939](https://github.com/rancher/rancher/security/advisories/GHSA-mhc6-2gfq-xx62) | Rancher now validates the `authImage` parameter in cluster import manifests to prevent YAML injection attacks. | 27 May 2026 | Rancher [v2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2), Rancher [v2.13.6](https://github.com/rancher/rancher/releases/tag/v2.13.6), [v2.12.10](https://github.com/rancher/rancher/releases/tag/v2.12.10), [v2.11.14](https://github.com/rancher/rancher/releases/tag/v2.11.14), and [v2.10.12](https://github.com/rancher/rancher/releases/tag/v2.10.12) |
 | [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
 | [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
 | [CVE-2023-32199](https://github.com/rancher/rancher/security/advisories/GHSA-j4vr-pcmw-hx59) | Rancher now removes the corresponding ClusterRoleBindings whenever the admin GlobalRole or its GlobalRoleBindings are deleted. Previously orphaned ClusterRoleBindings were marked with the annotation `authz.cluster.cattle.io/admin-globalrole-missing=true`. | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) and [v2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) |
@@ -20,6 +20,9 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
+| v2.11.15        |     v0.7.10     | &check;               | &cross;                   |
+| v2.11.14        |     v0.7.9      | &check;               | &cross;                   |
+| v2.11.13        |     v0.7.8      | &check;               | &cross;                   |
 | v2.11.12        |     v0.7.8      | &check;               | &cross;                   |
 | v2.11.11        |     v0.7.8      | &check;               | &cross;                   |
 | v2.11.10        |     v0.7.8      | &check;               | &cross;                   |
@@ -12,6 +12,9 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/

 | Patch 版本                                                         | 发布时间            |
 | ----------------------------------------------------------------- | ------------------ |
+| [2.12.11](https://github.com/rancher/rancher/releases/tag/v2.12.11) | 2026 年 06 月 29 日 |
+| [2.12.10](https://github.com/rancher/rancher/releases/tag/v2.12.10) | 2026 年 05 月 27 日 |
+| [2.12.9](https://github.com/rancher/rancher/releases/tag/v2.12.9) | 2026 年 04 月 30 日 |
 | [2.12.8](https://github.com/rancher/rancher/releases/tag/v2.12.8) | 2026 年 03 月 25 日 |
 | [2.12.7](https://github.com/rancher/rancher/releases/tag/v2.12.7) | 2026 年 02 月 25 日 |
 | [2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6) | 2026 年 01 月 29 日 |
@@ -236,19 +236,24 @@ import CommonPortsTable from '../../../shared-files/_common-ports-table.md';

 | 类型 | 协议 | 端口范围 | 源/目标 | 规则类型 |
 |-----------------|:--------:|:-----------:|------------------------|:---------:|
-| SSH | TCP | 22 | 0.0.0.0/0 | 入站 |
-| HTTP | TCP | 80 | 0.0.0.0/0 | 入站 |
-| 自定义 TCP 规则 | TCP | 443 | 0.0.0.0/0 | 入站 |
-| 自定义 TCP 规则 | TCP | 2376 | 0.0.0.0/0 | 入站 |
+| SSH | TCP | 22 | 0.0.0.0/0 and ::/0 | 入站 |
+| HTTP | TCP | 80 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 443 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 8443 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 2376 | 0.0.0.0/0 and ::/0 | 入站 |
 | 自定义 TCP 规则 | TCP | 2379-2380 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 UDP 规则 | UDP | 4789 | sg-xxx (rancher-nodes) | 入站 |
-| 自定义 TCP 规则 | TCP | 6443 | 0.0.0.0/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 6443 | 0.0.0.0/0 and ::/0 | 入站 |
 | 自定义 UDP 规则 | UDP | 8472 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 179 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 5473 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 9345 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 9796 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 TCP 规则 | TCP | 10250-10252 | sg-xxx (rancher-nodes) | 入站 |
 | 自定义 TCP 规则 | TCP | 10256 | sg-xxx (rancher-nodes) | 入站 |
-| 自定义 TCP 规则 | TCP | 30000-32767 | 0.0.0.0/0 | 入站 |
-| 自定义 UDP 规则 | UDP | 30000-32767 | 0.0.0.0/0 | 入站 |
-| 所有流量 | 全部 | 全部 | 0.0.0.0/0 | 出站 |
+| 自定义 TCP 规则 | TCP | 30000-32767 | 0.0.0.0/0 and ::/0 | 入站 |
+| 自定义 UDP 规则 | UDP | 30000-32767 | 0.0.0.0/0 and ::/0 | 入站 |
+| 所有流量 | 全部 | 全部 | 0.0.0.0/0 and ::/0 | 出站 |

 ### 打开 SUSE Linux 端口

@@ -6,130 +6,10 @@ title: 在云厂商的新节点上启动 Kubernetes
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider"/>
 </head>

-在 Rancher 中使用节点模板来创建 RKE 或 RKE2 集群时，每个生成的节点池都会显示在新的**主机池**选项卡中。你可以通过执行以下操作来查看主机池：
+在 Rancher 中使用节点模板来创建 RKE2 集群时，每个生成的节点池都会显示在新的**主机池**选项卡中。你可以通过执行以下操作来查看主机池：

 1. 点击**☰ > 集群管理**。
-1. 单击 RKE 或 RKE2 集群的名称。
-
-## RKE 集群
-
-使用 Rancher，你可以基于[节点模板](use-new-nodes-in-an-infra-provider.md#节点模板)创建节点池。此节点模板定义了要用于在基础设施提供商或云厂商中启动节点的参数。
-
-在托管在云厂商的节点池上安装 Kubernetes 的一个好处是，如果一个节点与集群断开连接，Rancher 可以自动创建另一个节点并将其加入集群，从而确保节点池的数量符合要求。
-
-可用于创建节点模板的云提供商是由[主机驱动](use-new-nodes-in-an-infra-provider.md#主机驱动)决定的。
-
-### 节点模板
-
-节点模板保存了用于在特定云提供商中配置节点时要使用的参数。这些节点可以从 UI 启动。Rancher 使用 [Docker Machine](https://github.com/docker/docs/blob/vnext-engine/machine/overview.md) 来配置这些节点。可用于创建节点模板的云提供商取决于 Rancher 中状态是 Active 的主机驱动。
-
-在 Rancher 中创建节点模板后，模板会被保存，以便你可以再次使用该模板来创建节点池。节点模板绑定到你的登录名。添加模板后，你可以将其从用户配置文件中删除。
-
-#### 节点标签
-
-你可以为每个节点模板添加[标签](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)，这样，使用节点模板创建的节点都会自动带有这些标签。
-
-无效标签会阻止升级，或阻止 Rancher 启动。有关标签语法的详细信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
-
-#### 节点污点
-
-你可以为每个节点模板添加[污点](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)，这样，使用节点模板创建的节点都会自动带有这些污点。
-
-由于污点可以同时添加到节点模板和节点池中，因此如果添加了相同键的污点效果没有冲突，则所有污点都将添加到节点中。如果存在具有相同键但不同效果的污点，则节点池中的污点将覆盖节点模板中的污点。
-
-#### 节点模板的管理员控制
-
-管理员可以控制所有节点模板。现在，管理员可以维护 Rancher 中的所有节点模板。当节点模板所有者不再使用 Rancher 时，他们创建的节点模板可以由管理员管理，以便继续更新和维护集群。
-
-要访问所有节点模板，管理员需要执行以下操作：
-
-1. 点击 **☰ > 集群管理**。
-1. 单击 **RKE1 配置 > 节点模板**。
-
-**结果**：列出所有节点模板。你可以通过单击 **⋮** 来编辑或克隆模板。
-
-### 节点池
-
-使用 Rancher，你可以基于[节点模板](#节点模板)创建节点池。
-
-节点模板定义了节点的配置，例如要使用的操作系统、CPU 数量和内存量。
-
-使用节点池的好处是，如果一个节点被销毁或删除，你可以增加 Active 节点的数量来补偿丢失的节点。节点池可以帮助你确保节点池的计数符合要求。
-
-每个节点池必须分配一个或多个节点角色。
-
-每个节点角色（即 etcd、controlplane 和 worker）都应分配给不同的节点池。虽然你可以将多个节点角色分配给同一个节点池，但不要在生产集群中执行此操作。
-
-推荐的设置：
-
- 具有 etcd 角色且计数为 3 的节点池
- 具有 controlplane 角色且计数至少为 2 的节点池
- 具有 worker 角色且计数至少为 2 的节点池
-
-**离线环境中的 RKE1 下游集群节点**：
-
-默认情况下，在配置 RKE1 下游集群节点时（例如在 vSphere 中），Rancher 会尝试运行 Docker 安装脚本。但是，Rancher Docker 安装脚本在离线环境中会运行失败。要解决此问题，如果 Docker 已预安装到 VM 镜像上，你可以选择在创建节点模板时跳过安装 Docker。为此，你可以在 Rancher UI **引擎选项**下的 `Docker 安装 URL` 下拉列表中选择 **无**。
-
-<figcaption>**引擎选项下拉列表**</figcaption>
-
-![引擎选项下拉列表](/img/node-template-engine-options-rke1.png)
-
-#### 节点池污点
-
-如果你没有在节点模板上定义[污点](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)，则可以为每个节点池添加污点。将污点添加到节点池的好处是你可以更改节点模板，而不需要先确保污点存在于新模板中。
-
-每个污点都将自动添加到节点池中已创建的节点。因此，如果你在已有节点的节点池中添加污点，污点不会应用到已有的节点，但是添加到该节点池中的新节点都将获得该污点。
-
-如果污点同时添加到节点模板和节点池中，且添加了相同键的污点效果没有冲突，则所有污点都将添加到节点中。如果存在具有相同键但不同效果的污点，则节点池中的污点将覆盖节点模板中的污点。
-
-#### 节点自动替换
-
-Rancher 可以自动替换节点池中无法访问的节点。如果节点在指定的时间中处于 Inactive 状态，Rancher 将使用该节点池的节点模板来重新创建节点。
-
-:::caution
-
-自我修复节点池的功能帮助你替换<b>无状态</b>应用的 worker 节点。不建议在 master 节点或连接了持久卷的节点的节点池上启用节点自动替换，因为虚拟机会被临时处理。节点池中的节点与集群断开连接时，其持久卷将被破坏，从而导致有状态应用的数据丢失。
-
-:::
-
-节点自动替换基于 Kubernetes 节点控制器工作。节点控制器定期检查所有节点的状态（可通过 `kube-controller` 的 `--node-monitor-period` 标志配置）。一个节点不可访问时，节点控制器将污染该节点。发生这种情况时，Rancher 将开始其删除倒计时。你可以配置 Rancher 等待删除节点的时间。如果在删除倒计时结束前污点没有被删除，Rancher 将继续删除该节点。Rancher 会根据节点池设置的数量来创建新的节点。
-
-#### 启用节点自动替换
-
-创建节点池时，你可以指定 Rancher 替换无响应节点的等待时间（以分钟为单位）。
-
-1. 在创建或编辑集群的表单中，转到**节点池**。
-1. 转到要启用节点自动替换的节点池。在 **Recreate Unreachable After** 字段中，输入 Rancher 在替换节点之前应该等待节点响应的分钟数。
-1. 填写表单的其余部分以创建或编辑集群。
-
-**结果** ：已为节点池启用节点自动替换。
-
-#### 禁用节点自动替换
-
-你可以执行以下步骤从 Rancher UI 禁用节点自动替换：
-
-1. 点击 **☰ > 集群管理**。
-1. 在**集群**页面上，转到要禁用节点自动替换的集群，然后单击 **⋮ > 编辑配置**。
-1. 在**节点池**部分中，转到要启用节点自动替换的节点池。在 **Recreate Unreachable After** 字段中，输入 0。
-1. 单击**保存**。
-
-**结果**：已禁用节点池的节点自动替换。
-
-### 云凭证
-
-节点模板可以使用云凭证，来存储用于在云提供商中启动节点的凭证，其优点是：
-
- 凭证会存储为更安全的 Kubernetes 密文，而且你无需每次都输入凭证便可编辑节点模板。
-
- 创建云凭证后，你可以重新使用该凭证来创建其他节点模板。
-
- 多个节点模板可以使用相同的云凭证来创建节点池。如果你的密钥被泄露或过期，则可以在一个位置更新云凭证，从而一次更新所有使用该凭证的节点模板。
-
-创建云凭证后，用户可以[管理创建的云凭证](../../../../reference-guides/user-settings/manage-cloud-credentials.md)。
-
-### 主机驱动
-
-如果你找不到想要的主机驱动，你可以在 Rancher 的[内置主机驱动](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#激活停用主机驱动)中查看并激活它，也可以[添加自定义主机驱动](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#添加自定义主机驱动)。
+1. Click the name of the RKE2 cluster.

 ## RKE2 集群

@@ -21,21 +21,6 @@ kubeconfig 文件及其内容特定于各个集群。你可以从 Rancher 的**

 如果管理员[关闭了 kubeconfig 令牌生成](../../../../api/api-tokens.md#在生成的-kubeconfig-中禁用令牌)，则 kubeconfig 文件要求 [Rancher CLI](../../../../reference-guides/cli-with-rancher/rancher-cli.md) 存在于你的 PATH 中。

-## RKE 集群的两种身份验证方法
-
-如果集群不是 [RKE 集群](../../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)，kubeconfig 文件只允许你以一种方式访问集群，即通过 Rancher Server 进行身份验证，然后 Rancher 允许你在集群上运行 kubectl 命令。
-
-对于 RKE 集群，kubeconfig 文件允许你通过两种方式进行身份验证：
-
- **通过 Rancher Server 身份验证代理**：Rancher 的身份验证代理会验证你的身份，然后将你连接到要访问的下游集群。
- **直接使用下游集群的 API Server**：RKE 集群默认启用授权集群端点。此端点允许你使用 kubectl CLI 和 kubeconfig 文件访问下游 Kubernetes 集群，且 RKE 集群默认启用该端点。在这种情况下，下游集群的 Kubernetes API server 通过调用 Rancher 设置的 webhook（`kube-api-auth` 微服务）对你进行身份验证。
-
-第二种方法（即直接连接到集群的 Kubernetes API server）非常重要，因为如果你无法连接到 Rancher，这种方法可以让你访问下游集群。
-
-要使用授权集群端点，你需要配置 kubectl，从而使用 Rancher 在创建 RKE 集群时生成的 kubeconfig 文件中的额外 kubectl 上下文。该文件可以从 Rancher UI 的**集群**视图中下载，配置 kubectl 的说明在[此页面](use-kubectl-and-kubeconfig.md#直接使用下游集群进行身份验证)。
-
-[架构介绍](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md)也详细解释了这些与下游 Kubernetes 集群通信的方法，并介绍了 Rancher 的工作原理以及 Rancher 如何与下游集群通信的详细信息。
-
 ## 关于 kube-api-auth 身份验证 Webhook

 `kube-api-auth` 微服务是为[授权集群端点](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-授权集群端点)提供用户认证功能而部署的。当你使用 `kubectl` 访问下游集群时，集群的 Kubernetes API server 会使用 `kube-api-auth` 服务作为 webhook 对你进行身份验证。
@@ -64,10 +64,6 @@ Rancher v2.5 简化了在 Rancher 管理的集群上安装 Longhorn 的过程。

 在将数据存储在 iSCSI 卷上的 [Rancher 启动的 Kubernetes 集群](../../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)中，你可能会遇到 kubelet 无法自动连接 iSCSI 卷的问题。有关解决此问题的详细信息，请参阅[此页面](manage-persistent-storage/install-iscsi-volumes.md)。

-## hostPath 卷
-
-在创建 hostPath 卷之前，你需要在集群配置中设置 [extra_bind](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/#extra-binds/)。这会将路径作为卷安装在你的 kubelet 中，可用于工作负载中的 hostPath 卷。
-
 ## 将 vSphere Cloud Provider 从树内迁移到树外

 Kubernetes 正在逐渐不在树内维护云提供商。vSphere 有一个树外云提供商，可通过安装 vSphere 云提供商和云存储插件来使用。
@@ -15,6 +15,9 @@ title: 安装 Adapter

 | Rancher 版本 | Adapter 版本 |
 |-----------------|:----------------:|
+| v2.12.11         |  107.0.0+up7.0.0 |
+| v2.12.10         |  107.0.0+up7.0.0 |
+| v2.12.9         |  107.0.0+up7.0.0 |
 | v2.12.8         |  107.0.0+up7.0.0 |
 | v2.12.7         |  107.0.0+up7.0.0 |
 | v2.12.6         |  107.0.0+up7.0.0 |
@@ -79,6 +79,19 @@ Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`

 ## 故障排除

+### Resource Exhaustion of `inotify` Watchers and File Descriptors
+
+When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
+
+This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
+
+Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
+
+```shell
+sysctl -w fs.inotify.max_user_instances=8192
+sysctl -w fs.inotify.max_user_watches=524288
+```
+
 ### 日志缓冲区导致 Pod 过载

 根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
@@ -10,6 +10,10 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已

 | ID | 描述 | 日期 | 解决 |
 |----|-------------|------|------------|
+| [CVE-2026-44949](https://github.com/rancher/webhook/security/advisories/GHSA-h83p-cq95-vph4) | Fixed a security vulnerability in rancher-webhook where the FleetWorkspace mutating admission webhook performed side effects without authenticating requests, allowing a pod inside the cluster to create arbitrary namespaces and inject RBAC bindings. | 29 June 2026 | Rancher [v2.14.3](https://github.com/rancher/rancher/releases/tag/v2.14.3), Rancher [v2.13.7](https://github.com/rancher/rancher/releases/tag/v2.13.7), Rancher [v2.12.11](https://github.com/rancher/rancher/releases/tag/v2.12.11) and Rancher [v2.11.15](https://github.com/rancher/rancher/releases/tag/v2.11.15) |
+| [CVE-2026-44946](https://github.com/rancher/rancher/security/advisories/GHSA-c5jm-xcmq-9j95) | Fixed a security vulnerability in Rancher's SAML authentication handler where a valid signed SAML response could be replayed by an attacker who had also captured the victim's pre-authentication SAML state cookie, allowing the attacker to create a separate authenticated session with the victim's permissions. All SAML providers (Okta, Ping, ADFS, Keycloak, Shibboleth) were affected. | 29 June 2026 | Rancher [v2.14.3](https://github.com/rancher/rancher/releases/tag/v2.14.3), Rancher [v2.13.7](https://github.com/rancher/rancher/releases/tag/v2.13.7), Rancher [v2.12.11](https://github.com/rancher/rancher/releases/tag/v2.12.11) and Rancher [v2.11.15](https://github.com/rancher/rancher/releases/tag/v2.11.15) |
+| [CVE-2026-41052](https://github.com/rancher/rancher/security/advisories/GHSA-vx8h-4prv-g744) | Updated the permissions of the built-in `project-owner` role to no longer include the `updatepsa` verb. This prevents users with this role from bypassing restricted PSA policies or deploying privileged workloads within their projects. If your organization requires users to retain this capability, administrators must create a custom project role that explicitly grants the `updatepsa` verb for the project resource. | 27 May 2026 | Rancher [v2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2), Rancher [v2.13.6](https://github.com/rancher/rancher/releases/tag/v2.13.6), [v2.12.10](https://github.com/rancher/rancher/releases/tag/v2.12.10) |
+| [CVE-2026-44939](https://github.com/rancher/rancher/security/advisories/GHSA-mhc6-2gfq-xx62) | Rancher now validates the `authImage` parameter in cluster import manifests to prevent YAML injection attacks. | 27 May 2026 | Rancher [v2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2), Rancher [v2.13.6](https://github.com/rancher/rancher/releases/tag/v2.13.6), [v2.12.10](https://github.com/rancher/rancher/releases/tag/v2.12.10), [v2.11.14](https://github.com/rancher/rancher/releases/tag/v2.11.14), and [v2.10.12](https://github.com/rancher/rancher/releases/tag/v2.10.12) |
 | [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
 | [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
 | [CVE-2023-32199](https://github.com/rancher/rancher/security/advisories/GHSA-j4vr-pcmw-hx59) | Rancher now removes the corresponding ClusterRoleBindings whenever the admin GlobalRole or its GlobalRoleBindings are deleted. Previously orphaned ClusterRoleBindings were marked with the annotation `authz.cluster.cattle.io/admin-globalrole-missing=true`. | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) and [v2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) |
--- a/Show More
+++ b/Show More