Merge branch 'rancher:main' into update-api-sidebar

2026-09-25 04:28:15 +00:00 · 2024-03-29 13:24:58 -07:00
parent de1b9f3a08 2cb7e383fa
commit 867eb490b7
120 changed files with 4220 additions and 1723 deletions
@@ -6,7 +6,9 @@ title: Troubleshooting Certificates
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting"/>
 </head>

-### How Do I Know if My Certificates are in PEM Format?
+<DockerSupportWarning />
+
+## How Do I Know if My Certificates are in PEM Format?

 You can recognize the PEM format by the following traits:

@@ -48,7 +50,7 @@ VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
 -----END PRIVATE KEY-----
 ```

-### Converting a Certificate Key From PKCS8 to PKCS1
+## Converting a Certificate Key From PKCS8 to PKCS1

 If you are using a PKCS8 certificate key file, Rancher will log the following line:

@@ -64,7 +66,7 @@ openssl rsa -in key.pem -out convertedkey.pem

 You can now use `convertedkey.pem` as certificate key file for Rancher.

-### What is the Order of Certificates if I Want to Add My Intermediate(s)?
+## What is the Order of Certificates if I Want to Add My Intermediate(s)?

 The order of adding certificates is as follows:

@@ -77,7 +79,7 @@ The order of adding certificates is as follows:
 -----END CERTIFICATE-----
 ```

-### How Do I Validate My Certificate Chain?
+## How Do I Validate My Certificate Chain?

 You can validate the certificate chain by using the `openssl` binary. If the output of the command (see the command example below) ends with `Verify return code: 0 (ok)`, your certificate chain is valid. The `ca.pem` file must be the same as you added to the `rancher/rancher` container.

@@ -3,16 +3,12 @@ title: Installing Rancher on a Single Node Using Docker
 description: For development and testing environments only, use a Docker install. Install Docker on a single Linux host, and deploy Rancher with a single Docker container.
 ---

-:::caution
-
-Docker installs are not supported in production environments. These instructions are provided for testing and development purposes only. Please don't use this method to install Rancher in production environments.
-
-:::
-
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker"/>
 </head>

+<DockerSupportWarning />
+
 Rancher can be installed by running a single Docker container.

 In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container.
@@ -6,6 +6,8 @@ title: Rolling Back Rancher Installed with Docker
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher"/>
 </head>

+<DockerSupportWarning />
+
 If a Rancher upgrade does not complete successfully, you'll have to roll back to your Rancher setup that you were using before [Docker Upgrade](./upgrade-docker-installed-rancher.md). Rolling back restores:

 - Your previous version of Rancher.
@@ -8,6 +8,8 @@ title: Upgrading Rancher Installed with Docker

 The following instructions will guide you through upgrading a Rancher server that was installed with Docker.

+<DockerSupportWarning />
+
 ## Prerequisites

 - **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades/upgrades.md#known-upgrade-issues) in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete 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) 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.
@@ -52,8 +52,6 @@ When you need to make changes to your infrastructure, instead of manually updati

 - You can reverse engineer how to do define a setting in Terraform by changing the setting in Rancher, then going back and checking your Terraform state file to see how it maps to the current state of your infrastructure.

