Merge pull request #2371 from pmkovar/CNAME

Retire the site/repo
Retire the site
2026-09-29 06:29:34 +00:00 · 2026-07-20 18:37:26 +02:00 · 2026-07-20 18:07:17 +02:00 · 2026-07-08 14:07:22 -07:00 · 2026-07-08 13:32:14 -07:00 · 2026-07-08 13:25:18 -07:00
9521 changed files with 477720 additions and 314339 deletions
@@ -0,0 +1 @@
+blank_issues_enabled: false
@@ -4,12 +4,22 @@ about: Track tasks that need to be done every release.
 title: '<VERSION> - Rancher Manager Release Maintenance Task Checklist'
 ---

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

+- [ ] Create a new branch for the release. Release-specific updates should use this branch as its base
 - [ ] Update the [versions table](https://ranchermanager.docs.rancher.com/versions)
 - [ ] Update the [Rancher:webhook version mapping table](https://ranchermanager.docs.rancher.com/reference-guides/rancher-webhook)
 - [ ] Update the [CNI popularity table](https://ranchermanager.docs.rancher.com/faq/container-network-interface-providers#cni-community-popularity)
- [ ] Update the [CSP adapter compatibility matrix](https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter#rancher-vs-adapter-compatibility-matrix):
- [ ] Update the [deprecated features table](https://ranchermanager.docs.rancher.com/faq/deprecated-features):
+- [ ] Update the [CSP adapter compatibility matrix](https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter#rancher-vs-adapter-compatibility-matrix)
+- [ ] Update the [deprecated features table](https://ranchermanager.docs.rancher.com/faq/deprecated-features)
+- [ ] Update the swagger-<VERSION>.json file
+- [ ] Create a PR merging the release branch back into the main branch
 - [ ] Create a new [release](https://github.com/rancher/rancher-docs/releases)
 - [ ] Update Algolia search index
@@ -3,6 +3,13 @@ name: Request a New Feature
 about: For requesting new feature(s) to be added to the docs.
 ---

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

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

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

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

 ## Reminders
@@ -1,31 +0,0 @@
-name: Create issue to track porting between Community and Product docs
-
-on:
-  pull_request_target:
-    types:
-      - closed
-    branches: 
-      - main
-    paths-ignore:
-      - '**/README.md'
-
-permissions:
-  issues: write
-  pull-requests: read
-
-jobs:
-  create_issue:
-    if: github.event.pull_request.merged == true && contains( github.event.pull_request.labels.*.name, 'port/community-product')
-    runs-on: ubuntu-latest
-    steps:
-    - name: Create issue
-      env:
-        GH_TOKEN: ${{ github.token }}
-        REPO_TYPE: ${{ contains( github.repository, 'product-docs') && 'Product' || 'Community' }}
-        PR_TITLE: ${{ github.event.pull_request.title }}
-      run: |
-        gh issue create \
-          --repo ${{ github.repository }} \
-          --title "Port $REPO_TYPE docs PR #${{ github.event.pull_request.number }}: $PR_TITLE" \
-          --body "Reference: https://github.com/${{ github.repository }}/pull/${{ github.event.pull_request.number }}" \
-          --label port/community-product
@@ -1,52 +0,0 @@
-name: Deploy to GitHub Pages
-
-on:
-  push:
-    branches:
-      - main
-    paths-ignore:
-      - '**/README.md'
-      - '**/.github/ISSUE_TEMPLATE/**'
-
-jobs:
-  build:
-    name: Build Docusaurus
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 18
-          cache: yarn
-
-      - name: Install dependencies
-        run: yarn install --frozen-lockfile
-      - name: Build website
-        env:
-          NODE_OPTIONS: "--max_old_space_size=7168"
-        run: yarn build --no-minify
-
-      - name: Upload Build Artifact
-        uses: actions/upload-pages-artifact@v3
-        with:
-          path: build
-
-  deploy:
-    name: Deploy to GitHub Pages
-    needs: build
-
-    permissions:
-      pages: write
-      id-token: write
-    
-    environment:
-      name: github-pages
-      url: ${{ steps.deployment.outputs.page_url }}
-
-    runs-on: ubuntu-latest
-    steps:
-      - name: Deploy to GitHub Pages
-        id: deployment
-        uses: actions/deploy-pages@v4
@@ -11,10 +11,10 @@ jobs:
    name: Test deployment
    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
        with:
          fetch-depth: 0
-      - uses: actions/setup-node@v4
+      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4
        with:
          node-version: 18
          cache: yarn
@@ -27,5 +27,5 @@ jobs:
        run: yarn run remark --quiet --use remark-lint-no-dead-urls ./docs
      - name: Test build website
        env:
-          NODE_OPTIONS: "--max_old_space_size=7168"
-        run: yarn build --no-minify
+          NODE_OPTIONS: "--max_old_space_size=10240"
+        run: yarn build --no-minify
@@ -1 +1 @@
-* @btat @LucasSaintarbor @sunilarjun
+* @btat @LucasSaintarbor @pmkovar @sunilarjun
@@ -1,5 +1,12 @@
 # Contribute to Rancher Docs

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

 ## Make a Suggestion
@@ -15,7 +22,7 @@ To get started, [fork](https://github.com/rancher/rancher-docs/fork) and clone t

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

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

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

@@ -93,7 +100,7 @@ Subsequent executions will check for updated dependencies, if there are none, it

 License
 =======
-Copyright (c) 2014-2025 [SUSE, LLC.](https://www.suse.com/)
+Copyright (c) 2014-2026 [SUSE, LLC.](https://www.suse.com/)

 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.
@@ -41,7 +41,7 @@ Prometheus RemoteRead and RemoteWrite can be configured as custom answers in the

 For more information on remote endpoints and storage, refer to the [Prometheus documentation.](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage)

-The Prometheus operator documentation contains the full [RemoteReadSpec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#remotereadspec) and [RemoteWriteSpec.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#remotewritespec)
+The Prometheus operator documentation contains the full [RemoteReadSpec](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#remotereadspec) and [RemoteWriteSpec.](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#remotewritespec)

 An example configuration would be:

@@ -155,15 +155,32 @@ You may terminate the SSL/TLS on a L7 load balancer external to the Rancher clus

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

-#### Configuring Ingress for External TLS when Using NGINX v0.25
+### Configuring Ingress for External TLS when Using NGINX v0.22

-In NGINX v0.25, the behavior of NGINX has [changed](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md#0220) regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.25, you must edit the `cluster.yml` to enable the `use-forwarded-headers` option for ingress:
+In NGINX v0.22, the behavior of NGINX has [changed](https://github.com/kubernetes/ingress-nginx/blob/06efac9f0b6f8f84b553f58ccecf79dc42c75cc6/Changelog.md) regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.22, you must enable the `use-forwarded-headers` option for ingress:

+For RKE installations, edit the `cluster.yml` to add the following settings.
 ```yaml
 ingress:
  provider: nginx
  options:
-    use-forwarded-headers: "true"
+    use-forwarded-headers: 'true'
+```
+
+For RKE2 installations, you can create a custom `rke2-ingress-nginx-config.yaml` file at `/var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml` containing this required setting to enable using forwarded headers with external TLS termination. Without this required setting applied, the external LB will continuously respond with redirect loops it receives from the ingress controller. (This can be created before or after rancher is installed, rke2 server agent will notice this addition and automatically apply it.)
+
+```yaml
+---
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata:
+  name: rke2-ingress-nginx
+  namespace: kube-system
+spec:
+  valuesContent: |-
+    controller:
+      config:
+        use-forwarded-headers: "true"
 ```

 #### Required Headers
@@ -41,7 +41,7 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..

 The upgrade instructions assume you are using Helm 3.

-For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](helm2.md) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.

 ### For air gap installs: Populate private registry

@@ -16,12 +16,13 @@ The following steps quickly deploy a Rancher Server with a single node cluster a
 - [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
 - At least 4GB of free RAM.

-### Note
- Vagrant will require plugins to create VirtualBox VMs. Install them with the following commands:
+:::note 

-  `vagrant plugin install vagrant-vboxmanage`
+Vagrant requires plugins to create VirtualBox VMs. Install them with the following commands: 
+- `vagrant plugin install vagrant-vboxmanage` 
+- `vagrant plugin install vagrant-vbguest` 

-  `vagrant plugin install vagrant-vbguest`
+:::

 ## Getting Started

@@ -111,7 +111,7 @@ If you are experiencing issues while testing the connection to the Keycloak serv
 When you click on **Authenticate with Keycloak**, your are not redirected to your IdP.

  * Verify your Keycloak client configuration.
-  * Make sure `Force Post Binding` set to `OFF`.
+  * Make sure `Force Post Binding` is set to `OFF`.


 ### Forbidden message displayed after IdP login
@@ -10,7 +10,7 @@ After installation, the [system administrator](manage-role-based-access-control-

 ## First Log In

-After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**.You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.
+After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**. You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.

 >**Important!** After you set the Rancher Server URL, we do not support updating it. Set the URL with extreme care.

@@ -38,7 +38,7 @@ These methods of communicating with downstream Kubernetes clusters are also expl

 ### About the kube-api-auth Authentication Webhook

-The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint,](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) which is only available for [RKE clusters.](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.
+The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) which is only available for [RKE clusters.](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.

 During cluster provisioning, the file `/etc/kubernetes/kube-api-authn-webhook.yaml` is deployed and `kube-apiserver` is configured with `--authentication-token-webhook-config-file=/etc/kubernetes/kube-api-authn-webhook.yaml`. This configures the `kube-apiserver` to query `http://127.0.0.1:6440/v1/authenticate` to determine authentication for bearer tokens.

@@ -0,0 +1,18 @@
+---
+title: API Reference
+hide_table_of_contents: true
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-reference"/>
+</head>
+
+:::note
+
+At this time, not all Rancher resources are available through the Rancher Kubernetes API.
+
+:::
+
+import ApiDocMdx from '@theme/ApiDocMdx';
+
+<ApiDocMdx id="rancher-api-v2-10" />
@@ -0,0 +1,219 @@
+---
+title: Projects
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/workflows/projects"/>
+</head>
+
+## Creating a Project
+
+Project resources may only be created on the management cluster. See below for [creating namespaces under projects in a managed cluster](#creating-a-namespace-in-a-project).
+
+### Creating a Basic Project
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+EOF
+```
+
+When creating a new project, you have two primary options for setting the name:
+
+- **Automatic Generation:** Use `metadata.generateName` to ensure a unique project ID. However, note that you must use `kubectl create` (instead of `kubectl apply`) with this option, as `kubectl apply` does not support it.
+- **Manual Naming:** You can explicitly set the project ID using `metadata.name`. If a project with that exact name already exists, the name request is denied.
+The display name seen in the UI is set by `spec.displayName`. If `spec.displayName` is not provided, the field `metadata.name` is used instead.
+
+Set `metadata.namespace` and `spec.clusterName` to the ID for the cluster the project belongs to.
+
+If you create a project through a cluster member account and want that account to be able to access the project, you must include the annotation `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  annotations: 
+    field.cattle.io/creatorId: user-id
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+EOF
+```
+
+Setting the `field.cattle.io/creatorId` field creates a `ProjectRoleTemplateBinding` that grants the specified user the ability to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
+
+Setting the  `field.cattle.io/creator-principal-name` annotation to the user's principal preserves it in a projectroletemplatebinding automatically created for the project owner.
+
+If you don't want the creator to be added as the owner member (e.g. if the creator is a cluster administrator) to the project you may set the `field.cattle.io/no-creator-rbac` annotation to `true`, which will prevent the corresponding projectroletemplatebinding from being created.
+
+### Creating a Project With a Resource Quota
+
+Refer to [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/).
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+  resourceQuota:
+    limit:
+      limitsCpu: 1000m
+  namespaceDefaultResourceQuota:
+    limit:
+      limitsCpu: 50m
+EOF
+```
+
+### Creating a Project With Container Limit Ranges
+
+Refer to [Kubernetes Limit Ranges](https://kubernetes.io/docs/concepts/policy/limit-range/).
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+  containerDefaultResourceLimit:
+    limitsCpu:    100m
+    limitsMemory: 100Mi
+    requestsCpu:  50m
+    requestsMemory: 50Mi
+EOF
+```
+
+### Backing Namespace
+
+After creating the project, the field `status.backingNamespace` gets populated. This represents the namespace in the management cluster that is created to manage project related resources. Examples of resources stored in the backing namespace are [project scoped secrets](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md#creating-secrets-in-projects) and [project role template bindings](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles).
+
+## Adding a Member to a Project
+
+Look up the project's [backing namespace](#backing-namespace) to specify the `metadata.namespace` field value and look up the project's ID to specify the `projectName` field value.
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+Look up the role template ID to specify the `roleTemplateName` field value (e.g. `project-member` or `project-owner`).
+
+```bash
+kubectl get roletemplates
+```
+
+When adding a user member specify the `userPrincipalName` field:
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: ProjectRoleTemplateBinding
+metadata:
+  generateName: prtb-
+  namespace: c-m-abcde-p-vwxyz
+projectName: c-m-abcde:p-vwxyz
+roleTemplateName: project-member
+userPrincipalName: keycloak_user://user
+EOF
+```
+
+When adding a group member specify the `groupPrincipalName` field instead:
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: ProjectRoleTemplateBinding
+metadata:
+  generateName: prtb-
+  namespace: p-vwxyz
+projectName: c-m-abcde:p-vwxyz
+roleTemplateName: project-member
+groupPrincipalName: keycloak_group://group
+EOF
+```
+
+Create a projectroletemplatebinding for each role you want to assign to the project member.
+
+## Listing Project Members
+
+Look up the project backing namespace:
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+To list projectroletemplatebindings in the project's backing namespace:
+
+```bash
+kubectl --namespace c-m-abcde-p-vwxyz get projectroletemplatebindings
+```
+
+## Deleting a Member From a Project
+
+Lookup the projectroletemplatebinding IDs containing the member in the project's namespace as decribed in the [Listing Project Members](#listing-project-members) section.
+
+Delete the projectroletemplatebinding from the project's namespace:
+
+```bash
+kubectl --namespace c-m-abcde-p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
+```
+
+## Creating a Namespace in a Project
+
+The Project resource resides in the management cluster, even if the Project is for a managed cluster. The namespaces under the project reside in the managed cluster.
+
+On the management cluster, look up the project ID for the cluster you are administrating if generated using `metadata.generateName`:
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+On the managed cluster, create a namespace with a project annotation:
+
+```bash
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: mynamespace
+  annotations:
+    field.cattle.io/projectId: c-m-abcde:p-vwxyz
+EOF
+```
+
+Note the format, `<cluster ID>:<project ID>`.
+
+## Deleting a Project
+
+Look up the project to delete in the cluster namespace:
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+Delete the project under the cluster namespace:
+
+```bash
+kubectl --namespace c-m-abcde delete project p-vwxyz
+```
+
+Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
+
+It does delete all project role template bindings for the projects, so recreating the project will not restore members added to the project, and you have to add users as members again.
@@ -0,0 +1,199 @@
+---
+title: Container Network Interface (CNI) Providers
+description: Learn about Container Network Interface (CNI), the CNI providers Rancher provides, the features they offer, and how to choose a provider for you
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/container-network-interface-providers"/>
+</head>
+
+## What is CNI?
+
+CNI (Container Network Interface), a [Cloud Native Computing Foundation project](https://cncf.io/), consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of  plugins. CNI concerns itself only with network connectivity of containers and removing allocated resources when the container is deleted.
+
+Kubernetes uses CNI as an interface between network providers and Kubernetes pod networking.
+
+![CNI Logo](/img/cni-logo.png)
+
+For more information visit [CNI GitHub project](https://github.com/containernetworking/cni).
+
+## What Network Models are Used in CNI?
+
+CNI network providers implement their network fabric using either an encapsulated network model such as Virtual Extensible Lan ([VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan)) or an unencapsulated network model such as Border Gateway Protocol ([BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)).
+
+### What is an Encapsulated Network?
+
+This network model provides a logical Layer 2 (L2) network encapsulated over the existing Layer 3 (L3) network topology that spans the Kubernetes cluster nodes. With this model you have an isolated L2 network for containers without needing routing distribution, all at the cost of minimal overhead in terms of processing and increased IP package size, which comes from an IP header generated by overlay encapsulation. Encapsulation information is distributed by UDP ports between Kubernetes workers, interchanging network control plane information about how MAC addresses can be reached. Common encapsulation used in this kind of network model is VXLAN, Internet Protocol Security (IPSec), and IP-in-IP.
+
+In simple terms, this network model generates a kind of network bridge extended between Kubernetes workers, where pods are connected.
+
+This network model is used when an extended L2 bridge is preferred. This network model is sensitive to L3 network latencies of the Kubernetes workers. If datacenters are in distinct geolocations, be sure to have low latencies between them to avoid eventual network segmentation.
+
+CNI network providers using this network model include Flannel, Canal, Weave, and Cilium. By default, Calico is not using this model, but it can be configured to do so.
+
+![Encapsulated Network](/img/encapsulated-network.png)
+
+### What is an Unencapsulated Network?
+
+This network model provides an L3 network to route packets between containers. This model doesn't generate an isolated l2 network, nor generates overhead. These benefits come at the cost of Kubernetes workers having to manage any route distribution that's needed. Instead of using IP headers for encapsulation, this network model uses a network protocol between Kubernetes workers to distribute routing information to reach pods, such as [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol).
+
+In simple terms, this network model generates a kind of network router extended between Kubernetes workers, which provides information about how to reach pods.
+
+This network model is used when a routed L3 network is preferred. This mode dynamically updates routes at the OS level for Kubernetes workers. It's less sensitive to latency.
+
+CNI network providers using this network model include Calico and Cilium. Cilium may be configured with this model although it is not the default mode.
+
+![Unencapsulated Network](/img/unencapsulated-network.png)
+
+## What CNI Providers are Provided by Rancher?
+
+### RKE Kubernetes clusters
+
+Out-of-the-box, Rancher provides the following CNI network providers for RKE Kubernetes clusters: Canal, Flannel, Calico, and Weave.
+
+You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
+
+#### Canal
+
+![Canal Logo](/img/canal-logo.png)
+
+Canal is a CNI network provider that gives you the best of Flannel and Calico. It allows users to easily deploy Calico and Flannel networking together as a unified networking solution, combining Calico’s network policy enforcement with the rich superset of Calico (unencapsulated) and/or Flannel (encapsulated) network connectivity options.
+
+In Rancher, Canal is the default CNI network provider combined with Flannel and VXLAN encapsulation.
+
+Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (health checks). If using Wireguard, you should open UDP ports `51820` and `51821`. For more details, refer to [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md).
+
+![](/img/canal-diagram.png)
+
+For more information, refer to the [Rancher maintained Canal source](https://github.com/rancher/rke2-charts/tree/main-source/packages/rke2-canal) and the [Canal GitHub Page](https://github.com/projectcalico/canal).
+
+#### Flannel
+
+![Flannel Logo](/img/flannel-logo.png)
+
+Flannel is a simple and easy way to configure L3 network fabric designed for Kubernetes. Flannel runs a single binary agent named flanneld on each host, which is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host's public IP). Packets are forwarded using one of several backend mechanisms, with the default encapsulation being [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan).
+
+Encapsulated traffic is unencrypted by default. Flannel provides two solutions for encryption:
+
+* [IPSec](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#ipsec), which makes use of [strongSwan](https://www.strongswan.org/) to establish encrypted IPSec tunnels between Kubernetes workers. It is an experimental backend for encryption.
+* [WireGuard](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#wireguard), which is a more faster-performing alternative to strongSwan.
+
+Kubernetes workers should open UDP port `8472` (VXLAN). See [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
+
+![Flannel Diagram](/img/flannel-diagram.png)
+
+For more information, see the [Flannel GitHub Page](https://github.com/flannel-io/flannel).
+
+#### Weave
+
+<DeprecationWeave />
+
+![Weave Logo](/img/weave-logo.png)
+
+Weave enables networking and network policy in Kubernetes clusters across the cloud. Additionally, it support encrypting traffic between the peers.
+
+Kubernetes workers should open TCP port `6783` (control port), UDP port `6783` and UDP port `6784` (data ports). See the [port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
+
+For more information, see the following pages:
+
+- [Weave Net Official Site](https://github.com/weaveworks/weave/blob/master/site/overview.md)
+
+### RKE2 Kubernetes clusters
+
+Out-of-the-box, Rancher provides the following CNI network providers for RKE2 Kubernetes clusters: [Canal](#canal) (see above section), Calico, and Cilium.
+
+You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
+
+#### Calico
+
+![Calico Logo](/img/calico-logo.png)
+
+Calico enables networking and network policy in Kubernetes clusters across the cloud. By default, Calico uses a pure, unencapsulated IP network fabric and policy engine to provide networking for your Kubernetes workloads. Workloads are able to communicate over both cloud infrastructure and on-prem using BGP.
+
+Calico also provides a stateless IP-in-IP or VXLAN encapsulation mode that can be used, if necessary. Calico also offers policy isolation, allowing you to secure and govern your Kubernetes workloads using advanced ingress and egress policies.
+
+Kubernetes workers should open TCP port `179` if using BGP or UDP port `4789` if using VXLAN encapsulation. In addition, TCP port `5473` is needed when using Typha. See [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
+
+:::note Important:
+
+In Rancher v2.6.3, Calico probes fail on Windows nodes upon RKE2 installation. <b>Note that this issue is resolved in v2.6.4.</b>
+
+- To work around this issue, first navigate to `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`.
+
+- There, change the current setting: `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` to this new setting: `https://raw.githubusercontent.com/rancher/rke2/master/windows/rke2-install.ps1`.
+
+:::
+
+![Calico Diagram](/img/calico-diagram.svg)
+
+For more information, see the following pages:
+
+- [Project Calico Official Site](https://www.projectcalico.org/)
+- [Project Calico GitHub Page](https://github.com/projectcalico/calico)
+
+#### Cilium
+
+![Cilium Logo](/img/cilium-logo.png)
+
+Cilium enables networking and network policies (L3, L4, and L7) in Kubernetes. By default, Cilium uses eBPF technologies to route packets inside the node and VXLAN to send packets to other nodes. Unencapsulated techniques can also be configured.
+
+Cilium recommends kernel versions greater than 5.2 to be able to leverage the full potential of eBPF. Kubernetes workers should open TCP port `8472` for VXLAN and TCP port `4240` for health checks. In addition, ICMP 8/0 must be enabled for health checks. For more information, check [Cilium System Requirements](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements).
+
+##### Ingress Routing Across Nodes in Cilium
+<br/>
+By default, Cilium does not allow pods to contact pods on other nodes. To work around this, enable the ingress controller to route requests across nodes with a `CiliumNetworkPolicy`.
+
+After selecting the Cilium CNI and enabling Project Network Isolation for your new cluster, configure as follows:
+
+```
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: hn-nodes
+  namespace: default
+spec:
+  endpointSelector: {}
+  ingress:
+    - fromEntities:
+      - remote-node
+```
+
+## CNI Features by Provider
+
+The following table summarizes the different features available for each CNI network provider provided by Rancher.
+
+| Provider | Network Model | Route Distribution | Network Policies | Mesh | External Datastore | Encryption | Ingress/Egress Policies |
+| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
+| Canal | Encapsulated (VXLAN) | No | Yes | No | K8s API | Yes | Yes |
+| Flannel | Encapsulated (VXLAN) | No | No | No | K8s API | Yes | No |
+| Calico | Encapsulated (VXLAN,IPIP) OR Unencapsulated | Yes | Yes | Yes | Etcd and K8s API | Yes | Yes |
+| Weave | Encapsulated | Yes | Yes | Yes | No | Yes | Yes |
+| Cilium | Encapsulated (VXLAN) | Yes | Yes | Yes | Etcd and K8s API | Yes | Yes |
+
+- Network Model: Encapsulated or unencapsulated. For more information, see [What Network Models are Used in CNI?](#what-network-models-are-used-in-cni)
+
+- Route Distribution: An exterior gateway protocol designed to exchange routing and reachability information on the Internet. BGP can assist with pod-to-pod networking between clusters. This feature is a must on unencapsulated CNI network providers, and it is typically done by BGP. If you plan to build clusters split across network segments, route distribution is a feature that's nice-to-have.
+
+- Network Policies: Kubernetes offers functionality to enforce rules about which services can communicate with each other using network policies. This feature is stable as of Kubernetes v1.7 and is ready to use with certain networking plugins.
+
+- Mesh: This feature allows service-to-service networking communication between distinct Kubernetes clusters.
+
+- External Datastore: CNI network providers with this feature need an external datastore for its data.
+
+- Encryption: This feature allows cyphered and secure network control and data planes.
+
+- Ingress/Egress Policies: This feature allows you to manage routing control for both Kubernetes and non-Kubernetes communications.
+
+## CNI Community Popularity
+
+<CNIPopularityTable />
+
+## Which CNI Provider Should I Use?
+
+It depends on your project needs. There are many different providers, which each have various features and options. There isn't one provider that meets everyone's needs.
+
+Canal is the default CNI network provider. We recommend it for most use cases. It provides encapsulated networking for containers with Flannel, while adding Calico network policies that can provide project/namespace isolation in terms of networking.
+
+## How can I configure a CNI network provider?
+
+Please see [Cluster Options](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md) on how to configure a network provider for your cluster. For more advanced configuration options, please see how to configure your cluster using a [Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-cluster-config-file-reference) and the options for [Network Plug-ins](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/).
@@ -0,0 +1,31 @@
+---
+title: Deprecated Features in Rancher
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
+</head>
+
+## Where can I find out which features have been deprecated in Rancher?
+
+Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:
+
+| Patch Version |  Release Date |
+|---------------|---------------|
+| [2.10.12](https://github.com/rancher/rancher/releases/tag/v2.10.12) | May 27, 2026 |
+| [2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) | January 29, 2026 |
+| [2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10) | September 25, 2025 |
+| [2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) | August 27, 2025 |
+| [2.10.8](https://github.com/rancher/rancher/releases/tag/v2.10.8) | July 30, 2025 |
+| [2.10.7](https://github.com/rancher/rancher/releases/tag/v2.10.7) | June 25, 2025 |
+| [2.10.6](https://github.com/rancher/rancher/releases/tag/v2.10.6) | May 22, 2025 |
+| [2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5) | Apr 24, 2025 |
+| [2.10.4](https://github.com/rancher/rancher/releases/tag/v2.10.4) | Mar 31, 2025 |
+| [2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3) | Feb 27, 2025 |
+| [2.10.2](https://github.com/rancher/rancher/releases/tag/v2.10.2) | Jan 29, 2025 |
+| [2.10.1](https://github.com/rancher/rancher/releases/tag/v2.10.1) | Dec 19, 2024 |
+| [2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | Nov 18, 2024 |
+
+## What can I expect when a feature is marked for deprecation?
+
+In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
@@ -0,0 +1,359 @@
+---
+title: Install/Upgrade Rancher on a Kubernetes Cluster
+description: Learn how to install Rancher in development and production environments. Read about single node and high availability installation
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster"/>
+</head>
+
+In this section, you'll learn how to deploy Rancher on a Kubernetes cluster using the Helm CLI.
+
+
+## Prerequisites
+
+- [Kubernetes Cluster](#kubernetes-cluster)
+- [Ingress Controller](#ingress-controller)
+- [CLI Tools](#cli-tools)
+
+### Kubernetes Cluster
+
+Set up the Rancher server's local Kubernetes cluster.
+
+Rancher can be installed on any Kubernetes cluster. This cluster can use upstream Kubernetes, or it can use one of Rancher's Kubernetes distributions, or it can be a managed Kubernetes cluster from a provider such as Amazon EKS.
+
+For help setting up a Kubernetes cluster, we provide these tutorials:
+
+- **RKE:** For the tutorial to install an RKE Kubernetes cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/rke1-for-rancher.md) For help setting up the infrastructure for a high-availability RKE cluster, refer to [this page.](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-rke1-kubernetes-cluster.md)
+- **K3s:** For the tutorial to install a K3s Kubernetes cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/k3s-for-rancher.md) For help setting up the infrastructure for a high-availability K3s cluster, refer to [this page.](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-k3s-kubernetes-cluster.md)
+- **RKE2:** For the tutorial to install an RKE2 Kubernetes cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/rke2-for-rancher.md) For help setting up the infrastructure for a high-availability RKE2 cluster, refer to [this page.](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-rke2-kubernetes-cluster.md)
+- **Amazon EKS:** For details on how to install Rancher on Amazon EKS, including how to install an Ingress controller so that the Rancher server can be accessed, refer to [this page.](rancher-on-amazon-eks.md)
+- **AKS:** For details on how to install Rancher with Azure Kubernetes Service, including how to install an Ingress controller so that the Rancher server can be accessed, refer to [this page.](rancher-on-aks.md)
+- **GKE:** For details on how to install Rancher with Google Kubernetes Engine, including how to install an Ingress controller so that the Rancher server can be accessed, refer to [this page.](rancher-on-gke.md) GKE has two modes of operation when creating a Kubernetes cluster, Autopilot and Standard mode. The cluster configuration for Autopilot mode has restrictions on editing the kube-system namespace. However, Rancher needs to create resources in the kube-system namespace during installation. As a result, you will not be able to install Rancher on a GKE cluster created in Autopilot mode.
+
+
+### Ingress Controller
+
+The Rancher UI and API are exposed through an Ingress. This means the Kubernetes cluster that you install Rancher in must contain an Ingress controller.
+
+For RKE, RKE2, and K3s installations, you don't have to install the Ingress controller manually because one is installed by default.
+
+For distributions that do not include an Ingress Controller by default, like a hosted Kubernetes cluster such as EKS, GKE, or AKS, you have to deploy an Ingress controller first. Note that the Rancher Helm chart does not set an `ingressClassName` on the ingress by default. Because of this, you have to configure the Ingress controller to also watch ingresses without an `ingressClassName`.
+
+Examples are included in the **Amazon EKS**, **AKS**, and **GKE** tutorials above.
+
+### CLI Tools
+
+The following CLI tools are required for setting up the Kubernetes cluster. Please make sure these tools are installed and available in your `$PATH`.
+
+- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
+- [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes. Refer to the [Helm version requirements](../resources/helm-version-requirements.md) to choose a version of Helm to install Rancher. Refer to the [instructions provided by the Helm project](https://helm.sh/docs/intro/install/) for your specific platform.
+
+## Install the Rancher Helm Chart
+
+Rancher is installed using the [Helm](https://helm.sh/) package manager for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm, we can create configurable deployments instead of just using static files.
+
+For systems without direct internet access, see [Air Gap: Kubernetes install](../other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md).
+
+To choose a Rancher version to install, refer to [Choosing a Rancher Version.](../resources/choose-a-rancher-version.md)
+
+To choose a version of Helm to install Rancher with, refer to the [Helm version requirements](../resources/helm-version-requirements.md)
+
+:::note
+
+The installation instructions assume you are using Helm 3.
+
+:::
+
+To set up Rancher,
+
+1. [Add the Helm chart repository](#1-add-the-helm-chart-repository)
+2. [Create a namespace for Rancher](#2-create-a-namespace-for-rancher)
+3. [Choose your SSL configuration](#3-choose-your-ssl-configuration)
+4. [Install cert-manager](#4-install-cert-manager) (unless you are bringing your own certificates, or TLS will be terminated on a load balancer)
+5. [Install Rancher with Helm and your chosen certificate option](#5-install-rancher-with-helm-and-your-chosen-certificate-option)
+6. [Verify that the Rancher server is successfully deployed](#6-verify-that-the-rancher-server-is-successfully-deployed)
+7. [Save your options](#7-save-your-options)
+
+### 1. Add the Helm Chart Repository
+
+Use `helm repo add` command to add the Helm chart repository that contains charts to install Rancher. For more information about the repository choices and which is best for your use case, see [Choosing a Rancher Version](../resources/choose-a-rancher-version.md).
+
+- Latest: Recommended for trying out the newest features
+    ```
+    helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+    ```
+- Stable: Recommended for production environments
+    ```
+    helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+    ```
+- Alpha: Experimental preview of upcoming releases.
+    ```
+    helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
+    ```
+    Note: Upgrades are not supported to, from, or between Alphas.
+
+### 2. Create a Namespace for Rancher
+
+We'll need to define a Kubernetes namespace where the resources created by the Chart should be installed. This should always be `cattle-system`:
+
+```
+kubectl create namespace cattle-system
+```
+
+### 3. Choose your SSL Configuration
+
+The Rancher management server is designed to be secure by default and requires SSL/TLS configuration.
+
+:::note
+
+If you want to externally terminate SSL/TLS, see [TLS termination on an External Load Balancer](../installation-references/helm-chart-options.md#external-tls-termination). As outlined on that page, this option does have additional requirements for TLS verification.
+
+:::
+
+There are three recommended options for the source of the certificate used for TLS termination at the Rancher server:
+
+- **Rancher-generated TLS certificate:** In this case, you will need to install `cert-manager` into the cluster. Rancher utilizes `cert-manager` to issue and maintain its certificates. Rancher will generate a CA certificate of its own, and sign a cert using that CA. `cert-manager` is then responsible for managing that certificate. No extra action is needed when `agent-tls-mode` is set to strict. More information can be found on this setting in [Agent TLS Enforcement](../installation-references/tls-settings.md#agent-tls-enforcement).
+- **Let's Encrypt:** The Let's Encrypt option also uses `cert-manager`. However, in this case, cert-manager is combined with a special Issuer for Let's Encrypt that performs all actions (including request and validation) necessary for getting a Let's Encrypt issued cert. This configuration uses HTTP validation (`HTTP-01`), so the load balancer must have a public DNS record and be accessible from the internet. When setting `agent-tls-mode` to `strict`, you must also specify `--privateCA=true` and upload the Let's Encrypt CA as described in [Adding TLS Secrets](../resources/add-tls-secrets.md). More information can be found on this setting in [Agent TLS Enforcement](../installation-references/tls-settings.md#agent-tls-enforcement).
+- **Bring your own certificate:** This option allows you to bring your own public- or private-CA signed certificate. Rancher will use that certificate to secure websocket and HTTPS traffic. In this case, you must upload this certificate (and associated key) as PEM-encoded files with the name `tls.crt` and `tls.key`. If you are using a private CA, you must also upload that certificate. This is due to the fact that this private CA may not be trusted by your nodes. Rancher will take that CA certificate, and generate a checksum from it, which the various Rancher components will use to validate their connection to Rancher. If `agent-tls-mode` is set to `strict`, the CA must be uploaded, so that downstream clusters can successfully connect. More information can be found on this setting in [Agent TLS Enforcement](../installation-references/tls-settings.md#agent-tls-enforcement).
+
+
+| Configuration                  | Helm Chart Option           | Requires cert-manager                 |
+| ------------------------------ | ----------------------- | ------------------------------------- |
+| Rancher Generated Certificates (Default) | `ingress.tls.source=rancher`  | [yes](#4-install-cert-manager) |
+| Let’s Encrypt                  | `ingress.tls.source=letsEncrypt`  | [yes](#4-install-cert-manager) |
+| Certificates from Files        | `ingress.tls.source=secret`        | no               |
+
+### 4. Install cert-manager
+
+> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer](../installation-references/helm-chart-options.md#external-tls-termination).
+
+This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
+
+<details id="cert-manager">
+  <summary>Click to Expand</summary>
+
+:::note Important:
+
+Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation](../resources/upgrade-cert-manager.md).
+
+:::
+
+These instructions are adapted from the [official cert-manager documentation](https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm).
+
+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
+```
+# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
+
+# Add the Jetstack Helm repository
+helm repo add jetstack https://charts.jetstack.io
+
+# Update your local Helm chart repository cache
+helm repo update
+
+# Install the cert-manager Helm chart
+helm install cert-manager jetstack/cert-manager \
+  --namespace cert-manager \
+  --create-namespace \
+  --set crds.enabled=true
+```
+
+Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
+
+```
+kubectl get pods --namespace cert-manager
+
+NAME                                       READY   STATUS    RESTARTS   AGE
+cert-manager-5c6866597-zw7kh               1/1     Running   0          2m
+cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
+cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m
+```
+
+</details>
+
+### 5. Install Rancher with Helm and Your Chosen Certificate Option
+
+The exact command to install Rancher differs depending on the certificate configuration.
+
+However, irrespective of the certificate configuration, the name of the Rancher installation in the `cattle-system` namespace should always be `rancher`.
+
+:::tip Testing and Development:
+
+This final command to install Rancher requires a domain name that forwards traffic to Rancher. If you are using the Helm CLI to set up a proof-of-concept, you can use a fake domain name when passing the `hostname` option. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`, which would expose Rancher on an IP where it is running. Production installs would require a real domain name.
+
+:::
+
+<Tabs>
+<TabItem value="Rancher-generated Certificates">
+
+The default is for Rancher to generate a CA and uses `cert-manager` to issue the certificate for access to the Rancher server interface.
+
+Because `rancher` is the default option for `ingress.tls.source`, we are not specifying `ingress.tls.source` when running the `helm install` command.
+
+- Set the `hostname` to the DNS name you pointed at your load balancer.
+- Set the `bootstrapPassword` to something unique for the `admin` user.
+- To install a specific Rancher version, use the `--version` flag, example: `--version 2.7.0`
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set bootstrapPassword=admin
+```
+
+If you are installing an alpha version, Helm requires adding the `--devel` option to the install command:
+
+```
+helm install rancher rancher-alpha/rancher --devel
+```
+
+Wait for Rancher to be rolled out:
+
+```
+kubectl -n cattle-system rollout status deploy/rancher
+Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
+deployment "rancher" successfully rolled out
+```
+
+</TabItem>
+<TabItem value="Let's Encrypt">
+
+This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA.
+
+:::note
+
+You need to have port 80 open as the HTTP-01 challenge can only be done on port 80.
+
+:::
+
+In the following command,
+
+- `hostname` is set to the public DNS record,
+- Set the `bootstrapPassword` to something unique for the `admin` user.
+- `ingress.tls.source` is set to `letsEncrypt`
+- `letsEncrypt.email` is set to the email address used for communication about your certificate (for example, expiry notices)
+- Set `letsEncrypt.ingress.class` to whatever your ingress controller is, e.g., `traefik`, `nginx`, `haproxy`, etc.
+
+:::warning
+
+When `agent-tls-mode` is set to `strict` (the default value for new installs of Rancher starting from v2.9.0), you must supply the `privateCA=true` chart value (e.x. through `--set privateCA=true`) and upload the Let's Encrypt Certificate Authority as outlined in [Adding TLS Secrets](../resources/add-tls-secrets.md). Information on identifying the Let's Encrypt Root CA can be found in the Let's Encrypt [docs](https://letsencrypt.org/certificates/). If you don't upload the CA, then Rancher may fail to connect to new or existing downstream clusters.
+
+:::
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set bootstrapPassword=admin \
+  --set ingress.tls.source=letsEncrypt \
+  --set letsEncrypt.email=me@example.org \
+  --set letsEncrypt.ingress.class=nginx
+```
+
+If you are installing an alpha version, Helm requires adding the `--devel` option to the install command:
+
+```
+helm install rancher rancher-alpha/rancher --devel
+```
+
+Wait for Rancher to be rolled out:
+
+```
+kubectl -n cattle-system rollout status deploy/rancher
+Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
+deployment "rancher" successfully rolled out
+```
+
+</TabItem>
+<TabItem value="Certificates from Files">
+In this option, Kubernetes secrets are created from your own certificates for Rancher to use.
+
+When you run this command, the `hostname` option must match the `Common Name` or a `Subject Alternative Names` entry in the server certificate or the Ingress controller will fail to configure correctly.
+
+Although an entry in the `Subject Alternative Names` is technically required, having a matching `Common Name` maximizes compatibility with older browsers and applications.
+
+:::note
+
+If you want to check if your certificates are correct, see [How do I check Common Name and Subject Alternative Names in my server certificate?](../../../faq/technical-items.md#how-do-i-check-common-name-and-subject-alternative-names-in-my-server-certificate)
+
+:::
+
+- Set the `hostname`.
+- Set the `bootstrapPassword` to something unique for the `admin` user.
+- Set `ingress.tls.source` to `secret`.
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set bootstrapPassword=admin \
+  --set ingress.tls.source=secret
+```
+If you are installing an alpha version, Helm requires adding the `--devel` option to the install command:
+
+```
+helm install rancher rancher-alpha/rancher --devel
+```
+
+If you are using a Private CA signed certificate , add `--set privateCA=true` to the command:
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set bootstrapPassword=admin \
+  --set ingress.tls.source=secret \
+  --set privateCA=true
+```
+
+Now that Rancher is deployed, see [Adding TLS Secrets](../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the Ingress controller can use them.
+
+</TabItem>
+</Tabs>
+
+The Rancher chart configuration has many options for customizing the installation to suit your specific environment. Here are some common advanced scenarios.
+
+- [HTTP Proxy](../installation-references/helm-chart-options.md#http-proxy)
+- [Private Container Image Registry](../installation-references/helm-chart-options.md#private-registry-and-air-gap-installs)
+- [TLS Termination on an External Load Balancer](../installation-references/helm-chart-options.md#external-tls-termination)
+
+See the [Chart Options](../installation-references/helm-chart-options.md) for the full list of options.
+
+
+### 6. Verify that the Rancher Server is Successfully Deployed
+
+After adding the secrets, check if Rancher was rolled out successfully:
+
+```
+kubectl -n cattle-system rollout status deploy/rancher
+Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
+deployment "rancher" successfully rolled out
+```
+
+If you see the following error: `error: deployment "rancher" exceeded its progress deadline`, you can check the status of the deployment by running the following command:
+
+```
+kubectl -n cattle-system get deploy rancher
+NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+rancher   3         3         3            3           3m
+```
+
+It should show the same count for `DESIRED` and `AVAILABLE`.
+
+### 7. Save Your Options
+
+Make sure you save the `--set` options you used. You will need to use the same options when you upgrade Rancher to new versions with Helm.
+
+### Finishing Up
+
+That's it. You should have a functional Rancher server.
+
+In a web browser, go to the DNS name that forwards traffic to your load balancer. Then you should be greeted by the colorful login page.
+
+Doesn't work? Take a look at the [Troubleshooting](troubleshooting.md) Page
@@ -0,0 +1,143 @@
+---
+title: Installing Rancher on Azure Kubernetes Service
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks"/>
+</head>
+
+This page covers how to install Rancher on Microsoft's Azure Kubernetes Service (AKS).
+
+The guide uses command line tools to provision an AKS cluster with an ingress. If you prefer to provision your cluster using the Azure portal, refer to the [official documentation](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal).
+
+If you already have an AKS Kubernetes cluster, skip to the step about [installing an ingress.](#5-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)
+
+## Prerequisites
+
+:::caution
+
+Deploying to Microsoft Azure will incur charges.
+
+:::
+
+- [Microsoft Azure Account](https://azure.microsoft.com/en-us/free/): A Microsoft Azure Account is required to create resources for deploying Rancher and Kubernetes.
+- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
+- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
+- Your subscription has sufficient quota for at least 2 vCPUs. For details on Rancher server resource requirements, refer to [this section](../installation-requirements/installation-requirements.md)
+- When installing Rancher with Helm in Azure, use the L7 load balancer to avoid networking issues. For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
+
+## 1. Prepare your Workstation
+
+Install the following command line tools on your workstation:
+
+- The Azure CLI, **az:** For help, refer to these [installation steps.](https://docs.microsoft.com/en-us/cli/azure/)
+- **kubectl:** For help, refer to these [installation steps.](https://kubernetes.io/docs/tasks/tools/#kubectl)
+- **helm:** For help, refer to these [installation steps.](https://helm.sh/docs/intro/install/)
+
+## 2. Create a Resource Group
+
+After installing the CLI, you will need to log in with your Azure account.
+
+```
+az login
+```
+
+Create a [resource group](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal) to hold all relevant resources for your cluster. Use a location that applies to your use case.
+
+```
+az group create --name rancher-rg --location eastus
+```
+
+## 3. Create the AKS Cluster
+
+To create an AKS cluster, run the following command. Use a VM size that applies to your use case. Refer to [this article](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for available sizes and options. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
+
+```
+az aks create \
+  --resource-group rancher-rg \
+  --name rancher-server \
+  --kubernetes-version <VERSION> \
+  --node-count 3 \
+  --node-vm-size Standard_D2_v3
+```
+
+The cluster will take some time to be deployed.
+
+## 4. Get Access Credentials
+
+After the cluster is deployed, get the access credentials.
+
+```
+az aks get-credentials --resource-group rancher-rg --name rancher-server
+```
+
+This command merges your cluster's credentials into the existing kubeconfig and allows `kubectl` to interact with the cluster.
+
+## 5. Install an Ingress
+
+The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription. You can use a managed ingress controller provided by Azure or a third-party ingress controller like Traefik.
+
+:::warning
+It is not recommended to install a third-party ingress controller, like Traefik, if a managed ingress controller is already being used.
+:::
+
+:::warning
+**Ingress-NGINX EOL:** The community `ingress-nginx` controller reaches End-of-Life (EOL) in March 2026. This page uses Traefik, which is the recommended migration path for Rancher environments. 
+:::
+
+Traefik includes a native Ingress NGINX provider. This allows you to migrate from NGINX without rewriting your existing Ingress objects, as Traefik will automatically interpret `nginx.ingress.kubernetes.io` annotations. If you are upgrading a cluster that is already using `ingress-nginx`, follow this [guide](https://doc.traefik.io/traefik/migrate/nginx-to-traefik/) for more information.
+
+To install Traefik (chart version 39.0.0) on a fresh cluster, run the following `helm` commands:
+```bash
+helm repo add traefik https://traefik.github.io/charts
+helm repo update
+helm upgrade --install \
+  traefik traefik/traefik \
+  --namespace traefik \
+  --version 39.0.0 \
+  --create-namespace \
+  --set service.type=LoadBalancer \
+  --set ping.enabled=true \
+  --set service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/ping
+```
+
+## 6. Get Load Balancer IP
+
+To get the address of the load balancer, run:
+
+```bash
+kubectl get service traefik --namespace=traefik
+```
+
+The result should look similar to the following:
+
+```bash
+NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)
+ AGE
+traefik  LoadBalancer   10.0.116.18    40.31.180.83   80:31229/TCP,443:31050/TCP
+ 67s
+```
+
+Save the `EXTERNAL-IP`.
+
+## 7. Set up DNS
+
+External traffic to the Rancher server will need to be directed at the load balancer you created.
+
+Set up a DNS to point at the `EXTERNAL-IP` that you saved. This DNS will be used as the Rancher server URL.
+
+There are many valid ways to set up the DNS. For help, refer to the [Azure DNS documentation](https://docs.microsoft.com/en-us/azure/dns/)
+
+## 8. Install the Rancher Helm Chart
+
+Next, install the Rancher Helm chart by following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
+
+Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
+
+When installing Rancher on top of this setup, you will also need to pass the value below into the Rancher Helm install command in order to set the name of the ingress controller to be used with Rancher's ingress resource:
+
+```
+--set ingress.ingressClassName=traefik
+```
+
+Refer [here for the Helm install command](install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
@@ -0,0 +1,155 @@
+---
+title: Installing Rancher on Amazon EKS
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks"/>
+</head>
+
+This page covers installing Rancher on an Amazon EKS cluster.  You can also [install Rancher through the AWS Marketplace](../../quick-start-guides/deploy-rancher-manager/aws-marketplace.md).
+
+If you already have an EKS Kubernetes cluster, skip to the step about [installing an ingress.](#5-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)
+
+## Creating an EKS Cluster for the Rancher Server
+
+In this section, you'll install an EKS cluster with an ingress by using command line tools. This guide may be useful if you want to use fewer resources while trying out Rancher on EKS.
+
+:::note Prerequisites:
+
+- You should already have an AWS account.
+- It is recommended to use an IAM user instead of the root AWS account. You will need the IAM user's access key and secret key to configure the AWS command line interface.
+- The IAM user needs the minimum IAM policies described in the official [eksctl documentation.](https://eksctl.io/usage/minimum-iam-policies/)
+
+:::
+
+### 1. Prepare your Workstation
+
+Install the following command line tools on your workstation:
+
+- **The AWS CLI v2:** For help, refer to these [installation steps.](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
+- **eksctl:** For help, refer to these [installation steps.](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)
+- **kubectl:** For help, refer to these [installation steps.](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
+- **helm:** For help, refer to these [installation steps.](https://helm.sh/docs/intro/install/)
+
+### 2. Configure the AWS CLI
+
+To configure the AWS CLI, run the following command:
+
+```
+aws configure
+```
+
+Then enter the following values:
+
+| Value | Description |
+|-------|-------------|
+| AWS Access Key ID | The access key credential for the IAM user with EKS permissions. |
+| AWS Secret Access Key | The secret key credential for the IAM user with EKS permissions. |
+| Default region name | An [AWS region](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html#Concepts.RegionsAndAvailabilityZones.Regions) where the cluster nodes will be located. |
+| Default output format | Enter `json`. |
+
+### 3. Create the EKS Cluster
+
+To create an EKS cluster, run the following command. Use the AWS region that applies to your use case. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
+
+```
+eksctl create cluster \
+  --name rancher-server \
+  --version <VERSION> \
+  --region us-west-2 \
+  --nodegroup-name ranchernodes \
+  --nodes 3 \
+  --nodes-min 1 \
+  --nodes-max 4 \
+  --managed
+```
+
+The cluster will take some time to be deployed with CloudFormation.
+
+### 4. Test the Cluster
+
+To test the cluster, run:
+
+```
+eksctl get cluster
+```
+
+The result should look like the following:
+
+```
+eksctl get cluster
+2021-03-18 15:09:35 [ℹ]  eksctl version 0.40.0
+2021-03-18 15:09:35 [ℹ]  using region us-west-2
+NAME		REGION		EKSCTL CREATED
+rancher-server-cluster		us-west-2	True
+```
+
+### 5. Install an Ingress
+
+The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription. You can use a managed ingress controller provided by AWS (ALB) or a third-party ingress controller like Traefik.
+
+:::warning
+It is not recommended to install a third-party ingress controller, like Traefik, if a managed ingress controller (ALB) is already being used.
+:::
+
+
+:::warning
+**Ingress-NGINX EOL:** The community `ingress-nginx` controller reaches End-of-Life (EOL) in March 2026. This page uses Traefik, which is the recommended migration path for Rancher environments. 
+:::
+
+Traefik includes a native Ingress NGINX provider. This allows you to migrate from NGINX without rewriting your existing Ingress objects, as Traefik will automatically interpret `nginx.ingress.kubernetes.io` annotations. If you are upgrading a cluster that is already using `ingress-nginx`, follow this [guide](https://doc.traefik.io/traefik/migrate/nginx-to-traefik/) for more information.
+
+To install Traefik (chart version 39.0.0) on a fresh cluster, run the following `helm` commands:
+```bash
+helm repo add traefik https://traefik.github.io/charts
+helm repo update
+helm upgrade --install \
+  traefik traefik/traefik \
+  --namespace traefik \
+  --version 39.0.0 \
+  --create-namespace \
+  --set service.type=LoadBalancer \
+  --set ping.enabled=true \
+```
+
+
+### 6. Get Load Balancer IP
+
+To get the address of the load balancer, run:
+
+```bash
+kubectl get service traefik --namespace=traefik
+```
+
+The result should look similar to the following:
+
+```bash
+NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)
+ AGE
+traefik  LoadBalancer   10.100.90.18   a904a952c73bf4f668a17c46ac7c56ab-962521486.us-west-2.elb.amazonaws.com   80:31229/TCP,443:31050/TCP
+ 67s
+```
+
+Save the `EXTERNAL-IP`.
+
+### 7. Set up DNS
+
+External traffic to the Rancher server will need to be directed at the load balancer you created.
+
+Set up a DNS to point at the external IP that you saved. This DNS will be used as the Rancher server URL.
+
+There are many valid ways to set up the DNS. For help, refer to the AWS documentation on [routing traffic to an ELB load balancer.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html)
+
+### 8. Install the Rancher Helm Chart
+
+Next, install the Rancher Helm chart by following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
+
+Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
+
+When installing Rancher on top of this setup, you will also need to pass the value below into the Rancher Helm install command in order to set the name of the ingress controller to be used with Rancher's ingress resource:
+
+```
+--set ingress.ingressClassName=traefik
+```
+
+Refer [here for the Helm install command](install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
@@ -0,0 +1,216 @@
+---
+title: Installing Rancher on a Google Kubernetes Engine Cluster
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke"/>
+</head>
+
+In this section, you'll learn how to install Rancher using Google Kubernetes Engine.
+
+If you already have a GKE Kubernetes cluster, skip to the step about [installing an ingress.](#7-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)
+
+## Prerequisites
+
+- You will need a Google account.
+- You will need a Google Cloud billing account. You can manage your Cloud Billing accounts using the Google Cloud Console. For more information about the Cloud Console, visit [General guide to the console.](https://support.google.com/cloud/answer/3465889?hl=en&ref_topic=3340599)
+- You will need a cloud quota for at least one in-use IP address and at least 2 CPUs. For more details about hardware requirements for the Rancher server, refer to [this section.](../installation-requirements/installation-requirements.md)
+
+## 1. Enable the Kubernetes Engine API
+
+Take the following steps to enable the Kubernetes Engine API:
+
+1. Visit the [Kubernetes Engine page](https://console.cloud.google.com/projectselector/kubernetes?_ga=2.169595943.767329331.1617810440-856599067.1617343886) in the Google Cloud Console.
+1. Create or select a project.
+1. Open the project and enable the Kubernetes Engine API for the project. Wait for the API and related services to be enabled. This can take several minutes.
+1. Make sure that billing is enabled for your Cloud project. For information on how to enable billing for your project, refer to the [Google Cloud documentation.](https://cloud.google.com/billing/docs/how-to/modify-project#enable_billing_for_a_project)
+
+## 2. Open the Cloud Shell
+
+Cloud Shell is a shell environment for managing resources hosted on Google Cloud. Cloud Shell comes preinstalled with the `gcloud` command-line tool and kubectl command-line tool. The `gcloud` tool provides the primary command-line interface for Google Cloud, and `kubectl` provides the primary command-line interface for running commands against Kubernetes clusters.
+
+The following sections describe how to launch the cloud shell from the Google Cloud Console or from your local workstation.
+
+### Cloud Shell
+
+To launch the shell from the [Google Cloud Console,](https://console.cloud.google.com) go to the upper-right corner of the console and click the terminal button. When hovering over the button, it is labeled **Activate Cloud Shell**.
+
+### Local Shell
+
+To install `gcloud` and `kubectl`, perform the following steps:
+
+1. Install the Cloud SDK by following [these steps.](https://cloud.google.com/sdk/docs/install) The Cloud SDK includes the `gcloud` command-line tool. The steps vary based on your OS.
+1. After installing Cloud SDK, install the `kubectl` command-line tool by running the following command:
+
+    ```
+    gcloud components install kubectl
+    ```
+    In a later step, `kubectl` will be configured to use the new GKE cluster.
+1. [Install Helm 3](https://helm.sh/docs/intro/install/) if it is not already installed.
+1. Enable Helm experimental [support for OCI images](https://github.com/helm/community/blob/master/hips/hip-0006.md) with the `HELM_EXPERIMENTAL_OCI` variable. Add the following line to `~/.bashrc` (or `~/.bash_profile` in macOS, or wherever your shell stores environment variables):
+
+    ```
+    export HELM_EXPERIMENTAL_OCI=1
+    ```
+1. Run the following command to load your updated `.bashrc` file:
+
+    ```
+    source ~/.bashrc
+    ```
+    If you are running macOS, use this command:
+    ```
+    source ~/.bash_profile
+    ```
+
+
+
+## 3. Configure the gcloud CLI
+
+ Set up default gcloud settings using one of the following methods:
+
+- Using gcloud init, if you want to be walked through setting defaults.
+- Using gcloud config, to individually set your project ID, zone, and region.
+
+<Tabs>
+<TabItem value="Using gcloud init">
+
+  1. Run gcloud init and follow the directions:
+
+      ```
+      gcloud init
+      ```
+      If you are using SSH on a remote server, use the --console-only flag to prevent the command from launching a browser:
+
+      ```
+      gcloud init --console-only
+      ```
+  2. Follow the instructions to authorize gcloud to use your Google Cloud account and select the new project that you created.
+
+
+</TabItem>
+<TabItem value="Using gcloud config">
+</TabItem>
+</Tabs>
+
+## 4. Confirm that gcloud is configured correctly
+
+Run:
+
+```
+gcloud config list
+```
+
+The output should resemble the following:
+
+```
+[compute]
+region = us-west1 # Your chosen region
+zone = us-west1-b # Your chosen zone
+[core]
+account = <Your email>
+disable_usage_reporting = True
+project = <Your project ID>
+
+Your active configuration is: [default]
+```
+
+## 5. Create a GKE Cluster
+
+The following command creates a three-node cluster.
+
+Replace `cluster-name` with the name of your new cluster.
+
+When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
+
+To successfully create a GKE cluster with Rancher, your GKE must be in Standard mode. GKE has two modes of operation when creating a Kubernetes cluster, Autopilot and Standard mode. The cluster configuration for Autopilot mode has restrictions on editing the kube-system namespace. However, Rancher needs to create resources in the kube-system namespace during installation. As a result, you will not be able to install Rancher on a GKE cluster created in Autopilot mode. For more information about the difference between GKE Autopilot mode and Standard mode, visit [Compare GKE Autopilot and Standard.](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison)
+
+
+```
+gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=<VERSION>
+```
+
+## 6. Get Authentication Credentials
+
+After creating your cluster, you need to get authentication credentials to interact with the cluster:
+
+```
+gcloud container clusters get-credentials cluster-name
+```
+
+This command configures `kubectl` to use the cluster you created.
+
+
+## 7. Install an Ingress
+
+The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription. You can use a managed ingress controller provided by GCP or a third-party ingress controller like Traefik.
+
+:::warning
+It is not recommended to install a third-party ingress controller, like Traefik, if a managed ingress controller is already being used.
+:::
+
+:::warning
+**Ingress-NGINX EOL:** The community `ingress-nginx` controller reaches End-of-Life (EOL) in March 2026. This page uses Traefik, which is the recommended migration path for Rancher environments. 
+:::
+
+Traefik includes a native Ingress NGINX provider. This allows you to migrate from NGINX without rewriting your existing Ingress objects, as Traefik will automatically interpret `nginx.ingress.kubernetes.io` annotations. If you are upgrading a cluster that is already using `ingress-nginx`, follow this [guide](https://doc.traefik.io/traefik/migrate/nginx-to-traefik/) for more information.
+
+To install Traefik (chart version 39.0.0) on a fresh cluster, run the following `helm` commands:
+```bash
+helm repo add traefik https://traefik.github.io/charts
+helm repo update
+helm upgrade --install \
+  traefik traefik/traefik \
+  --namespace traefik \
+  --version 39.0.0 \
+  --create-namespace \
+  --set service.type=LoadBalancer \
+  --set ping.enabled=true \
+```
+
+
+## 8. Get Load Balancer IP
+
+To get the address of the load balancer, run:
+
+```bash
+kubectl get service traefik --namespace=traefik
+```
+
+The result should look similar to the following:
+
+```
+NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
+traefik   LoadBalancer   10.3.244.156   35.233.206.34   80:31876/TCP,443:32497/TCP    81s
+```
+
+Save the `EXTERNAL-IP`.
+
+## 9. Set up DNS
+
+External traffic to the Rancher server will need to be directed at the load balancer you created.
+
+Set up a DNS to point at the external IP that you saved. This DNS will be used as the Rancher server URL.
+
+There are many valid ways to set up the DNS. For help, refer to the Google Cloud documentation about [managing DNS records.](https://cloud.google.com/dns/docs/records)
+
+## 10. Install the Rancher Helm chart
+
+Next, install the Rancher Helm chart by following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
+
+Use the DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
+
+When installing Rancher on top of this setup, you will also need to set the name of the ingress controller to be used with Rancher's ingress resource:
+
+```
+--set ingress.ingressClassName=traefik
+```
+
+Refer [here for the Helm install command](install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
+
+In Rancher v2.7.5, if you intend to use the default GKE ingress on your cluster without enabling VPC-native cluster mode, you need to set the following flag:
+
+```
+--set service.type=NodePort
+```
+
+This is necessary because of compatibility issues between this setup and ClusterIP, the default type for `cattle-system/rancher`.
@@ -0,0 +1,203 @@
+---
+title: Troubleshooting the Rancher Server Kubernetes Cluster
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/troubleshooting"/>
+</head>
+
+This section describes how to troubleshoot an installation of Rancher on a Kubernetes cluster.
+
+### Relevant Namespaces
+
+Most of the troubleshooting will be done on objects in these 3 namespaces.
+
+- `cattle-system` - `rancher` deployment and pods.
+- `traefik` - Ingress controller pods and services.
+- `cert-manager` - `cert-manager` pods.
+
+### "default backend - 404"
+
+A number of things can cause the ingress-controller not to forward traffic to your rancher instance. Most of the time its due to a bad ssl configuration.
+
+Things to check
+
+- [Is Rancher Running](#check-if-rancher-is-running)
+- [Cert CN is "Kubernetes Ingress Controller Fake Certificate"](#cert-cn-is-kubernetes-ingress-controller-fake-certificate)
+
+### Check if Rancher is Running
+
+Use `kubectl` to check the `cattle-system` system namespace and see if the Rancher pods are in a Running state.
+
+```
+kubectl -n cattle-system get pods
+
+NAME                           READY     STATUS    RESTARTS   AGE
+pod/rancher-784d94f59b-vgqzh   1/1       Running   0          10m
+```
+
+If the state is not `Running`, run a `describe` on the pod and check the Events.
+
+```
+kubectl -n cattle-system describe pod
+
+...
+Events:
+  Type     Reason                 Age   From                Message
+  ----     ------                 ----  ----                -------
+  Normal   Scheduled              11m   default-scheduler   Successfully assigned rancher-784d94f59b-vgqzh to localhost
+  Normal   SuccessfulMountVolume  11m   kubelet, localhost  MountVolume.SetUp succeeded for volume "rancher-token-dj4mt"
+  Normal   Pulling                11m   kubelet, localhost  pulling image "rancher/rancher:v2.0.4"
+  Normal   Pulled                 11m   kubelet, localhost  Successfully pulled image "rancher/rancher:v2.0.4"
+  Normal   Created                11m   kubelet, localhost  Created container
+  Normal   Started                11m   kubelet, localhost  Started container
+```
+
+### Check the Rancher Logs
+
+Use `kubectl` to list the pods.
+
+```
+kubectl -n cattle-system get pods
+
+NAME                           READY     STATUS    RESTARTS   AGE
+pod/rancher-784d94f59b-vgqzh   1/1       Running   0          10m
+```
+
+Use `kubectl` and the pod name to list the logs from the pod.
+
+```
+kubectl -n cattle-system logs -f rancher-784d94f59b-vgqzh
+```
+
+### Cert CN is "Kubernetes Ingress Controller Fake Certificate"
+
+Use your browser to check the certificate details. If it says the Common Name is "Kubernetes Ingress Controller Fake Certificate", something may have gone wrong with reading or issuing your SSL cert.
+
+:::note
+
+If you are using LetsEncrypt to issue certs, it can sometimes take a few minutes to issue the cert.
+
+:::
+
+### Checking for issues with cert-manager issued certs (Rancher Generated or LetsEncrypt)
+
+`cert-manager` has 3 parts.
+
+- `cert-manager` pod in the `cert-manager` namespace.
+- `Issuer` object in the `cattle-system` namespace.
+- `Certificate` object in the `cattle-system` namespace.
+
+Work backwards and do a `kubectl describe` on each object and check the events. You can track down what might be missing.
+
+For example there is a problem with the Issuer:
+
+```
+kubectl -n cattle-system describe certificate
+...
+Events:
+  Type     Reason          Age                 From          Message
+  ----     ------          ----                ----          -------
+  Warning  IssuerNotReady  18s (x23 over 19m)  cert-manager  Issuer rancher not ready
+```
+
+```
+kubectl -n cattle-system describe issuer
+...
+Events:
+  Type     Reason         Age                 From          Message
+  ----     ------         ----                ----          -------
+  Warning  ErrInitIssuer  19m (x12 over 19m)  cert-manager  Error initializing issuer: secret "tls-rancher" not found
+  Warning  ErrGetKeyPair  9m (x16 over 19m)   cert-manager  Error getting keypair for CA issuer: secret "tls-rancher" not found
+```
+
+### Checking for Issues with Your Own SSL Certs
+
+Your certs get applied directly to the Ingress object in the `cattle-system` namespace.
+
+Check the status of the Ingress object and see if its ready.
+
+```
+kubectl -n cattle-system describe ingress
+```
+
+If its ready and the SSL is still not working you may have a malformed cert or secret.
+
+Check the `traefik` logs.
+
+```
+kubectl logs -n traefik traefik-6b94b8b688-bngw2
+...
+W0705 23:04:58.240571       7 backend_ssl.go:49] error obtaining PEM from secret cattle-system/tls-rancher-ingress: error retrieving secret cattle-system/tls-rancher-ingress: secret cattle-system/tls-rancher-ingress was not found
+```
+
+### No matches for kind "Issuer"
+
+The SSL configuration option you have chosen requires cert-manager to be installed before installing Rancher or else the following error is shown:
+
+```
+Error: validation failed: unable to recognize "": no matches for kind "Issuer" in version "certmanager.k8s.io/v1alpha1"
+```
+
+Install cert-manager and try installing Rancher again.
+
+
+### Canal Pods show READY 2/3
+
+The most common cause of this issue is port 8472/UDP is not open between the nodes. Check your local firewall, network routing or security groups.
+
+Once the network issue is resolved, the `canal` pods should timeout and restart to establish their connections.
+
+### Failed to dial to /var/run/docker.sock: ssh: rejected: administratively prohibited (open failed)
+
+Some causes of this error include:
+
+* User specified to connect with does not have permission to access the Docker socket. This can be checked by logging into the host and running the command `docker ps`:
+
+```
+$ ssh user@server
+user@server$ docker ps
+CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
+```
+
+See [Manage Docker as a non-root user](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user) how to set this up properly.
+
+* When using RedHat/CentOS as operating system, you cannot use the user `root` to connect to the nodes because of [Bugzilla #1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). You will need to add a separate user and configure it to access the Docker socket. See [Manage Docker as a non-root user](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user) how to set this up properly.
+
+* SSH server version is not version 6.7 or higher. This is needed for socket forwarding to work, which is used to connect to the Docker socket over SSH. This can be checked using `sshd -V` on the host you are connecting to, or using netcat:
+```
+$ nc xxx.xxx.xxx.xxx 22
+SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10
+```
+
+### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: no key found
+
+The key file specified as `ssh_key_path` cannot be accessed. Make sure that you specified the private key file (not the public key, `.pub`), and that the user that is running the `rke` command can access the private key file.
+
+### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
+
+The key file specified as `ssh_key_path` is not correct for accessing the node. Double-check if you specified the correct `ssh_key_path` for the node and if you specified the correct user to connect with.
+
+### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: cannot decode encrypted private keys
+
+If you want to use encrypted private keys, you should use `ssh-agent` to load your keys with your passphrase. If the `SSH_AUTH_SOCK` environment variable is found in the environment where the `rke` command is run, it will be used automatically to connect to the node.
+
+### Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
+
+The node is not reachable on the configured `address` and `port`.
+
+### Agent reports TLS errors 
+
+When using Rancher, you may encounter error messages from the `fleet-agent`, `system-agent`, or `cluster-agent`, such as the message below:
+```
+tls: failed to verify certificate: x509: failed to load system roots and no roots provided; readdirent /dev/null: not a directory
+```
+
+This occurs when Rancher was configured with `agent-tls-mode` set to `strict`, but couldn't find cacerts in the `cacert` setting. To resolve the issue, set the `agent-tls-mode` to `system-store`, or upload the CA for Rancher as described in [Adding TLS Secrets](../resources/add-tls-secrets.md).
+
+### New Cluster Deployment is stuck in "Waiting for Agent to check in"
+
+When Rancher has `agent-tls-mode` set to `strict`, new clusters may fail to provision and report a generic "Waiting for Agent to check in" error message. The root cause of this is similar to the above case of TLS errors - Rancher's agent can't determine which CA Rancher is using (or can't verify that Rancher's cert is actually signed by the specified certificate authority).  
+
+To resolve the issue, set the `agent-tls-mode` to `system-store` or upload the CA for Rancher as described in [Adding TLS Secrets](../resources/add-tls-secrets.md).
+
@@ -0,0 +1,236 @@
+---
+title: Upgrades
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades"/>
+</head>
+
+The following instructions will guide you through upgrading a Rancher server that was installed on a Kubernetes cluster with Helm. These steps also apply to air-gapped installs with Helm.
+
+For the instructions to upgrade Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md)
+
+To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
+
+
+## Prerequisites
+
+### Access to kubeconfig
+
+Helm should be run from the same location as your kubeconfig file, or the same location where you run your kubectl commands from.
+
+If you installed Kubernetes with RKE, the config will have been created in the directory you ran `rke up` in.
+
+The kubeconfig can also be manually targeted for the intended cluster with the `--kubeconfig` tag (see: https://helm.sh/docs/helm/helm/)
+
+### Review Known Issues
+
+Review the list of known issues for each Rancher version, which 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.
+
+### Upgrade Path
+
+:::important
+
+**Important:** The only tested and supported Rancher upgrade path between minor versions (e.g. v2.9.x to v2.10.x) is to upgrade from the latest available patch version of your current running minor release to the latest available patch version of the next minor release.
+
+Before initiating a minor version upgrade, verify that you are running the most recent patch release of your current version.
+
+You can query the available chart versions with the Helm CLI:
+
+1. Update your local Helm repo cache.
+
+    ```
+    helm repo update
+    ```
+
+1. Search for available versions in your [specific repository](../resources/choose-a-rancher-version.md#helm-chart-repositories) (e.g., rancher-stable):
+
+    ```
+    helm search repo rancher-<CHART_REPO>/rancher --versions
+    ```
+
+If your installation is not on the latest patch version of the current minor release, you must upgrade to that version before proceeding to the next minor version.
+:::
+
+### Helm Version
+
+The upgrade instructions assume you are using Helm 3.
+
+### For air-gapped installs: Populate private registry
+
+For [air-gapped installs only,](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version. Follow the guide to [populate your private registry](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
+
+### For upgrades with cert-manager older than 0.8.0
+
+[Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753) Upgrade cert-manager to the latest version by following [these instructions.](../resources/upgrade-cert-manager.md)
+
+## Upgrade Outline
+
+Follow the steps to upgrade Rancher server:
+
+### 1. Back up Your Kubernetes Cluster that is Running Rancher Server
+
+Use the [backup application](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) to back up Rancher.
+
+You'll use the backup as a restore point if something goes wrong during upgrade.
+
+### 2. Update the Helm chart repository
+
+1. Update your local Helm repo cache.
+
+    ```
+    helm repo update
+    ```
+
+1. Get the repository name that you used to install Rancher.
+
+    For information about the repos and their differences, see [Helm Chart Repositories](../resources/choose-a-rancher-version.md#helm-chart-repositories).
+
+    - Latest: Recommended for trying out the newest features
+        ```
+        helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+        ```
+    - Stable: Recommended for production environments
+        ```
+        helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+        ```
+    - Alpha: Experimental preview of upcoming releases.
+        ```
+        helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
+        ```
+        Note: Upgrades are not supported to, from, or between Alphas.
+
+    ```
+    helm repo list
+
+    NAME          	       URL
+    stable        	       https://charts.helm.sh/stable
+    rancher-<CHART_REPO>	 https://releases.rancher.com/server-charts/<CHART_REPO>
+    ```
+
+    :::note
+
+    If you want to switch to a different Helm chart repository, please follow the [steps on how to switch repositories](../resources/choose-a-rancher-version.md#switching-to-a-different-helm-chart-repository). If you switch repositories, make sure to list the repositories again before continuing onto Step 3 to ensure you have the correct one added.
+
+    :::
+
+1. Fetch the latest chart to install Rancher from the Helm chart repository.
+
+    This command will pull down the latest charts and save it in the current directory as a `.tgz` file.
+
+    ```plain
+    helm fetch rancher-<CHART_REPO>/rancher
+    ```
+    You can fetch the chart for the specific version you are upgrading to by adding in the `--version=` tag.  For example:
+
+    ```plain
+    helm fetch rancher-<CHART_REPO>/rancher --version=2.6.8
+    ```
+### 3. Review Rancher Feature Chart Versions Before Upgrade
+
+Rancher feature charts follow specific release lines that align with Rancher versions. Major versions of feature charts correspond to Rancher minor versions and follow a defined versioning scheme.
+
+Before upgrading Rancher, review any installed Rancher feature charts and upgrade them to the latest available version within their current chart release line. This helps ensure compatibility and avoids potential issues during or after the Rancher upgrade.
+
+To review installed feature charts:
+
+1. In the Rancher UI, go to **Apps & Marketplace**.
+2. Select **Installed Apps**.
+3. Review the chart versions and upgrade to the latest patch release within the same chart major version if needed.
+
+For more information, see the [Helm Charts in Rancher – Versioning Scheme](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#versioning-scheme).
+
+### 4. Upgrade Rancher
+
+This section describes how to upgrade normal (Internet-connected) or air-gapped installations of Rancher with Helm.
+
+:::note Air Gap Instructions:
+
+If you are installing Rancher in an air-gapped environment, skip the rest of this page and render the Helm template by following the instructions on [this page.](air-gapped-upgrades.md)
+
+:::
+
+Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
+
+```
+helm get values rancher -n cattle-system
+
+hostname: rancher.my.org
+```
+
+:::note
+
+There will be more values that are listed with this command. This is just an example of one of the values.
+
+:::
+
+:::tip
+
+Your deployment name may vary; for example, if you're deploying Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'.
+Thus:
+```
+helm get values rancher-stable -n cattle-system
+
+hostname: rancher.my.org
+```
+
+:::
+
+If you are upgrading cert-manager to the latest version from v1.5 or below, follow the [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#option-c-upgrade-cert-manager-from-versions-15-and-below) to learn how to upgrade cert-manager without needing to perform an uninstall or reinstall of Rancher. Otherwise, follow the [steps to upgrade Rancher](#steps-to-upgrade-rancher) below.
+
+#### Steps to Upgrade Rancher
+
+Upgrade Rancher to the latest version with all your settings.
+
+Take all the values from the previous step and append them to the command using `--set key=value`.
+
+
+```
+helm upgrade rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org
+```
+
+:::note
+
+The above is an example, there may be more values from the previous step that need to be appended.
+
+:::
+
+:::tip
+
+If you deploy Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'.
+Thus:
+```
+helm upgrade rancher-stable rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org
+```
+
+:::
+
+Alternatively, it's possible to export the current values to a file and reference that file during upgrade. For example, to only change the Rancher version:
+
+1. Export the current values to a file:
+    ```
+    helm get values rancher -n cattle-system -o yaml > values.yaml
+    ```
+1. Update only the Rancher version:
+
+
+    ```
+    helm upgrade rancher rancher-<CHART_REPO>/rancher \
+      --namespace cattle-system \
+      -f values.yaml \
+      --version=2.6.8
+    ```
+
+### 5. Verify the Upgrade
+
+Log into Rancher to confirm that the upgrade succeeded.
+
+## Known Upgrade Issues
+
+A list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
@@ -0,0 +1,65 @@
+---
+title: Feature Flags
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references/feature-flags"/>
+</head>
+
+With feature flags, you can try out optional or experimental features, and enable legacy features that are being phased out.
+
+To learn more about feature values and how to enable them, see [Enabling Experimental Features](../../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md).
+
+:::note
+
+Some feature flags require a restart of the Rancher container. Features that require a restart are marked in the Rancher UI.
+
+:::
+
+The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/reference-guides/installation-references/feature-flags.md)):
+
+- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
+- `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
+- `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) for more information.
+- `harvester`: Manages access to the Virtualization Management page, where users can navigate directly to Harvester clusters and access the Harvester UI. See [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md) for more information.
+- `istio-virtual-service-ui`: Enables a [visual interface](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md) to create, read, update, and delete Istio virtual services and destination rules, which are Istio traffic management features.
+- `legacy`: Enables a set of features from 2.5.x and earlier, that are slowly being phased out in favor of newer implementations. These are a mix of deprecated features as well as features that will eventually be available to newer versions. This flag is disabled by default on new Rancher installations. If you're upgrading from a previous version of Rancher, this flag is enabled.
+- `managed-system-upgrade-controller`: Enables the installation of the system-upgrade-controller app in downstream imported RKE2/K3s clusters, as well as in the local cluster if it is an RKE2/K3s cluster.
+
+:::note Important:
+
+This `managed-system-upgrade-controller` flag is intended for **internal use only** and does not have an associated Feature CR. Use with caution.
+
+To control whether Rancher should manage the Kubernetes version of imported RKE2/K3s clusters, it is recommended to use the **imported-cluster-version-management** feature that is available in Rancher v2.11.0 or newer.
+
+For more details, please refer to the Rancher documentation for version v2.11 or newer.
+
+:::
+
+
+- `multi-cluster-management`: Allows multi-cluster provisioning and management of Kubernetes clusters. This flag can only be set at install time. It can't be enabled or disabled later.
+- `rke1-custom-node-cleanup`: Enables cleanup of deleted RKE1 custom nodes. We recommend that you keep this flag enabled, to prevent removed nodes from attempting to rejoin the cluster.
+- `rke2`: Enables provisioning RKE2 clusters. This flag is enabled by default.
+- `token-hashing`: Enables token hashing. Once enabled, existing tokens will be hashed and all new tokens will be hashed automatically with the SHA256 algorithm. Once a token is hashed it can't be undone. This flag can't be disabled after its enabled. See [API Tokens](../../../api/api-tokens.md#token-hashing) for more information.
+- `uiextension`: Enables UI extensions. This flag is enabled by default. Enabling or disabling the flag forces the Rancher pod to restart. The first time this flag is set to `true`, it creates a CRD and enables the controllers and endpoints necessary for the feature to work. If set to `false`, it disables the previously mentioned controllers and endpoints. Setting `uiextension` to `false` has no effect on the CRD -- it does not create a CRD if it does not yet exist, nor does it delete the CRD if it already exists. 
+- `unsupported-storage-drivers`: Enables types for storage providers and provisioners that aren't enabled by default. See [Allow Unsupported Storage Drivers](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md) for more information.
+- `ui-sql-cache`: Enables a SQLite-based cache for UI tables. See [UI Server-Side Pagination](../../../how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination.md) for more information.
+
+
+The following table shows the availability and default values for some feature flags in Rancher. Features marked "GA" are generally available:
+
+| Feature Flag Name             | Default Value | Status       | Available As Of | Additional Information |
+| ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
+| `clean-stale-secrets` | `true` | GA | v2.10.2 | |
+| `continuous-delivery` | `true` | GA | v2.6.0 | |
+| `external-rules` | v2.7.14: `false`, v2.8.5: `true` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
+| `fleet`  | `true` | Can no longer be disabled | v2.6.0 | |
+| `fleet`  | `true` | GA | v2.5.0 | |
+| `harvester` | `true` | Experimental | v2.6.1 | |
+| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
+| `managed-system-upgrade-controller` | `true` | GA | v2.10.0 | |
+| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 | |
+| `rke2` | `true` | Experimental | v2.6.0 | |
+| `token-hashing` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
+| `uiextension` | `true` | GA | v2.9.0 | |
+| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 | |
@@ -0,0 +1,225 @@
+---
+title: Rancher Helm Chart Options
+keywords: [rancher helm chart, rancher helm options, rancher helm chart options, helm chart rancher, helm options rancher, helm chart options rancher]
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references/helm-chart-options"/>
+</head>
+
+This page is a configuration reference for the Rancher Helm chart.
+
+For help choosing a Helm chart version, refer to [this page.](../../../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md)
+
+For information on enabling experimental features, refer to [this page.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)
+
+## Common Options
+
+| Option                    | Default Value | Description                                                                        |
+| ------------------------- | ------------- | ---------------------------------------------------------------------------------- |
+| `bootstrapPassword`       | " "           | `string` - Set the [bootstrap password](#bootstrap-password) for the first admin user. After logging in, the admin should reset their password. A randomly generated bootstrap password is used if this value is not set.
+| `hostname`                | " "           | `string` - the Fully Qualified Domain Name for your Rancher Server                 |
+| `ingress.tls.source`      | "rancher"     | `string` - Where to get the cert for the ingress. - "rancher, letsEncrypt, secret" |
+| `letsEncrypt.email`       | " "           | `string` - Your email address                                                      |
+| `letsEncrypt.environment` | "production"  | `string` - Valid options: "staging, production"                                    |
+| `privateCA`               | false         | `bool` - Set to true if your cert is signed by a private CA                        |
+
+<br/>
+
+## Advanced Options
+
+| Option                         | Default Value                                         | Description                                                                                                                                       |
+| ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `additionalTrustedCAs`         | false                                                 | `bool` - See [Additional Trusted CAs](#additional-trusted-cas)                                                                                    |
+| `addLocal`                     | "true"                                                | `string` - Have Rancher detect and import the "local" (upstream) Rancher server cluster.  _Note: This option is no longer available in v2.5.0. Consider using the `restrictedAdmin` option to prevent users from modifying the local cluster._              |
+| `agentTLSMode`                 | ""                                                    | `string` - either `system-store` or `strict`. See [Agent TLS Enforcement](./tls-settings.md#agent-tls-enforcement) |
+| `antiAffinity`                 | "preferred"                                           | `string` - AntiAffinity rule for Rancher pods - "preferred, required"                                                                             |
+| `auditLog.destination`         | "sidecar"                                             | `string` - Stream to sidecar container console or hostPath volume - "sidecar, hostPath"                                                           |
+| `auditLog.hostPath`            | "/var/log/rancher/audit"                              | `string` - log file destination on host (only applies when `auditLog.destination` is set to `hostPath`)                                           |
+| `auditLog.level`               | 0                                                     | `int` - set the [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md) level. 0 is off. [0-3]                                   |
+| `auditLog.maxAge`              | 1                                                     | `int` - maximum number of days to retain old audit log files (only applies when `auditLog.destination` is set to `hostPath`)                      |
+| `auditLog.maxBackup`           | 1                                                     | `int` - maximum number of audit log files to retain (only applies when `auditLog.destination` is set to `hostPath`)                               |
+| `auditLog.maxSize`             | 100                                                   | `int` - maximum size in megabytes of the audit log file before it gets rotated (only applies when `auditLog.destination` is set to `hostPath`)    |
+| `auditLog.image.repository`    | "registry.suse.com/bci/bci-micro"                     | `string` - Location for the image used to collect audit logs.                                                                                     |
+| `auditLog.image.tag`           | "15.4.14.3"                                           | `string` - Tag for the image used to collect audit logs.                                                                                          |
+| `auditLog.image.pullPolicy`    | "IfNotPresent"                                        | `string` - Override imagePullPolicy for auditLog images - "Always", "Never", "IfNotPresent".                                                   |
+| `busyboxImage`                 | ""                                             | `string` - Image location for busybox image used to collect audit logs. _Note: This option is deprecated use `auditLog.image.repository` to control auditing sidecar image._        |
+| `certmanager.version`          | ""                                                    | `string` - set cert-manager compatibility                                                                                                         |
+| `debug`                        | false                                                 | `bool` - set debug flag on rancher server                                                                                                         |
+| `extraEnv`                     | []                                                    | `list` - set additional environment variables for Rancher                                                          |
+| `imagePullSecrets`             | []                                                    | `list` - list of names of Secret resource containing private registry credentials                                                                 |
+| `ingress.configurationSnippet` | ""                                                    | `string` - additional Nginx configuration. Can be used for proxy configuration.   |
+| `ingress.extraAnnotations`     | {}                                                    | `map` - additional annotations to customize the ingress                                                                                           |
+|  `ingress.enabled` |  true   |    When set to false, Helm will not install a Rancher ingress. Set the option to false to deploy your own ingress.   |
+| `letsEncrypt.ingress.class`    | ""                                                    | `string` - optional ingress class for the cert-manager acmesolver ingress that responds to the Let's Encrypt ACME challenges. Options: traefik, nginx.       |                      |
+| `noProxy`                      | "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local,cattle-system.svc" | `string` - comma separated list of hostnames or ip address not to use the proxy                              |                                     |
+| `proxy`                        | ""                                                    | `string` - HTTP[S] proxy server for Rancher                                                                                                       |
+| `rancherImage`                 | "rancher/rancher"                                     | `string` - rancher image source                                                                                                                   |
+| `rancherImagePullPolicy`       | "IfNotPresent"                                        | `string` - Override imagePullPolicy for rancher server images - "Always", "Never", "IfNotPresent"                                                 |
+| `rancherImageTag`              | same as chart version                                 | `string` - rancher/rancher image tag                                                                                                              |
+| `replicas`                     | 3                                                     | `int` - Number of Rancher server replicas. Setting to -1 will dynamically choose 1, 2, or 3 based on the number of available nodes in the cluster.                                                                                                        |
+| `resources`                    | {}                                                    | `map` - rancher pod resource requests & limits                                                                                                    |
+| `restrictedAdmin`              | `false`                                               | `bool` - When this option is set to `true`, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin). |
+| `systemDefaultRegistry`        | ""                                                    | `string` - private registry to be used for all system container images, e.g., http://registry.example.com/                   |
+| `tls`                          | "ingress"                                             | `string` - See [External TLS Termination](#external-tls-termination) for details. - "ingress, external"                                           |
+| `useBundledSystemChart`        | `false`                                               | `bool` - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations.  |
+
+### Bootstrap Password
+
+You can [set a specific bootstrap password](../resources/bootstrap-password.md) during Rancher installation. If you don't set a specific bootstrap password, Rancher randomly generates a password for the first admin account.
+
+When you log in for the first time, use the bootstrap password you set to log in. If you did not set a bootstrap password, the Rancher UI shows commands that can be used to [retrieve the bootstrap password](../resources/bootstrap-password.md#retrieving-the-bootstrap-password). Run those commands and log in to the account. After you log in for the first time, you are asked to reset the admin password.
+
+### API Audit Log
+
+Enabling the [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md).
+
+You can collect this log as you would any container log. Enable [logging](../../../integrations-in-rancher/logging/logging.md) for the `System` Project on the Rancher server cluster.
+
+```plain
+--set auditLog.level=1
+```
+
+By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`. You can collect this log as you would any container log. When using the sidecar as the audit log destination, the `hostPath`, `maxAge`, `maxBackups`, and `maxSize` options do not apply. It's advised to use your OS or Docker daemon's log rotation features to control disk space use. Enable [logging](../../../integrations-in-rancher/logging/logging.md) for the Rancher server cluster or System Project.
+
+Set the `auditLog.destination` to `hostPath` to forward logs to volume shared with the host system instead of streaming to a sidecar container. When setting the destination to `hostPath` you may want to adjust the other auditLog parameters for log rotation.
+
+### Setting Extra Environment Variables
+
+You can set extra environment variables for Rancher server using `extraEnv`. This list is passed to the Rancher deployment in its YAML format. It is embedded under `env` for the Rancher container. Refer to the Kubernetes documentation for setting container environment variables, `extraEnv` can use any of the keys referenced in [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container).
+
+Consider an example that uses the `name` and `value` keys:
+
+```plain
+--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
+--set 'extraEnv[0].value=1.0'
+```
+
+If passing sensitive data as the value for an environment variable, such as proxy authentication credentials, it is strongly recommended that a secret reference is used. This will prevent sensitive data from being exposed in Helm or the Rancher deployment.
+
+Consider an example that uses the `name`, `valueFrom.secretKeyRef.name`, and `valueFrom.secretKeyRef.key` keys. See example in [HTTP Proxy](#http-proxy)
+
+### TLS Settings
+
+When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. The possible TLS settings depend on the used ingress controller.
+
+See [TLS settings](tls-settings.md) for more information and options.
+
+### Import `local` Cluster
+
+By default Rancher server will detect and import the `local` cluster it's running on. User with access to the `local` cluster will essentially have "root" access to all the clusters managed by Rancher server.
+
+:::caution
+
+If you turn addLocal off, most Rancher v2.5 features won't work, including the EKS provisioner.
+
+:::
+
+If this is a concern in your environment you can set this option to "false" on your initial install.
+
+This option is only effective on the initial Rancher install. See [Issue 16522](https://github.com/rancher/rancher/issues/16522) for more information.
+
+```plain
+--set addLocal="false"
+```
+
+### Customizing your Ingress
+
+To customize or use a different ingress with Rancher server you can set your own Ingress annotations.
+
+Please refer to the Traefik documentation for the full list of Ingress NGINX annotations that are [supported](https://doc.traefik.io/traefik/reference/routing-configuration/kubernetes/ingress-nginx/#annotations-support) and [unsupported](https://doc.traefik.io/traefik/reference/routing-configuration/kubernetes/ingress-nginx/#unsupported-annotations) by Traefik's kubernetesIngressNginx provider.
+
+Example on setting a custom certificate issuer:
+
+```plain
+--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
+```
+
+### HTTP Proxy
+
+Rancher requires internet access for some functionality (Helm charts). Use `proxy` to set your proxy server or use `extraEnv` to set the `HTTPS_PROXY` environment variable to point to your proxy server.
+
+Add your IP exceptions to the `noProxy` chart value as a comma separated list. Make sure you add the following values:
+- Pod cluster IP range (default: `10.42.0.0/16`).
+- Service cluster IP range (default: `10.43.0.0/16`).
+- Internal cluster domains (default: `.svc,.cluster.local`).
+- Any worker cluster `controlplane` nodes.
+Rancher supports CIDR notation ranges in this list.
+
+When not including sensitive data, the `proxy` or `extraEnv` chart options can be used. When using `extraEnv` the `noProxy` Helm option is ignored. Therefore, the `NO_PROXY` environment variable must also be set with `extraEnv`.
+
+The following is an example of setting proxy using the `proxy` chart option:
+
+```plain
+--set proxy="http://<proxy_url:proxy_port>/"
+```
+
+Example of setting proxy using the `extraEnv` chart option:
+```plain
+--set extraEnv[1].name=HTTPS_PROXY
+--set extraEnv[1].value="http://<proxy_url>:<proxy_port>/"
+--set extraEnv[2].name=NO_PROXY
+--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
+```
+
+When including sensitive data, such as proxy authentication credentials, use the `extraEnv` option with `valueFrom.secretRef` to prevent sensitive data from being exposed in Helm or the Rancher deployment.
+
+The following is an example of using `extraEnv` to configure proxy. This example secret would contain the value `"http://<username>:<password>@<proxy_url>:<proxy_port>/"` in the secret's `"https-proxy-url"` key:
+```plain
+--set extraEnv[1].name=HTTPS_PROXY
+--set extraEnv[1].valueFrom.secretKeyRef.name=secret-name
+--set extraEnv[1].valueFrom.secretKeyRef.key=https-proxy-url
+--set extraEnv[2].name=NO_PROXY
+--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
+```
+
+To learn more about how to configure environment variables, refer to [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container).
+
+### Additional Trusted CAs
+
+If you have private registries, catalogs or a proxy that intercepts certificates, you may need to add more trusted CAs to Rancher.
+
+```plain
+--set additionalTrustedCAs=true
+```
+
+Once the Rancher deployment is created, copy your CA certs in pem format into a file named `ca-additional.pem` and use `kubectl` to create the `tls-ca-additional` secret in the `cattle-system` namespace.
+
+```plain
+kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-additional.pem=./ca-additional.pem
+```
+
+### Private Registry and Air Gap Installs
+
+For details on installing Rancher with a private registry, see the [air gap installation docs.](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md)
+
+## External TLS Termination
+
+We recommend configuring your load balancer as a Layer 4 balancer, forwarding plain 80/tcp and 443/tcp to the Rancher Management cluster nodes. The Ingress Controller on the cluster will redirect http traffic on port 80 to https on port 443.
+
+You may terminate the SSL/TLS on a L7 load balancer external to the Rancher cluster (ingress). Use the `--set tls=external` option and point your load balancer at port http 80 on all of the Rancher cluster nodes. This will expose the Rancher interface on http port 80. Be aware that clients that are allowed to connect directly to the Rancher cluster will not be encrypted. If you choose to do this we recommend that you restrict direct access at the network level to just your load balancer.
+
+:::note
+
+If you are using a Private CA signed certificate (or if `agent-tls-mode` is set to `strict`), add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate](../../../getting-started/installation-and-upgrade/resources/add-tls-secrets.md) to add the CA cert for Rancher. 
+
+:::
+
+Your load balancer must support long lived websocket connections and will need to insert proxy headers so Rancher can route links correctly.
+
+### Required Headers
+
+- `Host`
+- `X-Forwarded-Proto`
+- `X-Forwarded-Port`
+- `X-Forwarded-For`
+
+### Recommended Timeouts
+
+- Read Timeout: `1800 seconds`
+- Write Timeout: `1800 seconds`
+- Connect Timeout: `30 seconds`
+
+### Health Checks
+
+Rancher will respond `200` to health checks on the `/healthz` endpoint.
@@ -0,0 +1,101 @@
+---
+title: TLS Settings
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references/tls-settings"/>
+</head>
+
+Changing the default TLS settings depends on the chosen installation method.
+
+## Running Rancher in a highly available Kubernetes cluster
+
+When you install a Rancher managed Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. Traefik is the default ingress for K3s and can be used with RKE2, refer to [TLS Options](https://doc.traefik.io/traefik/https/tls/#tls-options) for further information.
+
+## Running Rancher in a single Docker container
+
+The default TLS configuration only accepts TLS 1.2 and secure TLS cipher suites. You can change this by setting the following environment variables:
+
+| Parameter | Description | Default | Available options |
+|-----|-----|-----|-----|
+| `CATTLE_TLS_MIN_VERSION` | Minimum TLS version | `1.2` | `1.0`, `1.1`, `1.2`, `1.3` |
+| `CATTLE_TLS_CIPHERS` | Allowed TLS cipher suites | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`,<br/>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | See [Golang tls constants](https://golang.org/pkg/crypto/tls/#pkg-constants) |
+
+## Agent TLS Enforcement
+
+The `agent-tls-mode` setting controls how Rancher's agents (`cluster-agent`, `fleet-agent`, and `system-agent`) validate Rancher's certificate.
+
+When the value is set to `strict`, Rancher's agents only trust certificates generated by the Certificate Authority contained in the `cacerts` setting. 
+When the value is set to `system-store`, Rancher's agents trust any certificate generated by a public Certificate Authority contained in the operating system's trust store including those signed by authorities such as Let's Encrypt. This can be a security risk, since any certificate generated by these external authorities, which are outside the user's control, are considered valid in this state.
+
+While the `strict` option enables a higher level of security, it requires Rancher to have access to the CA which generated the certificate visible to the agents. In the case of certain certificate configurations (notably, external certificates), this is not automatic, and extra configuration is needed. See the [installation guide](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md#3-choose-your-ssl-configuration) for more information on which scenarios require extra configuration.
+
+In Rancher v2.9.0 and later, this setting defaults to `strict` on new installs. For users installing or upgrading from a prior Rancher version, it is set to `system-store`.
+
+### Preparing for the Setting Change
+
+Each cluster contains a condition in the status field called `AgentTlsStrictCheck`. If `AgentTlsStrictCheck` is set to `"True"`, this indicates that the agents for the cluster are ready to operate in `strict` mode. You can manually inspect each cluster to see if they are ready using the Rancher UI or a kubectl command such as the following:
+
+```bash
+## the below command skips ouputs $CLUSTER_NAME,$STATUS for all non-local clusters
+kubectl get cluster.management.cattle.io -o jsonpath='{range .items[?(@.metadata.name!="local")]}{.metadata.name},{.status.conditions[?(@.type=="AgentTlsStrictCheck")].status}{"\n"}{end}'
+```
+
+### Changing the Setting
+
+You can change the setting using the Rancher UI or the `agentTLSMode` [helm chart option](./helm-chart-options.md).
+
+:::note
+
+If you specify the value through the Helm chart, you may only modify the value with Helm.
+
+:::
+
+:::warning
+
+Depending on your cert setup, additional action may be required, such as uploading the Certificate Authority which signed your certs. Review the [installation guide](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md#3-choose-your-ssl-configuration) before changing the setting to see if any additional requirements apply to your setup.
+
+:::
+
+To change the setting's value through the UI, navigate to the **Global Settings** page, and find the `agent-tls-mode` setting near the bottom of the page. When you change the setting through the UI, Rancher first checks that all downstream clusters have the condition `AgentTlsStrictCheck` set to `"True"` before allowing the request. This prevents outages from a certificate mismatch.
+
+
+#### Overriding the Setting Validation Checks
+
+In some cases, you may want to override the check ensuring all agents can accept the new TLS configuration:
+
+:::warning
+
+Rancher checks the status of all downstream clusters to prevent outages. Overriding this check is not recommended, and should be done with great caution.
+
+:::
+
+1. As an admin, generate a kubeconfig for the local cluster. In the below examples, this was saved to the `local_kubeconfig.yaml` file.
+2. Retrieve the current setting and save it to `setting.yaml`:
+```bash
+kubectl get setting agent-tls-mode -o yaml --kubeconfig=local_kubeconfig.yaml > setting.yaml
+```
+3. Update the `setting.yaml` file, replacing `value` with `strict`. Adding the `cattle.io/force: "true"` annotation overrides the cluster condition check, and should only be done with great care:
+
+:::warning
+
+Including the `cattle.io/force` annotation with any value (including, for example `"false"`) overrides the cluster condition check.
+
+:::
+
+```yaml
+apiVersion: management.cattle.io/v3
+customized: false
+default: strict
+kind: Setting
+metadata:
+  name: agent-tls-mode
+  annotations:
+    cattle.io/force: "true"
+source: ""
+value: strict
+```
+4. Apply the new version of the setting:
+```bash
+kubectl apply -f setting.yaml --kubeconfig=local_kubeconfig.yaml
+```
@@ -0,0 +1,350 @@
+---
+title: Port Requirements
+description: Read about port requirements needed in order for Rancher to operate properly, both for Rancher nodes and downstream Kubernetes cluster nodes
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-requirements/port-requirements"/>
+</head>
+
+import PortsIaasNodes from '@site/src/components/PortsIaasNodes'
+import PortsCustomNodes from '@site/src/components/PortsCustomNodes'
+import PortsImportedHosted from '@site/src/components/PortsImportedHosted'
+
+To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes.
+
+## Rancher Nodes
+
+The following table lists the ports that need to be open to and from nodes that are running the Rancher server.
+
+The port requirements differ based on the Rancher server architecture.
+
+Rancher can be installed on any Kubernetes cluster. For Rancher installs on a K3s, RKE, or RKE2 Kubernetes cluster, refer to the tabs below. For other Kubernetes distributions, refer to the distribution's documentation for the port requirements for cluster nodes.
+
+:::note Notes:
+
+- Rancher nodes may also require additional outbound access for any external authentication provider which is configured (LDAP for example).
+- Kubernetes recommends TCP 30000-32767 for node port services.
+- For firewalls, traffic may need to be enabled within the cluster and pod CIDR.
+- Rancher nodes may also need outbound access to an external S3 location which is used for storing cluster backups (Minio for example).
+
+:::
+
+### Ports for Rancher Server Nodes on K3s
+
+<details>
+  <summary>Click to expand</summary>
+
+The K3s server needs port 6443 to be accessible by the nodes.
+
+The nodes need to be able to reach other nodes over UDP port 8472 when Flannel VXLAN is used. The node should not listen on any other port. K3s uses reverse tunneling such that the nodes make outbound connections to the server and all kubelet traffic runs through that tunnel. However, if you do not use Flannel and provide your own custom CNI, then port 8472 is not needed by K3s.
+
+If you wish to utilize the metrics server, you will need to open port 10250 on each node.
+
+:::note Important:
+
+The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
+
+:::
+
+The following tables break down the port requirements for inbound and outbound traffic:
+
+<figcaption>Inbound Rules for Rancher Server Nodes</figcaption>
+
+| Protocol | Port | Source | Description
+|-----|-----|----------------|---|
+| TCP      | 80   | Load balancer/proxy that does external SSL termination                                                                                                                                | Rancher UI/API when external SSL termination is used |
+| TCP      | 443  | <ul><li>server nodes</li><li>agent nodes</li><li>hosted/registered Kubernetes</li><li>any source that needs to be able to use the Rancher UI or API</li></ul> | Rancher agent, Rancher UI/API, kubectl               |
+| TCP | 6443 | K3s server nodes | Kubernetes API
+| UDP | 8472 | K3s server and agent nodes | Required only for Flannel VXLAN.
+| TCP | 10250 | K3s server and agent nodes | kubelet
+
+<figcaption>Outbound Rules for Rancher Nodes</figcaption>
+
+| Protocol | Port | Destination                                              | Description                                   |
+| -------- | ---- | -------------------------------------------------------- | --------------------------------------------- |
+| TCP      | 22   | Any node IP from a node created using Node Driver        | SSH provisioning of nodes using Node Driver   |
+| TCP      | 443  | git.rancher.io |  Rancher catalog                     |
+| TCP      | 2376 | Any node IP from a node created using Node driver        | Docker daemon TLS port used by Docker Machine |
+| TCP      | 6443 | Hosted/Imported Kubernetes API                           | Kubernetes API server                         |
+
+</details>
+
+### Ports for Rancher Server Nodes on RKE
+
+<details>
+  <summary>Click to expand</summary>
+
+Typically Rancher is installed on three RKE nodes that all have the etcd, control plane and worker roles.
+
+The following tables break down the port requirements for traffic between the Rancher nodes:
+
+<figcaption>Rules for traffic between Rancher nodes</figcaption>
+
+| Protocol | Port | Description |
+|-----|-----|----------------|
+| TCP | 443 | Rancher agents |
+| TCP | 2379 | etcd client requests |
+| TCP | 2380 | etcd peer communication |
+| TCP | 6443 | Kubernetes apiserver |
+| TCP | 8443 | Nginx Ingress's Validating Webhook |
+| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
+| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
+| TCP | 10250 | Metrics server communication with all nodes |
+| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
+
+The following tables break down the port requirements for inbound and outbound traffic:
+
+<figcaption>Inbound Rules for Rancher Nodes</figcaption>
+
+| Protocol | Port | Source | Description |
+|-----|-----|----------------|---|
+| TCP | 22 | RKE CLI | SSH provisioning of node by RKE |
+| TCP | 80 | Load Balancer/Reverse Proxy | HTTP traffic to Rancher UI/API |
+| TCP | 443 | <ul><li>Load Balancer/Reverse Proxy</li><li>IPs of all cluster nodes and other API/UI clients</li></ul> | HTTPS traffic to Rancher UI/API |
+| TCP | 6443 | Kubernetes API clients | HTTPS traffic to Kubernetes API |
+
+<figcaption>Outbound Rules for Rancher Nodes</figcaption>
+
+| Protocol | Port | Destination | Description |
+|-----|-----|----------------|---|
+| TCP | 443 | git.rancher.io | Rancher catalog |
+| TCP | 22 | Any node created using a node driver | SSH provisioning of node by node driver |
+| TCP | 2376 | Any node created using a node driver | Docker daemon TLS port used by node driver |
+| TCP | 6443 | Hosted/Imported Kubernetes API                           | Kubernetes API server                         |
+| TCP | Provider dependent | Port of the Kubernetes API endpoint in hosted cluster | Kubernetes API |
+
+</details>
+
+### Ports for Rancher Server Nodes on RKE2
+
+<details>
+  <summary>Click to expand</summary>
+
+The RKE2 server needs port 6443 and 9345 to be accessible by other nodes in the cluster.
+
+All nodes need to be able to reach other nodes over UDP port 8472 when Flannel VXLAN is used.
+
+If you wish to utilize the metrics server, you will need to open port 10250 on each node.
+
+:::note Important:
+
+The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
+
+:::
+
+<figcaption>Inbound Rules for RKE2 Server Nodes</figcaption>
+
+| Protocol | Port | Source | Description
+|-----|-----|----------------|---|
+| TCP | 9345 | RKE2 server and agent nodes | Node registration. Port should be open on all server nodes to all other nodes in the cluster.
+| TCP | 6443 | RKE2 agent nodes | Kubernetes API
+| UDP | 8472 | RKE2 server and agent nodes | Required only for Flannel VXLAN
+| TCP | 10250 | RKE2 server and agent nodes | kubelet
+| TCP | 2379 | RKE2 server nodes | etcd client port
+| TCP | 2380 | RKE2 server nodes | etcd peer port
+| TCP | 30000-32767 | RKE2 server and agent nodes | NodePort port range. Can use TCP or UDP.
+| TCP | 5473 | Calico-node pod connecting to typha pod | Required when deploying with Calico
+| HTTP | 80 | Load balancer/proxy that does external SSL termination | Rancher UI/API when external SSL termination is used |
+| HTTPS | 443 | <ul><li>hosted/registered Kubernetes</li><li>any source that needs to be able to use the Rancher UI or API</li></ul> | Rancher agent, Rancher UI/API, kubectl. Not needed if you have a load balancer doing TLS termination. |
+
+Typically all outbound traffic is allowed.
+</details>
+
+### Ports for Rancher Server in Docker
+
+<details>
+  <summary>Click to expand</summary>
+
+The following tables break down the port requirements for Rancher nodes, for inbound and outbound traffic:
+
+<figcaption>Inbound Rules for Rancher Node</figcaption>
+
+| Protocol | Port | Source | Description
+|-----|-----|----------------|---|
+| TCP | 80 | Load balancer/proxy that does external SSL termination | Rancher UI/API when external SSL termination is used
+| TCP | 443 | <ul><li>hosted/registered Kubernetes</li><li>any source that needs to be able to use the Rancher UI or API</li></ul> | Rancher agent, Rancher UI/API, kubectl
+
+<figcaption>Outbound Rules for Rancher Node</figcaption>
+
+| Protocol | Port | Source | Description |
+|-----|-----|----------------|---|
+| TCP | 22 | Any node IP from a node created using Node Driver | SSH provisioning of nodes using Node Driver |
+| TCP | 443 | git.rancher.io |  Rancher catalog |
+| TCP | 2376 | Any node IP from a node created using a node driver | Docker daemon TLS port used by Docker Machine |
+| TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
+
+</details>
+
+## Downstream Kubernetes Cluster Nodes
+
+Downstream Kubernetes clusters run your apps and services. This section describes what ports need to be opened on the nodes in downstream clusters so that Rancher can communicate with them.
+
+The port requirements differ depending on how the downstream cluster was launched. Each of the tabs below list the ports that need to be opened for different [cluster types](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md).
+
+The following diagram depicts the ports that are opened for each [cluster type](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md).
+
+<figcaption>Port Requirements for the Rancher Management Plane</figcaption>
+
+![Basic Port Requirements](/img/port-communications.svg)
+
+:::tip
+
+If security isn't a large concern and you're okay with opening a few additional ports, you can use the table in [Commonly Used Ports](#commonly-used-ports) as your port reference instead of the comprehensive tables below.
+
+:::
+
+### Ports for Harvester Clusters
+
+Refer to the [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md#port-requirements) for more information on Harvester port requirements.
+
+
+### Ports for Rancher Launched Kubernetes Clusters using Node Pools
+
+<details>
+  <summary>Click to expand</summary>
+
+The following table depicts the port requirements for [Rancher Launched Kubernetes](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) with nodes created in an [Infrastructure Provider](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).
+
+:::note
+
+The required ports are automatically opened by Rancher during creation of clusters in cloud providers like Amazon EC2 or DigitalOcean.
+
+:::
+
+ <PortsIaasNodes/>
+
+</details>
+
+### Ports for Rancher Launched Kubernetes Clusters using Custom Nodes
+
+<details>
+  <summary>Click to expand</summary>
+
+The following table depicts the port requirements for [Rancher Launched Kubernetes](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) with [Custom Nodes](../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md).
+
+<PortsCustomNodes/>
+
+</details>
+
+### Ports for Hosted Kubernetes Clusters
+
+<details>
+  <summary>Click to expand</summary>
+
+The following table depicts the port requirements for [hosted clusters](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md).
+
+<PortsImportedHosted/>
+
+</details>
+
+### Ports for Registered Clusters
+
+:::note
+
+Registered clusters were called imported clusters before Rancher v2.5.
+
+:::
+
+<details>
+  <summary>Click to expand</summary>
+
+The following table depicts the port requirements for [registered clusters](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md).
+
+<PortsImportedHosted/>
+
+</details>
+
+
+## Other Port Considerations
+
+### Commonly Used Ports
+
+These ports are typically opened on your Kubernetes nodes, regardless of what type of cluster it is.
+
+import CommonPortsTable from '../../../shared-files/_common-ports-table.md';
+
+<CommonPortsTable />
+
+----
+
+### Local Node Traffic
+
+Ports marked as `local traffic` (i.e., `9099 TCP`) in the above requirements are used for Kubernetes healthchecks (`livenessProbe` and`readinessProbe`).
+These healthchecks are executed on the node itself. In most cloud environments, this local traffic is allowed by default.
+
+However, this traffic may be blocked when:
+
+- You have applied strict host firewall policies on the node.
+- You are using nodes that have multiple interfaces (multihomed).
+
+In these cases, you have to explicitly allow this traffic in your host firewall, or in case of public/private cloud hosted machines (i.e. AWS or OpenStack), in your security group configuration. Keep in mind that when using a security group as source or destination in your security group, explicitly opening ports only applies to the private interface of the nodes / instances.
+
+### Rancher AWS EC2 Security Group
+
+When using the [AWS EC2 node driver](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) to provision cluster nodes in Rancher, you can choose to let Rancher create a security group called `rancher-nodes`. The following rules are automatically added to this security group.
+
+| Type            | Protocol | Port Range  | Source/Destination     | Rule Type |
+|-----------------|:--------:|:-----------:|------------------------|:---------:|
+| SSH             |   TCP    |     22      | 0.0.0.0/0 and ::/0     |  Inbound  |
+| HTTP            |   TCP    |     80      | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |     443     | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |    8443     | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |    2376     | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |    6443     | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |     179     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |    5473     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |    9345     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |  2379-2380  | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    | 10250-10252 | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |    10256    | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom UDP Rule |   UDP    |    4789     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom UDP Rule |   UDP    |    8472     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |    9796     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    | 30000-32767 | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom UDP Rule |   UDP    | 30000-32767 | 0.0.0.0/0 and ::/0     |  Inbound  |
+| All traffic     |   All    |     All     | 0.0.0.0/0 and ::/0     | Outbound  |
+
+### Opening SUSE Linux Ports
+
+SUSE Linux may have a firewall that blocks all ports by default. To open the ports needed for adding the host to a custom cluster,
+
+<Tabs>
+<TabItem value="SLES 15 / openSUSE Leap 15">
+
+1. SSH into the instance.
+1. Start YaST in text mode:
+    ```
+    sudo yast2
+    ```
+
+1. Navigate to **Security and Users** > **Firewall** > **Zones:public** > **Ports**. To navigate within the interface, follow these [instructions](https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-yast-text.html#sec-yast-cli-navigate).
+1. To open the required ports, enter them into the **TCP Ports** and **UDP Ports** fields. In this example, ports 9796 and 10250 are also opened for monitoring. The resulting fields should look similar to the following:
+    ```yaml
+    TCP Ports
+    22, 80, 443, 2376, 2379, 2380, 6443, 9099, 9796, 10250, 10254, 30000-32767
+    UDP Ports
+    8472, 30000-32767
+    ```
+
+1. When all required ports are enter, select **Accept**.
+
+</TabItem>
+<TabItem value="SLES 12 / openSUSE Leap 42">
+
+1. SSH into the instance.
+1. Edit /`etc/sysconfig/SuSEfirewall2` and open the required ports. In this example, ports 9796 and 10250 are also opened for monitoring:
+    ```
+    FW_SERVICES_EXT_TCP="22 80 443 2376 2379 2380 6443 9099 9796 10250 10254 30000:32767"
+    FW_SERVICES_EXT_UDP="8472 30000:32767"
+    FW_ROUTE=yes
+    ```
+1. Restart the firewall with the new ports:
+    ```
+    SuSEfirewall2
+    ```
+
+</TabItem>
+</Tabs>
+
+**Result:** The node has the open ports required to be added to a custom cluster.
@@ -0,0 +1,394 @@
+---
+title: '3. Install Kubernetes (Skip for Docker Installs)'
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes"/>
+</head>
+
+:::note
+
+Skip this section if you are installing Rancher on a single node with Docker.
+
+:::
+
+This section describes how to install a Kubernetes cluster according to our [best practices for the Rancher server environment.](../../../../reference-guides/rancher-manager-architecture/architecture-recommendations.md#environment-for-kubernetes-installations) This cluster should be dedicated to run only the Rancher server.
+
+Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes providers.
+
+The steps to set up an air-gapped Kubernetes cluster on RKE, RKE2, or K3s are shown below.
+
+<Tabs>
+<TabItem value="K3s">
+
+In this guide, we are assuming you have created your nodes in your air gapped environment and have a secure Docker private registry on your bastion server.
+
+## Installation Outline
+
+1. [Prepare Images Directory](#1-prepare-images-directory)
+2. [Create Registry YAML](#2-create-registry-yaml)
+3. [Install K3s](#3-install-k3s)
+4. [Save and Start Using the kubeconfig File](#4-save-and-start-using-the-kubeconfig-file)
+
+## 1. Prepare Images Directory
+
+Obtain the images tar file for your architecture from the [releases](https://github.com/k3s-io/k3s/releases) page for the version of K3s you will be running.
+
+Place the tar file in the `images` directory before starting K3s on each node, for example:
+
+```sh
+sudo mkdir -p /var/lib/rancher/k3s/agent/images/
+sudo cp ./k3s-airgap-images-$ARCH.tar /var/lib/rancher/k3s/agent/images/
+```
+
+## 2. Create Registry YAML
+
+Create the registries.yaml file at `/etc/rancher/k3s/registries.yaml`. This will tell K3s the necessary details to connect to your private registry.
+
+The registries.yaml file should look like this before plugging in the necessary information:
+
+```yaml
+---
+mirrors:
+  customreg:
+    endpoint:
+      - "https://ip-to-server:5000"
+configs:
+  customreg:
+    auth:
+      username: xxxxxx # this is the registry username
+      password: xxxxxx # this is the registry password
+    tls:
+      cert_file: <path to the cert file used in the registry>
+      key_file:  <path to the key file used in the registry>
+      ca_file: <path to the ca file used in the registry>
+```
+
+Note, at this time only secure registries are supported with K3s (SSL with custom CA).
+
+For more information on private registries configuration file for K3s, refer to the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/private-registry/)
+
+## 3. Install K3s
+
+Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
+
+To specify the K3s (Kubernetes) version, use the INSTALL_K3S_VERSION (e.g., `INSTALL_K3S_VERSION="v1.24.10+k3s1"`) environment variable when running the K3s installation script.
+
+Obtain the K3s binary from the [releases](https://github.com/k3s-io/k3s/releases) page, matching the same version used to get the airgap images tar.
+Also obtain the K3s install script at https://get.k3s.io
+
+Place the binary in `/usr/local/bin` on each node.
+Place the install script anywhere on each node, and name it `install.sh`.
+
+Install K3s on each server:
+
+```
+INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_VERSION=<VERSION> ./install.sh
+```
+
+Install K3s on each agent:
+
+```
+INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_VERSION=<VERSION> K3S_URL=https://<SERVER>:6443 K3S_TOKEN=<TOKEN> ./install.sh
+```
+
+Where `<SERVER>` is the IP or valid DNS of the server and `<TOKEN>` is the node-token from the server found at `/var/lib/rancher/k3s/server/node-token`.
+
+:::note
+
+K3s additionally provides a `--resolv-conf` flag for kubelets, which may help with configuring DNS in air-gapped networks.
+
+:::
+
+## 4. Save and Start Using the kubeconfig File
+
+When you installed K3s on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/k3s/k3s.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
+
+To use this `kubeconfig` file,
+
+1. Install [kubectl,](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) a Kubernetes command-line tool.
+2. Copy the file at `/etc/rancher/k3s/k3s.yaml` and save it to the directory `~/.kube/config` on your local machine.
+3. In the kubeconfig file, the `server` directive is defined as localhost. Configure the server as the DNS of your load balancer, referring to port 6443. (The Kubernetes API server will be reached at port 6443, while the Rancher server will be reached at ports 80 and 443.) Here is an example `k3s.yaml`:
+
+```yaml
+apiVersion: v1
+clusters:
+- cluster:
+    certificate-authority-data: [CERTIFICATE-DATA]
+    server: [LOAD-BALANCER-DNS]:6443 # Edit this line
+  name: default
+contexts:
+- context:
+    cluster: default
+    user: default
+  name: default
+current-context: default
+kind: Config
+preferences: {}
+users:
+- name: default
+  user:
+    password: [PASSWORD]
+    username: admin
+```
+
+**Result:** You can now use `kubectl` to manage your K3s cluster. If you have more than one kubeconfig file, you can specify which one you want to use by passing in the path to the file when using `kubectl`:
+
+```
+kubectl --kubeconfig ~/.kube/config/k3s.yaml get pods --all-namespaces
+```
+
+For more information about the `kubeconfig` file, refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/cluster-access/) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
+
+## Note on Upgrading
+
+Upgrading an air-gap environment can be accomplished in the following manner:
+
+1. Download the new air-gap images (tar file) from the [releases](https://github.com/k3s-io/k3s/releases) page for the version of K3s you will be upgrading to. Place the tar in the `/var/lib/rancher/k3s/agent/images/` directory on each node. Delete the old tar file.
+2. Copy and replace the old K3s binary in `/usr/local/bin` on each node. Copy over the install script at https://get.k3s.io (as it is possible it has changed since the last release). Run the script again just as you had done in the past with the same environment variables.
+3. Restart the K3s service (if not restarted automatically by installer).
+
+</TabItem>
+<TabItem value="RKE2">
+
+In this guide, we are assuming you have created your nodes in your air-gapped environment and have a secure Docker private registry on your bastion server.
+
+## Installation Outline
+
+1. [Create RKE2 configuration](#1-create-rke2-configuration)
+2. [Create Registry YAML](#2-create-registry-yaml)
+3. [Install RKE2](#3-install-rke2)
+4. [Save and Start Using the kubeconfig File](#4-save-and-start-using-the-kubeconfig-file)
+
+## 1. Create RKE2 configuration
+
+Create the config.yaml file at `/etc/rancher/rke2/config.yaml`. This will contain all the configuration options necessary to create a highly available RKE2 cluster.
+
+On the first server the minimum config is:
+
+```
+token: my-shared-secret
+tls-san:
+  - loadbalancer-dns-domain.com
+```
+
+On each other server the config file should contain the same token and tell RKE2 to connect to the existing first server:
+
+```
+server: https://ip-of-first-server:9345
+token: my-shared-secret
+tls-san:
+  - loadbalancer-dns-domain.com
+```
+
+For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/ha).
+
+:::note
+
+RKE2 additionally provides a `resolv-conf` option for kubelets, which may help with configuring DNS in air-gap networks.
+
+:::
+
+## 2. Create Registry YAML
+
+Create the registries.yaml file at `/etc/rancher/rke2/registries.yaml`. This will tell RKE2 the necessary details to connect to your private registry.
+
+The registries.yaml file should look like this before plugging in the necessary information:
+
+```
+---
+mirrors:
+  customreg:
+    endpoint:
+      - "https://ip-to-server:5000"
+configs:
+  customreg:
+    auth:
+      username: xxxxxx # this is the registry username
+      password: xxxxxx # this is the registry password
+    tls:
+      cert_file: <path to the cert file used in the registry>
+      key_file:  <path to the key file used in the registry>
+      ca_file: <path to the ca file used in the registry>
+```
+
+For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/private_registry)
+
+## 3. Install RKE2
+
+Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/)
+
+Download the install script, rke2, rke2-images, and sha256sum archives from the release and upload them into a directory on each server:
+
+```
+mkdir /tmp/rke2-artifacts && cd /tmp/rke2-artifacts/
+wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/rke2-images.linux-amd64.tar.zst
+wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/rke2.linux-amd64.tar.gz
+wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/sha256sum-amd64.txt
+curl -sfL https://get.rke2.io --output install.sh
+```
+
+Next, run install.sh using the directory on each server, as in the example below:
+
+```
+INSTALL_RKE2_ARTIFACT_PATH=/tmp/rke2-artifacts sh install.sh
+```
+
+Then enable and start the service on all servers:
+
+``
+systemctl enable rke2-server.service
+systemctl start rke2-server.service
+``
+
+For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/airgap).
+
+## 4. Save and Start Using the kubeconfig File
+
+When you installed RKE2 on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/rke2/rke2.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
+
+To use this `kubeconfig` file,
+
+1. Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl), a Kubernetes command-line tool.
+2. Copy the file at `/etc/rancher/rke2/rke2.yaml` and save it to the directory `~/.kube/config` on your local machine.
+3. In the kubeconfig file, the `server` directive is defined as localhost. Configure the server as the DNS of your load balancer, referring to port 6443. (The Kubernetes API server will be reached at port 6443, while the Rancher server will be reached at ports 80 and 443.) Here is an example `rke2.yaml`:
+
+```
+apiVersion: v1
+clusters:
+- cluster:
+    certificate-authority-data: [CERTIFICATE-DATA]
+    server: [LOAD-BALANCER-DNS]:6443 # Edit this line
+  name: default
+contexts:
+- context:
+    cluster: default
+    user: default
+  name: default
+current-context: default
+kind: Config
+preferences: {}
+users:
+- name: default
+  user:
+    password: [PASSWORD]
+    username: admin
+```
+
+**Result:** You can now use `kubectl` to manage your RKE2 cluster. If you have more than one kubeconfig file, you can specify which one you want to use by passing in the path to the file when using `kubectl`:
+
+```
+kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
+```
+
+For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
+
+## Note on Upgrading
+
+Upgrading an air-gap environment can be accomplished in the following manner:
+
+1. Download the new air-gap artifacts and install script from the [releases](https://github.com/rancher/rke2/releases) page for the version of RKE2 you will be upgrading to.
+2. Run the script again just as you had done in the past with the same environment variables.
+3. Restart the RKE2 service.
+
+</TabItem>
+<TabItem value="RKE">
+We will create a Kubernetes cluster using Rancher Kubernetes Engine (RKE). Before being able to start your Kubernetes cluster, you’ll need to install RKE and create a RKE config file.
+
+## 1. Install RKE
+
+Install RKE by following the instructions in the [RKE documentation.](https://rancher.com/docs/rke/latest/en/installation/)
+
+:::note
+
+Certified version(s) of RKE based on the Rancher version can be found in the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
+
+:::
+
+## 2. Create an RKE Config File
+
+From a system that can access ports 22/TCP and 6443/TCP on the Linux host node(s) that you set up in a previous step, use the sample below to create a new file named `rancher-cluster.yml`.
+
+This file is an RKE configuration file, which is a configuration for the cluster you're deploying Rancher to.
+
+Replace values in the code sample below with help of the _RKE Options_ table. Use the IP address or DNS names of the three nodes you created.
+
+:::tip
+
+For more details on the options available, see the RKE [Config Options](https://rancher.com/docs/rke/latest/en/config-options/).
+
+:::
+
+<figcaption>RKE Options</figcaption>
+
+| Option             | Required             | Description                                                                             |
+| ------------------ | -------------------- | --------------------------------------------------------------------------------------- |
+| `address`          | ✓                    | The DNS or IP address for the node within the air gapped network.                          |
+| `user`             | ✓                    | A user that can run Docker commands.                                                    |
+| `role`             | ✓                    | List of Kubernetes roles assigned to the node.                                          |
+| `internal_address` | optional<sup>1</sup> | The DNS or IP address used for internal cluster traffic.                                |
+| `ssh_key_path`     |                      | Path to the SSH private key used to authenticate to the node (defaults to `~/.ssh/id_rsa`). |
+
+> <sup>1</sup> Some services like AWS EC2 require setting the `internal_address` if you want to use self-referencing security groups or firewalls.
+
+```yaml
+nodes:
+  - address: 10.10.3.187 # node air gap network IP
+    internal_address: 172.31.7.22 # node intra-cluster IP
+    user: rancher
+    role: ['controlplane', 'etcd', 'worker']
+    ssh_key_path: /home/user/.ssh/id_rsa
+  - address: 10.10.3.254 # node air gap network IP
+    internal_address: 172.31.13.132 # node intra-cluster IP
+    user: rancher
+    role: ['controlplane', 'etcd', 'worker']
+    ssh_key_path: /home/user/.ssh/id_rsa
+  - address: 10.10.3.89 # node air gap network IP
+    internal_address: 172.31.3.216 # node intra-cluster IP
+    user: rancher
+    role: ['controlplane', 'etcd', 'worker']
+    ssh_key_path: /home/user/.ssh/id_rsa
+
+private_registries:
+  - url: <REGISTRY.YOURDOMAIN.COM:PORT> # private registry url
+    user: rancher
+    password: '*********'
+    is_default: true
+```
+
+## 3. Run RKE
+
+After configuring `rancher-cluster.yml`, bring up your Kubernetes cluster:
+
+```
+rke up --config ./rancher-cluster.yml
+```
+
+## 4. Save Your Files
+
+:::note Important:
+
+The files mentioned below are needed to maintain, troubleshoot, and upgrade your cluster.
+
+:::
+
+Save a copy of the following files in a secure location:
+
+- `rancher-cluster.yml`: The RKE cluster configuration file.
+- `kube_config_cluster.yml`: The [Kubeconfig file](https://rancher.com/docs/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
+- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file](https://rancher.com/docs/rke/latest/en/installation/#kubernetes-cluster-state), this file contains the current state of the cluster including the RKE configuration and the certificates.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
+
+</TabItem>
+</Tabs>
+
+:::note
+
+The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
+
+:::
+
+## Issues or Errors?
+
+See the [Troubleshooting](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md) page.
+
+## [Next: Install Rancher](install-rancher-ha.md)
@@ -0,0 +1,250 @@
+---
+title: 4. Install Rancher
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha"/>
+</head>
+
+This section is about how to deploy Rancher for your air gapped environment in a high-availability Kubernetes installation. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy.
+
+## Privileged Access for Rancher
+
+When the Rancher server is deployed in the Docker container, a local Kubernetes cluster is installed within the container for Rancher to use. Because many features of Rancher run as deployments, and privileged mode is required to run containers within containers, you will need to install Rancher with the `--privileged` option.
+
+## Docker Instructions
+
+If you want to continue the air gapped installation using Docker commands, skip the rest of this page and follow the instructions on [this page.](docker-install-commands.md)
+
+## Kubernetes Instructions
+
+Rancher recommends installing Rancher on a Kubernetes cluster. A highly available Kubernetes install is comprised of three nodes running the Rancher server components on a Kubernetes cluster. The persistence layer (etcd) is also replicated on these three nodes, providing redundancy and data duplication in case one of the nodes fails.
+
+### 1. Add the Helm Chart Repository
+
+From a system that has access to the internet, fetch the latest Helm chart and copy the resulting manifests to a system that has access to the Rancher server cluster.
+
+1. If you haven't already, install `helm` locally on a workstation that has internet access. Note: Refer to the [Helm version requirements](../../resources/helm-version-requirements.md) to choose a version of Helm to install Rancher.
+
+2. Use `helm repo add` command to add the Helm chart repository that contains charts to install Rancher. For more information about the repository choices and which is best for your use case, see [Choosing a Rancher Version](../../resources/choose-a-rancher-version.md).
+    - Latest: Recommended for trying out the newest features
+        ```
+        helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+        ```
+    - Stable: Recommended for production environments
+        ```
+        helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+        ```
+    - Alpha: Experimental preview of upcoming releases.
+        ```
+        helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
+        ```
+        Note: Upgrades are not supported to, from, or between Alphas.
+
+3. Fetch the latest Rancher chart. This will pull down the chart and save it in the current directory as a `.tgz` file.
+    ```plain
+    helm fetch rancher-<CHART_REPO>/rancher
+    ```
+
+    If you require a specific version of Rancher, you can fetch this with the Helm `--version` parameter like in the following example:
+    ```plain
+    helm fetch rancher-stable/rancher --version=v2.4.8
+    ```
+
+### 2. Choose your SSL Configuration
+
+Rancher Server is designed to be secure by default and requires SSL/TLS configuration.
+
+When Rancher is installed on an air gapped Kubernetes cluster, there are two recommended options for the source of the certificate.
+
+:::note
+
+If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer](../../installation-references/helm-chart-options.md#external-tls-termination).
+
+:::
+
+| Configuration                              | Chart option                 | Description                                                                                                                                                 | Requires cert-manager |
+| ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
+| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br/> This is the **default** and does not need to be added when rendering the Helm template. | yes                   |
+| Certificates from Files                    | `ingress.tls.source=secret`  | Use your own certificate files by creating Kubernetes Secret(s). <br/> This option must be passed when rendering the Rancher Helm template.                  | no                    |
+
+### Helm Chart Options for Air Gap Installations
+
+When setting up the Rancher Helm template, there are several options in the Helm chart that are designed specifically for air gap installations.
+
+| Chart Option            | Chart Value                      | Description   |
+| ----------------------- | -------------------------------- | ---- |
+| `certmanager.version` | `<version>` | Configure proper Rancher TLS issuer depending of running cert-manager version. |
+| `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters.  |
+| `useBundledSystemChart` | `true`                           | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. |
+
+### 3. Fetch the Cert-Manager Chart
+
+Based on the choice your made in [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration), complete one of the procedures below.
+
+#### Option A: Default Self-Signed Certificate
+
+By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface.
+
+:::note
+
+Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade cert-manager documentation](../../resources/upgrade-cert-manager.md).
+
+:::
+
+##### 1. Add the cert-manager Repo
+
+From a system connected to the internet, add the cert-manager repo to Helm:
+
+```plain
+helm repo add jetstack https://charts.jetstack.io
+helm repo update
+```
+
+##### 2. Fetch the cert-manager Chart
+
+Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).
+
+```plain
+helm fetch jetstack/cert-manager --version v1.11.0
+```
+
+##### 3. Retrieve the cert-manager CRDs
+
+Download the required CRD file for cert-manager:
+   ```plain
+   curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
+   ```
+
+### 4. Install Rancher
+
+Copy the fetched charts to a system that has access to the Rancher server cluster to complete installation.
+
+#### 1. Install cert-manager
+
+Install cert-manager with the same options you would use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry.
+
+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
+<details id="install-cert-manager">
+  <summary>Click to expand</summary>
+
+If you are using self-signed certificates, install cert-manager:
+
+1. Create the namespace for cert-manager.
+
+    ```plain
+    kubectl create namespace cert-manager
+    ```
+
+2. Create the cert-manager CustomResourceDefinitions (CRDs).
+
+    ```plain
+    kubectl apply -f cert-manager-crd.yaml
+    ```
+
+3. Install cert-manager.
+
+    ```plain
+    helm install cert-manager ./cert-manager-v1.11.0.tgz \
+        --namespace cert-manager \
+        --set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller \
+        --set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook \
+        --set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector \
+        --set startupapicheck.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-ctl
+    ```
+
+</details>
+
+#### 2. Install Rancher
+
+First, refer to [Adding TLS Secrets](../../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them.
+
+Then, create the namespace for Rancher using kubectl:
+
+```plain
+kubectl create namespace cattle-system
+```
+
+Next, install Rancher, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
+
+
+Placeholder | Description
+------------|-------------
+`<VERSION>` | The version number of the output tarball.
+`<RANCHER.YOURDOMAIN.COM>` | The DNS name you pointed at your load balancer.
+`<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.
+`<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.
+
+```plain
+   helm install rancher ./rancher-<VERSION>.tgz \
+    --namespace cattle-system \
+    --set hostname=<RANCHER.YOURDOMAIN.COM> \
+    --set certmanager.version=<CERTMANAGER_VERSION> \
+    --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+    --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+    --set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+**Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.5.8`
+
+#### Option B: Certificates From Files Using Kubernetes Secrets
+
+##### 1. Create Secrets
+
+Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher.
+
+##### 2. Install Rancher
+
+Install Rancher, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
+
+
+| Placeholder                      | Description                                     |
+| -------------------------------- | ----------------------------------------------- |
+| `<VERSION>`                      | The version number of the output tarball.       |
+| `<RANCHER.YOURDOMAIN.COM>`       | The DNS name you pointed at your load balancer. |
+| `<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.         |
+
+```plain
+   helm install rancher ./rancher-<VERSION>.tgz \
+    --namespace cattle-system \
+    --set hostname=<RANCHER.YOURDOMAIN.COM> \
+    --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+    --set ingress.tls.source=secret \
+    --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+    --set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+If you are using a Private CA signed cert, add `--set privateCA=true` following `--set ingress.tls.source=secret`:
+
+```plain
+   helm install rancher ./rancher-<VERSION>.tgz \
+    --namespace cattle-system \
+    --set hostname=<RANCHER.YOURDOMAIN.COM> \
+    --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+    --set ingress.tls.source=secret \
+    --set privateCA=true \
+    --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+    --set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+
+The installation is complete.
+:::caution
+
+If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login. Leaving this active in an air-gapped environment can cause issues if the sockets cannot be opened successfully.
+
+:::
+
+## Additional Resources
+
+These resources could be helpful when installing Rancher:
+
+- [Importing and installing extensions in an air-gapped environment](../../../../integrations-in-rancher/rancher-extensions.md#importing-and-installing-extensions-in-an-air-gapped-environment)
+- [Rancher Helm chart options](../../installation-references/helm-chart-options.md)
+- [Adding TLS secrets](../../resources/add-tls-secrets.md)
+- [Troubleshooting Rancher Kubernetes Installations](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)
@@ -0,0 +1,332 @@
+---
+title: '2. Collect and Publish Images to your Private Registry'
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images"/>
+</head>
+
+This section describes how to set up your private registry so that when you install Rancher, Rancher will pull all the required images from this registry.
+
+By default, all images used to [provision Kubernetes clusters](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md) or launch any tools in Rancher, e.g. monitoring, pipelines, alerts, are pulled from Docker Hub. In an air gapped installation of Rancher, you will need a private registry that is located somewhere accessible by your Rancher server. Then, you will load the registry with all the images.
+
+Populating the private registry with images is the same process for installing Rancher with Docker and for installing Rancher on a Kubernetes cluster.
+
+The steps in this section differ depending on whether or not you are planning to use Rancher to provision a downstream cluster with Windows nodes or not. By default, we provide the steps of how to populate your private registry assuming that Rancher will provision downstream Kubernetes clusters with only Linux nodes. But if you plan on provisioning any [downstream Kubernetes clusters using Windows nodes](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md), there are separate instructions to support the images needed.
+
+:::note Prerequisites:
+
+You must have a [private registry](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry) available to use.
+
+If the registry has certs, follow [this K3s documentation](https://rancher.com/docs/k3s/latest/en/installation/private-registry/) about adding a private registry. The certs and registry configuration files need to be mounted into the Rancher container.
+
+:::
+
+<Tabs>
+<TabItem value="Linux Only Clusters">
+
+For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
+
+1. [Find the required assets for your Rancher version](#1-find-the-required-assets-for-your-rancher-version)
+2. [Collect the cert-manager image](#2-collect-the-cert-manager-image) (unless you are bringing your own certificates or terminating TLS on a load balancer)
+3. [Save the images to your workstation](#3-save-the-images-to-your-workstation)
+4. [Populate the private registry](#4-populate-the-private-registry)
+
+### Prerequisites
+
+These steps expect you to use a Linux workstation that has internet access, access to your private registry, and at least 20 GB of disk space.
+
+If you will use ARM64 hosts, the registry must support manifests. As of April 2020, Amazon Elastic Container Registry does not support manifests.
+
+### 1. Find the required assets for your Rancher version
+
+1. Go to our [releases page,](https://github.com/rancher/rancher/releases) find the Rancher v2.x.x release that you want to install, and click **Assets**. Note: Don't use releases marked `rc` or `Pre-release`, as they are not stable for production environments.
+
+2. From the release's **Assets** section, download the following files, which are required to install Rancher in an air-gap environment:
+
+| Release File   | Description  |
+| ---------------- | -------------- |
+| `rancher-images.txt`     | This file contains a list of images needed to install Rancher, provision clusters and user Rancher tools. |
+| `rancher-save-images.sh` | This script pulls all the images in the `rancher-images.txt` from Docker Hub and saves all of the images as `rancher-images.tar.gz`. |
+| `rancher-load-images.sh` | This script loads images from the `rancher-images.tar.gz` file and pushes them to your private registry.   |
+
+### 2. Collect the cert-manager image
+
+:::note
+
+Skip this step if you are using your own certificates, or if you are terminating TLS on an external load balancer.
+
+:::
+
+In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) image to `rancher-images.txt` as well.
+
+1.  Fetch the latest `cert-manager` Helm chart and parse the template for image details:
+
+    :::note
+
+    Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.12.0, please see our [upgrade documentation](../../resources/upgrade-cert-manager.md).
+
+    :::
+
+    ```plain
+    helm repo add jetstack https://charts.jetstack.io
+    helm repo update
+    helm fetch jetstack/cert-manager
+    helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
+    ```
+
+2.  Sort and unique the images list to remove any overlap between the sources:
+
+    ```plain
+    sort -u rancher-images.txt -o rancher-images.txt
+    ```
+
+### 3. Save the images to your workstation
+
+(Optional) Verify the image list before pulling:
+
+```bash
+wc -l rancher-images.txt
+head rancher-images.txt
+```
+
+1. Make `rancher-save-images.sh` executable:
+   ```bash
+   chmod +x rancher-save-images.sh
+   ```
+
+1. Run `rancher-save-images.sh` with the `rancher-images.txt` image list to create a tarball of all the required images:
+   ```bash
+   ./rancher-save-images.sh --image-list ./rancher-images.txt
+   ```
+
+(Optional) Specify a custom output file:
+
+```bash
+./rancher-save-images.sh \
+  --image-list ./rancher-images.txt \
+  --images rancher-images-custom.tar.gz
+```
+
+**Result:** Docker begins pulling the images required for an air-gap installation. The process may take several minutes.
+
+1. Verify that the tarball was created:
+   ```bash
+   ls -lh rancher-images.tar.gz
+   ```
+
+If some images fail to pull, review the output and retry after resolving any issues.
+
+### 4. Populate the private registry
+
+Next, you will move the images in the `rancher-images.tar.gz` to your private registry using the scripts to load the images.
+
+Move the images in the `rancher-images.tar.gz` to your private registry using the scripts to load the images.
+
+The `rancher-images.txt` is expected to be on the workstation in the same directory that you are running the `rancher-load-images.sh` script. The `rancher-images.tar.gz` should also be in the same directory.
+
+1.  Log into your private registry if required:
+   ```plain
+   docker login <REGISTRY.YOURDOMAIN.COM:PORT>
+   ```
+1.  Make `rancher-load-images.sh` an executable:
+   ```
+   chmod +x rancher-load-images.sh
+   ```
+
+1.  Use `rancher-load-images.sh` to extract, tag and push `rancher-images.txt` and `rancher-images.tar.gz` to your private registry:
+   ```plain
+   ./rancher-load-images.sh --image-list ./rancher-images.txt --registry <REGISTRY.YOURDOMAIN.COM:PORT>
+   ```
+
+</TabItem>
+<TabItem value="Linux and Windows Clusters">
+
+For Rancher servers that will provision Linux and Windows clusters, there are distinctive steps to populate your private registry for the Windows images and the Linux images. Since a Windows cluster is a mix of Linux and Windows nodes, the Linux images pushed into the private registry are manifests.
+
+## Windows Steps
+
+The Windows images need to be collected and pushed from a Windows server workstation.
+
+1. <a href="#windows-1">Find the required assets for your Rancher version</a>
+2. <a href="#windows-2">Save the images to your Windows Server workstation</a>
+3. <a href="#windows-3">Prepare the Docker daemon</a>
+4. <a href="#windows-4">Populate the private registry</a>
+
+### Prerequisites
+
+These steps expect you to use a Windows Server 1809 workstation that has internet access, access to your private registry, and at least 50 GB of disk space.
+
+The workstation must have Docker 18.02+ in order to support manifests, which are required when provisioning Windows clusters.
+
+Your registry must support manifests. As of April 2020, Amazon Elastic Container Registry does not support manifests.
+
+<a name="windows-1"></a>
+
+### 1. Find the required assets for your Rancher version
+
+1. Browse to our [releases page](https://github.com/rancher/rancher/releases) and find the Rancher v2.x.x release that you want to install. Don't download releases marked `rc` or `Pre-release`, as they are not stable for production environments.
+
+2. From the release's "Assets" section, download the following files:
+
+| Release File                 | Description      |
+|----------------------------|------------------|
+| `rancher-windows-images.txt` | This file contains a list of Windows images needed to provision Windows clusters.                                                                    |
+| `rancher-save-images.ps1`    | This script pulls all the images in the `rancher-windows-images.txt` from Docker Hub and saves all of the images as `rancher-windows-images.tar.gz`. |
+| `rancher-load-images.ps1`    | This script loads the images from the `rancher-windows-images.tar.gz` file and pushes them to your private registry.                                 |
+
+<a name="windows-2"></a>
+
+### 2. Save the images to your Windows Server workstation
+
+1. Using `powershell`, go to the directory that has the files that were downloaded in the previous step.
+
+1. Run `rancher-save-images.ps1` to create a tarball of all the required images:
+   ```plain
+   ./rancher-save-images.ps1
+   ```
+
+   **Result:** Docker begins pulling the images used for an air-gap install. Be patient. This process takes a few minutes. When the process completes, your current directory will output a tarball named `rancher-windows-images.tar.gz`. Check that the output is in the directory.
+
+<a name="windows-3"></a>
+
+### 3. Prepare the Docker daemon
+
+Append your private registry address to the `allow-nondistributable-artifacts` config field in the Docker daemon (`C:\ProgramData\Docker\config\daemon.json`). Since the base image of Windows images are maintained by the `mcr.microsoft.com` registry, this step is required as the layers in the Microsoft registry are missing from Docker Hub and need to be pulled into the private registry.
+
+   ```json
+   {
+     ...
+     "allow-nondistributable-artifacts": [
+       ...
+       "<REGISTRY.YOURDOMAIN.COM:PORT>"
+     ]
+     ...
+   }
+   ```
+
+<a name="windows-4"></a>
+
+### 4. Populate the private registry
+
+Move the images in the `rancher-windows-images.tar.gz` to your private registry using the scripts to load the images.
+
+The `rancher-windows-images.txt` is expected to be on the workstation in the same directory that you are running the `rancher-load-images.ps1` script. The `rancher-windows-images.tar.gz` should also be in the same directory.
+
+1. Using `powershell`, log into your private registry if required:
+   ```plain
+   docker login <REGISTRY.YOURDOMAIN.COM:PORT>
+   ```
+
+1. Using `powershell`, use `rancher-load-images.ps1` to extract, tag and push the images from `rancher-images.tar.gz` to your private registry:
+   ```plain
+   ./rancher-load-images.ps1 --registry <REGISTRY.YOURDOMAIN.COM:PORT>
+   ```
+
+## Linux Steps
+
+The Linux images need to be collected and pushed from a Linux host, but _must be done after_ populating the Windows images into the private registry. These step are different from the Linux only steps as the Linux images that are pushed will actually manifests that support Windows and Linux images.
+
+1. <a href="#linux-1">Find the required assets for your Rancher version</a>
+2. <a href="#linux-2">Collect all the required images</a>
+3. <a href="#linux-3">Save the images to your Linux workstation</a>
+4. <a href="#linux-4">Populate the private registry</a>
+
+### Prerequisites
+
+You must populate the private registry with the Windows images before populating the private registry with Linux images. If you have already populated the registry with Linux images, you will need to follow these instructions again as they will publish manifests that support Windows and Linux images.
+
+These steps expect you to use a Linux workstation that has internet access, access to your private registry, and at least 20 GB of disk space.
+
+The workstation must have Docker 18.02+ in order to support manifests, which are required when provisioning Windows clusters.
+
+<a name="linux-1"></a>
+
+### 1. Find the required assets for your Rancher version
+
+1. Browse to our [releases page](https://github.com/rancher/rancher/releases) and find the Rancher v2.x.x release that you want to install. Don't download releases marked `rc` or `Pre-release`, as they are not stable for production environments. Click **Assets**.
+
+2. From the release's **Assets** section, download the following files:
+
+| Release File                 | Description    |
+|----------------------------| -------------------------- |
+| `rancher-images.txt`         | This file contains a list of images needed to install Rancher, provision clusters and user Rancher tools.           |
+| `rancher-windows-images.txt` | This file contains a list of images needed to provision Windows clusters.                                                            |
+| `rancher-save-images.sh`     | This script pulls all the images in the `rancher-images.txt` from Docker Hub and saves all of the images as `rancher-images.tar.gz`. |
+| `rancher-load-images.sh`     | This script loads images from the `rancher-images.tar.gz` file and pushes them to your private registry.                             |
+
+<a name="linux-2"></a>
+
+### 2. Collect all the required images
+
+**For Kubernetes Installs using Rancher Generated Self-Signed Certificate:** In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) image to `rancher-images.txt` as well. You skip this step if you are using you using your own certificates.
+
+
+1. Fetch the latest `cert-manager` Helm chart and parse the template for image details:
+
+   :::note
+
+   Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.12.0, please see our [upgrade documentation](../../resources/upgrade-cert-manager.md).
+
+   :::
+
+   ```plain
+   helm repo add jetstack https://charts.jetstack.io
+   helm repo update
+   helm fetch jetstack/cert-manager
+   helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
+   ```
+
+2. Sort and unique the images list to remove any overlap between the sources:
+   ```plain
+   sort -u rancher-images.txt -o rancher-images.txt
+   ```
+
+<a name="linux-3"></a>
+
+### 3. Save the images to your workstation
+
+1. Make `rancher-save-images.sh` an executable:
+   ```
+   chmod +x rancher-save-images.sh
+   ```
+
+1. Run `rancher-save-images.sh` with the `rancher-images.txt` image list to create a tarball of all the required images:
+   ```plain
+   ./rancher-save-images.sh --image-list ./rancher-images.txt
+   ```
+
+**Result:** Docker begins pulling the images used for an air-gap install. Be patient. This process takes a few minutes. When the process completes, your current directory will output a tarball named `rancher-images.tar.gz`. Check that the output is in the directory.
+
+<a name="linux-4"></a>
+
+### 4. Populate the private registry
+
+Move the images in the `rancher-images.tar.gz` to your private registry using the `rancher-load-images.sh script` to load the images.
+
+The image list, `rancher-images.txt` or `rancher-windows-images.txt`, is expected to be on the workstation in the same directory that you are running the `rancher-load-images.sh` script. The `rancher-images.tar.gz` should also be in the same directory.
+
+1. Log into your private registry if required:
+   ```plain
+   docker login <REGISTRY.YOURDOMAIN.COM:PORT>
+   ```
+
+1. Make `rancher-load-images.sh` an executable:
+   ```
+   chmod +x rancher-load-images.sh
+   ```
+
+1. Use `rancher-load-images.sh` to extract, tag and push the images from `rancher-images.tar.gz` to your private registry:
+
+```plain
+./rancher-load-images.sh --image-list ./rancher-images.txt \
+   --windows-image-list ./rancher-windows-images.txt \
+   --registry <REGISTRY.YOURDOMAIN.COM:PORT>
+```
+
+</TabItem>
+</Tabs>
+
+### [Next step for Kubernetes Installs - Launch a Kubernetes Cluster](install-kubernetes.md)
+
+### [Next step for Docker Installs - Install Rancher](install-rancher-ha.md)
@@ -0,0 +1,260 @@
+---
+title: '2. Install Kubernetes'
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes"/>
+</head>
+
+Once the infrastructure is ready, you can continue with setting up a Kubernetes cluster to install Rancher in.
+
+The steps to set up RKE, RKE2, or K3s are shown below.
+
+For convenience, export the IP address and port of your proxy into an environment variable and set up the HTTP_PROXY variables for your current shell on every node:
+
+:::caution
+
+The `NO_PROXY` environment variable is not standardized, and the accepted format of the value can differ between applications. When configuring the `NO_PROXY` variable for Rancher, the value must adhere to the format expected by Golang.
+
+Specifically, the value should be a comma-delimited string which only contains IP addresses, CIDR notation, domain names, or special DNS labels (e.g. `*`). For a full description of the expected value format, refer to the [**upstream Golang documentation**](https://pkg.go.dev/golang.org/x/net/http/httpproxy#Config)
+
+:::
+
+```
+export proxy_host="10.0.0.5:8888"
+export HTTP_PROXY=http://${proxy_host}
+export HTTPS_PROXY=http://${proxy_host}
+export NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16
+```
+
+<Tabs>
+<TabItem value="K3s">
+
+First configure the HTTP proxy settings on the K3s systemd service, so that K3s's containerd can pull images through the proxy:
+
+```
+cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
+HTTP_PROXY=http://${proxy_host}
+HTTPS_PROXY=http://${proxy_host}
+NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
+EOF
+```
+
+Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
+
+To specify the K3s (Kubernetes) version, use the INSTALL_K3S_VERSION (e.g., `INSTALL_K3S_VERSION="v1.24.10+k3s1"`) environment variable when running the K3s installation script.
+
+On the first node, create a new cluster:
+```
+curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> K3S_TOKEN=<TOKEN> sh -s - server --cluster-init
+```
+
+And then join the other nodes:
+```
+curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> K3S_TOKEN=<TOKEN> sh -s - server --server https://<SERVER>:6443
+```
+
+Where `<SERVER>` is the IP or valid DNS of the server and `<TOKEN>` is the node-token from the server found at `/var/lib/rancher/k3s/server/node-token`.
+
+For more information on installing K3s see the [K3s installation docs](https://docs.k3s.io/installation).
+
+To have a look at your cluster run:
+
+```
+kubectl cluster-info
+kubectl get pods --all-namespaces
+```
+
+</TabItem>
+<TabItem value="RKE2">
+
+On every node, run the RKE2 installation script. Ensure that the RKE2 version you are installing is [supported by Rancher](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
+
+```
+curl -sfL https://get.rke2.io | INSTALL_RKE2_CHANNEL=v1.xx sh -
+```
+
+Then you have to configure the HTTP proxy settings on the RKE2 systemd service, so that RKE2's containerd can pull images through the proxy:
+
+```
+cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
+HTTP_PROXY=http://${proxy_host}
+HTTPS_PROXY=http://${proxy_host}
+NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
+EOF
+```
+
+Next create the RKE2 configuration file on every node following the [RKE2 High Availability documentation](https://docs.rke2.io/install/ha).
+
+After that start and enable the `rke2-server` service:
+
+```
+systemctl enable rke2-server.service
+systemctl start rke2-server.service
+```
+
+For more information on installing RKE2 see the [RKE2 documentation](https://docs.rke2.io).
+
+To have a look at your cluster run:
+
+```
+export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
+alias kubectl=/var/lib/rancher/rke2/bin/kubectl
+kubectl cluster-info
+kubectl get pods --all-namespaces
+```
+
+</TabItem>
+<TabItem value="RKE">
+
+First, you have to install Docker and setup the HTTP proxy on all three Linux nodes. For this perform the following steps on all three nodes.
+
+Next configure apt to use this proxy when installing packages. If you are not using Ubuntu, you have to adapt this step accordingly:
+
+```
+cat <<'EOF' | sudo tee /etc/apt/apt.conf.d/proxy.conf > /dev/null
+Acquire::http::Proxy "http://${proxy_host}/";
+Acquire::https::Proxy "http://${proxy_host}/";
+EOF
+```
+
+Now you can install Docker:
+
+```
+curl -sL https://releases.rancher.com/install-docker/19.03.sh | sh
+```
+
+Then ensure that your current user is able to access the Docker daemon without sudo:
+
+```
+sudo usermod -aG docker YOUR_USERNAME
+```
+
+And configure the Docker daemon to use the proxy to pull images:
+
+```
+sudo mkdir -p /etc/systemd/system/docker.service.d
+cat <<'EOF' | sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf > /dev/null
+[Service]
+Environment="HTTP_PROXY=http://${proxy_host}"
+Environment="HTTPS_PROXY=http://${proxy_host}"
+Environment="NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16"
+EOF
+```
+
+To apply the configuration, restart the Docker daemon:
+
+```
+sudo systemctl daemon-reload
+sudo systemctl restart docker
+```
+
+#### Air-gapped proxy
+
+You can now provision node driver clusters from an air-gapped cluster configured to use a proxy for outbound connections.
+
+In addition to setting the default rules for a proxy server, you must also add the rules shown below to provision node driver clusters from a proxied Rancher environment.
+
+You will configure your filepath according to your setup, e.g., `/etc/apt/apt.conf.d/proxy.conf`:
+
+```
+acl SSL_ports port 22
+acl SSL_ports port 2376
+
+acl Safe_ports port 22      # ssh
+acl Safe_ports port 2376    # docker port
+```
+
+### Creating the RKE Cluster
+
+You need several command line tools on the host where you have SSH access to the Linux nodes to create and interact with the cluster:
+
+*  [RKE CLI binary](https://rancher.com/docs/rke/latest/en/installation/#download-the-rke-binary)
+
+```
+sudo curl -fsSL -o /usr/local/bin/rke https://github.com/rancher/rke/releases/download/v1.1.4/rke_linux-amd64
+sudo chmod +x /usr/local/bin/rke
+```
+
+* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
+
+```
+curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
+chmod +x ./kubectl
+sudo mv ./kubectl /usr/local/bin/kubectl
+```
+
+Next, create a YAML file that describes the RKE cluster. Ensure that the IP addresses of the nodes and the SSH username are correct. For more information on the cluster YAML, have a look at the [RKE documentation](https://rancher.com/docs/rke/latest/en/example-yamls/).
+
+```yml
+nodes:
+  - address: 10.0.1.200
+    user: ubuntu
+    role: [controlplane,worker,etcd]
+  - address: 10.0.1.201
+    user: ubuntu
+    role: [controlplane,worker,etcd]
+  - address: 10.0.1.202
+    user: ubuntu
+    role: [controlplane,worker,etcd]
+
+services:
+  etcd:
+    backup_config:
+      interval_hours: 12
+      retention: 6
+```
+
+After that, you can create the Kubernetes cluster by running:
+
+```
+rke up --config rancher-cluster.yaml
+```
+
+RKE creates a state file called `rancher-cluster.rkestate`, this is needed if you want to perform updates, modify your cluster configuration or restore it from a backup. It also creates a `kube_config_cluster.yaml` file, that you can use to connect to the remote Kubernetes cluster locally with tools like kubectl or Helm. Make sure to save all of these files in a secure location, for example by putting them into a version control system.
+
+To have a look at your cluster run:
+
+```
+export KUBECONFIG=kube_config_cluster.yaml
+kubectl cluster-info
+kubectl get pods --all-namespaces
+```
+
+You can also verify that your external load balancer works, and the DNS entry is set up correctly. If you send a request to either, you should receive HTTP 404 response from the ingress controller:
+
+```
+$ curl 10.0.1.100
+default backend - 404
+$ curl rancher.example.com
+default backend - 404
+```
+
+### Save Your Files
+
+:::note Important:
+
+The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
+
+:::
+
+Save a copy of the following files in a secure location:
+
+- `rancher-cluster.yml`: The RKE cluster configuration file.
+- `kube_config_cluster.yml`: The [Kubeconfig file](https://rancher.com/docs/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
+- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file](https://rancher.com/docs/rke/latest/en/installation/#kubernetes-cluster-state), this file contains the current state of the cluster including the RKE configuration and the certificates.
+
+:::note
+
+The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
+
+:::
+
+</TabItem>
+</Tabs>
+
+### Issues or errors?
+
+See the [Troubleshooting](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md) page.
+
+### [Next: Install Rancher](install-rancher.md)
@@ -0,0 +1,108 @@
+---
+title: 3. Install Rancher
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-rancher"/>
+</head>
+
+Now that you have a running RKE cluster, you can install Rancher in it. For security reasons all traffic to Rancher must be encrypted with TLS. For this tutorial you are going to automatically issue a self-signed certificate through [cert-manager](https://cert-manager.io/). In a real-world use-case you will likely use Let's Encrypt or provide your own certificate.
+
+### Install the Helm CLI
+
+Install the [Helm](https://helm.sh/docs/intro/install/) CLI on a host where you have a kubeconfig to access your Kubernetes cluster:
+
+```
+curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
+chmod +x get_helm.sh
+sudo ./get_helm.sh
+```
+
+### Install cert-manager
+
+Add the cert-manager Helm repository:
+
+```
+helm repo add jetstack https://charts.jetstack.io
+```
+
+Create a namespace for cert-manager:
+
+```
+kubectl create namespace cert-manager
+```
+
+Install the CustomResourceDefinitions of cert-manager:
+
+```
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
+```
+
+And install it with Helm. Note that cert-manager also needs your proxy configured in case it needs to communicate with Let's Encrypt or other external certificate issuers:
+
+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
+```
+helm upgrade --install cert-manager jetstack/cert-manager \
+  --namespace cert-manager \
+  --set http_proxy=http://${proxy_host} \
+  --set https_proxy=http://${proxy_host} \
+  --set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
+```
+
+Now you should wait until cert-manager is finished starting up:
+
+```
+kubectl rollout status deployment -n cert-manager cert-manager
+kubectl rollout status deployment -n cert-manager cert-manager-webhook
+```
+
+### Install Rancher
+
+Next you can install Rancher itself. First, add the Helm repository:
+
+```
+helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+```
+
+Create a namespace:
+
+```
+kubectl create namespace cattle-system
+```
+
+And install Rancher with Helm. Rancher also needs a proxy configuration so that it can communicate with external application catalogs or retrieve Kubernetes version update metadata:
+
+```
+helm upgrade --install rancher rancher-latest/rancher \
+   --namespace cattle-system \
+   --set hostname=rancher.example.com \
+   --set proxy=http://${proxy_host} \
+   --set noProxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
+```
+
+After waiting for the deployment to finish:
+
+```
+kubectl rollout status deployment -n cattle-system rancher
+```
+
+You can now navigate to `https://rancher.example.com` and start using Rancher.
+
+:::caution
+
+If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login. Leaving this active in an air-gapped environment can cause issues if the sockets cannot be opened successfully.
+
+:::
+
+### Additional Resources
+
+These resources could be helpful when installing Rancher:
+
+- [Rancher Helm chart options](../../installation-references/helm-chart-options.md)
+- [Adding TLS secrets](../../resources/add-tls-secrets.md)
+- [Troubleshooting Rancher Kubernetes Installations](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)
@@ -0,0 +1,65 @@
+---
+title: Adding TLS Secrets
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/add-tls-secrets"/>
+</head>
+
+Kubernetes will create all the objects and services for Rancher, but it will not become available until we populate the `tls-rancher-ingress` secret in the `cattle-system` namespace with the certificate and key.
+
+Combine the server certificate followed by any intermediate certificate(s) needed into a file named `tls.crt`. Copy your certificate key into a file named `tls.key`.
+
+For example, [acme.sh](https://acme.sh) provides server certificate and CA chains in `fullchain.cer` file.
+This `fullchain.cer` should be renamed to `tls.crt` & certificate key file as `tls.key`.
+
+Use `kubectl` with the `tls` secret type to create the secrets.
+
+```
+kubectl -n cattle-system create secret tls tls-rancher-ingress \
+  --cert=tls.crt \
+  --key=tls.key
+```
+
+:::note
+
+If you want to replace the certificate, you can delete the `tls-rancher-ingress` secret using `kubectl -n cattle-system delete secret tls-rancher-ingress` and add a new one using the command shown above. If you are using a private CA signed certificate, replacing the certificate is only possible if the new certificate is signed by the same CA as the certificate currently in use.
+
+:::
+
+## Using a Private CA Signed Certificate
+
+If you are using a private CA, Rancher requires a copy of the private CA's root certificate or certificate chain, which the Rancher Agent uses to validate the connection to the server.
+
+Create a file named `cacerts.pem` that only contains the root CA certificate or certificate chain from your private CA, and use `kubectl` to create the `tls-ca` secret in the `cattle-system` namespace.
+
+```
+kubectl -n cattle-system create secret generic tls-ca \
+  --from-file=cacerts.pem
+```
+
+:::note
+
+The configured `tls-ca` secret is retrieved when Rancher starts. On a running Rancher installation the updated CA will take effect after new Rancher pods are started.
+
+The certificate chain must be properly formatted, or components may fail to download resources from the Rancher server. 
+
+:::
+
+## Adding Additional CA Certificates
+
+If you are using a node driver that makes API requests with a different CA than the one configured for Rancher, you can add additional root certificates and certificate chains. 
+
+Create a unique file ending in `.pem` for each certificate that is required, and use kubectl to create the 
+`tls-additional` secret in the `cattle-system` namespace.
+
+```console
+kubectl -n cattle-system create secret generic tls-additional \
+  --from-file=cacerts1.pem=cacerts1.pem --from-file=cacerts2.pem=cacerts2.pem
+```
+
+Rancher mounts these CA root certificates and certificate chains into the node driver pod during provisioning.
+
+## Updating a Private CA Certificate
+
+Follow the steps on [this page](update-rancher-certificate.md) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.
@@ -0,0 +1,30 @@
+---
+title: Helm Version Requirements
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/helm-version-requirements"/>
+</head>
+
+This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.
+
+## Identifying the Proper Helm v3 Version
+
+Select any Helm v3 version that is officially compatible with the Kubernetes version range you are using from our [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions).
+
+To apply this rule, you may need to reference two external resources:
+
+- **Helm Version Compatibility:** Refer to the [Helm Version Support Policy](https://helm.sh/docs/topics/version_skew/) and select the version matching the rule for your Rancher minor target.
+- **Rancher's Kubernetes Support Range:** Use the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions) to identify the Kubernetes versions supported by your target Rancher minor version.
+
+### Example
+
+- **Scenario:** You are targeting Rancher v2.10.8, which supports Kubernetes versions v1.28 through v1.31.
+- **Application:** Our rule requires a Helm version that supports this range. You can verify this by checking the Helm version's compatibility with the highest version in the range, Kubernetes v1.31.
+- **Result:** You find that Helm v3.16 support the Kubernetes v1.28-v1.31 range.
+- We recommend Helm v3.16 because matches Rancher's range exactly. 
+
+## Additional Notes
+
+- Helm v3.2.x or higher is required to install or upgrade Rancher v2.5.
+- When using tools that run Helm commands for you (like Terraform), you must make sure they are configured to use the correct Helm version.
@@ -0,0 +1,276 @@
+---
+title: Upgrading Cert-Manager
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/upgrade-cert-manager"/>
+</head>
+
+Rancher is compatible with the API version cert-manager.io/v1 and was last tested with cert-manager version v1.13.1.
+
+Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, three important changes to cert-manager are set to occur that you need to take action on if you have an HA deployment of Rancher:
+
+1. [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
+1. [Cert-manager is deprecating and replacing the certificate.spec.acme.solvers field](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/). This change has no exact deadline.
+1. [Cert-manager is deprecating `v1alpha1` API and replacing its API group](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/)
+
+To address these changes, this guide will do two things:
+
+1. Document the procedure for upgrading cert-manager
+1. Explain the cert-manager API changes and link to cert-manager's official documentation for migrating your data
+
+:::note Important:
+
+If you are upgrading cert-manager to the latest version from a version older than 1.5, follow the steps in [Option C](#option-c-upgrade-cert-manager-from-versions-15-and-below) below to do so. Note that you do not need to reinstall Rancher to perform this upgrade.
+
+:::
+
+## Upgrade Cert-Manager
+
+The namespace used in these instructions depends on the namespace cert-manager is currently installed in. If it is in kube-system use that in the instructions below. You can verify by running `kubectl get pods --all-namespaces` and checking which namespace the cert-manager-\* pods are listed in. Do not change the namespace cert-manager is running in or this can cause issues.
+
+In order to upgrade cert-manager, follow these instructions:
+
+### Option A: Upgrade cert-manager with Internet Access
+
+<details id="normal">
+  <summary>Click to expand</summary>
+
+1. [Back up existing resources](https://cert-manager.io/docs/tutorials/backup/) as a precaution
+
+    ```plain
+    kubectl get -o yaml --all-namespaces \
+    issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup.yaml
+    ```
+
+    :::note Important:
+
+    If you are upgrading from a version older than 0.11.0, Update the apiVersion on all your backed up resources from `certmanager.k8s.io/v1alpha1` to `cert-manager.io/v1alpha2`. If you use any cert-manager annotations on any of your other resources, you will need to update them to reflect the new API group. For details, refer to the documentation on [additional annotation changes.](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes)
+
+    :::
+
+1. [Uninstall existing deployment](https://cert-manager.io/docs/installation/uninstall/kubernetes/#uninstalling-with-helm)
+
+    ```plain
+    helm uninstall cert-manager
+    ```
+
+    Delete the CustomResourceDefinition using the link to the version vX.Y.Z you installed
+
+    ```plain
+    kubectl delete -f https://github.com/cert-manager/cert-manager/releases/download/vX.Y.Z/cert-manager.crds.yaml
+
+    ```
+
+1. Install the CustomResourceDefinition resources separately
+
+    ```plain
+    kubectl apply --validate=false -f https://github.com/cert-manager/cert-manager/releases/download/vX.Y.Z/cert-manager.crds.yaml
+
+    ```
+
+    :::note
+
+    If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false` flag to your `kubectl apply` command above. Otherwise, you will receive a validation error relating to the `x-kubernetes-preserve-unknown-fields` field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation.
+
+    :::
+
+1. Create the namespace for cert-manager if needed
+
+    ```plain
+    kubectl create namespace cert-manager
+    ```
+
+1. Add the Jetstack Helm repository
+
+    ```plain
+    helm repo add jetstack https://charts.jetstack.io
+    ```
+
+1. Update your local Helm chart repository cache
+
+    ```plain
+    helm repo update
+    ```
+
+1. Install the new version of cert-manager
+
+    ```plain
+    helm install \
+      cert-manager jetstack/cert-manager \
+      --namespace cert-manager
+    ```
+
+1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
+
+    ```plain
+    kubectl apply -f cert-manager-backup.yaml
+    ```
+
+</details>
+
+### Option B: Upgrade cert-manager in an Air-Gapped Environment
+
+<details id="airgap">
+  <summary>Click to expand</summary>
+
+### Prerequisites
+
+Before you can perform the upgrade, you must prepare your air gapped environment by adding the necessary container images to your private registry and downloading or rendering the required Kubernetes manifest files.
+
+1. Follow the guide to [Prepare your Private Registry](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md) with the images needed for the upgrade.
+
+1. From a system connected to the internet, add the cert-manager repo to Helm
+
+    ```plain
+    helm repo add jetstack https://charts.jetstack.io
+    helm repo update
+    ```
+
+1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).
+
+    ```plain
+    helm fetch jetstack/cert-manager
+    ```
+
+1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.
+
+    The Helm 3 command is as follows:
+
+    ```plain
+    helm template cert-manager ./cert-manager-v0.12.0.tgz --output-dir . \
+    --namespace cert-manager \
+    --set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller
+    --set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook
+    --set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
+    ```
+
+1. Download the required CRD file for cert-manager (old and new)
+
+    ```plain
+    curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
+    curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml
+    ```
+
+### Install cert-manager
+
+1. Back up existing resources as a precaution
+
+    ```plain
+    kubectl get -o yaml --all-namespaces \
+    issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup.yaml
+    ```
+
+    :::note Important:
+
+    If you are upgrading from a version older than 0.11.0, Update the apiVersion on all your backed up resources from `certmanager.k8s.io/v1alpha1` to `cert-manager.io/v1alpha2`. If you use any cert-manager annotations on any of your other resources, you will need to update them to reflect the new API group. For details, refer to the documentation on [additional annotation changes.](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes)
+
+    :::
+
+1. Delete the existing cert-manager installation
+
+    ```plain
+    kubectl -n cert-manager \
+    delete deployment,sa,clusterrole,clusterrolebinding \
+    -l 'app=cert-manager' -l 'chart=cert-manager-v0.5.2'
+    ```
+
+    Delete the CustomResourceDefinition using the link to the version vX.Y you installed
+
+    ```plain
+    kubectl delete -f cert-manager/cert-manager-crd-old.yaml
+    ```
+
+1. Install the CustomResourceDefinition resources separately
+
+    ```plain
+    kubectl apply -f cert-manager/cert-manager-crd.yaml
+    ```
+
+    :::note Important:
+
+    If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false` flag to your `kubectl apply` command above. Otherwise, you will receive a validation error relating to the `x-kubernetes-preserve-unknown-fields` field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation.
+
+    :::
+
+1. Create the namespace for cert-manager
+
+    ```plain
+    kubectl create namespace cert-manager
+    ```
+
+1. Install cert-manager
+
+    ```plain
+    kubectl -n cert-manager apply -R -f ./cert-manager
+    ```
+
+1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
+
+    ```plain
+    kubectl apply -f cert-manager-backup.yaml
+    ```
+
+</details>
+
+### Option C: Upgrade cert-manager from Versions 1.5 and Below
+
+<details id="normal">
+  <summary>Click to expand</summary>
+
+Previously, in order to upgrade cert-manager from an older version, an uninstall and reinstall of Rancher was recommended. Using the method below, you may upgrade cert-manager without those additional steps in order to better preserve your production environment:
+
+1. Install `cmctl`, the cert-manager CLI tool, using [the installation guide](https://cert-manager.io/docs/usage/cmctl/#installation).
+
+1. Ensure that any cert-manager custom resources that may have been stored in etcd at a deprecated API version get migrated to v1:
+
+    ```
+    cmctl upgrade migrate-api-version
+    ```
+    Refer to the [API version migration docs](https://cert-manager.io/docs/usage/cmctl/#migrate-api-version) for more information. Please also see the [docs to upgrade from 1.5 to 1.6](https://cert-manager.io/docs/installation/upgrading/upgrading-1.5-1.6/) and the [docs to upgrade from 1.6. to 1.7](https://cert-manager.io/docs/installation/upgrading/upgrading-1.6-1.7/) if needed.
+
+1. Upgrade cert-manager to v1.7.1 with a normal `helm upgrade`. You may go directly from version 1.5 to 1.7 if desired.
+
+1. Follow the Helm tutorial to [update the API version of a release manifest](https://helm.sh/docs/topics/kubernetes_apis/#updating-api-versions-of-a-release-manifest). The chart release name is `release_name=rancher` and the release namespace is `release_namespace=cattle-system`.
+
+1. In the decoded file, search for `cert-manager.io/v1beta1` and **replace it** with `cert-manager.io/v1`.
+
+1. Upgrade Rancher normally with `helm upgrade`.
+
+</details>
+
+### Verify the Deployment
+
+Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods:
+
+```
+kubectl get pods --namespace cert-manager
+
+NAME                                       READY   STATUS    RESTARTS   AGE
+cert-manager-5c6866597-zw7kh               1/1     Running   0          2m
+cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
+cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m
+```
+
+## Cert-Manager API change and data migration
+
+---
+
+Rancher now supports cert-manager versions 1.6.2 and 1.7.1. We recommend v1.7.x because v 1.6.x will reach end-of-life on March 30, 2022. To read more, see the [cert-manager docs](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md#4-install-cert-manager). For instructions on upgrading cert-manager from version 1.5 to 1.6, see the upstream cert-manager documentation [here](https://cert-manager.io/docs/installation/upgrading/upgrading-1.5-1.6/). For instructions on upgrading cert-manager from version 1.6 to 1.7, see the upstream cert-manager documentation [here](https://cert-manager.io/docs/installation/upgrading/upgrading-1.6-1.7/).
+
+---
+
+Cert-manager has deprecated the use of the `certificate.spec.acme.solvers` field and will drop support for it completely in an upcoming release.
+
+Per the cert-manager documentation, a new format for configuring ACME certificate resources was introduced in v0.8. Specifically, the challenge solver configuration field was moved. Both the old format and new are supported as of v0.9, but support for the old format will be dropped in an upcoming release of cert-manager. The cert-manager documentation strongly recommends that after upgrading you update your ACME Issuer and Certificate resources to the new format.
+
+Details about the change and migration instructions can be found in the [cert-manager v0.7 to v0.8 upgrade instructions](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/).
+
+The v0.11 release marks the removal of the v1alpha1 API that was used in previous versions of cert-manager, as well as our API group changing to be cert-manager.io instead of certmanager.k8s.io.
+
+We have also removed support for the old configuration format that was deprecated in the v0.8 release. This means you must transition to using the new solvers style configuration format for your ACME issuers before upgrading to v0.11. For more information, see the [upgrading to v0.8 guide](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/).
+
+Details about the change and migration instructions can be found in the [cert-manager v0.10 to v0.11 upgrade instructions](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/).
+
+More info about [cert-manager upgrade information](https://cert-manager.io/docs/installation/upgrade/).
+
@@ -0,0 +1,129 @@
+---
+title: Upgrading and Rolling Back Kubernetes
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes"/>
+</head>
+
+Following an upgrade to the latest version of Rancher, downstream Kubernetes clusters can be upgraded to use the latest supported version of Kubernetes.
+
+Rancher calls RKE (Rancher Kubernetes Engine) as a library when provisioning and editing RKE clusters. For more information on configuring the upgrade strategy for RKE clusters, refer to the [RKE documentation](https://rancher.com/docs/rke/latest/en/).
+
+
+## Tested Kubernetes Versions
+
+Before a new version of Rancher is released, it's tested with the latest minor versions of Kubernetes to ensure compatibility. For details on which versions of Kubernetes were tested on each Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/)
+
+## How Upgrades Work
+
+RKE v1.1.0 changed the way that clusters are upgraded.
+
+In this section of the [RKE documentation,](https://rancher.com/docs/rke/latest/en/upgrades/how-upgrades-work) you'll learn what happens when you edit or upgrade your RKE Kubernetes cluster.
+
+
+## Recommended Best Practice for Upgrades
+
+When upgrading the Kubernetes version of a cluster, we recommend that you:
+
+1. Take a snapshot.
+1. Initiate a Kubernetes upgrade.
+1. If the upgrade fails, revert the cluster to the pre-upgrade Kubernetes version. This is achieved by selecting the **Restore etcd and Kubernetes version** option. This will return your cluster to the pre-upgrade kubernetes version before restoring the etcd snapshot.
+
+The restore operation will work on a cluster that is not in a healthy or active state.
+
+## Upgrading the Kubernetes Version
+
+:::note Prerequisites:
+
+- The options below are available for [Rancher-launched Kubernetes clusters](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) and [Registered K3s Kubernetes clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#additional-features-for-registered-rke2-and-k3s-clusters).
+- The following options also apply to imported RKE2 clusters that you have registered. If you import a cluster from an external cloud platform but don't register it, you won't be able to upgrade the Kubernetes version from Rancher.
+- Before upgrading Kubernetes, [back up your cluster.](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/backup-restore-and-disaster-recovery.md)
+
+:::
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster you want to upgrade and click **⋮ > Edit Config**.
+1. From the **Kubernetes Version** drop-down, choose the version of Kubernetes that you want to use for the cluster.
+1. Click **Save**.
+
+**Result:** Kubernetes begins upgrading for the cluster.
+
+## Rolling Back
+
+A cluster can be restored to a backup in which the previous Kubernetes version was used. For more information, refer to the following sections:
+
+- [Backing up a cluster](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md#how-snapshots-work)
+- [Restoring a cluster from backup](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md#restoring-a-cluster-from-a-snapshot)
+
+## Configuring the Upgrade Strategy
+
+As of RKE v1.1.0, additional upgrade options became available to give you more granular control over the upgrade process. These options can be used to maintain availability of your applications during a cluster upgrade if certain [conditions and requirements](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability) are met.
+
+The upgrade strategy can be configured in the Rancher UI, or by editing the `cluster.yml`. More advanced options are available by editing the `cluster.yml`.
+
+### Configuring the Maximum Unavailable Worker Nodes in the Rancher UI
+
+From the Rancher UI, the maximum number of unavailable worker nodes can be configured. During a cluster upgrade, worker nodes will be upgraded in batches of this size.
+
+By default, the maximum number of unavailable worker is defined as 10 percent of all worker nodes. This number can be configured as a percentage or as an integer. When defined as a percentage, the batch size is rounded down to the nearest node, with a minimum of one node.
+
+To change the default number or percentage of worker nodes,
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster you want to upgrade and click **⋮ > Edit Config**.
+1. In the **Upgrade Strategy** tab, enter the **Worker Concurrency** as a fixed number or percentage. To get this number, you can take the number of nodes in your cluster and subtract the max unavailable nodes.
+1. Click **Save**.
+
+**Result:** The cluster is updated to use the new upgrade strategy.
+
+### Enabling Draining Nodes During Upgrades from the Rancher UI
+
+By default, RKE [cordons](https://kubernetes.io/docs/concepts/architecture/nodes/#manual-node-administration) each node before upgrading it. [Draining](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) is disabled during upgrades by default. If draining is enabled in the cluster configuration, RKE will both cordon and drain the node before it is upgraded.
+
+To enable draining each node during a cluster upgrade,
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster you want to enable node draining and click **⋮ > Edit Config**.
+1. Click **⋮ > Edit**.
+1. In the **Upgrade Strategy** tab, go to the **Drain nodes** field and click **Yes**. Node draining is configured separately for control plane and worker nodes.
+1. Configure the options for how pods are deleted. For more information about each option, refer to [this section.](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md#aggressive-and-safe-draining-options)
+1. Optionally, configure a grace period. The grace period is the timeout given to each pod for cleaning things up, so they will have chance to exit gracefully. Pods might need to finish any outstanding requests, roll back transactions or save state to some external storage. If this value is negative, the default value specified in the pod will be used.
+1. Optionally, configure a timeout, which is the amount of time the drain should continue to wait before giving up.
+1. Click **Save**.
+
+**Result:** The cluster is updated to use the new upgrade strategy.
+
+:::note
+
+- There is a [known issue](https://github.com/rancher/rancher/issues/25478) in which the Rancher UI doesn't show the state of etcd and controlplane as drained, even though they are being drained.
+- During an upgrade, nodes may be drained even when no user-visible YAML changes are present. This can occur if non-dynamic configuration files are updated or if a new `system-agent-installer` image is introduced. In such cases, Rancher generates a new upgrade plan, resulting in a new plan hash. When `Upgrade Strategy` is set to `Drain nodes`, this plan change can trigger node draining.
+
+:::
+
+### Maintaining Availability for Applications During Upgrades
+
+In [this section of the RKE documentation,](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability/) you'll learn the requirements to prevent downtime for your applications when upgrading the cluster.
+
+### Configuring the Upgrade Strategy in the cluster.yml
+
+More advanced upgrade strategy configuration options are available by editing the `cluster.yml`.
+
+For details, refer to [Configuring the Upgrade Strategy](https://rancher.com/docs/rke/latest/en/upgrades/configuring-strategy) in the RKE documentation. The section also includes an example `cluster.yml` for configuring the upgrade strategy.
+
+## Troubleshooting
+
+If a node doesn't come up after an upgrade, the `rke up` command errors out.
+
+No upgrade will proceed if the number of unavailable nodes exceeds the configured maximum.
+
+If an upgrade stops, you may need to fix an unavailable node or remove it from the cluster before the upgrade can continue.
+
+A failed node could be in many different states:
+
+- Powered off
+- Unavailable
+- User drains a node while upgrade is in process, so there are no kubelets on the node
+- The upgrade itself failed
+
+If the max unavailable number of nodes is reached during an upgrade, Rancher user clusters will be stuck in updating state and not move forward with upgrading any other control plane nodes. It will continue to evaluate the set of unavailable nodes in case one of the nodes becomes available. If the node cannot be fixed, you must remove the node in order to continue the upgrade.
@@ -0,0 +1,97 @@
+---
+title: Upgrading Kubernetes without Upgrading Rancher
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/upgrade-kubernetes-without-upgrading-rancher"/>
+</head>
+
+<EOLRKE1Warning />
+
+The RKE metadata feature allows you to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. This feature is useful for taking advantage of patch versions of Kubernetes, for example, if you want to upgrade to Kubernetes v1.14.7 when your Rancher server originally supported v1.14.6.
+
+:::note
+
+The Kubernetes API can change between minor versions. Therefore, we don't support introducing minor Kubernetes versions, such as introducing v1.15 when Rancher currently supports v1.14. You would need to upgrade Rancher to add support for minor Kubernetes versions.
+
+:::
+
+Rancher's Kubernetes metadata contains information specific to the Kubernetes version that Rancher uses to provision [RKE clusters](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md). Rancher syncs the data periodically and creates custom resource definitions (CRDs) for **system images,** **service options** and **addon templates**. Consequently, when a new Kubernetes version is compatible with the Rancher server version, the Kubernetes metadata makes the new version available to Rancher for provisioning clusters. The metadata gives you an overview of the information that the [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/) (RKE) uses for deploying various Kubernetes versions.
+
+This table below describes the CRDs that are affected by the periodic data sync.
+
+:::note
+
+Only administrators can edit metadata CRDs. It is recommended not to update existing objects unless explicitly advised.
+
+:::
+
+| Resource | Description | Rancher API URL |
+|----------|-------------|-----------------|
+| System Images | List of system images used to deploy Kubernetes through RKE. | `<RANCHER_SERVER_URL>/v3/rkek8ssystemimages` |
+| Service Options | Default options passed to Kubernetes components like `kube-api`, `scheduler`, `kubelet`, `kube-proxy`, and `kube-controller-manager` | `<RANCHER_SERVER_URL>/v3/rkek8sserviceoptions` |
+| Addon Templates | YAML definitions used to deploy addon components like Canal, Calico, Flannel, Weave, Kube-dns, CoreDNS, `metrics-server`, `nginx-ingress` | `<RANCHER_SERVER_URL>/v3/rkeaddons` |
+
+Administrators might configure the RKE metadata settings to do the following:
+
+- Refresh the Kubernetes metadata, if a new patch version of Kubernetes comes out and they want Rancher to provision clusters with the latest version of Kubernetes without having to upgrade Rancher
+- Change the metadata URL that Rancher uses to sync the metadata, which is useful for air gap setups if you need to sync Rancher locally instead of with GitHub
+- Prevent Rancher from auto-syncing the metadata, which is one way to prevent new and unsupported Kubernetes versions from being available in Rancher
+
+## Refresh Kubernetes Metadata
+
+The option to refresh the Kubernetes metadata is available for administrators by default, or for any user who has the **Manage Cluster Drivers** [global role.](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)
+
+To force Rancher to refresh the Kubernetes metadata, a manual refresh action is available:
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation menu, click **Drivers**.
+1. Click **Refresh Kubernetes Metadata**.
+
+You can configure Rancher to only refresh metadata when desired by setting `refresh-interval-minutes` to `0` (see below) and using this button to perform the metadata refresh manually when desired.
+
+### Configuring the Metadata Synchronization
+
+:::caution
+
+Only administrators can change these settings.
+
+:::
+
+The RKE metadata config controls how often Rancher syncs metadata and where it downloads data from. You can configure the metadata from the settings in the Rancher UI, or through the Rancher API at the endpoint `v3/settings/rke-metadata-config`.
+
+The way that the metadata is configured depends on the Rancher version.
+
+To edit the metadata config in Rancher,
+
+1. In the upper left corner, click **☰ > Global Settings**.
+1. Go to the **rke-metadata-config** section. Click  **⋮ > Edit Setting**.
+1. You can optionally fill in the following parameters:
+
+  - `refresh-interval-minutes`: This is the amount of time that Rancher waits to sync the metadata. To disable the periodic refresh, set `refresh-interval-minutes` to 0.
+  - `url`: This is the HTTP path that Rancher fetches data from. The path must be a direct path to a JSON file. For example, the default URL for Rancher v2.4 is `https://releases.rancher.com/kontainer-driver-metadata/release-v2.4/data.json`.
+1. Click **Save**.
+
+If you don't have an air gap setup, you don't need to specify the URL where Rancher gets the metadata, because the default setting is to pull from [Rancher's metadata Git repository.](https://github.com/rancher/kontainer-driver-metadata/blob/dev-v2.5/data/data.json)
+
+However, if you have an [air gap setup,](#air-gap-setups) you will need to mirror the Kubernetes metadata repository in a location available to Rancher. Then you need to change the URL to point to the new location of the JSON file.
+
+## Air Gap Setups
+
+Rancher relies on a periodic refresh of the `rke-metadata-config` to download new Kubernetes version metadata if it is supported with the current version of the Rancher server. For a table of compatible Kubernetes and Rancher versions, refer to the [service terms section.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.2.8/)
+
+If you have an air gap setup, you might not be able to get the automatic periodic refresh of the Kubernetes metadata from Rancher's Git repository. In that case, you should disable the periodic refresh to prevent your logs from showing errors. Optionally, you can configure your metadata settings so that Rancher can sync with a local copy of the RKE metadata.
+
+To sync Rancher with a local mirror of the RKE metadata, an administrator would configure the `rke-metadata-config` settings to point to the mirror. For details, refer to [Configuring the Metadata Synchronization.](#configuring-the-metadata-synchronization)
+
+After new Kubernetes versions are loaded into the Rancher setup, additional steps would be required in order to use them for launching clusters. Rancher needs access to updated system images. While the metadata settings can only be changed by administrators, any user can download the Rancher system images and prepare a private container image registry for them.
+
+To download the system images for the private registry: 
+
+1. Click **☰** in the top left corner.
+1. At the bottom of the left navigation, click the Rancher version number.
+1. Download the OS specific image lists for Linux or Windows.
+1. Download `rancher-images.txt`.
+1. Prepare the private registry using the same steps during the [air gap install](other-installation-methods/air-gapped-helm-cli-install/publish-images.md), but instead of using the `rancher-images.txt` from the releases page, use the one obtained from the previous steps.
+
+**Result:** The air gap installation of Rancher can now sync the Kubernetes metadata. If you update your private registry when new versions of Kubernetes are released, you can provision clusters with the new version without having to upgrade Rancher.
@@ -0,0 +1,69 @@
+---
+title: Overview
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/overview"/>
+</head>
+
+Rancher is a container management platform built for organizations that deploy containers in production. Rancher makes it easy to run Kubernetes everywhere, meet IT requirements, and empower DevOps teams.
+
+## Run Kubernetes Everywhere
+
+Kubernetes has become the container orchestration standard. Most cloud and virtualization vendors now offer it as standard infrastructure. Rancher users have the choice of creating Kubernetes clusters with Rancher Kubernetes Engine (RKE) or cloud Kubernetes services, such as GKE, AKS, and EKS. Rancher users can also import and manage their existing Kubernetes clusters created using any Kubernetes distribution or installer.
+
+## Meet IT Requirements
+
+Rancher supports centralized authentication, access control, and monitoring for all Kubernetes clusters under its control. For example, you can:
+
+- Use your Active Directory credentials to access Kubernetes clusters hosted by cloud vendors, such as GKE.
+- Setup and enforce access control and security policies across all users, groups, projects, clusters, and clouds.
+- View the health and capacity of your Kubernetes clusters from a single-pane-of-glass.
+
+## Empower DevOps Teams
+
+Rancher provides an intuitive user interface for DevOps engineers to manage their application workload. The user does not need to have in-depth knowledge of Kubernetes concepts to start using Rancher. Rancher catalog contains a set of useful DevOps tools. Rancher is certified with a wide selection of cloud native ecosystem products, including, for example, security tools, monitoring systems, container registries, and storage and networking drivers.
+
+The following figure illustrates the role Rancher plays in IT and DevOps organizations. Each team deploys their applications on the public or private clouds they choose. IT administrators gain visibility and enforce policies across all users, clusters, and clouds.
+
+![Platform](/img/platform.png)
+
+## Features of the Rancher API Server
+
+The Rancher API server is built on top of an embedded Kubernetes API server and an etcd database. It implements the following functionalities:
+
+### Authorization and Role-Based Access Control
+
+- **User management:** The Rancher API server [manages user identities](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md) that correspond to external authentication providers like Active Directory or GitHub, in addition to local users.
+- **Authorization:** The Rancher API server manages [access control](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md) and [security](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md) standards.
+
+### Working with Kubernetes
+
+- **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md) on existing nodes, or perform [Kubernetes upgrades.](installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)
+- **Catalog management:** Rancher provides the ability to use a [catalog of Helm charts](../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md) that make it easy to repeatedly deploy applications.
+- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you to manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration](../how-to-guides/advanced-user-guides/manage-projects/manage-projects.md) and for [managing applications within projects.](../how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-resources-setup.md)
+- **Fleet Continuous Delivery:** Within Rancher, you can leverage [Fleet Continuous Delivery](../integrations-in-rancher/fleet/fleet.md) to deploy applications from git repositories, without any manual operation, to targeted downstream Kubernetes clusters.
+- **Istio:** Our [integration with Istio](../integrations-in-rancher/istio/istio.md) is designed so that a Rancher operator, such as an administrator or cluster owner, can deliver Istio to developers. Then developers can use Istio to enforce security policies, troubleshoot problems, or manage traffic for green/blue deployments, canary deployments, or A/B testing.
+
+### Working with Cloud Infrastructure
+
+- **Tracking nodes:** The Rancher API server tracks identities of all the [nodes](../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md) in all clusters.
+- **Setting up infrastructure:**  When configured to use a cloud provider, Rancher can dynamically provision [new nodes](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md) and [persistent storage](../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) in the cloud.
+
+### Cluster Visibility
+
+- **Logging:** Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
+- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution.
+- **Alerting:** To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned.
+
+## Editing Downstream Clusters with Rancher
+
+The options and settings available for an existing cluster change based on the method that you used to provision it. For example, only clusters [provisioned by RKE](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) have **Cluster Options** available for editing.
+
+After a cluster is created with Rancher, a cluster administrator can manage cluster membership or manage node pools, among [other options.](../reference-guides/cluster-configuration/cluster-configuration.md)
+
+The following table summarizes the options and settings available for each cluster type:
+
+import ClusterCapabilitiesTable from '../shared-files/_cluster-capabilities-table.md';
+
+<ClusterCapabilitiesTable />
@@ -0,0 +1,18 @@
+---
+title: Rancher for AWS
+description: Learn about Rancher for AWS from the AWS Marketplace listing.
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace"/>
+</head>
+
+SUSE Rancher for AWS (SRA/SRFA) is a fully managed Software-as-a-Service (SaaS) offering available through the [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-yrzugbpzuukww). It provides a centralized control plane to manage, monitor, and scale Kubernetes clusters within an AWS environment.
+
+For deployment prerequisites, architecture requirements, and subscription details, refer to the [AWS Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-yrzugbpzuukww). For more information, refer to the [product documentation](https://documentation.suse.com/cloudnative/rancher-srfa/).
+
+:::note
+
+SUSE Rancher for AWS is an offering distinct from deploying and managing the Rancher server manually on Amazon EKS. If you intend to install and manage your own Rancher deployment on an EKS cluster, refer to [Installing Rancher on Amazon EKS](../../installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md).
+
+:::
@@ -0,0 +1,99 @@
+---
+title: Rancher AWS Quick Start Guide
+description: Read this step by step Rancher AWS guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/aws"/>
+</head>
+
+The following steps will quickly deploy a Rancher server on AWS in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+:::caution
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Prerequisites
+
+:::caution
+
+Deploying to Amazon AWS will incur charges.
+
+:::
+
+- [Amazon AWS Account](https://aws.amazon.com/account/): An Amazon AWS Account is required to create resources for deploying Rancher and Kubernetes.
+- [Amazon AWS Access Key](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html): Use this link to follow a tutorial to create an Amazon AWS Access Key if you don't have one yet.
+- [IAM Policy created](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start): Defines the permissions an account attached with this policy has.
+- Install [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Amazon AWS.
+
+### Example IAM Policy
+
+The AWS module just creates an EC2 KeyPair, an EC2 SecurityGroup and an EC2 instance. A simple policy would be:
+
+```json
+{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Effect": "Allow",
+            "Action": "ec2:*",
+            "Resource": "*"
+        }
+    ]
+}
+```
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the AWS folder containing the Terraform files by executing `cd quickstart/rancher/aws`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` and customize the following variables:
+
+    - `aws_access_key` - Amazon AWS Access Key
+    - `aws_secret_key` - Amazon AWS Secret Key
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.
+
+5. **Optional:** Modify optional variables within `terraform.tfvars`. See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) for more information.
+Suggestions include:
+
+   - `aws_region` - Amazon AWS region, choose the closest instead of the default (`us-east-1`)
+   - `prefix` - Prefix for all created resources
+   - `instance_type` - EC2 instance size used, minimum is `t3a.medium` but `t3a.large` or `t3a.xlarge` could be used if within budget
+   - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+
+    ```
+    Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
+
+    Outputs:
+
+    rancher_node_ip = xx.xx.xx.xx
+    rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
+    workload_node_ip = yy.yy.yy.yy
+    ```
+
+8. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+9. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/rancher/aws`.
+
+##### Result
+
+Two Kubernetes clusters are deployed into your AWS account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
+
+## What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
+
+## Destroying the Environment
+
+1. From the `quickstart/rancher/aws` folder, execute `terraform destroy --auto-approve`.
+
+2. Wait for confirmation that all resources have been destroyed.
@@ -0,0 +1,85 @@
+---
+title: Rancher Azure Quick Start Guide
+description: Read this step by step Rancher Azure guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/azure"/>
+</head>
+
+The following steps will quickly deploy a Rancher server on Azure in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+:::caution
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Prerequisites
+
+:::caution
+
+Deploying to Microsoft Azure will incur charges.
+
+:::
+
+- [Microsoft Azure Account](https://azure.microsoft.com/en-us/free/): A Microsoft Azure Account is required to create resources for deploying Rancher and Kubernetes.
+- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
+- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
+- [Microsoft Azure Client ID/Secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal): Use this link and follow instructions to create a Microsoft Azure client and secret.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Microsoft Azure.
+
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the Azure folder containing the Terraform files by executing `cd quickstart/rancher/azure`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` and customize the following variables:
+    - `azure_subscription_id` - Microsoft Azure Subscription ID
+    - `azure_client_id` - Microsoft Azure Client ID
+    - `azure_client_secret` - Microsoft Azure Client Secret
+    - `azure_tenant_id` - Microsoft Azure Tenant ID
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.
+
+5. **Optional:** Modify optional variables within `terraform.tfvars`.
+See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) for more information. Suggestions include:
+   - `azure_location` - Microsoft Azure region, choose the closest instead of the default (`East US`)
+   - `prefix` - Prefix for all created resources
+   - `instance_type` - Compute instance size used, minimum is `Standard_DS2_v2` but `Standard_DS2_v3` or `Standard_DS3_v2` could be used if within budget
+   - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster
+   - `windows_admin_password` - The admin password of the windows worker node
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+
+    ```
+    Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
+
+    Outputs:
+
+    rancher_node_ip = xx.xx.xx.xx
+    rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
+    workload_node_ip = yy.yy.yy.yy
+    ```
+
+8. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+9. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/rancher/azure`.
+
+#### Result
+
+Two Kubernetes clusters are deployed into your Azure account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
+
+## Destroying the Environment
+
+1. From the `quickstart/rancher/azure` folder, execute `terraform destroy --auto-approve`.
+
+2. Wait for confirmation that all resources have been destroyed.
@@ -0,0 +1,78 @@
+---
+title: Rancher DigitalOcean Quick Start Guide
+description: Read this step by step Rancher DigitalOcean guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/digitalocean"/>
+</head>
+
+The following steps will quickly deploy a Rancher server on DigitalOcean in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+:::caution
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Prerequisites
+
+:::caution
+
+Deploying to DigitalOcean will incur charges.
+
+:::
+
+- [DigitalOcean Account](https://www.digitalocean.com): You will require an account on DigitalOcean as this is where the server and cluster will run.
+- [DigitalOcean Access Key](https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key): Use this link to create a DigitalOcean Access Key if you don't have one.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to DigitalOcean.
+
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the DigitalOcean folder containing the Terraform files by executing `cd quickstart/rancher/do`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` and customize the following variables:
+    - `do_token` - DigitalOcean access key
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.
+
+5. **Optional:** Modify optional variables within `terraform.tfvars`.
+See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) for more information. Suggestions include:
+   - `do_region` - DigitalOcean region, choose the closest instead of the default (`nyc1`)
+   - `prefix` - Prefix for all created resources
+   - `droplet_size` - Droplet size used, minimum is `s-2vcpu-4gb` but `s-4vcpu-8gb` could be used if within budget
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+
+    ```
+    Apply complete! Resources: 15 added, 0 changed, 0 destroyed.
+
+    Outputs:
+
+    rancher_node_ip = xx.xx.xx.xx
+    rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
+    workload_node_ip = yy.yy.yy.yy
+    ```
+
+8. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+9. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/rancher/do`.
+
+#### Result
+
+Two Kubernetes clusters are deployed into your DigitalOcean account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
+
+## Destroying the Environment
+
+1. From the `quickstart/rancher/do` folder, execute `terraform destroy --auto-approve`.
+
+2. Wait for confirmation that all resources have been destroyed.
@@ -0,0 +1,108 @@
+---
+title: Rancher Equinix Metal Quick Start
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/equinix-metal"/>
+</head>
+
+## This tutorial walks you through the following:
+
+- Provisioning an Equinix Metal Server
+- Installation of Rancher 2.x
+- Creation of your first cluster
+- Deployment of an application, Nginx
+
+:::caution
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. The Docker install is not recommended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Quick Start Outline
+
+This Quick Start Guide is divided into different tasks for easier consumption.
+
+<br/>
+
+## Prerequisites
+
+- An [Equinix Metal account](https://deploy.equinix.com/developers/docs/metal/identity-access-management/users/)
+- An [Equinix Metal project](https://deploy.equinix.com/developers/docs/metal/projects/creating-a-project/)
+
+
+### 1. Provision a Equinix Metal Host
+
+Begin deploying an Equinix Metal Host. Equinix Metal Servers can be provisioned from either the Equinix Metal console, API, or CLI. You can find instructions for each deployment type on the [Equinix Metal deployment documentation](https://deploy.equinix.com/developers/docs/metal/deploy/on-demand/). You can find additional information on Equinix Metal server types in the [Equinix Metal Documentation](https://deploy.equinix.com/developers/docs/metal/hardware/standard-servers/).
+
+:::note Notes:
+
+- When provisioning a new Equinix Metal Server via the CLI or API you will need to provide the following information: project-id, plan, metro, and operating-system.
+- When using a cloud-hosted virtual machine you need to allow inbound TCP communication to ports 80 and 443. Please see your cloud host's documentation for information regarding port configuration.
+- For a full list of port requirements, refer to [Docker Installation](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md).
+- Provision the host according to our [Requirements](../../installation-and-upgrade/installation-requirements/installation-requirements.md).
+
+:::
+### 2. Install Rancher
+
+To install Rancher on your Equinix Metal host, connect to it and then use a shell to install.
+
+1.  Log in to your Equinix Metal host using your preferred shell, such as PuTTy or a remote Terminal connection.
+
+2.  From your shell, enter the following command:
+
+    ```
+    sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher
+    ```
+
+**Result:** Rancher is installed.
+
+### 3. Log In
+
+Log in to Rancher to begin using the application. After you log in, you'll make some one-time configurations.
+
+1.  Open a web browser and enter the IP address of your host: `https://<SERVER_IP>`.
+
+    Replace `<SERVER_IP>` with your host IP address.
+
+2.  When prompted, create a password for the default `admin` account.
+
+3.  Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node added to your cluster must be able to connect to this URL.<br/><br/>If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster.
+
+<br/>
+
+### 4. Create the Cluster
+
+Welcome to Rancher! You are now able to create your first Kubernetes cluster.
+
+In this task, you can use the versatile **Custom** option. This option lets you add _any_ Linux host (cloud-hosted VM, on-prem VM, or bare-metal) to be used in a cluster.
+
+1. Click **☰ > Cluster Management**.
+1. From the **Clusters** page, click **Create**.
+1. Choose **Custom**.
+1. Enter a **Cluster Name**.
+1. Click **Next**.
+1. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**.
+    - **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section.
+1. Copy the registration command to your clipboard.
+1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
+1. When you finish running the command on your Linux host, click **Done**.
+
+**Result:**
+
+Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
+
+You can access your cluster after its state is updated to **Active**.
+
+**Active** clusters are assigned two Projects:
+
+- `Default`, containing the `default` namespace
+- `System`, containing the `cattle-system`, `traefik`, `kube-public`, and `kube-system` namespaces
+
+#### Finished
+
+Congratulations! You have created your first cluster.
+
+#### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
@@ -0,0 +1,81 @@
+---
+title: Rancher GCP Quick Start Guide
+description: Read this step by step Rancher GCP guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/gcp"/>
+</head>
+
+The following steps will quickly deploy a Rancher server on GCP in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+:::caution
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Prerequisites
+
+:::caution
+
+Deploying to Google GCP will incur charges.
+
+:::
+
+- [Google GCP Account](https://console.cloud.google.com/): A Google GCP Account is required to create resources for deploying Rancher and Kubernetes.
+- [Google GCP Project](https://cloud.google.com/appengine/docs/standard/nodejs/building-app/creating-project): Use this link to follow a tutorial to create a GCP Project if you don't have one yet.
+- [Google GCP Service Account](https://cloud.google.com/iam/docs/creating-managing-service-account-keys): Use this link and follow instructions to create a GCP service account and token file.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Google GCP.
+
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the GCP folder containing the Terraform files by executing `cd quickstart/rancher/gcp`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` and customize the following variables:
+    - `gcp_account_json` - GCP service account file path and file name
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.
+
+5. **Optional:** Modify optional variables within `terraform.tfvars`.
+See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp) for more information.
+Suggestions include:
+   - `gcp_region` - Google GCP region, choose the closest instead of the default (`us-east4`)
+   - `gcp_zone` - Google GCP zone, choose the closest instead of the default (`us-east4-a`)
+   - `prefix` - Prefix for all created resources
+   - `machine_type` - Compute instance size used, minimum is `n1-standard-1` but `n1-standard-2` or `n1-standard-4` could be used if within budget
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+
+    ```
+    Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
+
+    Outputs:
+
+    rancher_node_ip = xx.xx.xx.xx
+    rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
+    workload_node_ip = yy.yy.yy.yy
+    ```
+
+8. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+9. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/rancher/gcp`.
+
+#### Result
+
+Two Kubernetes clusters are deployed into your GCP account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
+
+## Destroying the Environment
+
+1. From the `quickstart/rancher/gcp` folder, execute `terraform destroy --auto-approve`.
+
+2. Wait for confirmation that all resources have been destroyed.
@@ -0,0 +1,155 @@
+---
+title: Helm CLI Quick Start
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli"/>
+</head>
+
+These instructions capture a quick way to set up a proof-of-concept Rancher installation.
+
+These instructions assume you have a Linux virtual machine that you will communicate with from your local workstation. Rancher will be installed on the Linux machine. You will need to retrieve the IP address of that machine so that you can access Rancher from your local workstation. Rancher is designed to manage Kubernetes clusters remotely, so any Kubernetes cluster that Rancher manages in the future will also need to be able to reach this IP address.
+
+We don't recommend installing Rancher locally because it creates a networking problem. Installing Rancher on localhost does not allow Rancher to communicate with downstream Kubernetes clusters, so on localhost you wouldn't be able to test Rancher's cluster provisioning or cluster management functionality.
+
+Your Linux machine can be anywhere. It could be an Amazon EC2 instance, a Digital Ocean droplet, or an Azure virtual machine, to name a few examples. Other Rancher docs often use 'node' as a generic term for all of these. One possible way to deploy a Linux machine is by setting up an Amazon EC2 instance as shown in [this tutorial](../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md).
+
+The full installation requirements are [here](../../installation-and-upgrade/installation-requirements/installation-requirements.md).
+
+## Install K3s on Linux
+
+Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
+
+To specify the K3s (Kubernetes) version, use the INSTALL_K3S_VERSION (e.g., `INSTALL_K3S_VERSION="v1.24.10+k3s1"`) environment variable when running the K3s installation script.
+
+Install a K3s cluster by running this command on the Linux machine:
+
+```
+curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> sh -s - server --cluster-init
+```
+
+Using `--cluster-init` allows K3s to use embedded etcd as the datastore and has the ability to convert to an HA setup. Refer to [High Availability with Embedded DB](https://rancher.com/docs/k3s/latest/en/installation/ha-embedded/).
+
+Save the IP of the Linux machine.
+
+## Save the kubeconfig to your workstation
+
+The kubeconfig file is important for accessing the Kubernetes cluster. Copy the file at `/etc/rancher/k3s/k3s.yaml` from the Linux machine and save it to your local workstation in the directory `~/.kube/config`. One way to do this is by using the `scp` tool and run this command on your local machine:
+
+<Tabs>
+<TabItem value="Mac and Linux">
+
+```
+scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml ~/.kube/config
+```
+
+In some cases it may need to make sure that your shell has the environment variable `KUBECONFIG=~/.kube/config` defined, for instance, it can be exported in your profile or rc files.
+
+</TabItem>
+<TabItem value="Windows">
+
+By default, "scp" is not a recognized command, so we need to install a module first.
+
+In Windows Powershell:
+
+```
+Find-Module Posh-SSH
+Install-Module Posh-SSH
+
+## Get the remote kubeconfig file
+scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml $env:USERPROFILE\.kube\config
+```
+
+</TabItem>
+</Tabs>
+
+## Edit the Rancher server URL in the kubeconfig
+
+In the kubeconfig file, you will need to change the value of the `server` field to `<IP_OF_LINUX_NODE>:6443`. The Kubernetes API server will be reached at port 6443, while the Rancher server will be reached at ports 80 and 443. This edit is needed so that when you run Helm or kubectl commands from your local workstation, you will be able to communicate with the Kubernetes cluster that Rancher will be installed on.
+
+<Tabs>
+<TabItem value="Mac and Linux">
+
+One way to open the kubeconfig file for editing is to use Vim:
+
+```
+vi ~/.kube/config
+```
+
+Press `i` to put Vim in insert mode. To save your work, press `Esc`. Then press `:wq` and press `Enter`.
+
+
+</TabItem>
+<TabItem value="Windows">
+
+In Windows Powershell, you can use `notepad.exe` for editing the kubeconfig file:
+
+```
+notepad.exe $env:USERPROFILE\.kube\config
+```
+
+Once edited, either press `ctrl+s` or go to `File > Save` to save your work.
+
+</TabItem>
+</Tabs>
+
+## Install Rancher with Helm
+
+Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm](https://helm.sh/docs/intro/install/) installed.
+
+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
+```
+helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+
+kubectl create namespace cattle-system
+
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
+
+helm repo add jetstack https://charts.jetstack.io
+
+helm repo update
+
+helm install cert-manager jetstack/cert-manager \
+  --namespace cert-manager \
+  --create-namespace
+
+# Windows Powershell
+helm install cert-manager jetstack/cert-manager `
+  --namespace cert-manager `
+  --create-namespace
+```
+
+The final command to install Rancher is below. The command requires a domain name that forwards traffic to the Linux machine. For the sake of simplicity in this tutorial, you can use a fake domain name to create your proof-of-concept. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`.
+
+To install a specific Rancher version, use the `--version` flag (e.g., `--version 2.6.6`). Otherwise, the latest Rancher is installed by default. Refer to [Choosing a Rancher Version](../../installation-and-upgrade/resources/choose-a-rancher-version.md).
+
+
+See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.
+
+```
+helm install rancher rancher-latest/rancher \
+  --namespace cattle-system \
+  --set hostname=<IP_OF_LINUX_NODE>.sslip.io \
+  --set replicas=1 \
+  --set bootstrapPassword=<PASSWORD_FOR_RANCHER_ADMIN>
+
+# Windows Powershell
+helm install rancher rancher-latest/rancher `
+  --namespace cattle-system `
+  --set hostname=<IP_OF_LINUX_NODE>.sslip.io `
+  --set replicas=1 `
+  --set bootstrapPassword=<PASSWORD_FOR_RANCHER_ADMIN>
+```
+
+Now if you navigate to `<IP_OF_LINUX_NODE>.sslip.io` in a web browser, you should see the Rancher UI.
+
+To make these instructions simple, we used a fake domain name and self-signed certificates to do this installation. Therefore, you will probably need to add a security exception to your web browser to see the Rancher UI. Note that for production installs, you would need a high-availability setup with a load balancer, a real domain name and real certificates.
+
+These instructions also left out the full installation requirements and other installation options. If you have any issues with these steps, refer to the full [Helm CLI installation docs.](../../installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)
+
+To launch new Kubernetes clusters with your new Rancher server, you may need to set up cloud credentials in Rancher. For more information, see [Launching Kubernetes clusters with Rancher.](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)
@@ -0,0 +1,80 @@
+---
+title: Rancher Hetzner Cloud Quick Start Guide
+description: Read this step by step Rancher Hetzner Cloud guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/hetzner-cloud"/>
+</head>
+
+The following steps will quickly deploy a Rancher server on Hetzner Cloud in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+:::caution
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Prerequisites
+
+:::caution
+
+Deploying to Hetzner Cloud will incur charges.
+
+:::
+
+- [Hetzner Cloud Account](https://www.hetzner.com): You will require an account on Hetzner as this is where the server and cluster will run.
+- [Hetzner API Access Key](https://docs.hetzner.cloud/#getting-started): Use these instructions to create a Hetzner Cloud API Key if you don't have one.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to Hetzner.
+
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the Hetzner folder containing the Terraform files by executing `cd quickstart/rancher/hcloud`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` and customize the following variables:
+    - `hcloud_token` - Hetzner API access key
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.
+
+5. **Optional:** Modify optional variables within `terraform.tfvars`.
+See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Hetzner Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/hcloud) for more information.
+Suggestions include:
+
+   - `prefix` - Prefix for all created resources
+   - `instance_type` - Instance type, minimum required is `cx21`
+   - `hcloud_location` - Hetzner Cloud location, choose the closest instead of the default (`fsn1`)
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+
+    ```
+    Apply complete! Resources: 15 added, 0 changed, 0 destroyed.
+
+    Outputs:
+
+    rancher_node_ip = xx.xx.xx.xx
+    rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
+    workload_node_ip = yy.yy.yy.yy
+    ```
+
+8. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+9. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/rancher/hcloud`.
+
+#### Result
+
+Two Kubernetes clusters are deployed into your Hetzner account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
+
+## Destroying the Environment
+
+1. From the `quickstart/rancher/hcloud` folder, execute `terraform destroy --auto-approve`.
+
+2. Wait for confirmation that all resources have been destroyed.
@@ -0,0 +1,82 @@
+---
+title: Rancher Linode Quick Start Guide
+description: Read this step by step guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/linode"/>
+</head>
+
+The following steps will quickly deploy a Rancher server on Linode in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+:::caution
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Prerequisites
+
+:::caution
+
+Deploying to Linode will incur charges.
+
+:::
+
+- [Linode Account](https://www.linode.com/): The Linode account to run provision server and cluster under.
+- [Linode Personal Access Token](https://techdocs.akamai.com/cloud-computing/docs/manage-personal-access-tokens): A Linode Personal Access Token to authenticate with.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster on Linode.
+
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the Linode folder containing the Terraform files by executing `cd quickstart/rancher/linode`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` and customize the following variables:
+    - `linode_token` - The Linode Personal Access Token mentioned above.
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.
+
+5. **Optional:** Modify optional variables within `terraform.tfvars`.
+See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Linode Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/linode) for more information. Suggestions include:
+   - `linode_region` - The target Linode region to provision the server and cluster in.
+     - Default: `eu-central`
+     - For a complete list of regions, see the [official Region Availability page](https://www.linode.com/global-infrastructure/availability/).
+   - `prefix` - The prefix for all created infrastructure.
+   - `linode_type` - The type/plan that all infrastructure Linodes should use.
+     - Default: `g6-standard-2` 
+     - For a complete list of plans, see the [official Plan Types page](https://techdocs.akamai.com/cloud-computing/docs/compute-instance-plan-types).
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+
+    ```
+    Apply complete! Resources: 15 added, 0 changed, 0 destroyed.
+
+    Outputs:
+
+    rancher_node_ip = xx.xx.xx.xx
+    rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
+    workload_node_ip = yy.yy.yy.yy
+    ```
+
+8. Paste the `rancher_server_url` from the output above into the browser and log in when prompted. The default username is `admin` and the password is defined in `rancher_server_admin_password`.
+9. `ssh` into the Rancher Server using the `id_rsa` key generated in `quickstart/rancher/linode`.
+
+#### Result
+
+Two Kubernetes clusters are deployed on your Linode account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
+
+## Destroying the Environment
+
+1. From the `quickstart/rancher/linode` folder, execute `terraform destroy --auto-approve`.
+
+2. Wait for confirmation that all resources have been destroyed.
@@ -0,0 +1,80 @@
+---
+title: Rancher Outscale Quick Start Guide
+description: Read this step by step Rancher Outscale guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/outscale-qs"/>
+</head>
+
+The following steps will quickly deploy a Rancher server on Outscale in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+:::note
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Prerequisites
+
+:::caution
+
+Deploying to Outscale will incur charges.
+
+:::
+
+- [Outscale Account](https://en.outscale.com/): You will require an account on Outscale as this is where the server and cluster will run.
+- [Outscale Access Key](https://docs.outscale.com/en/userguide/About-Access-Keys.html): Use these instructions to create an Outscale Access Key if you don't have one.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Outscale.
+
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the Outscale folder containing the Terraform files by executing `cd quickstart/rancher/outscale`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` and customize the following variables:
+    - `access_key_id` - Outscale access key
+    - `secret_key_id` - Outscale secret key
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.
+
+5. **Optional:** Modify optional variables within `terraform.tfvars`.
+See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Outscale Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/outscale) for more information.
+Suggestions include:
+    - `region` - Outscale region, choose the closest instead of the default (`eu-west-2`)
+    - `prefix` - Prefix for all created resources
+    - `instance_type` - Instance type, minimum required is `tinav3.c2r4p3`
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+
+    ```
+    Apply complete! Resources: 21 added, 0 changed, 0 destroyed.
+
+    Outputs:
+
+    rancher_node_ip = xx.xx.xx.xx
+    rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
+    workload_node_ip = yy.yy.yy.yy
+    ```
+
+8. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+9. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/rancher/outscale`.
+
+#### Result
+
+Two Kubernetes clusters are deployed into your Outscale account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
+
+## Destroying the Environment
+
+1. From the `quickstart/rancher/outscale` folder, execute `terraform destroy --auto-approve`.
+
+2. Wait for confirmation that all resources have been destroyed.
@@ -0,0 +1,56 @@
+---
+title: Rancher Vagrant Quick Start
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/vagrant"/>
+</head>
+
+The following steps quickly deploy a Rancher Server with a single node cluster attached.
+
+:::caution
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Prerequisites
+
+- [Vagrant](https://developer.hashicorp.com/vagrant): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
+- [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
+- At least 4GB of free RAM.
+
+:::note 
+
+Vagrant requires plugins to create VirtualBox VMs. Install them with the following commands: 
+- `vagrant plugin install vagrant-vboxmanage` 
+- `vagrant plugin install vagrant-vbguest` 
+
+:::
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the folder containing the Vagrantfile by executing `cd quickstart/rancher/vagrant`.
+
+3. **Optional:** Edit `config.yaml` to:
+
+    - Change the number of nodes and the memory allocations, if required. (`node.count`, `node.cpus`, `node.memory`)
+    - Change the password of the `admin` user for logging into Rancher. (`admin_password`)
+
+4. To initiate the creation of the environment run, `vagrant up --provider=virtualbox`.
+
+5. Once provisioning finishes, go to `https://192.168.56.101` in the browser. The default user/password is `admin/adminPassword`.
+
+**Result:** Rancher Server and your Kubernetes cluster is installed on VirtualBox.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
+
+## Destroying the Environment
+
+1. From the `quickstart/rancher/vagrant` folder execute `vagrant destroy -f`.
+
+2. Wait for the confirmation that all resources have been destroyed.
--- a/Show More
+++ b/Show More