- If you want to manage Kubernetes cluster settings, Rancher settings, and hardware settings all in one place, use [Terraform modules](https://github.com/rancher/terraform-modules). You can pass a cluster configuration YAML file or an RKE template configuration file to a Terraform module so that the Terraform module will create it. In that case, you could use your infrastructure-as-code to manage the version control and revision history of both your Kubernetes cluster and its underlying hardware.
-
 ## Tip for Creating CIS Benchmark Compliant Clusters

 This section describes one way that you can make security and compliance-related config files standard in your clusters.
@@ -139,6 +139,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
+  --set installCRDs=true \
  --version v1.5.1
 ```

@@ -6,7 +6,9 @@ title: Troubleshooting Certificates
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting"/>
 </head>

-### How Do I Know if My Certificates are in PEM Format?
+<DockerSupportWarning />
+
+## How Do I Know if My Certificates are in PEM Format?

 You can recognize the PEM format by the following traits:

@@ -48,7 +50,7 @@ VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
 -----END PRIVATE KEY-----
 ```

-### Converting a Certificate Key From PKCS8 to PKCS1
+## Converting a Certificate Key From PKCS8 to PKCS1

 If you are using a PKCS8 certificate key file, Rancher will log the following line:

@@ -64,7 +66,7 @@ openssl rsa -in key.pem -out convertedkey.pem

 You can now use `convertedkey.pem` as certificate key file for Rancher.

-### What is the Order of Certificates if I Want to Add My Intermediate(s)?
+## What is the Order of Certificates if I Want to Add My Intermediate(s)?

 The order of adding certificates is as follows:

@@ -77,7 +79,7 @@ The order of adding certificates is as follows:
 -----END CERTIFICATE-----
 ```

-### How Do I Validate My Certificate Chain?
+## How Do I Validate My Certificate Chain?

 You can validate the certificate chain by using the `openssl` binary. If the output of the command (see the command example below) ends with `Verify return code: 0 (ok)`, your certificate chain is valid. The `ca.pem` file must be the same as you added to the `rancher/rancher` container.

@@ -3,16 +3,12 @@ title: Installing Rancher on a Single Node Using Docker
 description: For development and testing environments only, use a Docker install. Install Docker on a single Linux host, and deploy Rancher with a single Docker container.
 ---

-:::caution
-
-Docker installs are not supported in production environments. These instructions are provided for testing and development purposes only. Please don't use this method to install Rancher in production environments.
-
-:::
-
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker"/>
 </head>

+<DockerSupportWarning />
+
 Rancher can be installed by running a single Docker container.

 In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container.
@@ -6,6 +6,8 @@ title: Rolling Back Rancher Installed with Docker
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher"/>
 </head>

+<DockerSupportWarning />
+
 If a Rancher upgrade does not complete successfully, you'll have to roll back to your Rancher setup that you were using before [Docker Upgrade](upgrade-docker-installed-rancher.md). Rolling back restores:

 - Your previous version of Rancher.
@@ -8,6 +8,8 @@ title: Upgrading Rancher Installed with Docker

 The following instructions will guide you through upgrading a Rancher server that was installed with Docker.

+<DockerSupportWarning />
+
 ## Prerequisites

 - **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#known-upgrade-issues) in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete 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) 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.
@@ -52,8 +52,6 @@ When you need to make changes to your infrastructure, instead of manually updati

 - You can reverse engineer how to do define a setting in Terraform by changing the setting in Rancher, then going back and checking your Terraform state file to see how it maps to the current state of your infrastructure.

- If you want to manage Kubernetes cluster settings, Rancher settings, and hardware settings all in one place, use [Terraform modules](https://github.com/rancher/terraform-modules). You can pass a cluster configuration YAML file or an RKE template configuration file to a Terraform module so that the Terraform module will create it. In that case, you could use your infrastructure-as-code to manage the version control and revision history of both your Kubernetes cluster and its underlying hardware.
-
 ## Tip for Creating CIS Benchmark Compliant Clusters

 This section describes one way that you can make security and compliance-related config files standard in your clusters.
@@ -1,50 +1,52 @@
 ---
-title: Helm Charts in Rancher
+title: Helm Charts and Apps
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/helm-charts-in-rancher"/>
 </head>

-In this section, you'll learn how to manage Helm chart repositories and applications in Rancher.
+In this section, you'll learn how to manage Helm chart repositories and apps in Rancher.

-### Changes in Rancher v2.5
+## Catalogs and Changes in Rancher v2.5

-In Rancher v2.5, the Apps and Marketplace feature replaced the catalog system.
+In Rancher v2.5, the **Apps and Marketplace** feature replaces the catalog system.

-In the cluster manager, Rancher uses a catalog system to import bundles of charts and then uses those charts to either deploy custom helm applications or Rancher's tools such as Monitoring or Istio. The catalog system is still available in the cluster manager in Rancher v2.5, but it is deprecated.
+In the cluster manager, Rancher uses a catalog system to import bundles of charts and then uses those charts to either deploy custom Kubernetes applications or Rancher's tools such as Monitoring or Istio. The catalog system is still available in the cluster manager in Rancher v2.5, but it is deprecated.
+
+### How Helm Charts Work in Rancher

 Now in the Cluster Explorer, Rancher uses a similar but simplified version of the same system. Repositories can be added in the same way that catalogs were, but are specific to the current cluster. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts.

-### Charts
+## Charts

-From the top-left menu select _"Apps & Marketplace"_ and you will be taken to the Charts page.
+From the top-left menu select **Apps & Marketplace** and you will be taken to the **Charts** page.

-The charts page contains all Rancher, Partner, and Custom Charts.
+The **Charts** page contains all Rancher, Partner, and Custom charts.

-* Rancher tools such as Logging or Monitoring are included under the Rancher label
-* Partner charts reside under the Partners label
-* Custom charts will show up under the name of the repository
+* Rancher tools such as Logging or Monitoring are included under the Rancher label.
+* Partner charts reside under the Partners label.
+* Custom charts will show up under the name of the repository.

 All three types are deployed and managed in the same way.

 > Apps managed by the Cluster Manager should continue to be managed only by the Cluster Manager, and apps managed with the Cluster Explorer must be managed only by the Cluster Explorer.

-### Repositories
+## Repositories

-From the left sidebar select _"Repositories"_.
+From the left sidebar select **Repositories**.

 These items represent Helm repositories, and can be either traditional Helm endpoints which have an index.yaml, or Git repositories which will be cloned and can point to a specific branch. In order to use custom charts, simply add your repository here and they will become available in the Charts tab under the name of the repository.

-#### Add Custom Git Repositories
+### Add Custom Git Repositories

 Click **Create** and select the target, **Git repository containing Helm chart...** to add a custom Git repository that contains your Helm charts or cluster template definitions.

-You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from the default, `main`.
+You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from whichever branch the repo owner has set as the default. Usually, the default branch is either `main` or `master`.

 Whenever you add a chart repository to Rancher, it becomes available immediately.

-#### Add Custom Helm Chart Repositories
+### Add Custom Helm Chart Repositories

 You can add your own Helm chart repositories to serve chart packages to Rancher. You can use any HTTP server, as long as the server can respond to GET requests and serve YAML files and tar archives.

@@ -52,11 +54,11 @@ For more information on Helm chart repositories, see the [official Helm docs](ht

 To add a custom Helm chart repository to Rancher, click **Create** and select **http(s) URL to an index generated by Helm** as the target. Enter a repo name and the index URL address of the chart repository.

-#### Add Private Git/Helm Chart Repositories
+### Add Private Git/Helm Chart Repositories

 You can add private Git or Helm chart repositories with SSH key credentials or an HTTP basic auth secret, such as a username and password.

-#### Add a Private CA to Repositories
+### Add a Private CA to Repositories

 To add a private CA to Helm chart repositories:

@@ -79,35 +81,41 @@ To add a private CA to Helm chart repositories:
    [...]
    ```

-> **Note:** Helm chart repositories with authentication
->
-> As of Rancher v2.5.12, a new value `disableSameOriginCheck` has been added to the Repo.Spec. This allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
->
-> To use this feature for an existing Helm chart repository, click <b>⋮ > Edit YAML</b>. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
->
-> ```yaml
+:::note Helm chart repositories with authentication
+
+As of Rancher v2.5.12, a new value `disableSameOriginCheck` has been added to the Repo.Spec. This allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
+
+To use this feature for an existing Helm chart repository, click **⋮ > Edit YAML**. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
+
+```yaml
 [...]
 spec:
  disableSameOriginCheck: true
 [...]
 ```

-### Helm Compatibility
+:::
+
+## Helm Compatibility

 The Cluster Explorer only supports Helm 3 compatible charts.

+## Deploy and Upgrade Charts

-### Deployment and Upgrades
+From the **Charts** tab select a chart to install. Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files, but all chart installations can modify the values.yaml and other basic settings. Once you click install, a Helm operation job is deployed, and the console for the job is displayed.

-From the _"Charts"_ tab select a Chart to install. Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files, but all chart installations can modify the values.yaml and other basic settings. Once you click install, a Helm operation job is deployed, and the console for the job is displayed.
+To view all recent changes, go to the **Recent Operations** tab. From there you can view the call that was made, conditions, events, and logs.

-To view all recent changes, go to the _"Recent Operations"_ tab. From there you can view the call that was made, conditions, events, and logs.
+After installing a chart, you can find it in the **Installed Apps** tab. In this section you can upgrade or delete the installation, and see further details. When choosing to upgrade, the form and values presented will be the same as installation.

-After installing a chart, you can find it in the _"Installed Apps"_ tab. In this section you can upgrade or delete the installation, and see further details. When choosing to upgrade, the form and values presented will be the same as installation.
+Most Rancher tools have additional pages located in the toolbar below the **Apps & Marketplace** section to help manage and use features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.

-Most Rancher tools have additional pages located in the toolbar below the _"Apps & Marketplace"_ section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.
+:::caution

-> If you are upgrading your chart using _"Customize Helm options before upgrade"_ , please be aware that using the _"--force"_ option may result in errors if your chart has immutable fields. This is because some objects in Kubernetes cannot be changed once they are created. To ensure you do not get this error you can:
-  * use the default upgrade option ( i.e do not use _"--force"_ option )
-  * uninstall the existing chart and install the upgraded chart
-  * delete the resources with immutable fields from the cluster before performing the _"--force"_ upgrade
+If you are upgrading your chart using **Customize Helm options before upgrade**, please be aware that using the `--force` option may result in errors if your chart has immutable fields. This is because some objects in Kubernetes cannot be changed once they are created. To ensure you do not get this error you can:
+
+  * Use the default upgrade option ( i.e do not use `--force` option ).
+  * Uninstall the existing chart and install the upgraded chart.
+  * Delete the resources with immutable fields from the cluster before performing the `--force` upgrade.
+
+:::
@@ -166,6 +166,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
+  --set installCRDs=true \
  --version v1.11.0
 ```

@@ -29,7 +29,7 @@ A restore is performed by creating a Restore custom resource.
 1. In the left navigation bar, click **Rancher Backups > Restore**.
    :::note

-    If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps & Marketplace** (Rancher before v2.6.5) or **Apps** (Rancher v2.6.5+). Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#charts) for more information.
+    If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps & Marketplace** (Rancher before v2.6.5) or **Apps** (Rancher v2.6.5+). Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#access-charts) for more information.

    :::

@@ -6,7 +6,9 @@ title: Troubleshooting Certificates
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting"/>
 </head>

-### How Do I Know if My Certificates are in PEM Format?
+<DockerSupportWarning />
+
+## How Do I Know if My Certificates are in PEM Format?

 You can recognize the PEM format by the following traits:

@@ -48,7 +50,7 @@ VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
 -----END PRIVATE KEY-----
 ```

-### Converting a Certificate Key From PKCS8 to PKCS1
+## Converting a Certificate Key From PKCS8 to PKCS1

 If you are using a PKCS8 certificate key file, Rancher will log the following line:

@@ -64,7 +66,7 @@ openssl rsa -in key.pem -out convertedkey.pem

 You can now use `convertedkey.pem` as certificate key file for Rancher.

-### What is the Order of Certificates if I Want to Add My Intermediate(s)?
+## What is the Order of Certificates if I Want to Add My Intermediate(s)?

 The order of adding certificates is as follows:

@@ -77,7 +79,7 @@ The order of adding certificates is as follows:
 -----END CERTIFICATE-----
 ```

-### How Do I Validate My Certificate Chain?
+## How Do I Validate My Certificate Chain?

 You can validate the certificate chain by using the `openssl` binary. If the output of the command (see the command example below) ends with `Verify return code: 0 (ok)`, your certificate chain is valid. The `ca.pem` file must be the same as you added to the `rancher/rancher` container.

@@ -3,16 +3,12 @@ title: Installing Rancher on a Single Node Using Docker
 description: For development and testing environments only, use a Docker install. Install Docker on a single Linux host, and deploy Rancher with a single Docker container.
 ---

-:::caution
-
-Docker installs are not supported in production environments. These instructions are provided for testing and development purposes only. Please don't use this method to install Rancher in production environments.
-
-:::
-
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker"/>
 </head>

+<DockerSupportWarning />
+
 Rancher can be installed by running a single Docker container.

 In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container.
@@ -6,6 +6,8 @@ title: Rolling Back Rancher Installed with Docker
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher"/>
 </head>

+<DockerSupportWarning />
+
 If a Rancher upgrade does not complete successfully, you'll have to roll back to your Rancher setup that you were using before [Docker Upgrade](upgrade-docker-installed-rancher.md). Rolling back restores:

 - Your previous version of Rancher.
@@ -8,11 +8,7 @@ title: Upgrading Rancher Installed with Docker

 The following instructions will guide you through upgrading a Rancher server that was installed with Docker.

-:::caution
-
-**Docker installs are not supported in production environments.** These instructions are provided for testing and development purposes only. If you have already deployed a Docker install in production and need to upgrade to a new Rancher version, we recommend [migrating to the Helm chart install](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) before upgrading.
-
-:::
+<DockerSupportWarning />

 ## Prerequisites

@@ -52,8 +52,6 @@ When you need to make changes to your infrastructure, instead of manually updati

 - You can reverse engineer how to do define a setting in Terraform by changing the setting in Rancher, then going back and checking your Terraform state file to see how it maps to the current state of your infrastructure.

- If you want to manage Kubernetes cluster settings, Rancher settings, and hardware settings all in one place, use [Terraform modules](https://github.com/rancher/terraform-modules). You can pass a cluster configuration YAML file or an RKE template configuration file to a Terraform module so that the Terraform module will create it. In that case, you could use your infrastructure-as-code to manage the version control and revision history of both your Kubernetes cluster and its underlying hardware.
-
 ## Tip for Creating CIS Benchmark Compliant Clusters

 This section describes one way that you can make security and compliance-related config files standard in your clusters.
@@ -1,18 +1,32 @@
 ---
-title: Helm Charts in Rancher
+title: Helm Charts and Apps
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher"/>
 </head>

-In this section, you'll learn how to manage Helm chart repositories and applications in Rancher. Helm chart repositories are managed using **Apps & Marketplace** (Rancher before v2.6.5) or **Apps** (Rancher v2.6.5+). It uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Helm applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.
+In this section, you'll learn how to manage Helm chart repositories and applications in Rancher. 

-### Changes in Rancher v2.6
+## How Helm Charts Work in Rancher

-Starting in Rancher v2.6.0, a new versioning scheme for Rancher feature charts was implemented. The changes are centered around the major version of the charts and the +up annotation for upstream charts, where applicable.
+Rancher uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Kubernetes applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.

-**Major Version:** The major version of the charts is tied to Rancher minor versions. When you upgrade to a new Rancher minor version, you should ensure that all of your **Apps & Marketplace** (Rancher before v2.6.5) or **Apps** (Rancher v2.6.5+) charts are also upgraded to the correct release line for the chart.
+### Catalogs, Apps, and the Rancher UI
+
+[Rancher v2.4 and earlier](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI.  
+
+Helm chart repositories are now managed using **Apps & Marketplace** (before Rancher v2.6.5) or **Apps** (Rancher v2.6.5 and later).
+
+### Versioning Changes in Rancher v2.6
+
+Starting in Rancher v2.6.0, a new versioning scheme for Rancher feature charts was implemented. The changes are centered around the major version of the charts and the `+up` annotation for upstream charts, where applicable.
+
+**Major Version:** The major versions of feature charts are tied to Rancher minor versions. When you upgrade to a new Rancher minor version, you should ensure that all of your charts are also upgraded to the correct release line for the chart.
+
+**Charts based on upstream:** When you upgrade, make sure that the upstream chart version is compatible with your Rancher version. The `+up` annotation for the chart indicates which upstream version the Rancher chart is tracking. For example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some additional Rancher patches.
+
+When upgrading Rancher versions, don't downgrade the version of the chart that you are using. For example, if you are using a version of Monitoring that is later than `16.6.0` in Rancher v2.5, you shouldn't upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.

 :::note

@@ -20,7 +34,7 @@ Any major versions that are less than the ones mentioned in the table below are

 :::

-**Feature Charts:**
+### Feature Charts

 | **Name** | **Supported Minimum Version** | **Supported Maximum Version** |
 | ---------------- | ------------ | ------------ |
@@ -41,36 +55,28 @@ Any major versions that are less than the ones mentioned in the table below are
 | rancher-vsphere-csi | 100.3.0+up2.5.1-rancher1 | 100.3.0+up2.5.1-rancher1 |
 | rancher-wins-upgrader | 0.0.100 | 100.0.1+up0.0.1 |

-<br/>
-**Charts based on upstream:** For charts that are based on upstreams, the +up annotation should inform you of what upstream version the Rancher chart is tracking. Check the upstream version compatibility with Rancher during upgrades also.
-
- As an example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some Rancher patches added to it.
-
- On upgrades, ensure that you are not downgrading the version of the chart that you are using. For example, if you are using a version of Monitoring > `16.6.0` in Rancher 2.5, you should not upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.
-
-
-### Charts
+## Access Charts

 <Tabs groupId="rancher-version">
 <TabItem value="Rancher v2.6.5+">

-From the top-left menu select **Apps** and you will be taken to the Charts page.
+From the top-left menu select **Apps** and you will be taken to the **Charts** page.

 </TabItem>
 <TabItem value="Rancher before v2.6.5">

-From the top-left menu select **Apps & Marketplace** and you will be taken to the Charts page.
+From the top-left menu select **Apps & Marketplace** and you will be taken to the **Charts** page.

 </TabItem>
 </Tabs>

-The charts page contains all Rancher, Partner, and Custom Charts.
+The **Charts** page contains all Rancher, Partner, and Custom charts. You can filter charts by selecting the left-most dropdown menu:

-* Rancher tools such as Logging or Monitoring are included under the Rancher label
-* Partner charts reside under the Partners label
-* Custom charts will show up under the name of the repository
+* Rancher tools such as Logging or Monitoring are listed under the **Rancher** label.
+* Partner charts are under the **Partners** label.
+* Custom charts are listed under the name of their respective repository.

-All three types are deployed and managed in the same way.
+All three types of charts are deployed and managed in the same way.

 :::note

@@ -78,38 +84,48 @@ Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) s

 :::

-### Repositories
+## Manage Repositories

-From the left sidebar select _"Repositories"_.
+The **Repositories** page lists your Helm repositories. These include traditional Helm endpoints which have an index.yaml, and Git repositories that are cloned and point to a specific branch. To use custom charts, add your repository here. After you add a repository, you can access custom charts in the **Charts** page, listed under the name of the repository.

-These items represent Helm repositories, and can be either traditional Helm endpoints which have an index.yaml, or Git repositories which will be cloned and can point to a specific branch. In order to use custom charts, simply add your repository here and they will become available in the Charts tab under the name of the repository.
+To access the **Repositories** page, select **Repositories** from the left nevigation menu.

-#### Add Custom Git Repositories
+### Add Custom Git Repositories

-Click **Create** and select the target, **Git repository containing Helm chart...** to add a custom Git repository that contains your Helm charts or cluster template definitions.
+To add a custom Git repository that contains your Helm charts or cluster template definitions:

-You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from the default, `main`.
+1. Select **Repositories** from the left nevigation menu.
+1. Click **Create**.
+1. Select the target, **Git repository containing Helm chart...**.
+1. You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from whichever branch the repo owner has set as the default. Usually, the default branch is named either `main` or `master`.
+1. Click **Create** to add the repository. 

-Whenever you add a chart repository to Rancher, it becomes available immediately.
+After you add a chart repository to Rancher, it becomes available immediately.

-#### Add Custom Helm Chart Repositories
+### Add Custom Helm Chart Repositories

 You can add your own Helm chart repositories to serve chart packages to Rancher. You can use any HTTP server, as long as the server can respond to GET requests and serve YAML files and tar archives.

 For more information on Helm chart repositories, see the [official Helm docs](https://helm.sh/docs/topics/chart_repository/).

-To add a custom Helm chart repository to Rancher, click **Create** and select **http(s) URL to an index generated by Helm** as the target. Enter a repo name and the index URL address of the chart repository.
+1. Select **Repositories** from the left nevigation menu.
+1. Click **Create**.
+1. Select the target, **http(s) URL to an index generated by Helm**. 
+1. Enter a repo name and the index URL address of the chart repository.

-#### Add Private Git/Helm Chart Repositories
+### Add Private Git/Helm Chart Repositories

 You can add private Git or Helm chart repositories with SSH key credentials or an HTTP basic auth secret, such as a username and password.

-#### Add a Private CA to Repositories
+### Add a Private CA to Repositories

 To add a private CA to Helm chart repositories:

- **HTTP-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
-    ```
+1. Select **Repositories** from the left nevigation menu. 
+1. Find the row associated with the Git or HTTP-based repository you want to add a private CA to, and click **⋮ > Edit YAML**.
+1. Set the `caBundle` value, as in the following example:
+
+  ```yaml
    [...]
    spec:
      caBundle:
@@ -117,26 +133,13 @@ To add a private CA to Helm chart repositories:
    ...
    nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
    [...]
-    ```
-
-
- **Git-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
-    ```
-    [...]
-    spec:
-      caBundle:
-    MIIFXzCCA0egAwIBAgIUWNy8WrvSkgNzV0zdWRP79j9cVcEwDQYJKoZIhvcNAQELBQAwPzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYDVQQKDAtNeU9yZywgSW5jLjENMAsGA1UEAwwEcm9vdDAeFw0yMTEyMTQwODMyMTdaFw0yNDEwMDMwODMyMT
-    ...
-    nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
-    [...]
-    ```
-
+  ```

 :::note Helm chart repositories with authentication

 As of Rancher v2.6.3, a new value `disableSameOriginCheck` has been added to the Repo.Spec. This allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.

-To use this feature for an existing Helm chart repository, click <b>⋮ > Edit YAML</b>. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
+To use this feature for an existing Helm chart repository, click **⋮ > Edit YAML**. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.

 ```yaml
 [...]
@@ -147,41 +150,39 @@ spec:

 :::

-### Helm Compatibility
+## Helm Compatibility

 Only Helm 3 compatible charts are supported.

+## Deploy and Upgrade Charts

-### Deployment and Upgrades
+From the **Charts** tab select a chart to install. Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files, but all chart installations can modify the values.yaml and other basic settings. After you click install, a Helm operation job is deployed, and the console for the job is displayed.

-From the _"Charts"_ tab select a Chart to install. Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files, but all chart installations can modify the values.yaml and other basic settings. Once you click install, a Helm operation job is deployed, and the console for the job is displayed.
+To view all recent changes, go to the **Recent Operations** tab. From there you can view the call that was made, conditions, events, and logs.

-To view all recent changes, go to the _"Recent Operations"_ tab. From there you can view the call that was made, conditions, events, and logs.
+After installing a chart, you can find it in the **Installed Apps** tab. In this section you can upgrade or delete the installation, and see further details. When choosing to upgrade, the form and values presented will be the same as installation.

-After installing a chart, you can find it in the _"Installed Apps"_ tab. In this section you can upgrade or delete the installation, and see further details. When choosing to upgrade, the form and values presented will be the same as installation.
-
-Most Rancher tools have additional pages located in the toolbar below the _"Apps & Marketplace"_ section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.
+Most Rancher tools have additional pages located in the toolbar below the **Apps & Marketplace** section to help manage and use features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.

 :::caution

-If you are upgrading your chart using _"Customize Helm options before upgrade"_ , please be aware that using the _"--force"_ option may result in errors if your chart has immutable fields. This is because some objects in Kubernetes cannot be changed once they are created. To ensure you do not get this error you can:
+If you are upgrading your chart using **Customize Helm options before upgrade**, please be aware that using the `--force` option may result in errors if your chart has immutable fields. This is because some objects in Kubernetes cannot be changed after they are created. To ensure you do not get this error you can:

-  * use the default upgrade option ( i.e do not use _"--force"_ option )
-  * uninstall the existing chart and install the upgraded chart
-  * delete the resources with immutable fields from the cluster before performing the _"--force"_ upgrade
+  * Use the default upgrade option ( i.e do not use `--force` option ).
+  * Uninstall the existing chart and install the upgraded chart.
+  * Delete the resources with immutable fields from the cluster before performing the `--force` upgrade.

 :::

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

-The upgrade button has been removed for legacy apps from the **Apps & Marketplace > Installed Apps** page.
+The upgrade button isn't available for legacy apps on the **Apps > Installed Apps** page.

-If you have a legacy app installed and want to upgrade it:
+If you want to upgrade an installed legacy app, the [legacy feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on. This flag is automatically turned on if you had a legacy app already running before you upgraded Rancher.

- The legacy [feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on (if it's not turned on automatically because of having a legacy app before upgrading)
- You can upgrade the app from cluster explorer, from the left nav section **Legacy > Project > Apps**
- For multi-cluster apps, you can go to **≡ > Multi-cluster Apps** and upgrade the app from there
+- You can upgrade the app from cluster explorer, from the left nav section **Legacy > Project > Apps**.
+- For multi-cluster apps, you can go to **≡ > Multi-cluster Apps** and upgrade the app from there.

-### Limitations
+## Limitations

-Dashboard apps or Rancher feature charts **cannot** be installed using the Rancher CLI.
+Dashboard apps or Rancher feature charts can't be installed using the Rancher CLI.
@@ -10,8 +10,9 @@ By default, some cluster-level API tokens are generated with infinite time-to-li

 You can deactivate API tokens by deleting them or by deactivating the user account.

-### Deleting tokens
-To delete a token,
+## Deleting Tokens
+
+To delete a token:

 1. Go to the list of all tokens in the Rancher API view at `https://<Rancher-Server-IP>/v3/tokens`.

@@ -19,7 +20,7 @@ To delete a token,

 1. Click **Delete**.

-Here is the complete list of tokens that are generated with `ttl=0`:
+The following is a complete list of tokens generated with `ttl=0`:

 | Token             | Description                                                                            |
 | ----------------- | -------------------------------------------------------------------------------------- |
@@ -30,12 +31,12 @@ Here is the complete list of tokens that are generated with `ttl=0`:
 | `helm-token-*`    | Token for Helm chart deployment                                                        |
 | `*-pipeline*`     | Pipeline token for project                                                             |
 | `telemetry-*`     | Telemetry token                                                                        |
-| `drain-node-*`    | Token for drain (we use `kubectl` for drain because there is no native Kubernetes API) |
+| `drain-node-*`    | Token for drain (Rancher uses `kubectl` for drain because there is no native Kubernetes API) |


-### Setting TTL on Kubeconfig Tokens
+## Setting TTL on Kubeconfig Tokens

-Admins can set a global time-to-live (TTL) on Kubeconfig tokens. Changing the default kubeconfig TTL can be done by navigating to global settings and setting [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) to the desired duration in minutes. The default value of [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) is 0, which means tokens never expire.
+Admins can set a global time-to-live (TTL) on Kubeconfig tokens. Changing the default kubeconfig TTL can be done by navigating to global settings and setting [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) to the desired duration in minutes. The default value of [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) is `0`, which means that tokens never expire.

 :::note

@@ -43,49 +44,55 @@ This setting is used by all kubeconfig tokens except those created by the CLI to

 :::

-### Disable Tokens in Generated Kubeconfigs
+## Disable Tokens in Generated Kubeconfigs

-1. Set the `kubeconfig-generate-token` setting to `false`. This setting instructs Rancher to no longer automatically generate a token when a user clicks on download a kubeconfig file. Once this setting is deactivated, a generated kubeconfig will reference the [Rancher CLI](../cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl) to retrieve a short-lived token for the cluster. When this kubeconfig is used in a client, such as `kubectl`, the Rancher CLI needs to be installed to complete the log in request.
+1. Set the `kubeconfig-generate-token` setting to `false`. This setting instructs Rancher to no longer automatically generate a token when a user clicks on download a kubeconfig file. When this setting is deactivated, a generated kubeconfig references the [Rancher CLI](../cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl) to retrieve a short-lived token for the cluster. When this kubeconfig is used in a client, such as `kubectl`, the Rancher CLI needs to be installed to complete the log in request.

 2. Set the `kubeconfig-token-ttl-minutes` setting to the desired duration in minutes. By default, `kubeconfig-token-ttl-minutes` is 960 (16 hours).

-### Token Hashing
+## Token Hashing

-Users can enable token hashing, where tokens will undergo a one-way hash using the SHA256 algorithm. This is a non-reversible process, once enabled, this feature cannot be disabled. It is advisable to take backups prior to enabling and/or evaluating in a test environment first.
+Users can enable token hashing, where tokens undergo a one-way hash using the SHA256 algorithm. This is a non-reversible process: once enabled, this feature cannot be disabled. It is advisable to take backups prior to enabling and/or evaluating in a test environment first.

 To enable token hashing, refer to [this section](../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md).

-This feature will affect all tokens which include, but are not limited to, the following:
+This feature affects all tokens which include, but are not limited to, the following:

 - Kubeconfig tokens
 - Bearer tokens API keys/calls
 - Tokens used by internal operations

-### Token Settings
+## Token Settings
+
 These global settings affect Rancher token behavior.

 | Setting                                                                         | Description                                                                                                                                                                                                                    |
 | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes)               | TTL in minutes on a user auth session token.                                                                                                                                                                                   |
-| [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except those [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). **Introduced in version 2.6.6.**                                                   |
-| [`kubeconfig-token-ttl-minutes`](#kubeconfig-token-ttl-minutes)                 | TTL used for tokens generated via the CLI.  **Deprecated since version 2.6.6, and will be removed in 2.8.0.** This setting will be removed, and `kubeconfig-default-token-TTL-minutes` will be used for all kubeconfig tokens. |
+| [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except those [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). **Introduced in version 2.6.6.**                                                   |
+| [`kubeconfig-token-ttl-minutes`](#kubeconfig-token-ttl-minutes)                 | TTL used for tokens generated via the CLI.  **Deprecated since version 2.6.6, and removed in 2.8.0.** Rancher v2.8 and later instead use `kubeconfig-default-token-ttl-minutes` for all kubeconfig tokens. |
 | [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes)                     | Max TTL for all tokens except those controlled by [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes).                                                                                                           |
 | [`kubeconfig-generate-token`](#kubeconfig-generate-token)                       | If true, automatically generate tokens when a user downloads a kubeconfig.                                                                                                                                                     |

-#### auth-user-session-ttl-minutes
-Time to live (TTL) duration in minutes used to determine when a user auth session token expires. When expired, the user will be required to log in and obtain a new token. This setting is not affected by [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). Session tokens are created when a user logs into Rancher.
+### auth-user-session-ttl-minutes

-#### kubeconfig-default-token-TTL-minutes
-Time to live (TTL) duration in minutes used to determine when a kubeconfig token expires. When the token is expired, the API will reject the token. This setting can not be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). This setting applies to a token generated in a requested kubeconfig file. Except those [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs).
+Time to live (TTL) duration in minutes, used to determine when a user auth session token expires. When expired, the user must log in and obtain a new token. This setting is not affected by [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). Session tokens are created when a user logs into Rancher.
+
+### kubeconfig-default-token-ttl-minutes
+
+Time to live (TTL) duration in minutes, used to determine when a kubeconfig token expires. When the token is expired, the API rejects the token. This setting can't be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). This setting applies to tokens generated in a requested kubeconfig file, except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). The default value is `0`, which means that tokens never expire.
 **Introduced in version 2.6.6**.

-#### kubeconfig-token-ttl-minutes
-Time to live (TTL) duration in minutes used to determine when a kubeconfig token that was generated by the CLI expires. Tokens are generated by the CLI when [`kubeconfig-generate-token`](#kubeconfig-generate-token) is false. When the token is expired, the API will reject the token. This setting can not be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes).
-**Deprecated since version 2.6.6, and will be removed in 2.8.0: This setting will be replaced with the value of [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes).**
+### kubeconfig-token-ttl-minutes

-#### auth-token-max-ttl-minutes
-Maximum Time to Live (TTL) in minutes allowed for auth tokens. If a user attempts to create a token with a TTL greater than `auth-token-max-ttl-minutes`, Rancher will set the token TTL to the value of `auth-token-max-ttl-minutes`. Auth tokens are tokens created for authenticating API requests.
-**Changed in version 2.6.6: Applies to all kubeconfig tokens and api tokens.**
+Time to live (TTL) duration in minutes, used to determine when a kubeconfig token that was generated by the CLI expires. Tokens are generated by the CLI when [`kubeconfig-generate-token`](#kubeconfig-generate-token) is false. When the token is expired, the API rejects the token. This setting can't be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes).
+**Deprecated since Rancher v2.6.6.**

-#### kubeconfig-generate-token
-When true, kubeconfigs requested through the UI will contain a valid token. When false, the kubeconfig will contain a command that uses the Rancher CLI to prompt the user to log in. [The CLI then will retrieve and cache a token for the user](../cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl).
+### auth-token-max-ttl-minutes
+
+Maximum Time to Live (TTL) in minutes allowed for auth tokens. If a user attempts to create a token with a TTL greater than `auth-token-max-ttl-minutes`, Rancher sets the token TTL to the value of `auth-token-max-ttl-minutes`. Auth tokens are tokens created for authenticating API requests. The default value is `0`, which means that tokens never expire.
+**Rancher v2.6.6 and later: Applies to all kubeconfig tokens and api tokens.**
+
+### kubeconfig-generate-token
+
+When true, kubeconfigs requested through the UI contain a valid token. When false, the kubeconfig contains a command that uses the Rancher CLI to prompt the user to log in. [The CLI then retrieves and caches a token for the user](../cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl).
@@ -160,7 +160,8 @@ helm repo update
 # Install the cert-manager Helm chart
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
-  --create-namespace
+  --create-namespace \
+  --set installCRDs=true
 ```

 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -78,7 +78,7 @@ A restore is performed by creating a Restore custom resource.
 1. In the left navigation bar, click **Rancher Backups > Restore**.
    :::note

-    If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps**. Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#charts) for more information.
+    If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps**. Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#access-charts) for more information.

    :::

@@ -6,7 +6,9 @@ title: Troubleshooting Certificates
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting"/>
 </head>

-### How Do I Know if My Certificates are in PEM Format?
+<DockerSupportWarning />
+
+## How Do I Know if My Certificates are in PEM Format?

 You can recognize the PEM format by the following traits:

@@ -48,7 +50,7 @@ VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
 -----END PRIVATE KEY-----
 ```

-### Converting a Certificate Key From PKCS8 to PKCS1
+## Converting a Certificate Key From PKCS8 to PKCS1

 If you are using a PKCS8 certificate key file, Rancher will log the following line:

@@ -64,7 +66,7 @@ openssl rsa -in key.pem -out convertedkey.pem

 You can now use `convertedkey.pem` as certificate key file for Rancher.

-### What is the Order of Certificates if I Want to Add My Intermediate(s)?
+## What is the Order of Certificates if I Want to Add My Intermediate(s)?

 The order of adding certificates is as follows:

@@ -77,7 +79,7 @@ The order of adding certificates is as follows:
 -----END CERTIFICATE-----
 ```

-### How Do I Validate My Certificate Chain?
+## How Do I Validate My Certificate Chain?

 You can validate the certificate chain by using the `openssl` binary. If the output of the command (see the command example below) ends with `Verify return code: 0 (ok)`, your certificate chain is valid. The `ca.pem` file must be the same as you added to the `rancher/rancher` container.

@@ -3,16 +3,12 @@ title: Installing Rancher on a Single Node Using Docker
 description: For development and testing environments only, use a Docker install. Install Docker on a single Linux host, and deploy Rancher with a single Docker container.
 ---

-:::caution
-
-Docker installs are not supported in production environments. These instructions are provided for testing and development purposes only. Please don't use this method to install Rancher in production environments.
-
-:::
-
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker"/>
 </head>

+<DockerSupportWarning />
+
 Rancher can be installed by running a single Docker container.

 In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container.
@@ -6,6 +6,8 @@ title: Rolling Back Rancher Installed with Docker
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher"/>
 </head>

+<DockerSupportWarning />
+
 If a Rancher upgrade does not complete successfully, you'll have to roll back to your Rancher setup that you were using before [Docker Upgrade](upgrade-docker-installed-rancher.md). Rolling back restores:

 - Your previous version of Rancher.
@@ -8,11 +8,7 @@ title: Upgrading Rancher Installed with Docker

 The following instructions will guide you through upgrading a Rancher server that was installed with Docker.

-:::caution
-
-**Docker installs are not supported in production environments.** These instructions are provided for testing and development purposes only. If you have already deployed a Docker install in production and need to upgrade to a new Rancher version, we recommend [migrating to the Helm chart install](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) before upgrading.
-
-:::
+<DockerSupportWarning />

 ## Prerequisites

@@ -52,8 +52,6 @@ When you need to make changes to your infrastructure, instead of manually updati

 - You can reverse engineer how to do define a setting in Terraform by changing the setting in Rancher, then going back and checking your Terraform state file to see how it maps to the current state of your infrastructure.

- If you want to manage Kubernetes cluster settings, Rancher settings, and hardware settings all in one place, use [Terraform modules](https://github.com/rancher/terraform-modules). You can pass a cluster configuration YAML file or an RKE template configuration file to a Terraform module so that the Terraform module will create it. In that case, you could use your infrastructure-as-code to manage the version control and revision history of both your Kubernetes cluster and its underlying hardware.
-
 ## Tip for Creating CIS Benchmark Compliant Clusters

 This section describes one way that you can make security and compliance-related config files standard in your clusters.
@@ -1,20 +1,48 @@
 ---
-title: Helm Charts in Rancher
+title: Helm Charts and Apps
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher"/>
 </head>

-In this section, you'll learn how to manage Helm chart repositories and applications in Rancher. Helm chart repositories are managed using **Apps**. It uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Helm applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.
+In this section, you'll learn how to manage Helm chart repositories and apps in Rancher. 
+
+## How Helm Charts Work in Rancher
+
+Helm chart repositories in Rancher are managed using **Apps**.
+
+Rancher uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Kubernetes applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.
+
+### Catalogs, Apps, and the Rancher UI
+
+[Rancher v2.4 and earlier](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI. 
+
+Rancher v2.5 replaced the former catalog system with a new **Apps & Marketplace** feature. 
+
+Since Rancher v2.6.5, the **Apps & Marketplace** feature is named **Apps** in the UI.

 ### Versioning Scheme

 The Rancher feature charts versioning scheme is centered around the major version of the charts and the `+up` annotation for upstream charts, where applicable.

-**Major Version:** The major version of the charts is tied to Rancher minor versions. When you upgrade to a new Rancher minor version, you should ensure that all of your **Apps** charts are also upgraded to the correct release line for the chart.
+**Major Version:** The major versions of feature charts are tied to particular minor versions of Rancher. When you upgrade to a new Rancher minor version, you should ensure that all of your feature charts are also upgraded to the correct release line for the chart.

-**Feature Charts:**
+**Charts based on upstream:** When you upgrade, make sure that the upstream chart version is compatible with your Rancher version. The `+up` annotation for the chart indicates which upstream version the Rancher chart is tracking. For example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some additional Rancher patches.
+
+When upgrading Rancher versions, don't downgrade the version of the chart that you are using. For example, if you are using a version of Monitoring that is later than `16.6.0` in Rancher v2.5, you shouldn't upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.
+
+#### Prerelease Versions
+
+Prereleases adhere to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` is considered a prerelease. Prerelease versions are not displayed by default and must be configured to do so.
+
+To display prerelease versions:
+
+1. Click on your user avatar in the upper right corner.
+1. Click **Preferences**.
+1. Under **Helm Charts**, select **Include Prerelease Versions**.
+
+### Feature Charts

 | **Name** | **Supported Minimum Version** | **Supported Maximum Version** |
 | ---------------- | ------------ | ------------ |
@@ -35,73 +63,82 @@ The Rancher feature charts versioning scheme is centered around the major versio
 | rancher-vsphere-csi | 100.3.0+up2.5.1-rancher1 | 100.3.0+up2.5.1-rancher1 |
 | rancher-wins-upgrader | 0.0.100 | 100.0.1+up0.0.1 |

-<br/>
-**Charts based on upstream:** For charts that are based on upstreams, the +up annotation should inform you of what upstream version the Rancher chart is tracking. Check the upstream version compatibility with Rancher during upgrades also.
+## Access Charts

- As an example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some Rancher patches added to it.
+The **Charts** page contains all Rancher, Partner, and Custom charts. You can filter charts by selecting the left-most dropdown menu:

- On upgrades, ensure that you are not downgrading the version of the chart that you are using. For example, if you are using a version of Monitoring > `16.6.0` in Rancher 2.5, you should not upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.
+* Rancher tools such as Logging or Monitoring are listed under the **Rancher** label.
+* Partner charts are under the **Partners** label.
+* Custom charts are listed under the name of their respective repository.

-### Prerelease Versions
-
-Prereleases adhere to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` is considered a prerelease. Prerelease versions are not displayed by default and must be configured to do so.
-
-To display prerelease versions:
-
-1. Click on your user avatar in the upper right corner.
-1. Click **Preferences**.
-1. Under **Helm Charts**, select **Include Prerelease Versions**.
-
-### Charts
-
-From the top-left menu select _"Apps"_ and you will be taken to the Charts page.
-
-The charts page contains all Rancher, Partner, and Custom Charts.
-
-* Rancher tools such as Logging or Monitoring are included under the Rancher label
-* Partner charts reside under the Partners label
-* Custom charts will show up under the name of the repository
-
-All three types are deployed and managed in the same way.
+All three types of charts are deployed and managed in the same way.

 :::note

-Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) should continue to be managed only by the Cluster Manager, and apps managed with <b>Apps</b> in the new UI must be managed only by <b>Apps</b>.
+Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) continue to be managed only by the Cluster Manager, and apps managed with **Apps** in the new UI must be managed only by **Apps**.

 :::

-### Repositories
+To access the **Charts** page:

-From the left sidebar select _"Repositories"_.
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose charts you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.

-These items represent Helm repositories, and can be either traditional Helm endpoints which have an index.yaml, or Git repositories which will be cloned and can point to a specific branch. In order to use custom charts, simply add your repository here and they will become available in the Charts tab under the name of the repository.
+## Manage Repositories

-#### Add Custom Git Repositories
+The **Repositories** page lists your Helm repositories. These include traditional Helm endpoints which have an index.yaml, and Git repositories that are cloned and point to a specific branch. To use custom charts, add your repository here. After you add a repository, you can access custom charts in the **Charts** page, listed under the name of the repository.

-Click **Create** and select the target, **Git repository containing Helm chart...** to add a custom Git repository that contains your Helm charts or cluster template definitions.
+To access the **Repositories** page:

-You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from the default, `main`.
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.

-Whenever you add a chart repository to Rancher, it becomes available immediately.
+### Add Custom Git Repositories

-#### Add Custom Helm Chart Repositories
+To add a custom Git repository that contains your Helm charts or cluster template definitions:
+
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
+1. Click **Create**.
+1. Select the target, **Git repository containing Helm chart...**.
+1. You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from whichever branch the repo owner has set as the default. Usually, the default branch is named either `main` or `master`.
+1. Click **Create** to add the repository. 
+
+After you add a chart repository to Rancher, it becomes available immediately.
+
+### Add Custom Helm Chart Repositories

 You can add your own Helm chart repositories to serve chart packages to Rancher. You can use any HTTP server, as long as the server can respond to GET requests and serve YAML files and tar archives.

 For more information on Helm chart repositories, see the [official Helm docs](https://helm.sh/docs/topics/chart_repository/).

-To add a custom Helm chart repository to Rancher, click **Create** and select **http(s) URL to an index generated by Helm** as the target. Enter a repo name and the index URL address of the chart repository.
+To add a custom Helm chart repository to Rancher:

-#### Add Private Git/Helm Chart Repositories
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
+1. Click **Create**.
+1. Select the target, **http(s) URL to an index generated by Helm**.
+1. Enter a repo name and the index URL address of the chart repository.
+1. Click **Create** to add the repository. 
+
+### Add Private Git/Helm Chart Repositories

 You can add private Git or Helm chart repositories with SSH key credentials or an HTTP basic auth secret, such as a username and password.

-#### Add a Private CA to Repositories
+### Add a Private CA to Repositories

-To add a private CA to Helm chart repositories:
+To add a private CA to Helm chart repositories, you must add a base64 encoded copy of the CA certificate in DER format to the `spec.caBundle field` of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Instructions are the same for both Git-based and HTTP-based repositories:

- **HTTP-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
-    ```
+1. Click **☰**. Under **Explore Cluster** in the left navigation menu, select a cluster.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
+1. Find the row associated with the Git or HTTP-based repository you want to add a private CA to, and click **⋮ > Edit YAML**.
+1. Set the `caBundle` value, as in the following example:
+
+  ```yaml
    [...]
    spec:
      caBundle:
@@ -109,25 +146,13 @@ To add a private CA to Helm chart repositories:
    ...
    nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
    [...]
-    ```
-
-
- **Git-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
-    ```
-    [...]
-    spec:
-      caBundle:
-    MIIFXzCCA0egAwIBAgIUWNy8WrvSkgNzV0zdWRP79j9cVcEwDQYJKoZIhvcNAQELBQAwPzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYDVQQKDAtNeU9yZywgSW5jLjENMAsGA1UEAwwEcm9vdDAeFw0yMTEyMTQwODMyMTdaFw0yNDEwMDMwODMyMT
-    ...
-    nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
-    [...]
-    ```
+  ```

 :::note Helm chart repositories with authentication

-The Repo.Spec contains a `disableSameOriginCheck` value that allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
+The Repo.Spec contains a `disableSameOriginCheck` value. This value allows you to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories, such as those that have redirects to a different origin URL.

-To use this feature for an existing Helm chart repository, click <b>⋮ > Edit YAML</b>. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
+To use this feature for an existing Helm chart repository, follow previous steps up to edit the YAML. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.

 ```yaml
 [...]
@@ -142,37 +167,51 @@ spec:

 Only Helm 3 compatible charts are supported.

+## Deploy and Upgrade Charts

-### Deployment and Upgrades
+To install and deploy a chart:

-From the _"Charts"_ tab select a Chart to install. Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files, but all chart installations can modify the values.yaml and other basic settings. Once you click install, a Helm operation job is deployed, and the console for the job is displayed.
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose charts you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
+1. Select a chart, and click **Install**. 

-To view all recent changes, go to the _"Recent Operations"_ tab. From there you can view the call that was made, conditions, events, and logs.
+Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files. However, all chart installations can modify the values.yaml and other basic settings. After you click **Install**, a Helm operation job is deployed, and the console for the job is displayed.

-After installing a chart, you can find it in the _"Installed Apps"_ tab. In this section you can upgrade or delete the installation, and see further details. When choosing to upgrade, the form and values presented will be the same as installation.
+To view all recent changes, click **Apps > Recent Operations** in the left navigation menu. From there you can view the calls, conditions, events, and logs.

-Most Rancher tools have additional pages located in the toolbar below the _"Apps"_ section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.
+After installing a chart, you can view it by clicking **Apps > Installed Apps** in the left navigation menu. You can upgrade or delete the installation, and see further details. Upgrading uses the same forms and values as you saw during inital installation. 
+
+Most Rancher tools have additional pages located in the toolbar below the **Apps** section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.

 :::caution

-If you are upgrading your chart using _"Customize Helm options before upgrade"_ , please be aware that using the _"--force"_ option may result in errors if your chart has immutable fields. This is because some objects in Kubernetes cannot be changed once they are created. To ensure you do not get this error you can:
+If you are upgrading your chart using **Customize Helm options before upgrade**, and your chart contains immutable fields, using the `--force` option may result in errors. This is because some objects in Kubernetes can't be changed after they're created. To prevent this error:

-  * use the default upgrade option ( i.e do not use _"--force"_ option )
-  * uninstall the existing chart and install the upgraded chart
-  * delete the resources with immutable fields from the cluster before performing the _"--force"_ upgrade
+  * Use the default upgrade option (i.e don't use `--force`).
+  * Uninstall the existing chart and install the upgraded chart.
+  * Delete the resources with immutable fields from the cluster before performing a forced upgrade.

 :::

-#### Legacy Apps
+### Legacy Apps

-The upgrade button has been removed for legacy apps from the **Apps > Installed Apps** page.
+The upgrade button isn't available for legacy apps on the **Apps > Installed Apps** page.

-If you have a legacy app installed and want to upgrade it:
+If you want to upgrade an installed legacy app, the [legacy feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on. This flag is automatically turned on if you had a legacy app already running before you upgraded Rancher.

- The legacy [feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on (if it's not turned on automatically because of having a legacy app before upgrading)
- You can upgrade the app from cluster explorer, from the left nav section **Legacy > Project > Apps**
- For multi-cluster apps, you can go to **≡ > Multi-cluster Apps** and upgrade the app from there
+1. Enable the [legacy feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md), if it isn't enabled already.
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose apps you want to access. Click **Explore** at the end of the cluster's row.
+1. Click **Legacy > Project > Apps**.

-### Limitations
+If you don't see **Apps** listed under **Legacy > Project**, click the project/namespace search bar in the top navigation and select the relevant project from the dropdown menu.

-Dashboard apps or Rancher feature charts **cannot** be installed using the Rancher CLI.
+To upgrade legacy multi-cluster apps:
+
+1. Click **☰**. 
+1. Under **Legacy Apps**, click **Multi-cluster Apps**.
+
+## Limitations
+
+Dashboard apps or Rancher feature charts can't be installed using the Rancher CLI.
@@ -7,12 +7,12 @@ title: Migrating Amazon In-tree to Out-of-tree
 </head>

 :::note
-Rancher Prime provides access to Rancher v2.7.11, a version of Rancher v2.7.x which supports Kubernetes 1.27. If you use Rancher v2.7.11 and upgrade to Kubernetes 1.27, you must use an out-of-tree cloud provider.
+Rancher Prime provides access to Rancher v2.7.11, a version of Rancher v2.7.x which supports Kubernetes v1.27. If you use Rancher v2.7.11 and upgrade to Kubernetes 1.27, you must use an out-of-tree cloud provider.
 :::

-Kubernetes is moving away from maintaining cloud providers in-tree. In Kubernetes 1.27 and later, the in-tree cloud providers have been removed. 
+Kubernetes is moving away from maintaining cloud providers in-tree. In Kubernetes 1.27 and later, the in-tree cloud providers have been removed. The Rancher UI allows you to upgrade to Kubernetes v1.27 when you migrate from an in-tree to out-of-tree provider. 

-You can migrate from an in-tree to an out-of-tree AWS cloud provider on Kubernetes 1.26 and earlier. All existing clusters must migrate prior to upgrading to v1.27 in order to stay functional.
+However, if you're performing a manual migration, existing clusters must upgrade to Kubernetes v1.27 after you migrate in order to remain functional.

 To migrate from the in-tree cloud provider to the out-of-tree AWS cloud provider, you must stop the existing cluster's kube controller manager and install the AWS cloud controller manager. There are many ways to do this. Refer to the official AWS documentation on the [external cloud controller manager](https://cloud-provider-aws.sigs.k8s.io/getting_started/) for details.

@@ -56,7 +56,7 @@ spec:
 2. Cordon control plane nodes so that AWS cloud controller pods run on nodes only after upgrading to the external cloud provider:

 ```shell
-kubectl cordon -l "node-role.kubernetes.io/controlplane=true"
+kubectl cordon -l "node-role.kubernetes.io/control-plane=true"
 ```

 3. To install the AWS cloud controller manager with leader migration enabled, follow Steps 1-3 for [deploying the cloud controller manager chart](../set-up-cloud-providers/amazon.md#using-the-out-of-tree-aws-cloud-provider). From Kubernetes 1.22 onwards, the kube-controller-manager will utilize a default configuration which will satisfy the controller-to-manager migration. Update container args of the `aws-cloud-controller-manager` under `spec.rkeConfig.additionalManifest` to enable leader migration:
@@ -352,9 +352,9 @@ tolerations:
    value: 'true'
  - effect: NoSchedule
    value: 'true'
-    key: node-role.kubernetes.io/controlplane
+    key: node-role.kubernetes.io/control-plane
 nodeSelector:
-  node-role.kubernetes.io/controlplane: 'true'
+  node-role.kubernetes.io/control-plane: 'true'
 args:
  - --configure-cloud-routes=false
  - --use-service-account-credentials=true
@@ -639,7 +639,7 @@ kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
      - get
 ```

-9. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector:
+9. Rancher-provisioned RKE2 nodes are tainted `node-role.kubernetes.io/control-plane`. Update tolerations and the nodeSelector:

 ```yaml
 tolerations:
@@ -648,13 +648,13 @@ tolerations:
    value: 'true'
  - effect: NoSchedule
    value: 'true'
-    key: node-role.kubernetes.io/controlplane
+    key: node-role.kubernetes.io/control-plane

 ```

 ```yaml
 nodeSelector:
-  node-role.kubernetes.io/controlplane: 'true'
+  node-role.kubernetes.io/control-plane: 'true'
 ```

 :::note
@@ -663,7 +663,7 @@ There's currently a [known issue](https://github.com/rancher/dashboard/issues/92

 ```yaml
 nodeSelector:
-  node-role.kubernetes.io/controlplane: 'true'
+  node-role.kubernetes.io/control-plane: 'true'
 ```

 :::
@@ -18,7 +18,7 @@ In clusters that store data on GlusterFS volumes, you may experience an issue wh
 - The `systemd-run` binary needs to be compatible with Debian OS on which the hyperkube image is based (this can be checked using the following command on each cluster node, replacing the image tag with the Kubernetes version you want to use)

 ```
-docker run -v /usr/bin/systemd-run:/usr/bin/systemd-run --entrypoint /usr/bin/systemd-run rancher/hyperkube:v1.16.2-rancher1 --version
+docker run -v /usr/bin/systemd-run:/usr/bin/systemd-run -v /usr/lib/x86_64-linux-gnu/libcrypto.so.3:/usr/lib/x86_64-linux-gnu/libcrypto.so.3 -v /lib/systemd/libsystemd-shared-249.so:/lib/systemd/libsystemd-shared-249.so --entrypoint /usr/bin/systemd-run rancher/hyperkube:v1.26.14-rancher1 --version
 ```

 :::caution
@@ -32,6 +32,8 @@ services:
  kubelet:
    extra_binds:
      - "/usr/bin/systemd-run:/usr/bin/systemd-run"
+      - "/usr/lib/x86_64-linux-gnu/libcrypto.so.3:/usr/lib/x86_64-linux-gnu/libcrypto.so.3"
+      - "/lib/systemd/libsystemd-shared-249.so:/lib/systemd/libsystemd-shared-249.so"
 ```

 After the cluster has finished provisioning, you can check the `kubelet` container logging to see if the functionality is activated by looking for the following logline:
@@ -2,10 +2,6 @@
 title: AWS Marketplace Pay-as-you-go (PAYG) Integration
 ---

-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace/aws-marketplace-payg-integration/aws-marketplace-payg-integration"/>
-</head>
-
 ## Overview

 Rancher Prime integrates with the [AWS Marketplace](https://aws.amazon.com/marketplace) as a pay-as-you-go (PAYG) offering. This brings the value of running and managing Kubernetes environments to AWS customers, benefiting from a new pay-monthly pricing model available through the AWS Marketplace. This listing will enable you to manage any CNCF-certified Kubernetes distribution in AWS, on-prem, or at the edge. To learn more, see our non-EMEA and EMEA AWS Marketplace offerings for Rancher Prime:
@@ -13,6 +9,10 @@ Rancher Prime integrates with the [AWS Marketplace](https://aws.amazon.com/marke
 - [Rancher Prime](https://aws.amazon.com/marketplace/pp/prodview-f2bvszurj2p2c)
 - [Rancher Prime (EMEA Orders Only)](https://aws.amazon.com/marketplace/pp/prodview-ocgjwd5c2aj5i)

+## FAQ
+
+For more details on how Rancher pay-as-you-go offerings work, refer to the [pay-as-you-go FAQ](../cloud-marketplace-payg-integration.md#faq).
+
 ## Limitations

 - Currently, you must be running Rancher v2.7.9. When you deploy a supported PAYG version, you can update to newer versions of Rancher when the listing is updated.
@@ -21,489 +21,3 @@ Rancher Prime integrates with the [AWS Marketplace](https://aws.amazon.com/marke

 1. Complete the [prerequisite steps](prerequisites.md).
 2. [Install the Rancher Prime PAYG offering on the AWS Marketplace](installing-rancher-prime.md).
-
-## FAQ
-
-The following is a list of frequently asked questions.
-
-### Marketplace Listing
-
-#### What is the Rancher Prime listing on the AWS Marketplace?
-
-By selecting the Rancher Prime listing from the AWS Marketplace, customers can deploy Rancher to their Kubernetes environment with the advantage of having monthly billing via AWS.
-
-#### Where do I find the Rancher Prime listings?
-
-There are two listings in the AWS Marketplace. They are:
-
- [Rancher Prime](https://aws.amazon.com/marketplace/pp/prodview-f2bvszurj2p2c)
- [Rancher Prime (EMEA Orders Only)](https://aws.amazon.com/marketplace/pp/prodview-ocgjwd5c2aj5i)
-
-#### Why are there two listings? Which one should I use?
-
-We have two listings for Rancher Prime, "EU, EEA, or UK Orders" and "non EU, EEA, or UK Orders." You should pick the listing that reflects where your AWS account gets billed.
-
-#### Are these listings available in all countries?
-
-No. The Rancher listing on AWS is not available to purchase in all countries.
-
-Your billing country is based on the AWS Account ID used to do the deployment.
-
-Please refer to the following lists of countries that can and cannot transact Rancher Prime via the AWS Marketplace.
-
-<details>
-  <summary>Countries that can transact SUSE Rancher Support through the AWS Marketplace</summary>
-    <div>
-      <li>Australia, AU</li>
-      <li>Austria, AT</li>
-      <li>Bangladesh, BD</li>
-      <li>Belgium, BE</li>
-      <li>Bulgaria, BG</li>
-      <li>Cameroon, CM</li>
-      <li>Canada, CA</li>
-      <li>Chile, CL</li>
-      <li>Croatia, HR</li>
-      <li>Cyprus, CY</li>
-      <li>Czech Republic, CZ</li>
-      <li>Denmark, DK</li>
-      <li>Egypt, EG</li>
-      <li>Estonia, EE</li>
-      <li>Finland, FI</li>
-      <li>France, FR</li>
-      <li>Germany, DE</li>
-      <li>Greece, GR</li>
-      <li>Hungary, HU</li>
-      <li>Iceland, IS</li>
-      <li>India, IN</li>
-      <li>Indonesia, ID</li>
-      <li>Ireland, IE</li>
-      <li>Isle of Man, IM</li>
-      <li>Italy, IT</li>
-      <li>Kenya, KE</li>
-      <li>Kingdom of Saudi Arabia, SA</li>
-      <li>Korea, Republic of, KR</li>
-      <li>Latvia, LV</li>
-      <li>Lithuania, LT</li>
-      <li>Liechtenstein, LI</li>
-      <li>Luxembourg, LU</li>
-      <li>Malaysia, MY</li>
-      <li>Malta, MT</li>
-      <li>Netherlands, NL</li>
-      <li>New Zealand, NZ</li>
-      <li>Norway, NO</li>
-      <li>Poland, PL</li>
-      <li>Portugal, PT</li>
-      <li>Romania, RO</li>
-      <li>Russian Federation, RU</li>
-      <li>Singapore, SG</li>
-      <li>Slovakia, SK</li>
-      <li>Slovenia, SI</li>
-      <li>South Africa, ZA</li>
-      <li>Spain, ES</li>
-      <li>Sweden, SE</li>
-      <li>Switzerland, CH</li>
-      <li>Taiwan, Province of China, TW</li>
-      <li>Turkey, TR</li>
-      <li>United Kingdom, GB</li>
-      <li>United States, US</li>
-  </div>
-</details>
-
-<details>
-  <summary>Countries that cannot transact SUSE Rancher Support via the AWS Marketplace</summary>
-    <div>
-      <li>Afghanistan, AF</li>
-      <li>Åland Islands, AX</li>
-      <li>Albania, AL</li>
-      <li>Algeria, DZ</li>
-      <li>American Samoa, AS</li>
-      <li>Andorra, AD</li>
-      <li>Angola, AO</li>
-      <li>Anguilla, AI</li>
-      <li>Antarctica, AQ</li>
-      <li>Antigua and Barbuda, AG</li>
-      <li>Argentina, AR</li>
-      <li>Armenia, AM</li>
-      <li>Aruba, AW</li>
-      <li>Azerbaijan, AZ</li>
-      <li>Bahamas, BS</li>
-      <li>Bahrain, BH</li>
-      <li>Barbados, BB</li>
-      <li>Belarus, BY</li>
-      <li>Belize, BZ</li>
-      <li>Benin, BJ</li>
-      <li>Bermuda, BM</li>
-      <li>Bhutan, BT</li>
-      <li>Bonaire, BQ</li>
-      <li>Bolivarian Republic of Venezuela, VE</li>
-      <li>Bosnia and Herzegovina, BA</li>
-      <li>Botswana, BW</li>
-      <li>Bouvet Island, BV</li>
-      <li>Brazil, BR</li>
-      <li>British Indian Ocean Territory, IO</li>
-      <li>Brunei Darussalam, BN</li>
-      <li>Burkina Faso, BF</li>
-      <li>Burundi, BI</li>
-      <li>Cambodia, KH</li>
-      <li>Cape Verde, CV</li>
-      <li>Cayman Islands, KY</li>
-      <li>Central African Republic, CF</li>
-      <li>Chad, TD</li>
-      <li>China, CN</li>
-      <li>Christmas Island, CX</li>
-      <li>Cocos (Keeling) Islands, CC</li>
-      <li>Colombia, CO</li>
-      <li>Comoros, KM</li>
-      <li>Congo, CG</li>
-      <li>Cook Islands, CK</li>
-      <li>Costa Rica, CR</li>
-      <li>Côte d'Ivoire, CI</li>
-      <li>Curaçao, CW</li>
-      <li>Democratic Republic of the Congo, CD</li>
-      <li>Djibouti, DJ</li>
-      <li>Dominica, DM</li>
-      <li>Dominican Republic, DO</li>
-      <li>Ecuador, EC</li>
-      <li>El Salvador, SV</li>
-      <li>Equatorial Guinea, GQ</li>
-      <li>Eritrea, ER</li>
-      <li>Ethiopia, ET</li>
-      <li>Falkland Islands (Malvinas), FK</li>
-      <li>Faroe Islands, FO</li>
-      <li>Federated States of Micronesia, FM</li>
-      <li>Fiji, FJ</li>
-      <li>Former Yugoslav Republic of Macedonia, MK</li>
-      <li>French Guiana, GF</li>
-      <li>French Polynesia, PF</li>
-      <li>French Southern Territories, TF</li>
-      <li>Gabon, GA</li>
-      <li>Gambia, GM</li>
-      <li>Georgia, GE</li>
-      <li>Ghana, GH</li>
-      <li>Gibraltar, GI</li>
-      <li>Greenland, GL</li>
-      <li>Grenada, GD</li>
-      <li>Guadeloupe, GP</li>
-      <li>Guam, GU</li>
-      <li>Guatemala, GT</li>
-      <li>Guernsey, GG</li>
-      <li>Guinea, GN</li>
-      <li>Guinea-Bissau, GW</li>
-      <li>Guyana, GY</li>
-      <li>Haiti, HT</li>
-      <li>Heard Island and McDonald Islands, HM</li>
-      <li>Holy See (Vatican  City State), VA</li>
-      <li>Honduras, HN</li>
-      <li>Hong Kong, HK</li>
-      <li>Iraq, IQ</li>
-      <li>Israel, IL</li>
-      <li>Jamaica, JM</li>
-      <li>Japan, JP</li>
-      <li>Jersey, JE</li>
-      <li>Jordan, JO</li>
-      <li>Kazakhstan, KZ</li>
-      <li>Kiribati, KI</li>
-      <li>Kuwait, KW</li>
-      <li>Kyrgyzstan, KG</li>
-      <li>Lao People's Democratic Republic, LA</li>
-      <li>Lebanon, LB</li>
-      <li>Lesotho, LS</li>
-      <li>Liberia, LR</li>
-      <li>Libyan Arab Jamahiriya, LY</li>
-      <li>Macao, MO</li>
-      <li>Madagascar, MG</li>
-      <li>Malawi, MW</li>
-      <li>Maldives, MV</li>
-      <li>Mali, ML</li>
-      <li>Marshall Islands, MH</li>
-      <li>Martinique, MQ</li>
-      <li>Mauritania, MR</li>
-      <li>Mauritius, MU</li>
-      <li>Mayotte, YT</li>
-      <li>Mexico, MX</li>
-      <li>Mongolia, MN</li>
-      <li>Montenegro, ME</li>
-      <li>Montserrat, MS</li>
-      <li>Morocco, MA</li>
-      <li>Mozambique, MZ</li>
-      <li>Myanmar, MM</li>
-      <li>Namibia, NA</li>
-      <li>Nauru, NR</li>
-      <li>Nepal, NP</li>
-      <li>New Caledonia, NC</li>
-      <li>Nicaragua, NI</li>
-      <li>Niger, NE</li>
-      <li>Nigeria, NG</li>
-      <li>Niue, NU</li>
-      <li>Norfolk Island, NF</li>
-      <li>Northern Mariana Islands, MP</li>
-      <li>Oman, OM</li>
-      <li>Pakistan, PK</li>
-      <li>Palau, PW</li>
-      <li>Occupied Palestinian Territory, PS</li>
-      <li>Panama, PA</li>
-      <li>Papua New Guinea, PG</li>
-      <li>Paraguay, PY</li>
-      <li>Peru, PE</li>
-      <li>Philippines, PH</li>
-      <li>Pitcairn, PN</li>
-      <li>Plurinational State of Bolivia, BO</li>
-      <li>Puerto Rico, PR</li>
-      <li>Qatar, QA</li>
-      <li>Republic of Moldova, MD</li>
-      <li>Réunion, RE</li>
-      <li>Rwanda, RW</li>
-      <li>Saint Barthélemy, BL</li>
-      <li>Saint Helena, Ascension and Tristan da Cunha, SH</li>
-      <li>Saint Kitts and Nevis, KN</li>
-      <li>Saint Lucia, LC</li>
-      <li>Saint Martin, MF</li>
-      <li>Saint Pierre and Miquelon, PM</li>
-      <li>Saint Vincent and the Grenadines, VC</li>
-      <li>Samoa, WS</li>
-      <li>San Marino, SM</li>
-      <li>Sao Tome and Principe, ST</li>
-      <li>Senegal, SN</li>
-      <li>Serbia, RS</li>
-      <li>Seychelles, SC</li>
-      <li>Sierra Leone, SL</li>
-      <li>Sint Maarten, SX</li>
-      <li>Solomon Islands, SB</li>
-      <li>Somalia, SO</li>
-      <li>South Georgia and the South Sandwich Islands, GS</li>
-      <li>South Sudan, SS</li>
-      <li>Sri Lanka, LK</li>
-      <li>Suriname, SR</li>
-      <li>Svalbard and Jan Mayen, SJ</li>
-      <li>Swaziland, SZ</li>
-      <li>Tajikistan, TJ</li>
-      <li>Thailand, TH</li>
-      <li>Timor-Leste, TL</li>
-      <li>Togo, TG</li>
-      <li>Tokelau, TK</li>
-      <li>Tonga, TO</li>
-      <li>Trinidad and Tobago, TT</li>
-      <li>Tunisia, TN</li>
-      <li>Turkmenistan, TM</li>
-      <li>Turks and Caicos Islands, TC</li>
-      <li>Tuvalu, TV</li>
-      <li>Uganda, UG</li>
-      <li>Ukraine, UA</li>
-      <li>United Arab Emirates, AE</li>
-      <li>United Republic of Tanzania, TZ</li>
-      <li>United States Minor Outlying Islands, UM</li>
-      <li>Uruguay, UY</li>
-      <li>Uzbekistan, UZ</li>
-      <li>Vanuatu, VU</li>
-      <li>Viet Nam, VN</li>
-      <li>Virgin Islands, British, VG</li>
-      <li>Virgin Islands, U.S., VI</li>
-      <li>Wallis and Futuna, WF</li>
-      <li>Western Sahara, EH</li>
-      <li>Yemen, YE</li>
-      <li>Zambia, ZM</li>
-      <li>Zimbabwe, ZW</li>
-    </div>
-</details>
-
-#### My AWS account is in the USA, but I want to deploy Rancher in another AWS region, a region that is in a country where I currently cannot transact Rancher Prime. Is this possible?
-
-Yes. As long as your AWS account is billed to one of the allowed countries, it is possible to deploy Rancher in any AWS regions.
-
-#### Is this listing available in China?
-
-While it is not possible to transact/bill Rancher Prime in China, it is possible to deploy into AWS regions in China.
-
-#### Can I still deploy Rancher using the "Rancher Setup" listing from the AWS Marketplace?
-
-"Rancher Setup" is no longer available via AWS Marketplace. Customers should deploy an EKS Cluster to host Rancher. Follow the steps in this [guide](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md) except for the Rancher installation. The Rancher product installation should be carried out as per [installing the Rancher Prime PAYG offering on Amazon's AWS Marketplace](installing-rancher-prime.md).
-
-### Billing
-
-#### I have an existing Rancher Prime subscription. Can I use this on AWS?
-
-BYOS (Bring Your Own Subscription) Rancher deployments are supported on AWS; however, billing will not be via the AWS Marketplace. Once the existing subscription term ends, you can purchase Rancher Prime via the AWS Marketplace and reconfigure your cluster to support monthly billing via AWS.
-
-#### I have an existing Rancher Subscription purchased via the ’Rancher Premium Support’ listing on AWS. Isthis transferable to the new model?
-
-No. A new deployment of Rancher Prime is required to benefit from the new monthly billing model.
-
-#### I have an existing deployment covered by a Rancher subscription; can I use this new listing in AWS for new deployments?
-
-Yes. the listing works independently from your existing subscriptions. Please remember that support processes may be different for deployments using your existing subscription and those billed via the AWS Marketplace.
-
-#### Tell me more about how the billing for Rancher Prime works via AWS?
-
-When purchasing Rancher Prime via the AWS Marketplace, the billing is as follows:
-
- Billing is monthly and handled via AWS Marketplace.
- Managed nodes are counted hourly when Rancher is active and added to a usage
-total.
- An average node count is calculated for the month.
- There is a monthly usage charge for each node in the average node count.
- The monthly usage charge depends on the number of nodes in use.
- There is a 5-node minimum; if the average node count is less than 5 nodes, the
-charge will be for 5 nodes.
-
-#### What are the pricing tiers?
-
-Rancher Prime has different pricing tiers when purchasing via the AWS Marketplace. This is based on the number of nodes which Rancher is managing. Details of the tiers are below. Please check the listing for further pricing information.
-
-| Tier     | Nodes (from) |  Nodes (to) |
-| :------: | :----------: | :---------: |
-| **1**    | 5            | 15          |
-| **2**    | 16           | 50          |
-| **3**    | 51           | 100         |
-| **4**    | 101          | 250         |
-| **5**    | 251          | 1000        |
-| **6**    | 1001         |             |
-
-#### Is there a way to try Rancher before purchasing?
-
-If using the Rancher Prime listing in the AWS Marketplace, billing will commence from the time of deployment.
-
-Rancher can be deployed manually using the standard documentation and repositories. When ready to benefit from a supported platform and have this billed via the AWS Marketplace, follow the available [documentation](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md) to deploy Rancher Prime from the AWS Marketplace and migrate.
-
-#### How does SUSE calculate the ‘average number of managed nodes’ to bill for?
-
-The average node count is calculated by adding the number of managed nodes (counted hourly) and dividing by the number of hours Rancher has been active in the billing cycle.
-
-Below are three examples of how the average node count is calculated. Check the table below for the details.
-
-:::note
-
-In our example month, we are using 730 hours; this may differ depending on the number of days in the month and the billing cycle.
-
-:::
-
- **Static usage:** Using Rancher to manage 10 nodes, for 1 month (730 hours) with no additional nodes added in the month.
- **Bursting Model:** Using Rancher to manage 10 nodes for 3 weeks (562 hours) in the month, bursting to 30 nodes for 1 week (168 hours).
- **Transient cluster:** A temporary deployment of Rancher on 20 nodes for 2 weeks (336 hours).
-
-|                   | Hours Active (Hours Rancher is active in the month) | Nodes (Managed Nodes counted at each check-in) | Usage total (Sum of nodes reported at each check-in) | Average Node Count (Usage total / hours active) | Note                |
-| ----------------- | :--:                                        | :------------------------:                     | :----:                                          | :--:                                       | :------------------------------:  |
-| **Static Usage**  | 730                                         | 10                                             | 7300                                            | 10                                         | 10 @ Tier 1                       |
-| **Bursting Model**    | 730                                         | 10 (562 hrs), 30 (168 hrs)                      | 10660                                           | 15                                         | 15 @ Tier 1 (rounded from 14.6)   |
-| **Transient Cluster** | 336                                         | 20                                             | 6720                                            | 20                                         | 20 @ Tier 2                       |
-
-#### Are special commercial terms available?
-
-Depending on the deployment, securing special commercial terms (e.g., an annual subscription) may be possible. This will be handled via an AWS Private offer. Please contact SUSE for more information.
-
-#### Can my spend on Rancher Prime count towards my AWS Enterprise Discount Program?
-
-Yes. Please contact your AWS Sales Team for more details.
-
-#### How do I purchase Rancher for additional nodes?
-
-Once Rancher has been deployed from the listing on AWS and billing is active, there is no need to make a specific purchase for additional nodes. Billing is dynamic and based on the number of nodes Rancher is managing. Just deploy or onboard additional clusters to Rancher as needed.
-
-#### Is this an annual commitment, will it auto-renew?
-
-By default, the Rancher Prime listing in AWS is billed on a monthly cycle, based on usage. Billing is ongoing for as long as Rancher is deployed.
-
-It is possible to set up an annual commitment via an AWS Private Offer; these will need to be reviewed and renewed at the end of the term, or the deployment will drop back to the default monthly billing cycle.
-
-### Technical (Billing)
-
-#### Do I need a Kubernetes cluster running in AWS to install Rancher and be billed via the AWS Marketplace?
-
-Yes. To benefit from monthly billing via the Marketplace, the primary Rancher cluster must be an EKS Cluster running in your AWS Account.
-
-#### Which Kubernetes distributions can the AWS Marketplace listing be deployed on?
-
-The AWS Marketplace listing for Rancher Prime with Marketplace billing must be deployed on Amazon EKS. Downstream clusters / managed worker nodes can run on any CNCF compliant Kubernetes platform, EKS, EKS-A, Rancher Kubernetes Engine, etc.
-
-#### What is the deployment mechanism?
-
-The AWS Marketplace listing for Rancher Prime is deployed using Helm.
-
-#### What is the easiest way to get started?
-
-One of the easiest ways to get started is to deploy the AWS Marketplace listing for Rancher Prime to an existing EKS cluster. Follow the instructions in the usage section, a Helm chart takes care of the installation and the setup for billing.
-
-#### What is the minimum version of Rancher required to support AWS Marketplace billing?
-
-The minimum version supporting marketplace billing is Rancher 2.7.9.
-
-#### What version of Rancher is installed when using the Marketplace listing?
-
-The AWS Marketplace listing for Rancher Prime is tied to a specific version of Rancher, typically the latest version available at the time of the listing update. Please check the listing for further information.
-
-#### I need a prior version of Rancher, can I still use the listing?
-
-No. There is no choice over the Rancher version when deploying using the AWS Marketplace listing. If a prior version of Rancher is required, this must be installed manually using the standard documentation.
-
-:::note
-
-Billing through AWS Marketplace may not be supported with previous versions.
-
-:::
-
-#### How often is the listing updated (including the version of Rancher, etc.)?
-
-The marketplace listing is tied to a specific version of Rancher, usually the latest version available at the time of listing. Typically, these are updated quarterly, or more frequently if there are security issues.
-
-#### I have many Kubernetes clusters across multiple AWS accounts, does the Rancher Prime billing still work and enable tiered pricing?
-
-Yes. Downstream clusters managed by Rancher can be deployed across single or multiple AWS accounts, on-premises, or even in other public clouds. Downstream nodes will report up to the primary Rancher deployment. Tiered pricing is enabled and billing will be routed to the AWS account in which the primary cluster is running.
-
-#### I have multiple independent clusters, each running a separate installation of the AWS Marketplace listing for Rancher Prime. How is this billed?
-
-As the Rancher Prime deployments are independent, each deployment is billed separately from the others. It is not possible to benefit from tiered pricing.
-
-#### If managing multiple independent Rancher clusters, consider custom terms from SUSE. How can I benefit from tiered pricing across all Rancher deployments?
-
-The primary Rancher cluster must be running on EKS in the AWS Cloud and running the AWS Marketplace listing for Rancher. To benefit from tiered pricing, managed clusters (downstream clusters) should be connected to the primary Rancher cluster.
-
-#### I have purchased multiple SUSE products from the AWS Marketplace (e.g., SUSE Manager, NeuVector Prime and now Rancher Prime). Does the AWS Marketplace billing method still work?
-
-Yes. The billing mechanism of each deployment is independent, each product will be billed separately via the AWS Marketplace.
-
-#### I already have an existing EKS cluster in place and want to add Rancher and have this billed via Marketplace. Is this possible?
-
-Yes. Simply deploy the AWS Marketplace listing for Rancher Prime.
-
-#### I already have an existing cluster, with Rancher deployed. Can I just install the marketplace version and have support billed via the AWS Marketplace?
-
-In order to benefit from monthly billing via the AWS Marketplace, the primary Rancher cluster needs to be deployed from the listing, it is then possible to migrate the existing Rancher configuration to the new deployment.
-
-Please follow the [documentation](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md) and be sure to back up the existing Rancher configuration.
-
-### Technical (Product)
-
-#### How do I get support?
-
-It is very simple to [open a support case](https://scc.suse.com/cloudsupport) with SUSE for Rancher Prime. Create a ‘supportconfig’ via the Rancher UI and upload the output to the SUSE Customer Center. The support config bundle can be exported from the Rancher console using the ‘Get Support’ button at the bottom of the page. For deployments when Rancher is managing multiple downstream clusters, export the support config bundle from the primary cluster only.
-
-If the billing mechanism on the primary cluster is active, a support case will be opened. Further details can be found in the [documentation](../supportconfig.md).
-
-#### What are the resource requirements for installing Rancher on EKS?
-
-Please check the documentation for best practices.
-
-#### Is there any difference between Rancher Prime from the AWS Marketplace and the versions I can run in my own data center?
-
-Rancher Prime available in the AWS Marketplace is the same product, with the same functionality that you would run on-premises or with a manual installation. The only difference between deploying manually and deploying via the AWS Marketplace listing is the billing route.
-
-#### Does the primary cluster (responsible for billing) need to run 24/7?
-
-To ensure continuity with support, it is recommended that the primary Rancher cluster always remains active.
-
-#### What if the primary cluster responsible for billing is unable to connect to the AWS Billing framework?
-
-There may be multiple reasons why the primary cluster is unable to connect to the AWS framework, but it is the customer’s responsibility to ensure that the primary cluster is active and connected. Whilst the cluster is not connected to the billing framework, it is not possible to raise a support request.
-
-#### My primary cluster has been offline. What will happen with billing when reconnected?
-
-If the primary cluster is offline or disconnected from the AWS billing framework for a period of time, when it reconnects, the stored usage data will be uploaded to AWS and will appear on your next AWS bill.
-
-Depending on when in the month the primary cluster gets reconnected you may have several months of usage on your next billing cycle.
-
-#### Can the managed worker nodes reside on premises, at the edge or even on another cloud provider?
-
-Yes. Nodes can run anywhere. SUSE Rancher will count the total number of nodes managed regardless of where they are deployed.
-
-#### How do I get fixes and updates for Rancher?
-
-To update to the latest version of the Rancher Prime PAYG offering supported in the marketplace listing, please see [upgrading Rancher Prime PAYG cluster in AWS](upgrading-rancher-payg-cluster.md).
@@ -2,10 +2,6 @@
 title: Azure Marketplace Pay-as-you-go (PAYG) Integration
 ---

-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace/azure-marketplace-payg-integration/azure-marketplace-payg-integration"/>
-</head>
-
 ## Overview

 Rancher Prime integrates with the [Azure Marketplace](https://azuremarketplace.microsoft.com) as a pay-as-you-go (PAYG) offering. This brings the value of running and managing Kubernetes environments to Azure customers, benefiting from a new pay-monthly pricing model available through the Azure Marketplace. This listing will enable you to manage any CNCF-certified Kubernetes distribution in Azure, on-prem, or at the edge. To learn more, see our non-EMEMA and EMEA Azure Marketplace offerings for Rancher Prime:
@@ -13,6 +9,10 @@ Rancher Prime integrates with the [Azure Marketplace](https://azuremarketplace.m
 - [Rancher Prime with 24x7 Support](https://portal.azure.com/#view/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/suse.rancher-prime-llc/selectionMode~/false/resourceGroupId//resourceGroupLocation//dontDiscardJourney~/false/selectedMenuId/home/launchingContext~/%7B%22galleryItemId%22%3A%22suse.rancher-prime-llcpay-as-you-go%22%2C%22source%22%3A%5B%22GalleryFeaturedMenuItemPart%22%2C%22VirtualizedTileDetails%22%5D%2C%22menuItemId%22%3A%22home%22%2C%22subMenuItemId%22%3A%22Search%20results%22%2C%22telemetryId%22%3A%221dafcf16-920e-46ea-80c9-dc85c6bd3a17%22%7D/searchTelemetryId/c2300fb7-ba7b-462a-ba57-a37cb5e2822d)
 - [Rancher Prime with 24x7 Support (EMEA Orders Only)](https://portal.azure.com/#view/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/suseirelandltd1692213356027.rancher-prime-ltd/selectionMode~/false/resourceGroupId//resourceGroupLocation//dontDiscardJourney~/false/selectedMenuId/home/launchingContext~/%7B%22galleryItemId%22%3A%22suseirelandltd1692213356027.rancher-prime-ltdpay-as-you-go%22%2C%22source%22%3A%5B%22GalleryFeaturedMenuItemPart%22%2C%22VirtualizedTileDetails%22%5D%2C%22menuItemId%22%3A%22home%22%2C%22subMenuItemId%22%3A%22Search%20results%22%2C%22telemetryId%22%3A%22c6b1d79a-b577-47b0-90e5-41e6c49688ab%22%7D/searchTelemetryId/1793144d-e0d9-466e-8e36-dfeddc73163b)

+## FAQ
+
+For more details on how Rancher pay-as-you-go offerings work, refer to the [pay-as-you-go FAQ](../cloud-marketplace-payg-integration.md#faq).
+
 ## Limitations

 - Currently, you must be running Rancher v2.7.9. When you deploy a supported PAYG version, you can update to newer versions of Rancher when the listing is updated.
@@ -21,215 +21,3 @@ Rancher Prime integrates with the [Azure Marketplace](https://azuremarketplace.m

 1. Complete the [prerequisite steps](prerequisites.md).
 2. [Install the Rancher Prime PAYG offering on the Azure Marketplace](installing-rancher-prime.md).
-
-## FAQ
-
-The following is a list of frequently asked questions.
-
-### Marketplace Listing
-
-#### What is the Rancher Prime listing on the Azure Marketplace?
-
-By selecting the Rancher Prime listing in the Azure Marketplace, customers can deploy Rancher to their Microsoft Azure Kubernetes Service (AKS) cluster environment to manage any downstream CNCF-certified Kubernetes distribution with the advantage of having monthly billing for Rancher Prime via Microsoft Azure.
-
-**Where do I find the Rancher Prime listings?**
-
-There are two listings in the Azure Marketplace. They are:
-
- [Rancher Prime with 24x7 Support](https://portal.azure.com/#view/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/suse.rancher-prime-llc/selectionMode~/false/resourceGroupId//resourceGroupLocation//dontDiscardJourney~/false/selectedMenuId/home/launchingContext~/%7B%22galleryItemId%22%3A%22suse.rancher-prime-llcpay-as-you-go%22%2C%22source%22%3A%5B%22GalleryFeaturedMenuItemPart%22%2C%22VirtualizedTileDetails%22%5D%2C%22menuItemId%22%3A%22home%22%2C%22subMenuItemId%22%3A%22Search%20results%22%2C%22telemetryId%22%3A%221dafcf16-920e-46ea-80c9-dc85c6bd3a17%22%7D/searchTelemetryId/c2300fb7-ba7b-462a-ba57-a37cb5e2822d)
- [Rancher Prime with 24x7 Support (EMEA Orders Only)](https://portal.azure.com/#view/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/suseirelandltd1692213356027.rancher-prime-ltd/selectionMode~/false/resourceGroupId//resourceGroupLocation//dontDiscardJourney~/false/selectedMenuId/home/launchingContext~/%7B%22galleryItemId%22%3A%22suseirelandltd1692213356027.rancher-prime-ltdpay-as-you-go%22%2C%22source%22%3A%5B%22GalleryFeaturedMenuItemPart%22%2C%22VirtualizedTileDetails%22%5D%2C%22menuItemId%22%3A%22home%22%2C%22subMenuItemId%22%3A%22Search%20results%22%2C%22telemetryId%22%3A%22c6b1d79a-b577-47b0-90e5-41e6c49688ab%22%7D/searchTelemetryId/1793144d-e0d9-466e-8e36-dfeddc73163b)
-
-#### Why are there two listings? Which one should I use?
-
-There are two listings for Rancher Prime to accommodate Microsoft Azure billing regions. You should pick the listing that reflects where your Azure account gets billed.
-
-#### Are these listings available in all countries?
-
-No. Due to billing limitations and other restrictions, the Rancher Prime Azure Marketplace listing may not be purchasable in all countries. The Azure account you use for deployment determines your billing country. Contact your Azure Sales Team for more details.
-
-#### My Azure account is in the USA, but I want to deploy Rancher in another Azure region, a region that is in a country where I currently cannot transact Rancher Prime. Is this possible?
-
-Yes. As long as your Azure account is billed to one of the allowed countries, it is possible to deploy Rancher Prime in any Azure region.
-
-#### Is this listing available in China?
-
-While it is not possible to transact/bill Rancher Prime in China, it is possible to deploy into Azure regions in China.
-
-### Billing
-
-#### I have an existing Rancher Prime subscription; can I use this on Azure?
-
-Self-installed BYOS (Bring Your Own Subscription) Rancher Prime deployments are supported on Azure; however, billing will not be via the Azure Marketplace. Once the existing subscription term ends, you can purchase Rancher Prime via the Azure Marketplace and reconfigure your cluster to support monthly billing via Azure.
-
-#### I have an existing deployment covered by a Rancher subscription; can I use this new listing in the Azure Marketplace for new deployments?
-
-Yes. the listing works independently from your existing Rancher Prime subscriptions. Only deployments through the marketplace listing will be billed through Azure. Support is always direct from SUSE.
-
-#### Tell me more about how the billing for Rancher Prime works via Azure?
-
-When purchasing Rancher Prime via the Azure Marketplace, the billing is as follows:
-
- Billing is monthly and handled via Azure.
- Managed nodes are counted hourly when Rancher is active and added to a usage total.
- An average node count is calculated for the month.
- There is a monthly usage charge for each node in the average node count.
- The monthly usage charge depends on the number of nodes in use.
- There is a 5-node minimum; if the average node count is less than 5 nodes, the charge will be for 5 nodes.
-
-#### What are the pricing tiers?
-
-Rancher Prime has different pricing tiers when purchasing via the Azure Marketplace. This is based on the number of nodes that Rancher is managing. Details of the tiers are shown below. Please check the listing for further pricing information.
-
-| Tier     | Nodes (from) |  Nodes (to) |
-| :------: | :----------: | :---------: |
-| **1**    | 5            | 15          |
-| **2**    | 16           | 50          |
-| **3**    | 51           | 100         |
-| **4**    | 101          | 250         |
-| **5**    | 251          | 1000        |
-| **6**    | 1001         |             |
-
-#### Is there a way to try Rancher before purchasing?
-
-If using the Rancher Prime listing in the Azure Marketplace, billing will commence from the time of deployment. You can try Rancher by deploying it per standard documentation. When ready to benefit from a supported platform and have this billed through Azure, deploy Rancher Prime via the Azure Marketplace and migrate your configuration.
-
-#### How does SUSE calculate the ‘average number of managed nodes’ to bill for?
-
-The average node count is calculated by adding the number of managed nodes (counted hourly) and dividing by the number of hours Rancher has been active in the billing cycle. Three examples are shown in the table below.
-
-:::note
-
-In our example month, we are using 730 hours; this may differ depending on the number of days in the month and the billing cycle.
-
-:::
-
- **Static Usage:**
-Using Rancher to manage 10 nodes for 1 month (730 hours) with no additional nodes added in the month.
- **Bursting Model:**
-Using Rancher to manage 10 nodes for 3 weeks (562 hours) in the month and bursting to 30 nodes for 1 week (168 hours).
- **Transient Cluster:**
-A temporary deployment of Rancher on 20 nodes for 2 weeks (336 hours).
-
-|                   | Hours Active (Hours Rancher is active in the month) | Nodes (Managed Nodes counted at each check-in) | Usage total (Sum of nodes reported at each check-in) | Average Node Count (Usage total / hours active) | Note                |
-| ----------------- | :--:                                        | :------------------------:                     | :----:                                          | :--:                                       | :------------------------------:  |
-| **Static Usage**  | 730                                         | 10                                             | 7300                                            | 10                                         | 10 @ Tier 1                       |
-| **Bursting Model**    | 730                                         | 10 (562 hrs), 30 (168 hrs)                      | 10660                                           | 15                                         | 15 @ Tier 1 (rounded from 14.6)   |
-| **Transient Cluster** | 336                                         | 20                                             | 6720                                            | 20                                         | 20 @ Tier 2                       |
-
-#### Are special commercial terms available?
-
-Depending on the deployment, securing special commercial terms (e.g., an annual subscription) may be possible. This will be handled via an Azure private offer. Please contact SUSE for more information.
-
-#### Can my spend on Rancher Prime count towards my MACC Program?
-
-Yes. Contact your Azure Sales Team for more details.
-
-#### How do I purchase Rancher for additional nodes?
-
-Once Rancher Prime has been deployed from the Azure Marketplace and billing is active, there is no need to make a specific purchase for additional nodes. Billing is dynamic and based on the number of nodes Rancher is managing. Just deploy or onboard additional clusters to Rancher as needed.
-
-#### Is this an annual commitment, will it auto-renew?
-
-By default, the Rancher Prime listing is billed on a monthly cycle, based on usage. Billing is ongoing for as long as Rancher Prime is deployed.
-
-It is possible to set up an annual commitment via an Azure Private Offer; these will need to be reviewed and renewed at the end of the term, or the deployment will drop back to the default monthly billing cycle.
-
-### Technical
-
-#### Do I need a Kubernetes cluster running in Azure to install Rancher and be billed via the Azure Marketplace?
-
-Yes. To benefit from monthly billing via Azure, the primary Rancher cluster must be an Azure Kubernetes Service (AKS) cluster running in your Azure account.
-
-#### Which Kubernetes distributions can the Rancher Prime Azure Marketplace listing be deployed on?
-
-The Rancher Prime marketplace listing must be deployed on Azure Kubernetes Service (AKS). Downstream/managed clusters can run any supported Kubernetes platform: RKE, RKE2, EKS, GKE, vanilla Kubernetes, OpenShift, Mirantis Kubernetes Engine, etc. See Supported Platforms for more details.
-
-#### What is the deployment mechanism?
-
-The Rancher Prime marketplace listing is deployed using Azure’s CNAB (with Helm inside).
-
-#### What is the easiest way to get started?
-
-One of the easiest ways to get started is to deploy the Rancher Prime marketplace listing to an existing AKS cluster. Follow the instructions in the usage section of the listing. A Helm chart takes care of installation and billing setup.
-
-#### What is the minimum version of Rancher required to support Azure Marketplace billing?
-
-The minimum version supporting marketplace billing is Rancher 2.7.9.
-
-#### What version of Rancher is installed when using the marketplace listing?
-
-The Rancher Prime marketplace listing is tied to a specific version of Rancher, typically the latest version available at the time of the listing update. Check the listing for further information.
-
-#### I need a prior version of Rancher; can I still use the listing?
-
-No. There is no choice over the Rancher version when deploying using the Azure Marketplace listing. If a prior version of Rancher is required, this must be installed manually using the standard documentation.
-
-:::note
-
-Billing through the Azure Marketplace may not be supported with earlier versions.
-
-:::
-
-#### How often is the listing updated (including the version of Rancher, etc.)?
-
-The marketplace listing is tied to a specific version of Rancher, usually it is the latest version available at the time the listing was last updated. Typically, the marketplace listing is updated quarterly, or more frequently to address any new security issues.
-
-#### I have many Kubernetes clusters across multiple Azure accounts; does the Rancher Prime billing still work and enable tiered pricing?
-
-Yes. Downstream/managed clusters can be deployed across single or multiple Azure accounts, on-premises, and in other public clouds. Downstream/managed nodes report up to Rancher Prime, enabling tiered pricing with billing routed to the Azure account in which the managing Rancher Prime cluster is running.
-
-#### I have multiple independent clusters, each running a separate installation of the Rancher Prime Azure Marketplace listing. How is this billed?
-
-As the Rancher Prime deployments are independent, each deployment is billed separately from the others. It is not possible to benefit from tiered pricing. If managing multiple independent Rancher Prime clusters, consider custom terms from SUSE.
-
-#### How can I benefit from tiered pricing across all Rancher deployments?
-
-The primary Rancher Prime cluster must be running on AKS in Microsoft Azure, deployed through the marketplace listing. To benefit from tiered pricing, downstream/managed clusters should be imported into the primary Rancher Prime cluster.
-
-#### I have purchased multiple SUSE products from the Azure Marketplace (e.g., SUSE Manager, NeuVector Prime, Rancher Prime). Does the Azure Marketplace billing method still work?
-
-Yes. The billing mechanisms for the deployments are independent and are billed separately via the Azure Marketplace.
-
-#### I already have an existing AKS cluster in place and want to add Rancher Prime to it and be billed through the Azure Marketplace. Is this possible?
-
-Yes. Simply deploy the Rancher Prime to the cluster with the Azure Marketplace listing.
-
-#### I already deployed Rancher to an existing AKS cluster. Can I just install the marketplace version to enable Azure Marketplace billing?
-
-No. You need to deploy Rancher Prime with the Azure Marketplace listing and migrate the existing Rancher configuration to this new deployment. Be sure that you back up your existing Rancher configuration.
-
-### Technical (Product)
-
-#### How do I get support?
-
-It is very simple to [open a support case](https://scc.suse.com/cloudsupport) with SUSE for Rancher Prime. Create a ‘supportconfig’ via the Rancher UI (click Get Support under the hamburger menu and follow instructions), then upload the ‘supportconfig’ output to the SUSE Customer Center. If the billing mechanism is active, a support case will be opened. See Supportconfig bundle in the Rancher [documentation](../supportconfig.md) for more details.
-
-:::note
-
-For deployments where Rancher Prime is managing multiple downstream clusters, be sure to export the ‘supportconfig’ bundle from the primary cluster only.
-
-:::
-
-#### What are the resource requirements for installing Rancher on AKS?
-
-Check the documentation for [best practices](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md#hosted-kubernetes).
-
-#### Is there any difference between Rancher Prime from Azure Marketplace and the versions I can run in my own data center?
-
-Rancher Prime available in the Azure Marketplace is the same product, with the same functionality that you would install manually in the cloud or on-premises. The only difference between deploying manually and deploying via the marketplace listing is the billing route.
-
-#### Does the primary cluster (responsible for billing) need to run 24/7?
-
-To ensure continuity of support, it is recommended that the primary Rancher Prime cluster always remain active.
-
-#### What if the primary cluster responsible for billing is unable to connect to the Azure billing framework?
-
-There may be multiple reasons why the primary cluster is unable to connect to the Azure billing framework, but it is the customer’s responsibility to ensure that the primary cluster is active and connected. While the cluster is not connected to the billing framework, it is not possible to raise a support request.
-
-#### My primary cluster has been offline. What will happen with billing when reconnected?
-
-If the Racher Prime cluster is offline or disconnected from the Azure billing framework for a period of time, when it reconnects, the stored usage data will be uploaded to Azure and will appear on your next Azure bill. Depending on the month when the primary cluster gets reconnected you may have several months of usage on your next billing cycle.
-
-#### How do I get fixes and updates for Rancher?
-
-To update to the latest version of the Rancher Prime PAYG offering supported in the marketplace listing, please see [upgrading Rancher Prime PAYG cluster in Azure](upgrading-rancher-payg-cluster.md).
@@ -0,0 +1,257 @@
+---
+title: Cloud Marketplace Pay-as-you-go (PAYG) Integration
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/v2.7/integrations-in-rancher/cloud-marketplace/cloud-marketplace-payg-integration"/>
+</head>
+
+Rancher Prime integrates with the [AWS Marketplace](https://aws.amazon.com/marketplace) and [Azure Marketplace](https://azuremarketplace.microsoft.com/) as a pay-as-you-go (PAYG) offering. This brings the value of running and managing Kubernetes environments to cloud customers, who benefit from a new pay-monthly pricing model available through their preferred cloud provider's marketplace. This listing will enable you to manage any CNCF-certified Kubernetes distribution in AWS, Azure, on-prem, or at the edge.
+
+## Limitations
+
+Currently, you must be running Rancher v2.7.9. When you deploy a supported PAYG version, you can update to newer versions of Rancher when the listing is updated.
+
+## How to Use
+
+<Tabs>
+<TabItem value="AWS">
+
+1. Complete the [prerequisite steps](../cloud-marketplace/aws-marketplace-payg-integration/prerequisites.md).
+2. [Install the Rancher Prime PAYG offering on the AWS Marketplace](../cloud-marketplace/aws-marketplace-payg-integration/installing-rancher-prime.md).
+
+</TabItem>
+<TabItem value="Azure">
+
+1. Complete the [prerequisite steps](../cloud-marketplace/azure-marketplace-payg-integration/prerequisites.md).
+2. [Install the Rancher Prime PAYG offering on the Azure Marketplace](../cloud-marketplace/azure-marketplace-payg-integration/installing-rancher-prime.md).
+
+</TabItem>
+</Tabs>
+
+## FAQ
+
+The following is a list of frequently asked questions.
+
+### Marketplace Listings
+
+#### What is the Rancher Prime listing on the cloud marketplace?
+
+By selecting the Rancher Prime listing from the AWS or Azure Marketplace, you can deploy Rancher to your Kubernetes environment with the advantage of having monthly billing via the cloud.
+
+#### Where do I find the Rancher Prime listings?
+
+There are two listings in each respective cloud marketplace. They are:
+
+**AWS**
+- [Rancher Prime](https://aws.amazon.com/marketplace/pp/prodview-f2bvszurj2p2c)
+- [Rancher Prime (EMEA Orders Only)](https://aws.amazon.com/marketplace/pp/prodview-ocgjwd5c2aj5i)
+
+**Azure**
+- [Rancher Prime with 24x7 Support](https://portal.azure.com/#view/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/suse.rancher-prime-llc/selectionMode~/false/resourceGroupId//resourceGroupLocation//dontDiscardJourney~/false/selectedMenuId/home/launchingContext~/%7B%22galleryItemId%22%3A%22suse.rancher-prime-llcpay-as-you-go%22%2C%22source%22%3A%5B%22GalleryFeaturedMenuItemPart%22%2C%22VirtualizedTileDetails%22%5D%2C%22menuItemId%22%3A%22home%22%2C%22subMenuItemId%22%3A%22Search%20results%22%2C%22telemetryId%22%3A%221dafcf16-920e-46ea-80c9-dc85c6bd3a17%22%7D/searchTelemetryId/c2300fb7-ba7b-462a-ba57-a37cb5e2822d)
+- [Rancher Prime with 24x7 Support (EMEA Orders Only)](https://portal.azure.com/#view/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/suseirelandltd1692213356027.rancher-prime-ltd/selectionMode~/false/resourceGroupId//resourceGroupLocation//dontDiscardJourney~/false/selectedMenuId/home/launchingContext~/%7B%22galleryItemId%22%3A%22suseirelandltd1692213356027.rancher-prime-ltdpay-as-you-go%22%2C%22source%22%3A%5B%22GalleryFeaturedMenuItemPart%22%2C%22VirtualizedTileDetails%22%5D%2C%22menuItemId%22%3A%22home%22%2C%22subMenuItemId%22%3A%22Search%20results%22%2C%22telemetryId%22%3A%22c6b1d79a-b577-47b0-90e5-41e6c49688ab%22%7D/searchTelemetryId/1793144d-e0d9-466e-8e36-dfeddc73163b)
+
+#### Why are there two listings? Which one should I use?
+
+We have two listings for Rancher Prime, a EU/EMEA version and a non-EU, non-UK version, due to different regulations in different locations. Whichever listing you choose, the images and support offered are identical. You should pick the listing for the location of your cloud provider account.
+
+#### Are these listings available in all countries?
+
+No. The PAYG listing isn't available in all countries.
+
+Your billing country is based on the cloud provider Account ID for the deployment.
+
+Please refer to [Geographical availability](https://documentation.suse.com/sle-public-cloud/all/html/public-cloud/countrylist.html) for a list of countries that can and cannot access Rancher Prime via the AWS and Azure cloud marketplaces.
+
+#### My cloud provider account is in the USA, but I want to deploy Rancher in another region, a region that is in a country where I currently cannot transact Rancher Prime. Is this possible?
+
+Yes. As long as your account is billed to one of the allowed countries, it is possible to deploy Rancher in any region.
+
+#### Is this listing available in China?
+
+While it is not possible to transact or bill Rancher Prime in China, it is possible to deploy into regions in China.
+
+#### Can I still deploy Rancher using the "Rancher Setup" listing from the AWS Marketplace?
+
+The Rancher Setup listing is no longer available via AWS Marketplace. Customers should deploy an EKS Cluster to host Rancher. Follow the steps in this [guide](../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md) except for the Rancher installation. The Rancher product installation should be carried out as per [installing the Rancher Prime PAYG offering on Amazon's AWS Marketplace](../cloud-marketplace/aws-marketplace-payg-integration/installing-rancher-prime.md).
+
+### Billing
+
+#### I have an existing Rancher Prime subscription. Can I use this on the cloud?
+
+BYOS (Bring Your Own Subscription) Rancher deployments are supported on the cloud; however, you won't be billed for your BYOS via the cloud marketplace. Once the existing subscription term ends, you can purchase Rancher Prime via the cloud marketplace and reconfigure your cluster to support monthly billing via the cloud.
+
+#### I have an existing Rancher Subscription purchased via the Rancher Premium Support listing on AWS. Is this transferable to the new model?
+
+No. A new deployment of Rancher Prime is required to benefit from the new monthly billing model.
+
+#### I have an existing deployment covered by a Rancher subscription; can I use this new marketplace listing for new deployments?
+
+Yes. The listing works independently of your existing subscriptions. Please remember that support processes may be different for deployments using your existing subscription and deployments billed via the cloud marketplace.
+
+#### Can you tell me more about how the billing for Rancher Prime works for the cloud marketplace?
+
+When purchasing Rancher Prime via the cloud marketplace, the billing is as follows:
+
+- Billing is monthly and handled via the marketplace.
+- Managed nodes are counted hourly when Rancher is active and added to a usage total.
+- An average node count is calculated for the month.
+- There is a monthly usage charge for each node in the average node count.
+- The monthly usage charge depends on the number of nodes in use.
+- There is a 5-node minimum; if the average node count is less than 5 nodes, the charge will be for 5 nodes.
+
+#### What are the pricing tiers?
+
+Pricing tiers are based on the number of nodes which Rancher is managing. Details of the tiers are below. Please check the respective listing for further price information.
+
+| Tier     | Nodes (from) |  Nodes (to) |
+| :------: | :----------: | :---------: |
+| **1**    | 5            | 15          |
+| **2**    | 16           | 50          |
+| **3**    | 51           | 100         |
+| **4**    | 101          | 250         |
+| **5**    | 251          | 1000        |
+| **6**    | 1001         |             |
+
+#### Is there a way to try Rancher before purchasing?
+
+If you use the Rancher Prime listing in a cloud provider marketplace, billing commences from the time of deployment.
+
+Rancher can be deployed manually using the standard documentation and repositories. When you're ready to benefit from a supported platform and have this billed via the marketplace, follow the available [documentation](../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md) to deploy Rancher Prime from the marketplace and migrate.
+
+#### How does SUSE calculate the average number of managed nodes to bill for?
+
+The average node count is calculated by adding together the number of managed nodes (counted hourly), and dividing this sum by the number of hours Rancher has been active in the billing cycle.
+
+Here are three examples of how the average node count is calculated. Check the following table for details.
+
+:::note
+
+In our example month, we are using 730 hours; this may differ depending on the number of days in the month and the billing cycle.
+
+:::
+
+- **Static usage:** Using Rancher to manage 10 nodes, for 1 month (730 hours) with no additional nodes added in the month.
+- **Bursting Model:** Using Rancher to manage 10 nodes for 3 weeks (562 hours) in the month, bursting to 30 nodes for 1 week (168 hours).
+- **Transient cluster:** A temporary deployment of Rancher on 20 nodes for 2 weeks (336 hours).
+
+|                   | Hours Active (Hours Rancher is active in the month) | Nodes (Managed Nodes counted at each check-in) | Usage total (Sum of nodes reported at each check-in) | Average Node Count (Usage total / hours active) | Note                |
+| ----------------- | :--:                                        | :------------------------:                     | :----:                                          | :--:                                       | :------------------------------:  |
+| **Static Usage**  | 730                                         | 10                                             | 7300                                            | 10                                         | 10 @ Tier 1                       |
+| **Bursting Model**    | 730                                         | 10 (562 hrs), 30 (168 hrs)                      | 10660                                           | 15                                         | 15 @ Tier 1 (rounded from 14.6)   |
+| **Transient Cluster** | 336                                         | 20                                             | 6720                                            | 20                                         | 20 @ Tier 2                       |
+
+#### Are special commercial terms available?
+
+Depending on the deployment, and the cloud provider, securing special commercial terms (e.g., an annual subscription) may be possible. For example, in AWS this is handled via an AWS Private offer. Please contact SUSE for more information.
+
+#### Can my spend on Rancher Prime count towards my cloud provider discount program?
+
+Yes. This should be possible through the:
+
+- Azure MACC Program
+- AWS Enterprise Discount Program
+
+Please contact your AWS or Azure sales team for more details.
+
+#### How do I purchase Rancher for additional nodes?
+
+Once Rancher is deployed from the listing on the cloud marketplace and billing is active, there is no need to make a specific purchase for additional nodes. Billing is dynamic and based on the number of nodes Rancher is managing. Just deploy or onboard additional clusters to Rancher as needed.
+
+#### Is this an annual commitment, or does it auto-renew?
+
+By default, the Rancher Prime listing in the cloud is billed on a monthly cycle, based on usage. Billing is ongoing for as long as Rancher is deployed.
+
+### Technical (Billing)
+
+#### Do I need a Kubernetes cluster running in the cloud to install Rancher and be billed via the cloud marketplace?
+
+Yes. To benefit from monthly billing via the cloud marketplace, the primary Rancher cluster must be an on the cloud provider's Kubernetes service.  In AWS an EKS cluster is required, while in Azure an AKS cluster is required.
+
+#### Which Kubernetes distributions can the marketplace listings be deployed on?
+
+The cloud marketplace listings for Rancher Prime must be deployed on Amazon EKS or Azure AKS. Downstream clusters and  managed worker nodes can run on any CNCF-compliant Kubernetes platform, such as AKS, EKS, EKS-A, or Rancher Kubernetes Engine (RKE).
+
+#### What is the deployment mechanism?
+
+The cloud marketplace listings for Rancher Prime are deployed using Helm.
+
+#### What is the easiest way to get started?
+
+Deploy a listing for Rancher Prime to an existing EKS or AKS cluster. Follow the instructions in the usage section. a Helm chart takes care of the installation and setup for billing.
+
+#### What version of Rancher is installed when using a marketplace listing?
+
+Each marketplace listing for Rancher Prime is tied to a specific version of Rancher, typically the latest version available at the time of the listing update. Please check the listing for further information.
+
+#### I need a prior version of Rancher, can I still use a marketplace listing?
+
+No. There is no choice over the Rancher version when deploying Rancher through a cloud marketplace listing. If a prior version of Rancher is required, it must be installed manually using the standard documentation.
+
+:::note
+
+Billing through the cloud provider marketplace may not be supported with previous versions.
+
+:::
+
+#### How often are the listings updated (including the version of Rancher, etc.)?
+
+Marketplace listings are tied to a specific version of Rancher, usually the latest version available at the time of listing. Typically, listings are updated quarterly, or more frequently if there are security issues.
+
+#### I have many Kubernetes clusters across multiple cloud accounts, does the Rancher Prime billing still work and enable tiered pricing?
+
+Yes. Downstream clusters managed by Rancher can be deployed across single or multiple cloud accounts, on-premises, or even in other public clouds. Downstream nodes report up to the primary Rancher deployment. Tiered pricing is enabled and billing is routed to the cloud account in which the primary cluster is running.
+
+#### I have multiple independent clusters, each running a separate installation of the marketplace listing for Rancher Prime. How is this billed?
+
+As the Rancher Prime deployments are independent, each deployment is billed separately from the others within the cloud marketplace. It is not possible to benefit from tiered pricing. Please contact SUSE.
+
+#### I have purchased multiple SUSE products from the cloud marketplace (e.g., SUSE Manager, NeuVector Prime and now Rancher Prime). Does the cloud marketplace billing method still apply?
+
+Yes. Since the billing mechanism of each deployment is independent, each product will be billed separately via the cloud marketplace.
+
+#### I already have an existing cluster, with Rancher deployed. Can I just install the marketplace version and have support billed via the cloud provider marketplace?
+
+In order to benefit from monthly billing via the marketplace, the primary Rancher cluster needs to be deployed from the listing. It is then possible to migrate the existing Rancher configuration to the new deployment.
+
+Please follow the [documentation](../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md) and be sure to back up the existing Rancher configuration.
+
+### Technical (Product)
+
+#### How do I contact support?
+
+It is very simple to [open a support case](https://scc.suse.com/cloudsupport) with SUSE for Rancher Prime. Create a support config via the Rancher UI and upload the output to the SUSE Customer Center. The support config bundle can be exported from the Rancher console using the **Get Support** button at the bottom of the page. For deployments where Rancher is managing multiple downstream clusters, export the support config bundle only from the primary cluster.
+
+If the billing mechanism on the primary cluster is active, a support case will be opened. Further details can be found in the [documentation](../cloud-marketplace/supportconfig.md).
+
+#### What are the resource requirements for installing Rancher on AKS or EKS?
+
+Please check the documentation for best practices.
+
+#### Is there any difference between Rancher Prime from the cloud marketplace and the versions I can run in my own data center?
+
+Rancher Prime available in the cloud marketplace is the same product, with the same functionality that you would run on-premises or with a manual installation. The only difference between deploying manually and deploying via a marketplace listing is the billing route.
+
+#### Does the primary cluster (responsible for billing) need to run 24/7?
+
+To ensure continuity with support, the primary Rancher cluster should always remains active.
+
+#### What if the primary cluster responsible for billing is unable to connect to the cloud provider billing framework?
+
+There may be multiple reasons why the primary cluster is unable to connect to the billing framework, but it is the customer’s responsibility to ensure that the primary cluster is active and connected. When the cluster is not connected to the billing framework, it is not possible to raise a support request.
+
+#### My primary cluster has been offline. What will happen with billing when reconnected?
+
+If the primary cluster is offline or disconnected from the cloud provider billing framework for a period of time, when it reconnects, the stored usage data will be uploaded and appear on your next marketplace bill.
+
+Depending on when in the month the primary cluster gets reconnected you may have several months of usage on your next billing cycle.
+
+#### Can the managed worker nodes reside on premises, at the edge or even on another cloud?
+
+Yes. Managed nodes (managed clusters) can run anywhere. SUSE Rancher will count the total number of nodes managed regardless of where they are deployed.
+
+#### How do I get fixes and updates for Rancher?
+
+To update to the latest supported version of the Rancher Prime PAYG offering, please see:
+  - [Upgrading Rancher Prime PAYG cluster in AWS](../cloud-marketplace/aws-marketplace-payg-integration/upgrading-rancher-payg-cluster.md)
+  - [Upgrading Rancher Prime PAYG cluster in Azure](../cloud-marketplace/azure-marketplace-payg-integration/upgrading-rancher-payg-cluster.md)
@@ -10,8 +10,9 @@ By default, some cluster-level API tokens are generated with infinite time-to-li

 You can deactivate API tokens by deleting them or by deactivating the user account.

-### Deleting tokens
-To delete a token,
+## Deleting Tokens
+
+To delete a token:

 1. Go to the list of all tokens in the Rancher API view at `https://<Rancher-Server-IP>/v3/tokens`.

@@ -19,7 +20,7 @@ To delete a token,

 1. Click **Delete**.

-Here is the complete list of tokens that are generated with `ttl=0`:
+The following is a complete list of tokens generated with `ttl=0`:

 | Token             | Description                                                                            |
 | ----------------- | -------------------------------------------------------------------------------------- |
@@ -29,12 +30,12 @@ Here is the complete list of tokens that are generated with `ttl=0`:
 | `compose-token-*` | Token for compose                                                                      |
 | `helm-token-*`    | Token for Helm chart deployment                                                        |
 | `telemetry-*`     | Telemetry token                                                                        |
-| `drain-node-*`    | Token for drain (we use `kubectl` for drain because there is no native Kubernetes API) |
+| `drain-node-*`    | Token for drain (Rancher uses `kubectl` for drain because there is no native Kubernetes API) |


 ### Setting TTL on Kubeconfig Tokens

-Admins can set a global time-to-live (TTL) on Kubeconfig tokens. Changing the default kubeconfig TTL can be done by navigating to global settings and setting [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) to the desired duration in minutes. The default value of [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) is 0, which means tokens never expire.
+Admins can set a global time-to-live (TTL) on Kubeconfig tokens. Changing the default kubeconfig TTL can be done by navigating to global settings and setting [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) to the desired duration in minutes. The default value of [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) is `0`, which means that tokens never expire.

 :::note

@@ -42,49 +43,55 @@ This setting is used by all kubeconfig tokens except those created by the CLI to

 :::

-### Disable Tokens in Generated Kubeconfigs
+## Disable Tokens in Generated Kubeconfigs

-1. Set the `kubeconfig-generate-token` setting to `false`. This setting instructs Rancher to no longer automatically generate a token when a user clicks on download a kubeconfig file. Once this setting is deactivated, a generated kubeconfig will reference the [Rancher CLI](../cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl) to retrieve a short-lived token for the cluster. When this kubeconfig is used in a client, such as `kubectl`, the Rancher CLI needs to be installed to complete the log in request.
+1. Set the `kubeconfig-generate-token` setting to `false`. This setting instructs Rancher to no longer automatically generate a token when a user clicks on download a kubeconfig file. When this setting is deactivated, a generated kubeconfig references the [Rancher CLI](../cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl) to retrieve a short-lived token for the cluster. When this kubeconfig is used in a client, such as `kubectl`, the Rancher CLI needs to be installed to complete the log in request.

-2. Set the `kubeconfig-token-ttl-minutes` setting to the desired duration in minutes. By default, `kubeconfig-token-ttl-minutes` is 960 (16 hours).
+2. Set the `kubeconfig-token-ttl-minutes` setting to the desired duration in minutes. By default, `kubeconfig-token-ttl-minutes` is `960` (16 hours).

-### Token Hashing
+## Token Hashing

-Users can enable token hashing, where tokens will undergo a one-way hash using the SHA256 algorithm. This is a non-reversible process, once enabled, this feature cannot be disabled. It is advisable to take backups prior to enabling and/or evaluating in a test environment first.
+Users can enable token hashing, where tokens undergo a one-way hash using the SHA256 algorithm. This is a non-reversible process: once enabled, this feature cannot be disabled. It is advisable to take backups prior to enabling and/or evaluating in a test environment first.

 To enable token hashing, refer to [this section](../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md).

-This feature will affect all tokens which include, but are not limited to, the following:
+This feature affects all tokens which include, but are not limited to, the following:

 - Kubeconfig tokens
 - Bearer tokens API keys/calls
 - Tokens used by internal operations

-### Token Settings
+## Token Settings
+
 These global settings affect Rancher token behavior.

 | Setting                                                                         | Description                                                                                                                                                                                                                    |
 | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes)               | TTL in minutes on a user auth session token.                                                                                                                                                                                   |
-| [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except those [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). **Introduced in version 2.6.6.**                                                   |
-| [`kubeconfig-token-ttl-minutes`](#kubeconfig-token-ttl-minutes)                 | TTL used for tokens generated via the CLI.  **Deprecated since version 2.6.6, and will be removed in 2.8.0.** This setting will be removed, and `kubeconfig-default-token-TTL-minutes` will be used for all kubeconfig tokens. |
-| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes)                     | Max TTL for all tokens except those controlled by [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes).                                                                                                           |
+| [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except those [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). **Introduced in version 2.6.6.**                                                   |
+| [`kubeconfig-token-ttl-minutes`](#kubeconfig-token-ttl-minutes)                 | TTL used for tokens generated via the CLI.  **Deprecated since version 2.6.6, and removed in 2.8.0.** Rancher v2.8 and later instead use `kubeconfig-default-token-ttl-minutes` for all kubeconfig tokens. |
+| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes)                     | Max TTL for all tokens except those controlled by [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes). May override `kubeconfig-default-token-ttl-minutes`.                                                                                                          |
 | [`kubeconfig-generate-token`](#kubeconfig-generate-token)                       | If true, automatically generate tokens when a user downloads a kubeconfig.                                                                                                                                                     |

-#### auth-user-session-ttl-minutes
-Time to live (TTL) duration in minutes used to determine when a user auth session token expires. When expired, the user will be required to log in and obtain a new token. This setting is not affected by [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). Session tokens are created when a user logs into Rancher.
+### auth-user-session-ttl-minutes

-#### kubeconfig-default-token-TTL-minutes
-Time to live (TTL) duration in minutes used to determine when a kubeconfig token expires. When the token is expired, the API will reject the token. This setting can not be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). This setting applies to a token generated in a requested kubeconfig file. Except those [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs).
+Time to live (TTL) duration in minutes, used to determine when a user auth session token expires. When expired, the user must log in and obtain a new token. This setting is not affected by [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). Session tokens are created when a user logs into Rancher.
+
+### kubeconfig-default-token-ttl-minutes
+
+Time to live (TTL) duration in minutes, used to determine when a kubeconfig token expires. When the token is expired, the API rejects the token. This setting can't be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). This setting applies to tokens generated in a requested kubeconfig file, except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). The default value is `0`, which means that tokens never expire.
 **Introduced in version 2.6.6**.

-#### kubeconfig-token-ttl-minutes
-Time to live (TTL) duration in minutes used to determine when a kubeconfig token that was generated by the CLI expires. Tokens are generated by the CLI when [`kubeconfig-generate-token`](#kubeconfig-generate-token) is false. When the token is expired, the API will reject the token. This setting can not be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes).
-**Deprecated since version 2.6.6, and will be removed in 2.8.0: This setting will be replaced with the value of [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes).**
+### kubeconfig-token-ttl-minutes

-#### auth-token-max-ttl-minutes
-Maximum Time to Live (TTL) in minutes allowed for auth tokens. If a user attempts to create a token with a TTL greater than `auth-token-max-ttl-minutes`, Rancher will set the token TTL to the value of `auth-token-max-ttl-minutes`. Auth tokens are tokens created for authenticating API requests.
-**Changed in version 2.6.6: Applies to all kubeconfig tokens and api tokens.**
+Time to live (TTL) duration in minutes used to determine when a kubeconfig token that was generated by the CLI expires. Tokens are generated by the CLI when [`kubeconfig-generate-token`](#kubeconfig-generate-token) is false. When the token is expired, the API rejects the token. This setting can't be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes).
+**Deprecated since Rancher v2.6.6.**

-#### kubeconfig-generate-token
-When true, kubeconfigs requested through the UI will contain a valid token. When false, the kubeconfig will contain a command that uses the Rancher CLI to prompt the user to log in. [The CLI then will retrieve and cache a token for the user](../cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl).
+### auth-token-max-ttl-minutes
+
+Maximum Time to Live (TTL) in minutes allowed for auth tokens. If a user attempts to create a token with a TTL greater than `auth-token-max-ttl-minutes`, Rancher sets the token TTL to the value of `auth-token-max-ttl-minutes`. Applies to all kubeconfig tokens and API tokens. The default value is `0`, which means that tokens never expire.
+**Rancher v2.6.5 and earlier: Applies only to tokens created for authenticating API requests.**
+
+### kubeconfig-generate-token
+
+When true, kubeconfigs requested through the UI contain a valid token. When false, kubeconfigs contain a command that uses the Rancher CLI to prompt the user to log in. [The CLI then  retrieves and caches a token for the user](../cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl).
@@ -20,7 +20,8 @@ Each Rancher version is designed to be compatible with a single version of the w

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
-| v2.7.11         |     v0.3.7      | &check;               | N/A                   |
+| v2.7.12         |     v0.3.7      | &check;               | N/A                       |
+| v2.7.11         |     v0.3.7      | &check;               | N/A                       |
 | v2.7.10         |     v0.3.6      | &check;               | &check;                   |
 | v2.7.9          |     v0.3.6      | &cross;               | &check;                   |
 | v2.7.8          |     v0.3.6      | &cross;               | &check;                   |
@@ -160,7 +160,8 @@ helm repo update
 # Install the cert-manager Helm chart
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
-  --create-namespace
+  --create-namespace \
+  --set installCRDs=true
 ```

 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -53,7 +53,7 @@ A restore is performed by creating a Restore custom resource.
 1. In the left navigation bar, click **Rancher Backups > Restore**.
    :::note

-    If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps**. Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#charts) for more information.
+    If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps**. Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#access-charts) for more information.

    :::

@@ -6,7 +6,9 @@ title: Troubleshooting Certificates
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting"/>
 </head>

-### How Do I Know if My Certificates are in PEM Format?
+<DockerSupportWarning />
+
+## How Do I Know if My Certificates are in PEM Format?

 You can recognize the PEM format by the following traits:

@@ -48,7 +50,7 @@ VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
 -----END PRIVATE KEY-----
 ```

-### Converting a Certificate Key From PKCS8 to PKCS1
+## Converting a Certificate Key From PKCS8 to PKCS1

 If you are using a PKCS8 certificate key file, Rancher will log the following line:

@@ -64,7 +66,7 @@ openssl rsa -in key.pem -out convertedkey.pem

 You can now use `convertedkey.pem` as certificate key file for Rancher.

-### What is the Order of Certificates if I Want to Add My Intermediate(s)?
+## What is the Order of Certificates if I Want to Add My Intermediate(s)?

 The order of adding certificates is as follows:

@@ -77,7 +79,7 @@ The order of adding certificates is as follows:
 -----END CERTIFICATE-----
 ```

-### How Do I Validate My Certificate Chain?
+## How Do I Validate My Certificate Chain?

 You can validate the certificate chain by using the `openssl` binary. If the output of the command (see the command example below) ends with `Verify return code: 0 (ok)`, your certificate chain is valid. The `ca.pem` file must be the same as you added to the `rancher/rancher` container.

@@ -3,16 +3,12 @@ title: Installing Rancher on a Single Node Using Docker
 description: For development and testing environments only, use a Docker install. Install Docker on a single Linux host, and deploy Rancher with a single Docker container.
 ---

-:::caution
-
-Docker installs are not supported in production environments. These instructions are provided for testing and development purposes only. Please don't use this method to install Rancher in production environments.
-
-:::
-
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker"/>
 </head>

+<DockerSupportWarning />
+
 Rancher can be installed by running a single Docker container.

 In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container.
@@ -6,6 +6,8 @@ title: Rolling Back Rancher Installed with Docker
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher"/>
 </head>

+<DockerSupportWarning />
+
 If a Rancher upgrade does not complete successfully, you'll have to roll back to your Rancher setup that you were using before [Docker Upgrade](upgrade-docker-installed-rancher.md). Rolling back restores:

 - Your previous version of Rancher.
@@ -8,11 +8,7 @@ title: Upgrading Rancher Installed with Docker

 The following instructions will guide you through upgrading a Rancher server that was installed with Docker.

-:::caution
-
-**Docker installs are not supported in production environments.** These instructions are provided for testing and development purposes only. If you have already deployed a Docker install in production and need to upgrade to a new Rancher version, we recommend [migrating to the Helm chart install](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) before upgrading.
-
-:::
+<DockerSupportWarning />

 ## Prerequisites

@@ -52,8 +52,6 @@ When you need to make changes to your infrastructure, instead of manually updati

 - You can reverse engineer how to do define a setting in Terraform by changing the setting in Rancher, then going back and checking your Terraform state file to see how it maps to the current state of your infrastructure.

- If you want to manage Kubernetes cluster settings, Rancher settings, and hardware settings all in one place, use [Terraform modules](https://github.com/rancher/terraform-modules). You can pass a cluster configuration YAML file or an RKE template configuration file to a Terraform module so that the Terraform module will create it. In that case, you could use your infrastructure-as-code to manage the version control and revision history of both your Kubernetes cluster and its underlying hardware.
-
 ## Tip for Creating CIS Benchmark Compliant Clusters

 This section describes one way that you can make security and compliance-related config files standard in your clusters.
@@ -1,20 +1,48 @@
 ---
-title: Helm Charts in Rancher
+title: Helm Charts and Apps
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher"/>
 </head>

-In this section, you'll learn how to manage Helm chart repositories and applications in Rancher. Helm chart repositories are managed using **Apps**. It uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Helm applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.
+In this section, you'll learn how to manage Helm chart repositories and apps in Rancher. 
+
+## How Helm Charts Work in Rancher
+
+Helm chart repositories in Rancher are managed using **Apps**.
+
+Rancher uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Kubernetes applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.
+
+### Catalogs, Apps, and the Rancher UI
+
+[Rancher v2.4 and earlier](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI. 
+
+Rancher v2.5 replaced the former catalog system with a new **Apps & Marketplace** feature. 
+
+Since Rancher v2.6.5, the **Apps & Marketplace** feature is named **Apps** in the UI.

 ### Versioning Scheme

 The Rancher feature charts versioning scheme is centered around the major version of the charts and the `+up` annotation for upstream charts, where applicable.

-**Major Version:** The major version of the charts is tied to Rancher minor versions. When you upgrade to a new Rancher minor version, you should ensure that all of your **Apps** charts are also upgraded to the correct release line for the chart.
+**Major Version:** The major versions of feature charts are tied to particular minor versions of Rancher. When you upgrade to a new Rancher minor version, you should ensure that all of your feature charts are also upgraded to the correct release line for the chart.

-**Feature Charts:**
+**Charts based on upstream:** When you upgrade, make sure that the upstream chart version is compatible with your Rancher version. The `+up` annotation for the chart indicates which upstream version the Rancher chart is tracking. For example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some additional Rancher patches.
+
+When upgrading Rancher versions, don't downgrade the version of the chart that you are using. For example, if you are using a version of Monitoring that is later than `16.6.0` in Rancher v2.5, you shouldn't upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.
+
+#### Prerelease Versions
+
+Prereleases adhere to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` is considered a prerelease. Prerelease versions are not displayed by default and must be configured to do so.
+
+To display prerelease versions:
+
+1. Click on your user avatar in the upper right corner.
+1. Click **Preferences**.
+1. Under **Helm Charts**, select **Include Prerelease Versions**.
+
+### Feature Charts

 | **Name** | **Supported Minimum Version** | **Supported Maximum Version** |
 | ---------------- | ------------ | ------------ |
@@ -35,73 +63,81 @@ The Rancher feature charts versioning scheme is centered around the major versio
 | rancher-vsphere-csi | 100.3.0+up2.5.1-rancher1 | 100.3.0+up2.5.1-rancher1 |
 | rancher-wins-upgrader | 0.0.100 | 100.0.1+up0.0.1 |

-<br/>
-**Charts based on upstream:** For charts that are based on upstreams, the +up annotation should inform you of what upstream version the Rancher chart is tracking. Check the upstream version compatibility with Rancher during upgrades also.
+## Access Charts

- As an example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some Rancher patches added to it.
+The **Charts** page contains all Rancher, Partner, and Custom charts. You can filter charts by selecting the left-most dropdown menu:

- On upgrades, ensure that you are not downgrading the version of the chart that you are using. For example, if you are using a version of Monitoring > `16.6.0` in Rancher 2.5, you should not upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.
+* Rancher tools such as Logging or Monitoring are listed under the **Rancher** label.
+* Partner charts are under the **Partners** label.
+* Custom charts are listed under the name of their respective repository.

-### Prerelease Versions
-
-Prereleases adhere to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` is considered a prerelease. Prerelease versions are not displayed by default and must be configured to do so.
-
-To display prerelease versions:
-
-1. Click on your user avatar in the upper right corner.
-1. Click **Preferences**.
-1. Under **Helm Charts**, select **Include Prerelease Versions**.
-
-### Charts
-
-From the top-left menu select _"Apps"_ and you will be taken to the Charts page.
-
-The charts page contains all Rancher, Partner, and Custom Charts.
-
-* Rancher tools such as Logging or Monitoring are included under the Rancher label
-* Partner charts reside under the Partners label
-* Custom charts will show up under the name of the repository
-
-All three types are deployed and managed in the same way.
+All three types of charts are deployed and managed in the same way.

 :::note

-Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) should continue to be managed only by the Cluster Manager, and apps managed with <b>Apps</b> in the new UI must be managed only by <b>Apps</b>.
+Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) continue to be managed only by the Cluster Manager, and apps managed with **Apps** in the new UI must be managed only by **Apps**.

 :::

-### Repositories
+To access the **Charts** page:

-From the left sidebar select _"Repositories"_.
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose charts you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.

-These items represent Helm repositories, and can be either traditional Helm endpoints which have an index.yaml, or Git repositories which will be cloned and can point to a specific branch. In order to use custom charts, simply add your repository here and they will become available in the Charts tab under the name of the repository.
+## Manage Repositories

-#### Add Custom Git Repositories
+The **Repositories** page lists your Helm repositories. These include traditional Helm endpoints which have an index.yaml, and Git repositories that are cloned and point to a specific branch. To use custom charts, add your repository here. After you add a repository, you can access custom charts in the **Charts** page, listed under the name of the repository.

-Click **Create** and select the target, **Git repository containing Helm chart...** to add a custom Git repository that contains your Helm charts or cluster template definitions.
+To access the **Repositories** page:

-You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from the default, `main`.
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.

-Whenever you add a chart repository to Rancher, it becomes available immediately.
+### Add Custom Git Repositories

-#### Add Custom Helm Chart Repositories
+To add a custom Git repository that contains your Helm charts or cluster template definitions:
+
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
+1. Click **Create**.
+1. Select the target, **Git repository containing Helm chart...**.
+1. You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from whichever branch the repo owner has set as the default. Usually, the default branch is named either `main` or `master`.
+1. Click **Create** to add the repository. 
+
+After you add a chart repository to Rancher, it becomes available immediately.
+
+### Add Custom Helm Chart Repositories

 You can add your own Helm chart repositories to serve chart packages to Rancher. You can use any HTTP server, as long as the server can respond to GET requests and serve YAML files and tar archives.

 For more information on Helm chart repositories, see the [official Helm docs](https://helm.sh/docs/topics/chart_repository/).

-To add a custom Helm chart repository to Rancher, click **Create** and select **http(s) URL to an index generated by Helm** as the target. Enter a repo name and the index URL address of the chart repository.
+To add a custom Helm chart repository to Rancher:

-#### Add Private Git/Helm Chart Repositories
+1. Click **☰**. Under **Explore Cluster** in the left navigation menu, select a cluster.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
+1. Click **Create**.
+1. Select the target, **http(s) URL to an index generated by Helm**.
+1. Enter a repo name and the index URL address of the chart repository.
+1. Click **Create** to add the repository. 
+
+### Add Private Git/Helm Chart Repositories

 You can add private Git or Helm chart repositories with SSH key credentials or an HTTP basic auth secret, such as a username and password.

-#### Add a Private CA to Repositories
+### Add a Private CA to Repositories

-To add a private CA to Helm chart repositories:
+To add a private CA to Helm chart repositories, you must add a base64 encoded copy of the CA certificate in DER format to the `spec.caBundle field` of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Instructions are the same for both Git-based and HTTP-based repositories:

- **HTTP-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
-    ```
+1. Click **☰**. Under **Explore Cluster** in the left navigation menu, select a cluster.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
+1. Find the row associated with the Git or HTTP-based repository you want to add a private CA to, and click **⋮ > Edit YAML**.
+1. Set the `caBundle` value, as in the following example:
+
+  ```yaml
    [...]
    spec:
      caBundle:
@@ -109,25 +145,13 @@ To add a private CA to Helm chart repositories:
    ...
    nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
    [...]
-    ```
-
-
- **Git-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
-    ```
-    [...]
-    spec:
-      caBundle:
-    MIIFXzCCA0egAwIBAgIUWNy8WrvSkgNzV0zdWRP79j9cVcEwDQYJKoZIhvcNAQELBQAwPzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYDVQQKDAtNeU9yZywgSW5jLjENMAsGA1UEAwwEcm9vdDAeFw0yMTEyMTQwODMyMTdaFw0yNDEwMDMwODMyMT
-    ...
-    nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
-    [...]
-    ```
+  ```

 :::note Helm chart repositories with authentication

-The Repo.Spec contains a `disableSameOriginCheck` value that allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
+The Repo.Spec contains a `disableSameOriginCheck` value. This value allows you to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories, such as those that have redirects to a different origin URL.

-To use this feature for an existing Helm chart repository, click <b>⋮ > Edit YAML</b>. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
+To use this feature for an existing Helm chart repository, follow previous steps up to edit the YAML. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.

 ```yaml
 [...]
@@ -142,37 +166,51 @@ spec:

 Only Helm 3 compatible charts are supported.

+## Deploy and Upgrade Charts

-### Deployment and Upgrades
+To install and deploy a chart:

-From the _"Charts"_ tab select a Chart to install. Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files, but all chart installations can modify the values.yaml and other basic settings. Once you click install, a Helm operation job is deployed, and the console for the job is displayed.
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose charts you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
+1. Select a chart, and click **Install**. 

-To view all recent changes, go to the _"Recent Operations"_ tab. From there you can view the call that was made, conditions, events, and logs.
+Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files. However, all chart installations can modify the values.yaml and other basic settings. After you click **Install**, a Helm operation job is deployed, and the console for the job is displayed.

-After installing a chart, you can find it in the _"Installed Apps"_ tab. In this section you can upgrade or delete the installation, and see further details. When choosing to upgrade, the form and values presented will be the same as installation.
+To view all recent changes, click **Apps > Recent Operations** in the left navigation menu. From there you can view the calls, conditions, events, and logs.

-Most Rancher tools have additional pages located in the toolbar below the _"Apps"_ section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.
+After installing a chart, you can view it by clicking **Apps > Installed Apps** in the left navigation menu. You can upgrade or delete the installation, and see further details. Upgrading uses the same forms and values as you saw during inital installation. 
+
+Most Rancher tools have additional pages located in the toolbar below the **Apps** section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.

 :::caution

-If you are upgrading your chart using _"Customize Helm options before upgrade"_ , please be aware that using the _"--force"_ option may result in errors if your chart has immutable fields. This is because some objects in Kubernetes cannot be changed once they are created. To ensure you do not get this error you can:
+If you are upgrading your chart using **Customize Helm options before upgrade**, and your chart contains immutable fields, using the `--force` option may result in errors. This is because some objects in Kubernetes can't be changed after they're created. To prevent this error:

-  * use the default upgrade option ( i.e do not use _"--force"_ option )
-  * uninstall the existing chart and install the upgraded chart
-  * delete the resources with immutable fields from the cluster before performing the _"--force"_ upgrade
+  * Use the default upgrade option (i.e don't use `--force`).
+  * Uninstall the existing chart and install the upgraded chart.
+  * Delete the resources with immutable fields from the cluster before performing a forced upgrade.

 :::

-#### Legacy Apps
+### Legacy Apps

-The upgrade button has been removed for legacy apps from the **Apps > Installed Apps** page.
+The upgrade button isn't available for legacy apps on the **Apps > Installed Apps** page.

-If you have a legacy app installed and want to upgrade it:
+If you want to upgrade an installed legacy app, the [legacy feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on. This flag is automatically turned on if you had a legacy app already running before you upgraded Rancher.

- The legacy [feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on (if it's not turned on automatically because of having a legacy app before upgrading)
- You can upgrade the app from cluster explorer, from the left nav section **Legacy > Project > Apps**
- For multi-cluster apps, you can go to **≡ > Multi-cluster Apps** and upgrade the app from there
+1. Enable the [legacy feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md), if it isn't enabled already.
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose apps you want to access. Click **Explore** at the end of the cluster's row.
+1. Click **Legacy > Project > Apps**.

-### Limitations
+If you don't see **Apps** listed under **Legacy > Project**, click the project/namespace search bar in the top navigation and select the relevant project from the dropdown menu.

-Dashboard apps or Rancher feature charts **cannot** be installed using the Rancher CLI.
+To upgrade legacy multi-cluster apps:
+
+1. Click **☰**. 
+1. Under **Legacy Apps**, click **Multi-cluster Apps**.
+
+## Limitations
+
+Dashboard apps or Rancher feature charts can't be installed using the Rancher CLI.
@@ -6,9 +6,9 @@ title: Migrating Amazon In-tree to Out-of-tree
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-amazon"/>
 </head>

-Kubernetes is moving away from maintaining cloud providers in-tree. In Kubernetes 1.27 and later, the in-tree cloud providers have been removed.
+Kubernetes is moving away from maintaining cloud providers in-tree. In Kubernetes v1.27 and later, the in-tree cloud providers have been removed. The Rancher UI allows you to upgrade to Kubernetes v1.27 when you migrate from an in-tree to out-of-tree provider. 

-You can migrate from an in-tree to an out-of-tree AWS cloud provider on Kubernetes 1.26 and earlier. All existing clusters must migrate prior to upgrading to v1.27 in order to stay functional.
+However, if you're performing a manual migration, existing clusters must upgrade to Kubernetes v1.27 after you migrate in order to remain functional.

 To migrate from the in-tree cloud provider to the out-of-tree AWS cloud provider, you must stop the existing cluster's kube controller manager and install the AWS cloud controller manager. There are many ways to do this. Refer to the official AWS documentation on the [external cloud controller manager](https://cloud-provider-aws.sigs.k8s.io/getting_started/) for details.

@@ -52,7 +52,7 @@ spec:
 2. Cordon control plane nodes so that AWS cloud controller pods run on nodes only after upgrading to the external cloud provider:

 ```shell
-kubectl cordon -l "node-role.kubernetes.io/controlplane=true"
+kubectl cordon -l "node-role.kubernetes.io/control-plane=true"
 ```

 3. To install the AWS cloud controller manager with leader migration enabled, follow Steps 1-3 for [deploying the cloud controller manager chart](../set-up-cloud-providers/amazon.md#using-the-out-of-tree-aws-cloud-provider). From Kubernetes 1.22 onwards, the kube-controller-manager will utilize a default configuration which will satisfy the controller-to-manager migration. Update container args of the `aws-cloud-controller-manager` under `spec.rkeConfig.additionalManifest` to enable leader migration:
@@ -352,9 +352,9 @@ tolerations:
    value: 'true'
  - effect: NoSchedule
    value: 'true'
-    key: node-role.kubernetes.io/controlplane
+    key: node-role.kubernetes.io/control-plane
 nodeSelector:
-  node-role.kubernetes.io/controlplane: 'true'
+  node-role.kubernetes.io/control-plane: 'true'
 args:
  - --configure-cloud-routes=false
  - --use-service-account-credentials=true
@@ -639,7 +639,7 @@ kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
      - get
 ```

-9. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector:
+9. Rancher-provisioned RKE2 nodes are tainted `node-role.kubernetes.io/control-plane`. Update tolerations and the nodeSelector:

 ```yaml
 tolerations:
@@ -648,13 +648,13 @@ tolerations:
    value: 'true'
  - effect: NoSchedule
    value: 'true'
-    key: node-role.kubernetes.io/controlplane
+    key: node-role.kubernetes.io/control-plane

 ```

 ```yaml
 nodeSelector:
-  node-role.kubernetes.io/controlplane: 'true'
+  node-role.kubernetes.io/control-plane: 'true'
 ```

 :::note
@@ -663,7 +663,7 @@ There's currently a [known issue](https://github.com/rancher/dashboard/issues/92

 ```yaml
 nodeSelector:
-  node-role.kubernetes.io/controlplane: 'true'
+  node-role.kubernetes.io/control-plane: 'true'
 ```

 :::
@@ -18,7 +18,7 @@ In clusters that store data on GlusterFS volumes, you may experience an issue wh
 - The `systemd-run` binary needs to be compatible with Debian OS on which the hyperkube image is based (this can be checked using the following command on each cluster node, replacing the image tag with the Kubernetes version you want to use)

 ```
-docker run -v /usr/bin/systemd-run:/usr/bin/systemd-run --entrypoint /usr/bin/systemd-run rancher/hyperkube:v1.16.2-rancher1 --version
+docker run -v /usr/bin/systemd-run:/usr/bin/systemd-run -v /usr/lib/x86_64-linux-gnu/libcrypto.so.3:/usr/lib/x86_64-linux-gnu/libcrypto.so.3 -v /lib/systemd/libsystemd-shared-249.so:/lib/systemd/libsystemd-shared-249.so --entrypoint /usr/bin/systemd-run rancher/hyperkube:v1.26.14-rancher1 --version
 ```

 :::caution
@@ -32,6 +32,8 @@ services:
  kubelet:
    extra_binds:
      - "/usr/bin/systemd-run:/usr/bin/systemd-run"
+      - "/usr/lib/x86_64-linux-gnu/libcrypto.so.3:/usr/lib/x86_64-linux-gnu/libcrypto.so.3"
+      - "/lib/systemd/libsystemd-shared-249.so:/lib/systemd/libsystemd-shared-249.so"
 ```

 After the cluster has finished provisioning, you can check the `kubelet` container logging to see if the functionality is activated by looking for the following logline:
@@ -20,6 +20,9 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
 | Rancher Version | Adapter Version  |
 |-----------------|:----------------:|
 | v2.8.0          | v103.0.0+up3.0.0 |
+| v2.8.1          | v103.0.0+up3.0.0 |
+| v2.8.2          | v103.0.0+up3.0.0 |
+| v2.8.3          | v103.0.1+up3.0.1 |

 ### 1. Gain Access to the Local Cluster

@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
+| v2.8.3          |     v0.4.3      | &cross;               | &check;                   |
 | v2.8.2          |     v0.4.2      | &check;               | &check;                   |
 | v2.8.1          |     v0.4.2      | &check;               | &check;                   |
 | v2.8.0          |     v0.4.2      | &cross;               | &check;                   |
@@ -74,10 +74,15 @@ kubectl -n ingress-nginx logs -l app=ingress-nginx

 ### Leader election

-The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` ConfigMap (in this example, `rancher-7dbd7875f7-qbj5k`).
+The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` Lease in the `kube-system` namespace (in this example, `rancher-dbc7ff869-gvg6k`).

 ```
-kubectl -n kube-system get configmap cattle-controllers -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
-{"holderIdentity":"rancher-7dbd7875f7-qbj5k","leaseDurationSeconds":45,"acquireTime":"2019-04-04T11:53:12Z","renewTime":"2019-04-04T12:24:08Z","leaderTransitions":0}
+kubectl -n kube-system get lease cattle-controllers
 ```

+Example output:
+
+```
+NAME                 HOLDER                    AGE
+cattle-controllers   rancher-dbc7ff869-gvg6k   6h10m
+```