Convert h1 to h2 (2.5)

2026-05-25 06:08:29 +00:00 · 2022-10-28 17:08:01 -07:00
parent 15a1e067a6
commit bb76e99d20
87 changed files with 319 additions and 336 deletions
@@ -256,7 +256,7 @@ The table below indicates what DNS provider is deployed by default. See [RKE doc
 | v2.2.5 and higher | v1.13.x and lower | kube-dns |
 | v2.2.4 and lower | any | kube-dns |

-# Rancher specific parameters
+## Rancher specific parameters

 Besides the RKE config file options, there are also Rancher specific settings that can be configured in the Config File (YAML):

@@ -14,7 +14,7 @@ For more detailed information on how to contribute to the development of Rancher

 On the Rancher Users Slack, the channel for developers is **#developer**.

-# Repositories
+## Repositories

 All of repositories are located within our main GitHub organization. There are many repositories used for Rancher, but we'll provide descriptions of some of the main ones used in Rancher.

@@ -38,13 +38,13 @@ To see all libraries/projects used in Rancher, see the [`go.mod` file](https://g
 ![Rancher diagram](/img/ranchercomponentsdiagram.svg)<br/>
 <sup>Rancher components used for provisioning/managing Kubernetes clusters.</sup>

-# Building
+## Building

 Every repository should have a Makefile and can be built using the `make` command. The `make` targets are based on the scripts in the `/scripts` directory in the repository, and each target will use [Dapper](https://github.com/rancher/dapper) to run the target in an isolated environment. The `Dockerfile.dapper` will be used for this process, and includes all the necessary build tooling needed.

 The default target is `ci`, and will run `./scripts/validate`, `./scripts/build`, `./scripts/test` and `./scripts/package`. The resulting binaries of the build will be in `./build/bin` and are usually also packaged in a Docker image.

-# Bugs, Issues or Questions
+## Bugs, Issues or Questions

 If you find any bugs or are having any trouble, please search the [reported issue](https://github.com/rancher/rancher/issues) as someone may have experienced the same issue or we are actively working on a solution.

@@ -110,7 +110,7 @@ Please follow this checklist when filing an issue which will helps us investigat
      - `/var/log/docker.log`
 - **Metrics:** If you are experiencing performance issues, please provide as much of data (files or screenshots) of metrics which can help determining what is going on. If you have an issue related to a machine, it helps to supply output of `top`, `free -m`, `df` which shows processes/memory/disk usage.

-# Docs
+## Docs

 If you have any updates to our documentation, please make any pull request to our docs repo.

@@ -42,7 +42,7 @@ Totals: | 1710m | 3304Mi | >8800m | >6048Mi | -
 </TabItem>
 </Tabs>

-# Configuring Resource Allocations
+## Configuring Resource Allocations

 You can individually configure the resource allocation for each type of Istio component. This section includes the default resource allocations for each component.

@@ -22,7 +22,7 @@ The `Outputs` and `ClusterOutputs` can now be configured by filling out forms in


 <a id="outputs-2-5-8"></a>
-# Outputs
+## Outputs

 The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.

@@ -72,7 +72,7 @@ For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](htt


 <a id="outputs-2-5-0"></a>
-# Outputs
+## Outputs

 The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.

@@ -33,7 +33,7 @@ sudo iptables --list

 This section describes how to use `firewalld` to apply the [firewall port rules](../../installation-requirements/port-requirements.md) for nodes in a high-availability Rancher server cluster.

-# Prerequisite
+## Prerequisite

 Install v7.x or later ofv`firewalld`:

@@ -43,7 +43,7 @@ systemctl start firewalld
 systemctl enable firewalld
 ```

-# Applying Firewall Port Rules
+## Applying Firewall Port Rules

 In the Rancher high-availability installation instructions, the Rancher server is set up on three nodes that have all three Kubernetes roles: etcd, controlplane, and worker. If your Rancher server nodes have all three roles, run the following commands on each node:

@@ -13,7 +13,7 @@ Environment Variable Key | Default Value | Status | Available as of
 `istio-virtual-service-ui` |`false` |  Experimental | v2.3.0
 `istio-virtual-service-ui` | `true` | GA                    | v2.3.2

-# About this Feature
+## About this Feature

 A central advantage of Istio's traffic management features is that they allow dynamic request routing, which is useful for canary deployments, blue/green deployments, or A/B testing.

@@ -7,7 +7,7 @@ import TabItem from '@theme/TabItem';

 > These instructions assume you have already followed the instructions for a Kubernetes upgrade on [this page,](upgrades.md) including the prerequisites, up until step 3. Upgrade Rancher.

-### Rancher Helm Template Options
+## Rancher Helm Template Options

 Render the Rancher template using the same chosen options that were used when installing Rancher. 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.

@@ -20,7 +20,6 @@ Placeholder | Description
 `<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.
 `<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.

-
 ### Option A: Default Self-signed Certificate

 <Tabs>
@@ -112,8 +111,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
 </TabItem>
 </Tabs>

-
-### Apply the Rendered Templates
+## Apply the Rendered Templates

 Copy the rendered manifest directories to a system with access to the Rancher server cluster and apply the rendered templates.

@@ -123,7 +121,7 @@ Use `kubectl` to apply the rendered manifests.
 kubectl -n cattle-system apply -R -f ./rancher
 ```

-# Verify the Upgrade
+## Verify the Upgrade

 Log into Rancher to confirm that the upgrade succeeded.

@@ -131,6 +129,6 @@ Log into Rancher to confirm that the upgrade succeeded.
 >
 > See [Restoring Cluster Networking](../../../../version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).

-# Known Upgrade Issues
+## 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)
@@ -8,7 +8,7 @@ The guide uses command line tools to provision an AKS cluster with an ingress. I

 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.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)

-# Prerequisites
+## Prerequisites

 >**Note**
 >Deploying to Microsoft Azure will incur charges.
@@ -19,7 +19,7 @@ If you already have an AKS Kubernetes cluster, skip to the step about [installin
 - Your subscription has sufficient quota for at least 2 vCPUs. For details on Rancher server resource requirements, refer to [this section](../../../pages-for-subheaders/installation-requirements.md#rke-and-hosted-kubernetes)
 - 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
+## 1. Prepare your Workstation

 Install the following command line tools on your workstation:

@@ -27,7 +27,7 @@ Install the following command line tools on your workstation:
 - **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
+## 2. Create a Resource Group

 After installing the CLI, you will need to log in with your Azure account.

@@ -41,7 +41,7 @@ Create a [resource group](https://docs.microsoft.com/en-us/azure/azure-resource-
 az group create --name rancher-rg --location eastus
 ```

-# 3. Create the AKS Cluster
+## 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.

@@ -56,7 +56,7 @@ az aks create \

 The cluster will take some time to be deployed.

-# 4. Get Access Credentials
+## 4. Get Access Credentials

 After the cluster is deployed, get the access credentials.

@@ -66,7 +66,7 @@ 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
+## 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.

@@ -83,7 +83,7 @@ helm upgrade --install \
  --create-namespace
 ```

-# 6. Get Load Balancer IP
+## 6. Get Load Balancer IP

 To get the address of the load balancer, run:

@@ -102,7 +102,7 @@ ingress-nginx-controller   LoadBalancer   10.0.116.18    40.31.180.83   80:31229

 Save the `EXTERNAL-IP`.

-# 7. Set up DNS
+## 7. Set up DNS

 External traffic to the Rancher server will need to be directed at the load balancer you created.

@@ -110,7 +110,7 @@ Set up a DNS to point at the `EXTERNAL-IP` that you saved. This DNS will be used

 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
+## 8. Install the Rancher Helm Chart

 Next, install the Rancher Helm chart by following the instructions on [this page.](../../../pages-for-subheaders/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.

@@ -13,7 +13,7 @@ If you already have an EKS Kubernetes cluster, skip to the step about [installin
 - [Automated Quickstart using AWS Best Practices](#automated-quickstart-using-aws-best-practices)
 - [Creating an EKS Cluster for the Rancher Server](#creating-an-eks-cluster-for-the-rancher-server)

-# Automated Quickstart using AWS Best Practices
+## Automated Quickstart using AWS Best Practices

 Rancher and Amazon Web Services collaborated on a quick start guide for deploying Rancher on an EKS cluster following AWS best practices. The deployment guide is [here.](https://aws-quickstart.github.io/quickstart-eks-rancher/)

@@ -39,7 +39,7 @@ Deploying this Quick Start for a new virtual private cloud (VPC) and new Amazon

 \* The CloudFormation template that deploys the Quick Start into an existing Amazon EKS cluster skips the components marked by asterisks and prompts you for your existing VPC configuration.

-# Creating an EKS Cluster for the Rancher Server
+## 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.

@@ -9,13 +9,13 @@ In this section, you'll learn how to install Rancher using Google Kubernetes Eng

 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.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)

-# Prerequisites
+## 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.](../../../pages-for-subheaders/installation-requirements.md#rke-and-hosted-kubernetes)

-# 1. Enable the Kubernetes Engine API
+## 1. Enable the Kubernetes Engine API

 Take the following steps to enable the Kubernetes Engine API:

@@ -24,7 +24,7 @@ Take the following steps to enable the Kubernetes Engine API:
 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
+## 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.

@@ -63,7 +63,7 @@ To install `gcloud` and `kubectl`, perform the following steps:



-# 3. Configure the gcloud CLI
+## 3. Configure the gcloud CLI

 Set up default gcloud settings using one of the following methods:

@@ -91,7 +91,7 @@ To install `gcloud` and `kubectl`, perform the following steps:
 </TabItem>
 </Tabs>

-# 4. Confirm that gcloud is configured correctly
+## 4. Confirm that gcloud is configured correctly

 Run:

@@ -113,7 +113,7 @@ project = <Your project ID>
 Your active configuration is: [default]
 ```

-# 5. Create a GKE Cluster
+## 5. Create a GKE Cluster

 The following command creates a three-node cluster.

@@ -125,7 +125,7 @@ When choosing a Kubernetes version, be sure to first consult the [support matrix
 gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=1.20.10-gke.301
 ```

-# 6. Get Authentication Credentials
+## 6. Get Authentication Credentials

 After creating your cluster, you need to get authentication credentials to interact with the cluster:

@@ -135,7 +135,7 @@ gcloud container clusters get-credentials cluster-name

 This command configures `kubectl` to use the cluster you created.

-# 7. Install an Ingress
+## 7. Install an Ingress

 The cluster needs an Ingress so that Rancher can be accessed from outside the cluster.

@@ -152,7 +152,7 @@ helm upgrade --install \
  --create-namespace
 ```

-# 8. Get the Load Balancer IP
+## 8. Get the Load Balancer IP

 To get the address of the load balancer, run:

@@ -169,7 +169,7 @@ ingress-nginx-controller   LoadBalancer   10.3.244.156   35.233.206.34   80:3187

 Save the `EXTERNAL-IP`.

-# 9. Set up DNS
+## 9. Set up DNS

 External traffic to the Rancher server will need to be directed at the load balancer you created.

@@ -177,7 +177,7 @@ Set up a DNS to point at the external IP that you saved. This DNS will be used a

 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
+## 10. Install the Rancher Helm chart

 Next, install the Rancher Helm chart by following the instructions on [this page.](../../../pages-for-subheaders/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.

@@ -6,7 +6,7 @@ title: Rollbacks
 - [Rolling Back to Rancher v2.2-v2.4+](#rolling-back-to-rancher-v2-2-v2-4)
 - [Rolling Back to Rancher v2.0-v2.1](#rolling-back-to-rancher-v2-0-v2-1)

-# Rolling Back to Rancher v2.5.0+
+## Rolling Back to Rancher v2.5.0+

 To roll back to Rancher v2.5.0+, use the **Rancher Backups** application and restore Rancher from backup.

@@ -90,7 +90,7 @@ When the target revision is determined, perform the rollback. This example will
 helm rollback rancher 3 -n cattle-system
 ```

-# Rolling Back to Rancher v2.2-v2.4+
+## Rolling Back to Rancher v2.2-v2.4+

 To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](../../../../version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.

@@ -98,6 +98,6 @@ For information on how to roll back Rancher installed with Docker, refer to [thi

 > Managed clusters are authoritative for their state. This means restoring the rancher server will not revert workload deployments or changes made on managed clusters after the snapshot was taken.

-# Rolling Back to Rancher v2.0-v2.1
+## Rolling Back to Rancher v2.0-v2.1

 Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](../../../../version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
@@ -15,7 +15,7 @@ To upgrade the components in your Kubernetes cluster, or the definition of the [
 - [Known Upgrade Issues](#known-upgrade-issues)
 - [RKE Add-on Installs](#rke-add-on-installs)

-# Prerequisites
+## Prerequisites

 ### Access to kubeconfig

@@ -49,7 +49,7 @@ If you are upgrading to Rancher v2.5 from a Rancher server that was started with

 [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
+## Upgrade Outline

 Follow the steps to upgrade Rancher server:

@@ -58,13 +58,13 @@ Follow the steps to upgrade Rancher server:
 - [3. Upgrade Rancher](#3-upgrade-rancher)
 - [4. Verify the Upgrade](#4-verify-the-upgrade)

-# 1. Back up Your Kubernetes Cluster that is Running 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 restoration point if something goes wrong during upgrade.

-# 2. Update the Helm chart repository
+## 2. Update the Helm chart repository

 1. Update your local helm repo cache.

@@ -114,7 +114,7 @@ You'll use the backup as a restoration point if something goes wrong during upgr
    helm fetch rancher-<CHART_REPO>/rancher --version=2.5.16
    ```

-# 3. Upgrade Rancher
+## 3. Upgrade Rancher

 This section describes how to upgrade normal (Internet-connected) or air gap installations of Rancher with Helm.

@@ -180,7 +180,7 @@ If you are currently running the cert-manager whose version is older than v0.11,
    --set hostname=rancher.my.org
    ```

-# 4. Verify the Upgrade
+## 4. Verify the Upgrade

 Log into Rancher to confirm that the upgrade succeeded.

@@ -188,6 +188,6 @@ Log into Rancher to confirm that the upgrade succeeded.
 >
 > See [Restoring Cluster Networking](../../../../version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).

-# Known Upgrade Issues
+## 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)
@@ -11,7 +11,7 @@ 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
+## Rancher Nodes

 The following table lists the ports that need to be open to and from nodes that are running the Rancher server.

@@ -163,7 +163,7 @@ The following tables break down the port requirements for Rancher nodes, for inb

 </details>

-# Downstream Kubernetes Cluster Nodes
+## 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.

@@ -229,7 +229,7 @@ The following table depicts the port requirements for [registered clusters](../.
 </details>


-# Other Port Considerations
+## Other Port Considerations

 ### Commonly Used Ports

@@ -11,11 +11,11 @@ This section is about how to deploy Rancher for your air gapped environment in a

 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
+## 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
+## 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.

@@ -26,7 +26,7 @@ This section describes installing Rancher:
 - [3. Render the Rancher Helm Template](#3-render-the-rancher-helm-template)
 - [4. Install Rancher](#4-install-rancher)

-# 1. Add the Helm Chart Repository
+## 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.

@@ -57,7 +57,7 @@ From a system that has access to the internet, fetch the latest Helm chart and c
    helm fetch rancher-stable/rancher --version=v2.4.8
    ```

-# 2. Choose your SSL Configuration
+## 2. Choose your SSL Configuration

 Rancher Server is designed to be secure by default and requires SSL/TLS configuration.

@@ -70,7 +70,7 @@ When Rancher is installed on an air gapped Kubernetes cluster, there are two rec
 | 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
+## 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.

@@ -80,11 +80,11 @@ When setting up the Rancher Helm template, there are several options in the Helm
 | `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. Render the Rancher Helm Template
+## 3. Render the Rancher Helm Template

 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
+## 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.
@@ -177,7 +177,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \



-# Option B: Certificates From Files using Kubernetes Secrets
+## Option B: Certificates From Files using Kubernetes Secrets


 ### 1. Create secrets
@@ -262,7 +262,7 @@ Then refer to [Adding TLS Secrets](../../resources/add-tls-secrets.md/) to publi



-# 4. Install Rancher
+## 4. Install Rancher

 Copy the rendered manifest directories to a system that has access to the Rancher server cluster to complete installation.

@@ -307,7 +307,7 @@ The installation is complete.

 > **Note:** 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
+## Additional Resources

 These resources could be helpful when installing Rancher:

@@ -110,7 +110,7 @@ The `rancher-images.txt` is expected to be on the workstation in the same direct

 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
+## Windows Steps

 The Windows images need to be collected and pushed from a Windows server workstation.

@@ -189,7 +189,7 @@ The `rancher-windows-images.txt` is expected to be on the workstation in the sam
   ./rancher-load-images.ps1 --registry <REGISTRY.YOURDOMAIN.COM:PORT>
   ```

-# Linux Steps
+## 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.

@@ -7,12 +7,12 @@ import TabItem from '@theme/TabItem';

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

-# Prerequisites
+## Prerequisites

 - **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#known-upgrade-issues) in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12) Note that upgrades to or from any chart in the [rancher-alpha repository](../../../../reference-guides/installation-references/helm-chart-options.md#helm-chart-repositories/) aren’t supported.
 - **For [air gap installs only,](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version.** Follow the guide to [populate your private registry](../air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.

-# Placeholder Review
+## Placeholder Review

 During upgrade, you'll enter a series of commands, filling placeholders with data from your environment. These placeholders are denoted with angled brackets and all capital letters (`<EXAMPLE>`).

@@ -24,7 +24,7 @@ docker stop <RANCHER_CONTAINER_NAME>

 In this command, `<RANCHER_CONTAINER_NAME>` is the name of your Rancher container.

-# Get Data for Upgrade Commands
+## Get Data for Upgrade Commands

 To obtain the data to replace the placeholders, run:

@@ -48,7 +48,7 @@ Write down or copy this information before starting the upgrade.

 You can obtain `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>` by logging into your Rancher server by remote connection and entering the command to view the containers that are running: `docker ps`. You can also view containers that are stopped using a different command: `docker ps -a`. Use these commands for help anytime during while creating backups.

-# Upgrade Outline
+## Upgrade Outline

 During upgrade, you create a copy of the data from your current Rancher container and a backup in case something goes wrong. Then you deploy the new version of Rancher in a new container using your existing data. Follow the steps to upgrade Rancher server:

@@ -59,7 +59,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
 - [5. Verify the Upgrade](#5-verify-the-upgrade)
 - [6. Clean up your old Rancher server container](#6-clean-up-your-old-rancher-server-container)

-# 1. Create a copy of the data from your Rancher server container
+## 1. Create a copy of the data from your Rancher server container

 1. Using a remote Terminal connection, log into the node running your Rancher server.

@@ -75,7 +75,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
    docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data rancher/rancher:<RANCHER_CONTAINER_TAG>
    ```

-# 2. Create a backup tarball
+## 2. Create a backup tarball

 1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>).

@@ -97,7 +97,7 @@ During upgrade, you create a copy of the data from your current Rancher containe

 1. Move your backup tarball to a safe location external from your Rancher server.

-# 3. Pull the New Docker Image
+## 3. Pull the New Docker Image

 Pull the image of the Rancher version that you want to upgrade to.

@@ -109,7 +109,7 @@ Placeholder | Description
 docker pull rancher/rancher:<RANCHER_VERSION_TAG>
 ```

-# 4. Start the New Rancher Server Container
+## 4. Start the New Rancher Server Container

 Start a new Rancher server container using the data from the `rancher-data` container. Remember to pass in all the environment variables that you had used when you started the original container.

@@ -351,7 +351,7 @@ As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subhe

 **Result:** You have upgraded Rancher. Data from your upgraded server is now saved to the `rancher-data` container for use in future upgrades.

-# 5. Verify the Upgrade
+## 5. Verify the Upgrade

 Log into Rancher. Confirm that the upgrade succeeded by checking the version displayed in the bottom-left corner of the browser window.

@@ -360,10 +360,10 @@ Log into Rancher. Confirm that the upgrade succeeded by checking the version dis
 > See [Restoring Cluster Networking](../../../../../version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).


-# 6. Clean up Your Old Rancher Server Container
+## 6. Clean up Your Old Rancher Server Container

 Remove the previous Rancher server container. If you only stop the previous Rancher server container (and don't remove it), the container may restart after the next server reboot.

-# Rolling Back
+## Rolling Back

 If your upgrade does not complete successfully, you can roll back Rancher server and its data back to its last healthy state. For more information, see [Docker Rollback](roll-back-docker-installed-rancher.md).
@@ -19,7 +19,7 @@ kubectl -n cattle-system create secret tls tls-rancher-ingress \

 > **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
+## Using a Private CA Signed Certificate

 If you are using a private CA, Rancher requires a copy of the CA certificate which is used by the Rancher Agent to validate the connection to the server.

@@ -32,6 +32,6 @@ kubectl -n cattle-system create secret generic tls-ca \

 > **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.

-# Updating a Private CA Certificate
+## 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](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.
@@ -6,9 +6,8 @@ The [System Charts](https://github.com/rancher/system-charts) repository contain

 In an air gapped installation of Rancher, you will need to configure Rancher to use a local copy of the system charts. This section describes how to use local system charts using a CLI flag.

-# Using Local System Charts
+## Using Local System Charts

 A local copy of `system-charts` has been packaged into the `rancher/rancher` container. To be able to use these features in an air gap install, you will need to run the Rancher install command with an extra environment variable, `CATTLE_SYSTEM_CATALOG=bundled`, which tells Rancher to use the local copy of the charts instead of attempting to fetch them from GitHub.

 Example commands for a Rancher installation with a bundled `system-charts` are included in the [air gap Docker installation](../other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md) instructions and the [air gap Kubernetes installation](../other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md) instructions.
-
@@ -2,7 +2,7 @@
 title: Updating the Rancher Certificate
 ---

-# Updating a Private CA Certificate
+## Updating a Private CA Certificate

 Follow these steps to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.

@@ -16,7 +16,7 @@ A summary of the steps is as follows:

 The details of these instructions are below.

-## 1. Create/update the certificate secret resource
+### 1. Create/update the certificate secret resource

 First, concatenate the server certificate followed by any intermediate certificate(s) to a file named `tls.crt` and provide the corresponding certificate key in a file named `tls.key`.

@@ -37,7 +37,7 @@ $ kubectl -n cattle-system create secret tls tls-rancher-ingress \
  --dry-run --save-config -o yaml | kubectl apply -f -
 ```

-## 2. Create/update the CA certificate secret resource
+### 2. Create/update the CA certificate secret resource

 If the new certificate was signed by a private CA, you will need to copy the corresponding root CA certificate into a file named `cacerts.pem` and create or update the `tls-ca secret` in the `cattle-system` namespace. If the certificate was signed by an intermediate CA, then the `cacerts.pem` must contain both the intermediate and root CA certificates (in this order).

@@ -56,7 +56,7 @@ $ kubectl -n cattle-system create secret generic tls-ca \
  --dry-run --save-config -o yaml | kubectl apply -f -
 ```

-## 3. Reconfigure the Rancher deployment
+### 3. Reconfigure the Rancher deployment

 > Before proceeding, generate an API token in the Rancher UI (<b>User > API & Keys</b>) and save the Bearer Token which you might need in step 4.

@@ -91,18 +91,18 @@ helm upgrade rancher rancher-stable/rancher \

 When the upgrade is completed, navigate to `https://<Rancher_SERVER>/v3/settings/cacerts` to verify that the value matches the CA certificate written in the `tls-ca` secret earlier.

-## 4. Reconfigure Rancher agents to trust the private CA
+### 4. Reconfigure Rancher agents to trust the private CA

 This section covers three methods to reconfigure Rancher agents to trust the private CA. This step is required if either of the following is true:

 - Rancher was initially configured to use the Rancher self-signed certificate (`ingress.tls.source=rancher`) or with a Let's Encrypt issued certificate (`ingress.tls.source=letsEncrypt`)
 - The root CA certificate for the new custom certificate has changed

-### Why is this step required?
+#### Why is this step required?

 When Rancher is configured with a certificate signed by a private CA, the CA certificate chain is downloaded into Rancher agent containers. Agents compare the checksum of the downloaded certificate against the `CATTLE_CA_CHECKSUM` environment variable. This means that, when the private CA certificate is changed on Rancher server side, the environvment variable `CATTLE_CA_CHECKSUM` must be updated accordingly.

-### Which method should I choose?
+#### Which method should I choose?

 Method 1 is the easiest one but requires all clusters to be connected to Rancher after the certificates have been rotated. This is usually the case if the process is performed right after updating the Rancher deployment (Step 3).

@@ -110,7 +110,7 @@ If the clusters have lost connection to Rancher but you have [Authorized Cluster

 Method 3 can be used as a fallback if method 1 and 2 are unfeasible.

-### Method 1: Kubectl command
+#### Method 1: Kubectl command

 For each cluster under Rancher management (except the `local` Rancher management cluster) run the following command using the Kubeconfig file of the Rancher management cluster (RKE or K3S).

@@ -120,8 +120,7 @@ kubectl patch clusters.management.cattle.io <REPLACE_WITH_CLUSTERID> -p '{"statu

 This command will cause all Agent Kubernetes resources to be reconfigured with the checksum of the new certificate.

-
-### Method 2: Manually update checksum
+#### Method 2: Manually update checksum

 Manually patch the agent Kubernetes resources by updating the `CATTLE_CA_CHECKSUM` environment variable to the value matching the checksum of the new CA certificate. Generate the new checksum value like so:

@@ -137,7 +136,7 @@ $ kubectl edit -n cattle-system ds/cattle-node-agent
 $ kubectl edit -n cattle-system deployment/cattle-cluster-agent
 ```

-### Method 3: Recreate Rancher agents
+#### Method 3: Recreate Rancher agents

 With this method you are recreating the Rancher agents by running a set of commands on a controlplane node of each downstream cluster.

@@ -147,7 +146,7 @@ Then, connect to a controlplane node of the downstream cluster via SSH, create a
 https://gist.github.com/superseb/b14ed3b5535f621ad3d2aa6a4cd6443b


-## 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher
+### 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher

 Select 'Force Update' for the clusters within the [Continuous Delivery](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#accessing-fleet-in-the-rancher-ui) view under Cluster Explorer in the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.

@@ -155,11 +154,11 @@ Select 'Force Update' for the clusters within the [Continuous Delivery](../../..

 Fleet agents in Rancher managed clusters store kubeconfig that is used to connect to the Rancher proxied kube-api in the fleet-agent secret of the fleet-system namespace. The kubeconfig contains a certificate-authority-data block containing the Rancher CA. When changing the Rancher CA, this block needs to be updated for a successful connection of the fleet-agent to Rancher.

-# Updating from a Private CA Certificate to a Common Certificate
+## Updating from a Private CA Certificate to a Common Certificate

 >It is possible to perform the opposite procedure as shown above: you may change from a private certificate to a common, or non-private, certificate. The steps involved are outlined below.

-## 1. Create/update the certificate secret resource
+### 1. Create/update the certificate secret resource

 First, concatenate the server certificate followed by any intermediate certificate(s) to a file named `tls.crt` and provide the corresponding certificate key in a file named `tls.key`.

@@ -180,7 +179,7 @@ $ kubectl -n cattle-system create secret tls tls-rancher-ingress \
  --dry-run --save-config -o yaml | kubectl apply -f -
 ```

-## 2. Delete the CA certificate secret resource
+### 2. Delete the CA certificate secret resource

 You will delete the `tls-ca secret` in the `cattle-system` namespace as it is no longer needed. You may also optionally save a copy of the `tls-ca secret` if desired.

@@ -196,7 +195,7 @@ To delete the existing `tls-ca` secret:
 kubectl -n cattle-system delete secret tls-ca
 ```

-## 3. Reconfigure the Rancher deployment
+### 3. Reconfigure the Rancher deployment

 > Before proceeding, [generate an API token in the Rancher UI](../../../reference-guides/user-settings/api-keys.md#creating-an-api-key) (<b>User > API & Keys</b>).

@@ -238,14 +237,14 @@ On upgrade, you can either
 set privateCA=false
 ```

-## 4. Reconfigure Rancher agents for the non-private/common certificate
+### 4. Reconfigure Rancher agents for the non-private/common certificate

 `CATTLE_CA_CHECKSUM` environment variable on the downstream cluster agents should be removed or set to "" (an empty string).

-## 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher
+### 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher

 Select 'Force Update' for the clusters within the [Continuous Delivery](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#accessing-fleet-in-the-rancher-ui) view under Cluster Explorer in the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.

-### Why is this step required?
+#### Why is this step required?

 Fleet agents in Rancher managed clusters store kubeconfig that is used to connect to the Rancher proxied kube-api in the fleet-agent secret of the fleet-system namespace. The kubeconfig contains a certificate-authority-data block containing the Rancher CA. When changing the Rancher CA, this block needs to be updated for a successful connection of the fleet-agent to Rancher.
@@ -24,7 +24,7 @@ To address these changes, this guide will do two things:

 > For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart](../install-upgrade-on-a-kubernetes-cluster/upgrades.md) under the upgrade Rancher section.

-# Upgrade Cert-Manager
+## 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.

@@ -239,4 +239,3 @@ We have also removed support for the old configuration format that was deprecate
 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/upgrading/).
-
@@ -45,7 +45,7 @@ The restore operation will work on a cluster that is not in a healthy or active

 **Result:** Kubernetes begins upgrading for the cluster.

-# Rolling Back
+## 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:

@@ -4,11 +4,11 @@ title: Overview

 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
+## 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
+## Meet IT requirements

 Rancher supports centralized authentication, access control, and monitoring for all Kubernetes clusters under its control. For example, you can:

@@ -16,7 +16,7 @@ Rancher supports centralized authentication, access control, and monitoring for
 - 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
+## 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.

@@ -24,7 +24,7 @@ The following figure illustrates the role Rancher plays in IT and DevOps organiz

 ![Platform](/img/platform.png)

-# Features of the Rancher API Server
+## 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:

@@ -52,7 +52,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
 - **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
+## 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](../../pages-for-subheaders/launch-kubernetes-with-rancher.md) have **Cluster Options** available for editing.

@@ -8,7 +8,7 @@ Only admins of the G Suite domain have access to the Admin SDK. Therefore, only

 Within Rancher, only administrators or users with the **Manage Authentication** [global role](../../manage-role-based-access-control-rbac/global-permissions.md) can configure authentication.

-# Prerequisites
+## Prerequisites
 - You must have a [G Suite admin account](https://admin.google.com) configured.
 - G Suite requires a [top private domain FQDN](https://github.com/google/guava/wiki/InternetDomainNameExplained#public-suffixes-and-private-domains) as an authorized domain. One way to get an FQDN is by creating an A-record in Route53 for your Rancher server. You do not need to update your Rancher Server URL setting with that record, because there could be clusters using that URL.
 - You must have the Admin SDK API enabled for your G Suite domain. You can enable it using the steps on [this page.](https://support.google.com/a/answer/60757?hl=en)
@@ -16,7 +16,7 @@ Within Rancher, only administrators or users with the **Manage Authentication**
 After the Admin SDK API is enabled, your G Suite domain's API screen should look like this:
 ![Enable Admin APIs](/img/Google-Enable-APIs-Screen.png)

-# Setting up G Suite for OAuth with Rancher
+## Setting up G Suite for OAuth with Rancher
 Before you can set up Google OAuth in Rancher, you need to log in to your G Suite account and do the following:

 1. [Add Rancher as an authorized domain in G Suite](#1-adding-rancher-as-an-authorized-domain)
@@ -89,7 +89,8 @@ Using the Unique ID of the service account key, register it as an Oauth Client u

 **Result:** The service account is registered as an OAuth client in your G Suite account.

-# Configuring Google OAuth in Rancher
+## Configuring Google OAuth in Rancher
+
 1. Sign into Rancher using a local user assigned the [administrator](../../manage-role-based-access-control-rbac/global-permissions.md) role. This user is also called the local principal.
 1.	From the **Global** view, click **Security > Authentication** from the main menu.
 1. Click **Google.** The instructions in the UI cover the steps to set up authentication with Google OAuth.
@@ -10,19 +10,11 @@ After you complete [Configuring Microsoft AD FS for Rancher](configure-ms-adfs-f
 >- The Relying Party Trust identifier URL is: `https://<RANCHER_SERVER>/v1-saml/adfs/saml/metadata`
 >- You must export the `federationmetadata.xml` file from your AD FS server. This can be found at: `https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml`

+1. From the **Global** view, select **Security > Authentication** from the main menu.

-1.	From the **Global** view, select **Security > Authentication** from the main menu.
-
-1.	Select **Microsoft Active Directory Federation Services**.
-
-1.	Complete the **Configure AD FS Account** form. Microsoft AD FS lets you specify an existing Active Directory (AD) server. The [configuration section below](#configuration) describe how you can map AD attributes to fields within Rancher.
-
-
-
-
-
-
+1. Select **Microsoft Active Directory Federation Services**.

+1. Complete the **Configure AD FS Account** form. Microsoft AD FS lets you specify an existing Active Directory (AD) server. The [configuration section below](#configuration) describe how you can map AD attributes to fields within Rancher.

 1. After you complete the **Configure AD FS Account** form, click **Authenticate with AD FS**, which is at the bottom of the page.

@@ -32,7 +24,7 @@ After you complete [Configuring Microsoft AD FS for Rancher](configure-ms-adfs-f

 **Result:** Rancher is configured to work with MS FS. Your users can now sign into Rancher using their MS FS logins.

-# Configuration
+## Configuration

 | Field | Description                |
 |---------------------------|-----------------|
@@ -6,7 +6,7 @@ Administrators have the permission to create RKE templates, and only administrat

 For more information on administrator permissions, refer to the [documentation on global permissions](../manage-role-based-access-control-rbac/global-permissions.md).

-# Giving Users Permission to Create Templates
+## Giving Users Permission to Create Templates

 Templates can only be created by users who have the global permission **Create RKE Templates.**

@@ -17,7 +17,7 @@ Global Permissions define user authorization outside the scope of any particular

 You cannot update or delete the built-in Global Permissions.

-# Restricted Admin
+## Restricted Admin

 A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation from the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster.

@@ -30,6 +30,7 @@ To bootstrap Rancher with the `restricted-admin` as the initial user, the Ranche
 ```
 CATTLE_RESTRICTED_DEFAULT_ADMIN=true
 ```
+
 ### List of `restricted-admin` Permissions

 The permissions for the `restricted-admin` role differ based on the Rancher version.
@@ -75,7 +76,7 @@ This can be done through **Security > Users** and moving any Administrator role

 Signed-in users can change themselves over to the `restricted-admin` if they wish, but they should only do that as the last step, otherwise they won't have the permissions to do so.

-# Global Permission Assignment
+## Global Permission Assignment

 Global permissions for local users are assigned differently than users who log in to Rancher using external authentication.

@@ -95,7 +96,7 @@ Permissions can be assigned to an individual user with [these steps.](#configuri

 You can [assign a role to everyone in the group at the same time](#configuring-global-permissions-for-groups) if the external authentication provider supports groups.

-# Custom Global Permissions
+## Custom Global Permissions

 Using custom permissions is convenient for providing users with narrow or specialized access to Rancher.

@@ -19,6 +19,6 @@ title: 1. Enable Istio in the Cluster

 **Result:** Istio is installed at the cluster level.

-# Additional Config Options
+## Additional Config Options

 For more information on configuring Istio, refer to the [configuration reference.](../../../pages-for-subheaders/configuration-options.md)
@@ -4,7 +4,7 @@ title: 6. Generate and View Traffic

 This section describes how to view the traffic that is being managed by Istio.

-# The Kiali Traffic Graph
+## The Kiali Traffic Graph

 The Istio overview page provides a link to the Kiali dashboard. From the Kiali dashboard, you are able to view graphs for each namespace. The Kiali graph provides a powerful way to visualize the topology of your Istio service mesh. It shows you which services communicate with each other.

@@ -16,7 +16,7 @@ For more information on the Istio gateway, refer to the [Istio documentation.](h

 ![In an Istio-enabled cluster, you can have two Ingresses: the default Nginx Ingress, and the default Istio controller.](/img/istio-ingress.svg)

-# Enable an Istio Gateway
+## Enable an Istio Gateway

 The ingress gateway is a Kubernetes service that will be deployed in your cluster. The Istio Gateway allows for more extensive customization and flexibility.

@@ -28,7 +28,7 @@ The ingress gateway is a Kubernetes service that will be deployed in your cluste

 **Result:** The gateway is deployed, and will now route traffic with applied rules

-# Example Istio Gateway
+## Example Istio Gateway

 We add the BookInfo app deployments in services when going through the Workloads example. Next we add an Istio Gateway so that the app is accessible from outside your cluster.

@@ -122,7 +122,7 @@ To get the ingress gateway URL and port,

 For help inspecting the Istio controller URL and ports, try the commands the [Istio documentation.](https://istio.io/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports)

-# Troubleshooting
+## Troubleshooting

 The [official Istio documentation](https://istio.io/docs/tasks/traffic-management/ingress/ingress-control/#troubleshooting) suggests `kubectl` commands to inspect the correct ingress host and ingress port for external requests.

@@ -509,7 +509,7 @@ kubectl -n kube-system apply -f cluster-autoscaler-deployment.yaml

 **Note:** Cluster-autoscaler deployment can also be set up using [manual configuration](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/aws#manual-configuration)

-# Testing
+## Testing

 At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:

@@ -7,7 +7,7 @@ After you launch a Kubernetes cluster in Rancher, you can manage individual node
 > If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters](../../../pages-for-subheaders/cluster-configuration.md).


-# Node Options Available for Each Cluster Creation Option
+## Node Options Available for Each Cluster Creation Option

 The following table lists which node options are available for each type of cluster in Rancher. Click the links in the **Option** column for more detailed information about each feature.

@@ -48,7 +48,7 @@ Options for managing nodes [hosted by a Kubernetes provider](../../../pages-for-

 Although you can deploy workloads to a [registered cluster](../../new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md) using Rancher, you cannot manage individual cluster nodes. All management of imported cluster nodes must take place outside of Rancher.

-# Managing and Editing Individual Nodes
+## Managing and Editing Individual Nodes

 Editing a node lets you:

@@ -59,11 +59,11 @@ Editing a node lets you:

 To manage individual nodes, browse to the cluster that you want to manage and then select **Nodes** from the main menu. You can open the options menu for a node by clicking its **&#8942;** icon (**...**).

-# Viewing a Node in the Rancher API
+## Viewing a Node in the Rancher API

 Select this option to view the node's [API endpoints](../../../pages-for-subheaders/about-the-api.md).

-# Deleting a Node
+## Deleting a Node

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

@@ -71,11 +71,11 @@ When you the delete a defective node, Rancher can automatically replace it with

 >**Tip:** If your cluster is hosted by an infrastructure provider, and you want to scale your cluster down instead of deleting a defective node, [scale down](#scaling-nodes) rather than delete.

-# Scaling Nodes
+## Scaling Nodes

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

-# SSH into a Node Hosted by an Infrastructure Provider
+## SSH into a Node Hosted by an Infrastructure Provider

 For [nodes hosted by an infrastructure provider](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md), you have the option of downloading its SSH key so that you can connect to it remotely from your desktop.

@@ -95,11 +95,11 @@ For [nodes hosted by an infrastructure provider](../../../pages-for-subheaders/u
    ssh -i id_rsa root@<IP_OF_HOST>
    ```

-# Cordoning a Node
+## Cordoning a Node

 _Cordoning_ a node marks it as unschedulable. This feature is useful for performing short tasks on the node during small maintenance windows, like reboots, upgrades, or decommissions.  When you're done, power back on and make the node schedulable again by uncordoning it.

-# Draining a Node
+## Draining a Node

 _Draining_ is the process of first cordoning the node, and then evicting all its pods. This feature is useful for performing node maintenance (like kernel upgrades or hardware maintenance). It prevents new pods from deploying to the node while redistributing existing pods so that users don't experience service interruption.

@@ -144,7 +144,7 @@ Once drain successfully completes, the node will be in a state of `drained`. You

 >**Want to know more about cordon and drain?** See the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node).

-# Labeling a Node to be Ignored by Rancher
+## Labeling a Node to be Ignored by Rancher

 Some solutions, such as F5's BIG-IP integration, may require creating a node that is never registered to a cluster.

@@ -10,7 +10,7 @@ To allow the Grafana dashboard to persist after the Grafana instance restarts, a
 - [Creating a Persistent Grafana Dashboard](#creating-a-persistent-grafana-dashboard)
 - [Known Issues](#known-issues)

-# Creating a Persistent Grafana Dashboard
+## Creating a Persistent Grafana Dashboard

 <Tabs>
 <TabItem value="Rancher v2.5.8+">
@@ -126,7 +126,7 @@ helm.sh/resource-policy: "keep"
 </TabItem>
 </Tabs>

-# Known Issues
+## Known Issues

 For users who are using Monitoring V2 v9.4.203 or below, uninstalling the Monitoring chart will delete the `cattle-dashboards` namespace, which will delete all persisted dashboards, unless the namespace is marked with the annotation `helm.sh/resource-policy: "keep"`.

@@ -11,7 +11,7 @@ This page describes how to enable monitoring and alerting within a cluster using

 You can enable monitoring with or without SSL.

-# Requirements
+## Requirements

 - Make sure that you are allowing traffic on port 9796 for each of your nodes because Prometheus will scrape metrics from here.
 - Make sure your cluster fulfills the resource requirements. The cluster should have at least 1950Mi memory available, 2700m CPU, and 50Gi storage. A breakdown of the resource limits and requests is [here.](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests)
@@ -26,13 +26,13 @@ rkeEtcd:

 > **Note:** If you want to set up Alertmanager, Grafana or Ingress, it has to be done with the settings on the Helm chart deployment. It's problematic to create Ingress outside the deployment.

-# Setting Resource Limits and Requests
+## Setting Resource Limits and Requests

 The resource requests and limits can be configured when installing `rancher-monitoring`.  To configure Prometheus resources from the Rancher UI, click **Apps & Marketplace > Monitoring** in the upper left corner.

 For more information about the default limits, see [this page.](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests)

-# Install the Monitoring Application
+## Install the Monitoring Application

 <Tabs>
 <TabItem value="Rancher v2.5.8">
@@ -5,7 +5,7 @@ title: Prometheus Configuration
 It is usually not necessary to directly edit the Prometheus custom resource because the monitoring application automatically updates it based on changes to ServiceMonitors and PodMonitors.
 > This section assumes familiarity with how monitoring components work together. For more information, see [this section.](../../../../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)

-# About the Prometheus Custom Resource
+## About the Prometheus Custom Resource

 The Prometheus CR defines a desired Prometheus deployment. The Prometheus Operator observes the Prometheus CR. When the CR changes, the Prometheus Operator creates `prometheus-rancher-monitoring-prometheus`, a Prometheus deployment based on the CR configuration.

@@ -9,7 +9,7 @@ A PrometheusRule defines a group of Prometheus alerting and/or recording rules.

 > This section assumes familiarity with how monitoring components work together. For more information, see [this section.](../../../../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)

-### Creating PrometheusRules in the Rancher UI
+## Creating PrometheusRules in the Rancher UI

 _Available as of v2.5.4_

@@ -25,7 +25,7 @@ To create rule groups in the Rancher UI,

 **Result:** Alerts can be configured to send notifications to the receiver(s).

-### About the PrometheusRule Custom Resource
+## About the PrometheusRule Custom Resource

 When you define a Rule (which is declared within a RuleGroup in a PrometheusRule resource), the [spec of the Rule itself](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#rule) contains labels that are used by Alertmanager to figure out which Route should receive this Alert. For example, an Alert with the label `team: front-end` will be sent to all Routes that match on that label.

@@ -42,7 +42,7 @@ Use the label selector field `ruleSelector` in the Prometheus object to define t

 For examples, refer to the Prometheus documentation on [recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/) and [alerting rules.](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)

-# Configuration
+## Configuration

 <Tabs>
 <TabItem value="Rancher v2.5.4">
@@ -8,7 +8,7 @@ Rancher recommends configuring recurrent `etcd` snapshots for all production clu

 Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.

-# How Snapshots Work
+## How Snapshots Work

 ### Snapshot Components

@@ -64,7 +64,7 @@ On restore, the following process is used:
 4. The other etcd nodes download the snapshot and validate the checksum so that they all use the same snapshot for the restore.
 5.  The cluster is restored and post-restore actions will be done in the cluster.

-# Configuring Recurring Snapshots
+## Configuring Recurring Snapshots

 Select how often you want recurring snapshots to be taken as well as how many snapshots to keep. The amount of time is measured in hours. With timestamped snapshots, the user has the ability to do a point-in-time recovery.

@@ -81,7 +81,7 @@ In the **Advanced Cluster Options** section, there are several options available
 | Recurring etcd Snapshot Creation Period | Time in hours between recurring snapshots| 12 hours |
 | Recurring etcd Snapshot Retention Count | Number of snapshots to retain| 6 |

-# One-Time Snapshots
+## One-Time Snapshots

 In addition to recurring snapshots, you may want to take a "one-time" snapshot. For example, before upgrading the Kubernetes version of a cluster it's best to backup the state of the cluster to protect against upgrade failure.

@@ -91,7 +91,7 @@ In addition to recurring snapshots, you may want to take a "one-time" snapshot.

 **Result:** Based on your [snapshot backup target](#snapshot-backup-targets), a one-time snapshot will be taken and saved in the selected backup target.

-# Snapshot Backup Targets
+## Snapshot Backup Targets

 Rancher supports two different backup targets:

@@ -130,7 +130,7 @@ The `S3` backup target supports using IAM authentication to AWS API in addition

 To give an application access to S3, refer to the AWS documentation on [Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)

-# Viewing Available Snapshots
+## Viewing Available Snapshots

 The list of all available snapshots for the cluster is available in the Rancher UI.

@@ -138,7 +138,7 @@ The list of all available snapshots for the cluster is available in the Rancher

 2. Click **Tools > Snapshots** from the navigation bar to view the list of saved snapshots. These snapshots include a timestamp of when they were created.

-# Safe Timestamps
+## Safe Timestamps

 Snapshot files are timestamped to simplify processing the files using external tools and scripts, but in some S3 compatible backends, these timestamps were unusable.

@@ -146,6 +146,6 @@ The option `safe_timestamp` is added to support compatible file names. When this

 This option is not available directly in the UI, and is only available through the `Edit as Yaml` interface.

-# Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0
+## Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0

 If you have any Rancher launched Kubernetes clusters that were created before v2.2.0, after upgrading Rancher, you must [edit the cluster](../../../pages-for-subheaders/cluster-configuration.md) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots before v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI](restore-rancher-launched-kubernetes-clusters-from-backup.md).
@@ -72,6 +72,6 @@ If the group of etcd nodes loses quorum, the Kubernetes cluster will report a fa

 6. After the single nodes is up and running, Rancher recommends adding additional etcd nodes to your cluster. If you have a [custom cluster](../../../pages-for-subheaders/use-existing-nodes.md) and you want to reuse an old node, you are required to [clean up the nodes](../../advanced-user-guides/manage-clusters/clean-cluster-nodes.md) before attempting to add them back into a cluster.

-# Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0
+## Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0

 If you have any Rancher launched Kubernetes clusters that were created before v2.2.0, after upgrading Rancher, you must [edit the cluster](../../../pages-for-subheaders/cluster-configuration.md) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots before v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI](restore-rancher-launched-kubernetes-clusters-from-backup.md).
@@ -10,7 +10,7 @@ This tutorial is about one possible way to set up your load balancer, not the on

 Rancher only supports using the Amazon NLB when terminating traffic in `tcp` mode for port 443 rather than `tls` mode. This is due to the fact that the NLB does not inject the correct headers into requests when terminated at the NLB. This means that if you want to use certificates managed by the Amazon Certificate Manager (ACM), you should use an ALB.

-# Setting up the Load Balancer
+## Setting up the Load Balancer

 Configuring an Amazon NLB is a multistage process:

@@ -19,11 +19,11 @@ Configuring an Amazon NLB is a multistage process:
 3. [Create Your NLB](#3-create-your-nlb)
 4. [Add listener to NLB for TCP port 80](#4-add-listener-to-nlb-for-tcp-port-80)

-# Requirements
+## Requirements

 These instructions assume you have already created Linux instances in EC2. The load balancer will direct traffic to these nodes.

-# 1. Create Target Groups
+## 1. Create Target Groups

 Begin by creating two target groups for the **TCP** protocol, one with TCP port 443 and one regarding TCP port 80 (providing redirect to TCP port 443). You'll add your Linux nodes to these groups.

@@ -86,7 +86,7 @@ Health check settings:
 | Timeout             | `6 seconds`    |
 | Interval            | `10 seconds`   |

-# 2. Register Targets
+## 2. Register Targets

 Next, add your Linux nodes to both target groups.

@@ -110,7 +110,7 @@ When the instances are added, click **Save** on the bottom right of the screen.

 Repeat those steps, replacing **rancher-tcp-443** with **rancher-tcp-80**. The same instances need to be added as targets to this target group.

-# 3. Create Your NLB
+## 3. Create Your NLB

 Use Amazon's Wizard to create a Network Load Balancer. As part of this process, you'll add the target groups you created in [1. Create Target Groups](#1-create-target-groups).

@@ -152,7 +152,7 @@ Look over the load balancer details and click **Create** when you're satisfied.

 After AWS creates the NLB, click **Close**.

-# 4. Add listener to NLB for TCP port 80
+## 4. Add listener to NLB for TCP port 80

 1. Select your newly created NLB and select the **Listeners** tab.

@@ -166,7 +166,7 @@ After AWS creates the NLB, click **Close**.

 6. Click **Save** in the top right of the screen.

-# Health Check Paths for NGINX Ingress and Traefik Ingresses
+## Health Check Paths for NGINX Ingress and Traefik Ingresses

 K3s and RKE Kubernetes clusters handle health checks differently because they use different Ingresses by default.

@@ -13,12 +13,13 @@ For systems without direct internet access, refer to the air gap installation in
 >
 > In both single-node setups, Rancher can be installed with Helm on the Kubernetes cluster in the same way that it would be installed on any other cluster.

-# Prerequisites
+## Prerequisites

 These instructions assume you have set up two nodes, a load balancer, a DNS record, and an external MySQL database as described in [this section.](../infrastructure-setup/ha-k3s-kubernetes-cluster.md)

 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/) To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script.
-# Installing Kubernetes
+
+## Installing Kubernetes

 ### 1. Install Kubernetes and Set up the K3s Server

@@ -16,7 +16,7 @@ For systems without direct internet access, refer to [Air Gap: Kubernetes instal
 >
 > In both single-node setups, Rancher can be installed with Helm on the Kubernetes cluster in the same way that it would be installed on any other cluster.

-# Installing Kubernetes
+## Installing Kubernetes

 ### Required CLI Tools

@@ -6,14 +6,15 @@ _Tested on v2.5.6_

 This section describes how to install a Kubernetes cluster according to the [best practices for the Rancher server environment.](../../../reference-guides/rancher-manager-architecture/architecture-recommendations.md#environment-for-kubernetes-installations)

-# Prerequisites
+## Prerequisites

 These instructions assume you have set up three nodes, a load balancer, and a DNS record, as described in [this section.](../infrastructure-setup/ha-rke2-kubernetes-cluster.md)

 Note that in order for RKE2 to work correctly with the load balancer, you need to set up two listeners: one for the supervisor on port 9345, and one for the Kubernetes API on port 6443.

 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/) To specify the RKE2 version, use the INSTALL_RKE2_VERSION environment variable when running the RKE2 installation script.
-# Installing Kubernetes
+
+## Installing Kubernetes

 ### 1. Install Kubernetes and Set up the RKE2 Server

@@ -9,13 +9,13 @@ This diagram is applicable to Kubernetes clusters [launched with Rancher using R
 ![Cluster diagram](/img/clusterdiagram.svg)<br/>
 <sup>Lines show the traffic flow between components. Colors are used purely for visual aid</sup>

-# etcd
+## etcd

 Nodes with the `etcd` role run etcd, which is a consistent and highly available key value store used as Kubernetes’ backing store for all cluster data. etcd replicates the data to each node.

 >**Note:** Nodes with the `etcd` role are shown as `Unschedulable` in the UI, meaning no pods will be scheduled to these nodes by default.

-# controlplane
+## controlplane

 Nodes with the `controlplane` role run the Kubernetes master components (excluding `etcd`, as it's a separate role). See [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components) for a detailed list of components.

@@ -33,10 +33,10 @@ The Kubernetes controller manager uses leader election using an endpoint in Kube

 The Kubernetes scheduler uses leader election using an endpoint in Kubernetes. One instance of the `kube-scheduler` will create an entry in the Kubernetes endpoints and updates that entry in a configured interval. Other instances will see an active leader and wait for that entry to expire (for example, when a node is unresponsive).

-# worker
+## worker

 Nodes with the `worker` role run the Kubernetes node components. See [Kubernetes: Node Components](https://kubernetes.io/docs/concepts/overview/components/#node-components) for a detailed list of components.

-# References
+## References

 * [Kubernetes: Node Components](https://kubernetes.io/docs/concepts/overview/components/#node-components)
@@ -8,7 +8,7 @@ Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has

 This page covers how to install the Cloud Provider Interface (CPI) and Cloud Storage Interface (CSI) plugins after bringing up a cluster.

-# Prerequisites
+## Prerequisites

 The vSphere versions supported:

@@ -19,7 +19,7 @@ The Kubernetes version must be 1.19 or higher.

 Using the vSphere out-of-tree cloud provider requires Linux nodes and is not supported on Windows.

-# Installation
+## Installation

 The Cloud Provider Interface (CPI) should be installed first before installing the Cloud Storage Interface (CSI).

@@ -47,7 +47,7 @@ The Cloud Provider Interface (CPI) should be installed first before installing t
 3. This chart creates a StorageClass with the `csi.vsphere.vmware.com` as the provisioner. Fill out the details for the StorageClass and launch the chart.


-# Using the CSI driver for provisioning volumes
+## Using the CSI driver for provisioning volumes

 The CSI chart by default creates a storageClass.

@@ -32,12 +32,12 @@ Upstream bug: https://github.com/kubernetes-sigs/vsphere-csi-driver/issues/628

 Rancher issue tracking this bug: https://github.com/rancher/rancher/issues/31105

-# Prerequisites
+## Prerequisites

 - vSphere CSI Migration requires vSphere 7.0u1. In order to be able to manage existing in-tree vSphere volumes, upgrade vSphere to 7.0u1.
 - The Kubernetes version must be 1.19 or higher.

-# Migration
+## Migration

 ### 1. Install the CPI plugin

@@ -9,7 +9,7 @@ First, you will set up your EC2 cloud credentials in Rancher. Then you will use

 Then you will create an EC2 cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.

-### Prerequisites
+## Prerequisites

 - **AWS EC2 Access Key and Secret Key** that will be used to create the instances. See [Amazon Documentation: Creating Access Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) how to create an Access Key and Secret Key.
 - **IAM Policy created** to add to the user of the Access Key And Secret Key. See [Amazon Documentation: Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) how to create an IAM policy. See our three example JSON policies below:
@@ -18,7 +18,7 @@ Then you will create an EC2 cluster in Rancher, and when configuring the new clu
  - [Example IAM Policy to allow encrypted EBS volumes](#example-iam-policy-to-allow-encrypted-ebs-volumes)
 - **IAM Policy added as Permission** to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to an user.

-# Creating an EC2 Cluster
+## Creating an EC2 Cluster

 The steps to create a cluster differ based on your Rancher version.

@@ -70,6 +70,7 @@ You can access your cluster after its state is updated to **Active.**

 - `Default`, containing the `default` namespace
 - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
+
 ### Optional Next Steps

 After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
@@ -77,7 +78,7 @@ After creating your cluster, you can access it through the Rancher UI. As a best
 - **Access your cluster with the kubectl CLI:** Follow [these steps](../../../../advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
 - **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps](../../../../advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.

-# IAM Policies
+## IAM Policies

 ### Example IAM Policy

@@ -22,7 +22,7 @@ For more information on configuring Azure node templates, refer to the [Azure no
 - [Preparation in Azure](#preparation-in-azure)
 - [Creating an Azure Cluster](#creating-an-azure-cluster)

-# Preparation in Azure
+## Preparation in Azure

 Before creating a node template in Rancher using a cloud infrastructure such as Azure, we must configure Rancher to allow the manipulation of resources in an Azure subscription.

@@ -39,7 +39,7 @@ az ad sp create-for-rbac \

 The creation of this service principal returns three pieces of identification information, *The application ID, also called the client ID*, *The client secret*, and *The tenant ID*. This information will be used when you create a node template for Azure.

-# Creating an Azure Cluster
+## Creating an Azure Cluster


 1. [Create your cloud credentials](#1-create-your-cloud-credentials)
@@ -14,7 +14,7 @@ Deployments use the Kubernetes registry secret to authenticate with a private Do

 Currently, deployments pull the private registry credentials automatically only if the workload is created in the Rancher UI and not when it is created via kubectl.

-# Creating a Registry
+## Creating a Registry

 >**Prerequisites:** You must have a [private registry](https://docs.docker.com/registry/deploying/) available to use.

@@ -40,7 +40,7 @@ Currently, deployments pull the private registry credentials automatically only
 - You can view the secret in the Rancher UI from the **Resources > Registries** view.
 - Any workload that you create in the Rancher UI will have the credentials to access the registry if the workload is within the registry's scope.

-# Using a Private Registry
+## Using a Private Registry

 You can deploy a workload with an image from a private registry through the Rancher UI, or with `kubectl`.

@@ -15,7 +15,7 @@ Ingress can be added for workloads to provide load balancing, SSL termination an
 **Result:** Your ingress is added to the project. The ingress begins enforcing your ingress rules.


-# Ingress Rule Configuration
+## Ingress Rule Configuration

 - [Automatically generate a sslip.io hostname](#automatically-generate-a-sslip-io-hostname)
 - [Specify a hostname to use](#specify-a-hostname-to-use)
@@ -10,7 +10,7 @@ When configuring a workload, you'll be able to choose which secrets to include.

 Mounted secrets will be updated automatically unless they are mounted as subpath volumes. For details on how updated secrets are propagated, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/secret/#mounted-secrets-are-updated-automatically)

-# Creating Secrets
+## Creating Secrets

 When creating a secret, you can make it available for any deployment within a project, or you can limit it to a single namespace.

@@ -36,7 +36,7 @@ When creating a secret, you can make it available for any deployment within a pr

 Mounted secrets will be updated automatically unless they are mounted as subpath volumes. For details on how updated secrets are propagated, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/secret/#mounted-secrets-are-updated-automatically)

-# What's Next?
+## What's Next?

 Now that you have a secret added to the project or namespace, you can add it to a workload that you deploy.

@@ -12,14 +12,14 @@ Throughout the installation instructions, there will be _tabs_ for each installa

 > **Important:** If you install Rancher following the Docker installation guide, there is no upgrade path to transition your Docker Installation to a Kubernetes Installation.

-# Installation Outline
+## Installation Outline

 1. [Set up infrastructure and private registry](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/infrastructure-private-registry.md)
 2. [Collect and publish images to your private registry](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images.md)
 3. [Set up a Kubernetes cluster (Skip this step for Docker installations)](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes.md)
 4. [Install Rancher](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md)

-# Upgrades
+## Upgrades

 To upgrade Rancher with Helm CLI in an air gap environment, follow [this procedure.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md)

@@ -10,8 +10,7 @@ If you also configure OpenLDAP as the back end to Shibboleth, it will return a S

 > The instructions in this section assume that you understand how Rancher, Shibboleth, and OpenLDAP work together. For a more detailed explanation of how it works, refer to [this page.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/configure-shibboleth-saml/about-group-permissions.md)

-
-# Setting up Shibboleth in Rancher
+## Setting up Shibboleth in Rancher

 ### Shibboleth Prerequisites
 >
@@ -69,7 +68,7 @@ If you configure Shibboleth without OpenLDAP, the following caveats apply due to

 To enable searching for groups when assigning permissions in Rancher, you will need to configure a back end for the SAML provider that supports groups, such as OpenLDAP.

-# Setting up OpenLDAP in Rancher
+## Setting up OpenLDAP in Rancher

 If you also configure OpenLDAP as the back end to Shibboleth, it will return a SAML assertion to Rancher with user attributes that include groups. Then authenticated users will be able to access resources in Rancher that their groups have permissions for.

@@ -91,6 +90,6 @@ Configure the settings for the OpenLDAP server, groups and users. For help filli
 2. From the **Global** view, navigate to **Security** > **Authentication**
 3. Select **OpenLDAP**. The **Configure an OpenLDAP server** form will be displayed.

-# Troubleshooting
+## Troubleshooting

 If you are experiencing issues while testing the connection to the OpenLDAP server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
@@ -24,7 +24,7 @@ Because the API sets the actual value and the command line sets the default valu

 For example, if you install Rancher, then set a feature flag to true with the Rancher API, then upgrade Rancher with a command that sets the feature flag to false, the default value will still be false, but the feature will still be enabled because it was set with the Rancher API. If you then deleted the set value (true) with the Rancher API, setting it to NULL, the default value (false) would take effect. See the [feature flags page](../reference-guides/installation-references/feature-flags.md) for more information.

-# Enabling Features when Starting Rancher
+## Enabling Features when Starting Rancher

 When you install Rancher, enable the feature you want with a feature flag. The command is different depending on whether you are installing Rancher on a single node or if you are doing a Kubernetes Installation of Rancher.

@@ -84,8 +84,7 @@ docker run -d -p 80:80 -p 443:443 \
  --features=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true
 ```

-
-# Enabling Features with the Rancher UI
+## Enabling Features with the Rancher UI

 1. In the upper left corner, click **☰ > Global Settings**.
 1. Click **Feature Flags**.
@@ -101,7 +100,7 @@ docker run -d -p 80:80 -p 443:443 \

 **Result:** The feature is disabled.

-# Enabling Features with the Rancher API
+## Enabling Features with the Rancher API

 1. Go to `<RANCHER-SERVER-URL>/v3/features`.
 1. In the `data` section, you will see an array containing all of the features that can be turned on with feature flags. The name of the feature is in the `id` field. Click the name of the feature you want to enable.
@@ -8,7 +8,7 @@ import TabItem from '@theme/TabItem';
 <Tabs>
 <TabItem value="Rancher v2.5.8+">

-# Changes in v2.5.8
+## Changes in v2.5.8

 - We now support private GKE clusters. Note: This advanced setup can require more steps during the cluster provisioning process. For details, see [this section.](../reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-private-clusters.md)
 - [Shared VPCs](https://cloud.google.com/vpc/docs/shared-vpc) are now supported.
@@ -22,7 +22,7 @@ import TabItem from '@theme/TabItem';
    - Node pools can be added while configuring the GKE cluster
 - When provisioning a GKE cluster, you can now use reusable cloud credentials instead of using a service account token directly to create the cluster.

-# Cluster Location
+## Cluster Location

 | Value | Description |
 |--------|--------------|
@@ -31,7 +31,7 @@ import TabItem from '@theme/TabItem';
 | Additional Zones | For zonal clusters, you can select additional zones to create a [multi-zone cluster.](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#multi-zonal_clusters) |
 | Region | For [regional clusters,](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#regional_clusters) you can select a region. For more information about available regions and zones, refer to [this section](https://cloud.google.com/compute/docs/regions-zones#available). The first part of each zone name is the name of the region. |

-# Cluster Options
+## Cluster Options

 ### Kubernetes Version

@@ -133,7 +133,7 @@ _Mutable: yes_

 Enable control plane authorized networks to block untrusted non-GCP source IPs from accessing the Kubernetes master through HTTPS. If selected, additional authorized networks may be added. If the cluster is created with a public endpoint, this option is useful for locking down access to the public endpoint to only certain networks, such as the network where your Rancher service is running. If the cluster only has a private endpoint, this setting is required.

-# Additional Options
+## Additional Options

 ### Cluster Addons

@@ -182,7 +182,7 @@ _Mutable: yes_

 Set the start time for a 4 hour maintenance window. The time is specified in the UTC time zone using the HH:MM format. For more information, refer to [this page.](https://cloud.google.com/kubernetes-engine/docs/concepts/maintenance-windows-and-exclusions)

-# Node Pools
+## Node Pools

 In this section, enter details describing the configuration of each node in the node pool.

@@ -240,7 +240,7 @@ You can apply labels to the node pool, which applies the labels to all nodes in

 Invalid labels can prevent upgrades or can prevent Rancher from starting. For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)

-# Group Details
+## Group Details

 In this section, enter details describing the node pool.

@@ -306,13 +306,13 @@ The shorter the refresh window, the less likely any race conditions will occur,
 </TabItem>
 <TabItem value="Rancher before v2.5.8">

-# Labels & Annotations
+## Labels & Annotations

 Add Kubernetes [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to the cluster.

 Invalid labels can prevent upgrades or can prevent Rancher from starting. For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)

-# Kubernetes Options
+## Kubernetes Options

 ### Location Type
 Zonal or Regional. With GKE, you can create a cluster tailored to the availability requirements of your workload and your budget. By default, a cluster's nodes run in a single compute zone. When multiple zones are selected, the cluster's nodes will span multiple compute zones, while the controlplane is located in a single zone. Regional clusters increase the availability of the controlplane as well. For help choosing the type of cluster availability, refer to [these docs.](https://cloud.google.com/kubernetes-engine/docs/best-practices/scalability#choosing_a_regional_or_zonal_control_plane)
@@ -15,7 +15,7 @@ Cluster Autoscaler is designed to run on Kubernetes master nodes. It can run in

 It's possible to run a customized deployment of Cluster Autoscaler on worker nodes, but extra care needs to be taken to ensure that Cluster Autoscaler remains up and running.

-# Cloud Providers
+## Cloud Providers

 Cluster Autoscaler provides support to distinct cloud providers. For more information, go to [cluster-autoscaler supported cloud providers.](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment)

@@ -17,7 +17,7 @@ RancherD is a single binary that first launches an RKE2 Kubernetes cluster, then
 - [Uninstall](#uninstall)
 - [RKE2 Documentation](#rke2-documentation)

-# About RancherD Installs
+## About RancherD Installs

 When RancherD is launched on a host, it first installs an RKE2 Kubernetes cluster, then deploys Rancher on the cluster as a Kubernetes daemonset.

@@ -29,7 +29,7 @@ In Part I of these instructions, you'll learn how to launch RancherD on a single

 Part II explains how to convert the single-node Rancher installation into a high-availability installation. If the Rancher server will manage downstream Kubernetes clusters, it is important to follow these steps. A discussion of recommended architecture for highly available Rancher deployments can be found in our [Best Practices Guide.](./rancher-server.md)

-# Prerequisites
+## Prerequisites

 ### Node Requirements

@@ -38,6 +38,7 @@ RancherD must be launched on a Linux OS. At this time, only OSes that leverage s
 The Linux node needs to fulfill the [installation requirements](installation-requirements.md) for hardware and networking. Docker is not required for RancherD installs.

 To install RancherD on SELinux Enforcing CentOS 8 nodes or RHEL 8 nodes, some [additional steps](installation-requirements.md#rancherd-on-selinux-enforcing-centos-8-or-rhel-8-nodes) are required.
+
 ### Root Access

 Before running the installation commands, you will need to log in as root:
@@ -71,7 +72,7 @@ The following should be taken into consideration when configuring the load balan
 - The Kubernetes API is served on port 6443, as normal.
 - In RancherD installs, the Rancher UI is served on port 8443 by default. (This is different from Helm chart installs, where port 443 is used by default.)

-# Part I: Installing Rancher
+## Part I: Installing Rancher

 ### 1. Set up Configurations

@@ -170,7 +171,7 @@ This will give you the URL, username and password needed to log into Rancher. Fo

 If Rancher will only manage the local Kubernetes cluster, the installation is complete.

-# Part II: High Availability
+## Part II: High Availability

 If you plan to use the Rancher server to manage downstream Kubernetes clusters, Rancher needs to be highly available. In these steps, you will add more nodes to achieve a high-availability cluster. Since Rancher is running as a daemonset, it will automatically launch on the nodes you add.

@@ -216,15 +217,15 @@ Repeat steps one and two for another Linux node, bringing the number of nodes in

 **Result:** Rancher is highly available and the installation is complete.

-# Upgrades
+## Upgrades

 For information on upgrades and rollbacks, refer to [this page.](../getting-started/installation-and-upgrade/other-installation-methods/install-rancher-on-linux/upgrade-rancherd.md)

-# Configuration
+## Configuration

 For information on how to configure certificates, node taints, Rancher Helm chart options, or RancherD CLI options, refer to the [configuration reference.](../reference-guides/cluster-configuration/rancher-server-configuration/rancherd-configuration-reference.md)

-# Uninstall
+## Uninstall

 To uninstall RancherD from your system, run the command below. This will shut down the process, remove the RancherD binary, and clean up files used by RancherD.

@@ -232,6 +233,6 @@ To uninstall RancherD from your system, run the command below. This will shut do
 rancherd-uninstall.sh
 ```

-# RKE2 Documentation
+## RKE2 Documentation

 For more information on RKE2, the Kubernetes distribution used to provision the underlying cluster, refer to the documentation [here.](https://docs.rke2.io/)
@@ -8,7 +8,7 @@ import TabItem from '@theme/TabItem';

 In this section, you'll learn how to deploy Rancher on a Kubernetes cluster using the Helm CLI.

-# Prerequisites
+## Prerequisites

 - [Kubernetes Cluster](#kubernetes-cluster)
 - [CLI Tools](#cli-tools)
@@ -42,7 +42,7 @@ To deploy Rancher v2.5 on a hosted Kubernetes cluster such as EKS, GKE, or AKS,

 For an example of how to deploy an ingress on EKS, refer to [this section.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md#5-install-an-ingress)

-# Install the Rancher Helm Chart
+## Install the Rancher Helm Chart

 Rancher is installed using the Helm package manager for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents.

@@ -5,7 +5,7 @@ description: Learn how to install Rancher in development and production environm

 This section provides an overview of the architecture options of installing Rancher, describing advantages of each option.

-# Terminology
+## Terminology

 In this section,

@@ -15,7 +15,7 @@ In this section,
 - **RKE2** is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
 - **RancherD** was an experimental tool for installing Rancher; a single binary that first launched an RKE2 Kubernetes cluster, then installed the Rancher server Helm chart on the cluster. It was available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.

-# Changes to Installation in Rancher v2.5
+## Changes to Installation in Rancher v2.5

 In Rancher v2.5, the Rancher management server can be installed on any Kubernetes cluster, including hosted clusters, such as Amazon EKS clusters.

@@ -23,7 +23,7 @@ For Docker installations, a local Kubernetes cluster is installed in the single

 The `restrictedAdmin` Helm chart option was added. 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/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin)

-# Overview of Installation Options
+## Overview of Installation Options

 Rancher can be installed on these main architectures:

@@ -79,10 +79,11 @@ When the nodes in your Kubernetes cluster are running and fulfill the [node requ

 For a longer discussion of Rancher architecture, refer to the [architecture overview,](rancher-manager-architecture.md) [recommendations for production-grade architecture,](../reference-guides/rancher-manager-architecture/architecture-recommendations.md) or our [best practices guide.](../reference-guides/best-practices/rancher-server/tips-for-running-rancher.md)

-# Prerequisites
+## Prerequisites
+
 Before installing Rancher, make sure that your nodes fulfill all of the [installation requirements.](installation-requirements.md)

-# Architecture Tip
+## Architecture Tip

 For the best performance and greater security, we recommend a separate, dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](kubernetes-clusters-in-rancher-setup.md) for running your workloads.

@@ -35,7 +35,7 @@ For a list of best practices that we recommend for running the Rancher server in

 The Rancher UI works best in Firefox or Chrome.

-# Operating Systems and Container Runtime Requirements
+## Operating Systems and Container Runtime Requirements

 Rancher should work with any modern Linux distribution.

@@ -101,11 +101,11 @@ Docker is required for Helm chart installs, and it can be installed by following

 Docker is not required for RancherD installs.

-# Hardware Requirements
+## Hardware Requirements

 The following sections describe the CPU, memory, and disk requirements for the nodes where the Rancher server is installed.

-# CPU and Memory
+## CPU and Memory

 Hardware requirements scale based on the size of your Rancher deployment. Provision each individual node according to the requirements. The requirements are different depending on if you are installing Rancher in a single container with Docker, or if you are installing Rancher on a Kubernetes cluster.

@@ -168,7 +168,7 @@ These CPU and memory requirements apply to a host with a [single-node](rancher-o
 | Small           | Up to 5  | Up to 50  | 1     | 4 GB |
 | Medium          | Up to 15 | Up to 200 | 2     | 8 GB |

-# Ingress
+## Ingress

 Each node in the Kubernetes cluster that Rancher is installed on should run an Ingress.

@@ -185,11 +185,11 @@ Currently, RKE2 deploys nginx-ingress as a deployment by default, so you will ne
 ### Ingress for EKS
 For an example of how to deploy an nginx-ingress-controller with a LoadBalancer service, refer to [this section.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md#5-install-an-ingress)

-# Disks
+## Disks

 Rancher performance depends on etcd in the cluster performance. To ensure optimal speed, we recommend always using SSD disks to back your Rancher management Kubernetes cluster. On cloud providers, you will also want to use the minimum size that allows the maximum IOPS. In larger clusters, consider using dedicated storage devices for etcd data and wal directories.

-# Networking Requirements
+## Networking Requirements

 This section describes the networking requirements for the node(s) where the Rancher server is installed.

@@ -201,7 +201,7 @@ Each node used should have a static IP configured, regardless of whether you are

 To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes. [Port Requirements](../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md) lists all the necessary ports for Rancher and Downstream Clusters for the different cluster types.

-# RancherD on SELinux Enforcing CentOS 8 or RHEL 8 Nodes
+## RancherD on SELinux Enforcing CentOS 8 or RHEL 8 Nodes

 Before installing Rancher on SELinux Enforcing CentOS 8 nodes or RHEL 8 nodes, you must install `container-selinux` and `iptables`:

@@ -6,7 +6,7 @@ This section describes how to enable Istio and start using it in your projects.

 If you use Istio for traffic management, you will need to allow external traffic to the cluster. In that case, you will need to follow all of the steps below.

-# Prerequisites
+## Prerequisites

 This guide assumes you have already [installed Rancher,](installation-and-upgrade.md) and you have already [provisioned a separate Kubernetes cluster](kubernetes-clusters-in-rancher-setup.md) on which you will install Istio.

@@ -14,8 +14,7 @@ The nodes in your cluster must meet the [CPU and memory requirements.](../explan

 The workloads and services that you want to be controlled by Istio must meet [Istio's requirements.](https://istio.io/docs/setup/additional-setup/requirements/)

-
-# Install
+## Install

 > **Quick Setup** If you don't need external traffic to reach Istio, and you just want to set up Istio for monitoring and tracing traffic within the cluster, skip the steps for [setting up the Istio gateway](../how-to-guides/advanced-user-guides/istio-setup-guide/set-up-istio-gateway.md) and [setting up Istio's components for traffic management.](../how-to-guides/advanced-user-guides/istio-setup-guide/set-up-traffic-management.md)

@@ -11,7 +11,7 @@ This section includes troubleshooting tips in the following categories:
 - [Troubleshooting nginx-proxy Nodes](../troubleshooting/kubernetes-components/troubleshooting-nginx-proxy.md)
 - [Troubleshooting Worker Nodes and Generic Components](../troubleshooting/kubernetes-components/troubleshooting-worker-nodes-and-generic-components.md)

-# Kubernetes Component Diagram
+## Kubernetes Component Diagram

 ![Cluster diagram](/img/clusterdiagram.svg)<br/>
 <sup>Lines show the traffic flow between components. Colors are used purely for visual aid</sup>
@@ -23,11 +23,11 @@ The monitoring application allows you to:
 - Defines precomputed, frequently needed or computationally expensive expressions as new time series based on metrics collected via Prometheus
 - Expose collected metrics from Prometheus to the Kubernetes Custom Metrics API via Prometheus Adapter for use in HPA

-# How Monitoring Works
+## How Monitoring Works

 For an explanation of how the monitoring components work together, see [this page.](../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)

-# Default Components and Deployments
+## Default Components and Deployments

 ### Built-in Dashboards

@@ -48,11 +48,11 @@ The monitoring application deploys some alerts by default. To see the default al

 For a list of monitoring components exposed in the Rancher UI, along with common use cases for editing them, see [this section.](../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#components-exposed-in-the-rancher-ui)

-# Role-based Access Control
+## Role-based Access Control

 For information on configuring access to monitoring, see [this page.](../explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md)

-# Guides
+## Guides

 - [Enable monitoring](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/enable-monitoring.md)
 - [Uninstall monitoring](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/uninstall-monitoring.md)
@@ -62,7 +62,7 @@ For information on configuring access to monitoring, see [this page.](../explana
 - [Debugging high memory usage](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/debug-high-memory-usage.md)
 - [Migrating from Monitoring V1 to V2](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md)

-# Configuration
+## Configuration

 ### Configuring Monitoring Resources in Rancher

@@ -79,7 +79,7 @@ For information on configuring access to monitoring, see [this page.](../explana

 For more information on `rancher-monitoring` chart options, including options to set resource limits and requests, see [this page.](../reference-guides/monitoring-v2-configuration/helm-chart-options.md)

-# Windows Cluster Support
+## Windows Cluster Support

 _Available as of v2.5.8_

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

 For more details on how to upgrade wins on existing Windows hosts, refer to the section on [Windows cluster support for Monitoring V2.](../explanations/integrations-in-rancher/monitoring-and-alerting/windows-support.md)

-
-
-# Known Issues
+## Known Issues

 There is a [known issue](https://github.com/rancher/rancher/issues/28787#issuecomment-693611821) that K3s clusters require more default memory. If you are enabling monitoring on a K3s cluster, we recommend setting `prometheus.prometheusSpec.resources.memory.limit` to 2500 Mi and `prometheus.prometheusSpec.resources.memory.request` to 1750 Mi.

@@ -6,19 +6,18 @@ This page captures some of the most important options for configuring Monitoring

 For information on configuring custom scrape targets and rules for Prometheus, please refer to the upstream documentation for the [Prometheus Operator.](https://github.com/prometheus-operator/prometheus-operator) Some of the most important custom resources are explained in the Prometheus Operator [design documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md) The Prometheus Operator documentation can help also you set up RBAC, Thanos, or custom configuration.

-# Setting Resource Limits and Requests
+## Setting Resource Limits and Requests

 The resource requests and limits for the monitoring application can be configured when installing `rancher-monitoring`. For more information about the default limits, see [this page.](../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests)

 >**Note:** On an idle cluster, Monitoring V2 has significantly higher CPU usage (up to 70%) as compared to Monitoring V1. To improve performance and achieve similar results as in Monitoring V1, turn off the Prometheus adapter.

-# Prometheus Configuration
+## Prometheus Configuration

 It is usually not necessary to directly edit the Prometheus custom resource.

 Instead, to configure Prometheus to scrape custom metrics, you will only need to create a new ServiceMonitor or PodMonitor to configure Prometheus to scrape additional metrics.

-
 ### ServiceMonitor and PodMonitor Configuration

 For details, see [this page.](../reference-guides/monitoring-v2-configuration/servicemonitors-and-podmonitors.md)
@@ -27,7 +26,7 @@ For details, see [this page.](../reference-guides/monitoring-v2-configuration/se

 For more information about directly editing the Prometheus custom resource, which may be helpful in advanced use cases, see [this page.](../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheus.md)

-# Alertmanager Configuration
+## Alertmanager Configuration

 The Alertmanager custom resource usually doesn't need to be edited directly. For most common use cases, you can manage alerts by updating Routes and Receivers.

@@ -24,11 +24,11 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins
 >**Note:** Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses.


-# Concepts
+## Concepts

 For an explanation of concepts and terminology used in this section, refer to [this page.](../reference-guides/pipelines/concepts.md)

-# How Pipelines Work
+## How Pipelines Work

 After enabling the ability to use pipelines in a project, you can configure multiple pipelines in each project. Each pipeline is unique and can be configured independently.

@@ -54,7 +54,7 @@ When you configure a pipeline in one of your projects, a namespace specifically

  >**Note:** The managed Jenkins instance works statelessly, so don't worry about its data persistency. The Docker Registry and Minio instances use ephemeral volumes by default, which is fine for most use cases. If you want to make sure pipeline logs can survive node failures, you can configure persistent volumes for them, as described in [data persistency for pipeline components](../reference-guides/pipelines/configure-persistent-data.md).

-# Roles-based Access Control for Pipelines
+## Roles-based Access Control for Pipelines

 If you can access a project, you can enable repositories to start building pipelines.

@@ -62,7 +62,7 @@ Only [administrators](../how-to-guides/advanced-user-guides/authentication-permi

 Project members can only configure repositories and pipelines.

-# Setting up Pipelines
+## Setting up Pipelines

 To set up pipelines, you will need to do the following:

@@ -202,7 +202,7 @@ Now that repositories are added to your project, you can start configuring the p
 **Results:** Your pipeline is now configured and ready to be run.


-# Pipeline Configuration Reference
+## Pipeline Configuration Reference

 Refer to [this page](../reference-guides/pipelines/pipeline-configuration.md) for details on how to configure a pipeline to:

@@ -220,8 +220,7 @@ The configuration reference also covers how to configure:
 - Environment variables
 - Secrets

-
-# Running your Pipelines
+## Running your Pipelines

 Run your pipeline for the first time. From the project view in Rancher, go to **Resources > Pipelines.** Find your pipeline and select the vertical **&#8942; > Run**.

@@ -233,7 +232,7 @@ During this initial run, your pipeline is tested, and the following pipeline com

 This process takes several minutes. When it completes, you can view each pipeline component from the project **Workloads** tab.

-# Triggering a Pipeline
+## Triggering a Pipeline

 When a repository is enabled, a webhook is automatically set in the version control provider. By default, the pipeline is triggered by a **push** event to a repository, but you can modify the event(s) that trigger running the pipeline.

@@ -6,7 +6,7 @@ In a lot of enterprise environments, servers or VMs running on premise do not ha

 Alternatively, it is also possible to set up Rancher completely air-gapped without any Internet access. This process is described in detail in the [Rancher docs](air-gapped-helm-cli-install.md).

-# Installation Outline
+## Installation Outline

 1. [Set up infrastructure](../getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/set-up-infrastructure.md)
 2. [Set up a Kubernetes cluster](../getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md)
@@ -18,15 +18,15 @@ The Rancher backup operator can be used to migrate Rancher from the single Docke

 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.

-# Requirements for OS, Docker, Hardware, and Networking
+## Requirements for OS, Docker, Hardware, and Networking

 Make sure that your node fulfills the general [installation requirements.](installation-requirements.md)

-# 1. Provision Linux Host
+## 1. Provision Linux Host

 Provision a single Linux host according to our [Requirements](installation-requirements.md) to launch your Rancher server.

-# 2. Choose an SSL Option and Install Rancher
+## 2. Choose an SSL Option and Install Rancher

 For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.

@@ -9,7 +9,7 @@ To use this option you'll need access to servers you intend to use in your Kuber

 This section describes how to set up a custom cluster.

-# Creating a Cluster with Custom Nodes
+## Creating a Cluster with Custom Nodes

 >**Want to use Windows hosts as Kubernetes workers?**
 >
@@ -108,7 +108,7 @@ If you share resources between clusters, you can change the tag to:
 Key=kubernetes.io/cluster/CLUSTERID, Value=shared
 ```

-# Optional Next Steps
+## Optional Next Steps

 After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:

@@ -8,8 +8,7 @@ One benefit of installing Kubernetes on node pools hosted by an infrastructure p

 The available cloud providers to create a node template are decided based on active [node drivers](use-new-nodes-in-an-infra-provider.md#node-drivers).

-
-# Node Templates
+## Node Templates

 A node template is the saved configuration for the parameters to use when provisioning nodes in a specific cloud provider. These nodes can be launched from the UI. Rancher uses [Docker Machine](https://docs.docker.com/machine/) to provision these nodes. The available cloud providers to create node templates are based on the active node drivers in Rancher.

@@ -38,7 +37,7 @@ To access all node templates, an administrator will need to do the following:

 **Result:** All node templates are listed and grouped by owner. The templates can be edited or cloned by clicking the **&#8942;.**

-# Node Pools
+## Node Pools

 Using Rancher, you can create pools of nodes based on a [node template](#node-templates).

@@ -102,7 +101,7 @@ You can disable node auto-replace from the Rancher UI with the following steps:

 **Result:** Node auto-replace is disabled for the node pool.

-# Cloud Credentials
+## Cloud Credentials

 Node templates can use cloud credentials to store credentials for launching nodes in your cloud provider, which has some benefits:

@@ -114,6 +113,6 @@ Node templates can use cloud credentials to store credentials for launching node

 After cloud credentials are created, the user can start [managing the cloud credentials that they created](../reference-guides/user-settings/manage-cloud-credentials.md).

-# Node Drivers
+## Node Drivers

 If you don't find the node driver that you want to use, you can see if it is available in Rancher's built-in [node drivers and activate it](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#activating-deactivating-node-drivers), or you can [add your own custom node driver](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#adding-custom-node-drivers).
@@ -20,8 +20,7 @@ For the full list of requirements, see [this section.](#requirements-for-windows

 For a summary of Kubernetes features supported in Windows, see the Kubernetes documentation on [supported functionality and limitations for using Kubernetes with Windows](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#supported-functionality-and-limitations) or the [guide for scheduling Windows containers in Kubernetes](https://kubernetes.io/docs/setup/production-environment/windows/user-guide-windows-containers/).

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

 The general node requirements for networking, operating systems, and Docker are the same as the node requirements for a [Rancher installation](installation-requirements.md).

@@ -137,7 +136,7 @@ If you are using the GCE (Google Compute Engine) cloud provider, you must do the
 - Enable the GCE cloud provider in the `cluster.yml` by following [these steps.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md)
 - When provisioning the cluster in Rancher, choose **Custom cloud provider** as the cloud provider in the Rancher UI.

-# Tutorial: How to Create a Cluster with Windows Support
+## Tutorial: How to Create a Cluster with Windows Support

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

@@ -145,8 +144,7 @@ When you provision a cluster with Rancher on existing nodes, you will add nodes

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

-
-# 1. Provision Hosts
+## 1. Provision Hosts

 To begin provisioning a cluster on existing nodes with Windows support, prepare your hosts.

@@ -170,7 +168,7 @@ You will provision three nodes:

 If your nodes are hosted by a **Cloud Provider** and you want automation support such as loadbalancers or persistent storage devices, your nodes have additional configuration requirements. For details, see [Selecting Cloud Providers.](./set-up-cloud-providers.md)

-# 2. Create the Cluster on Existing Nodes
+## 2. Create the Cluster on Existing Nodes

 The instructions for creating a Windows cluster on existing nodes are very similar to the general [instructions for creating a custom cluster](use-existing-nodes.md) with some Windows-specific requirements.

@@ -185,7 +183,7 @@ The instructions for creating a Windows cluster on existing nodes are very simil

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

-# 3. Add Nodes to the Cluster
+## 3. Add Nodes to the Cluster

 This section describes how to register your Linux and Worker nodes to your cluster. You will run a command on each node, which will install the Rancher agent and allow Rancher to manage each node.

@@ -263,6 +261,6 @@ After creating your cluster, you can access it through the Rancher UI. As a best
 - **Access your cluster with the kubectl CLI:** Follow [these steps](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
 - **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through the Rancher server. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.

-# Configuration for Storage Classes in Azure
+## Configuration for Storage Classes in Azure

 If you are using Azure VMs for your nodes, you can use [Azure files](https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv) as a StorageClass for the cluster. For details, refer to [this section.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/azure-storageclass-configuration.md)
@@ -4,11 +4,11 @@ title: Setting up the vSphere Cloud Provider

 In this section, you'll learn how to set up a vSphere cloud provider for a Rancher managed RKE Kubernetes cluster in vSphere.

-# In-tree Cloud Provider
+## In-tree Cloud Provider

 To use the in-tree vSphere cloud provider, you will need to use an RKE configuration option. For details, refer to [this page.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/vsphere/configure-in-tree-vsphere.md)

-# Out-of-tree Cloud Provider
+## Out-of-tree Cloud Provider

 _Available as of v2.5+_

@@ -15,7 +15,7 @@ A vSphere cluster may consist of multiple groups of VMs with distinct properties
 - [Provisioning Storage](#provisioning-storage)
 - [Enabling the vSphere Cloud Provider](#enabling-the-vsphere-cloud-provider)

-# vSphere Enhancements in Rancher v2.3
+## vSphere Enhancements in Rancher v2.3

 The vSphere node templates have been updated, allowing you to bring cloud operations on-premises with the following enhancements:

@@ -238,7 +238,7 @@ spec:
  encryptionConfigSecretName: test-encryptionconfig
 ```

-# Example Credential Secret for Storing Backups in S3
+## Example Credential Secret for Storing Backups in S3

 ```yaml
 apiVersion: v1
@@ -251,7 +251,7 @@ data:
  secretKey: <Enter your base64-encoded secret key>
 ```

-# Example EncryptionConfiguration
+## Example EncryptionConfiguration

 ```yaml
 apiVersion: apiserver.config.k8s.io/v1
@@ -13,7 +13,7 @@ This guide outlines a reference architecture for provisioning downstream Rancher

 ![Solution Overview](/img/solution_overview.drawio.svg)

-# 1. VM Considerations
+## 1. VM Considerations

 ### Leverage VM Templates to Construct the Environment

@@ -31,7 +31,7 @@ Doing so will ensure node VM's are spread across multiple datastores - preventin

 It’s important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double-checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node.

-# 2. Network Considerations
+## 2. Network Considerations

 ### Leverage Low Latency, High Bandwidth Connectivity Between ETCD Nodes

@@ -41,13 +41,13 @@ Deploy etcd members within a single data center where possible to avoid latency

 Each node used should have a static IP configured. In the case of DHCP, each node should have a DHCP reservation to make sure the node gets the same IP allocated.

-# 3. Storage Considerations
+## 3. Storage Considerations

 ### Leverage SSD Drives for ETCD Nodes

 ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible.

-# 4. Backups and Disaster Recovery
+## 4. Backups and Disaster Recovery

 ### Perform Regular Downstream Cluster Backups

@@ -2,7 +2,7 @@
 title: kubectl Utility
 ---

-# kubectl
+## kubectl

 Interact with Rancher using kubectl.

@@ -18,15 +18,15 @@ Run `kubectl cluster-info` or `kubectl get pods` successfully.

 _Requirements_

-If admins have [enforced TTL on kubeconfig tokens](../../reference-guides/about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens), the kubeconfig file requires the [Rancher CLI](../../pages-for-subheaders/cli-with-rancher.md) to be present in your PATH when you run `kubectl`. Otherwise, you’ll see an error like: 
+If admins have [enforced TTL on kubeconfig tokens](../../reference-guides/about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens), the kubeconfig file requires the [Rancher CLI](../../pages-for-subheaders/cli-with-rancher.md) to be present in your PATH when you run `kubectl`. Otherwise, you’ll see an error like:
 `Unable to connect to the server: getting credentials: exec: exec: "rancher": executable file not found in $PATH`.

-This feature enables kubectl to authenticate with the Rancher server and get a new kubeconfig token when required. The following auth providers are currently supported: 
+This feature enables kubectl to authenticate with the Rancher server and get a new kubeconfig token when required. The following auth providers are currently supported:

 1. Local
 2. Active Directory (LDAP only)
 3. FreeIPA
-4. OpenLDAP 
-5. SAML providers: Ping, Okta, ADFS, Keycloak, Shibboleth 
+4. OpenLDAP
+5. SAML providers: Ping, Okta, ADFS, Keycloak, Shibboleth

 When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server. The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../../reference-guides/about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens-period), or [gets deleted from the Rancher server](../../reference-guides/about-the-api/api-tokens.md#deleting-tokens). Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
@@ -19,7 +19,7 @@ Your cloud credential has these fields:
 | Port | Optional: configure configure the port of the vCenter or ESXi server. |
 | Username and password | Enter your vSphere login username and password. |

-# Scheduling
+## Scheduling

 Choose what hypervisor the virtual machine will be scheduled to.

@@ -16,7 +16,7 @@ In the RancherD installation instructions, we recommend running three server nod
 - [RancherD Server CLI Options](#rancherd-server-cli-options)
 - [RancherD Agent CLI Options](#rancherd-agent-cli-options)

-# Certificates for the Rancher Server
+## Certificates for the Rancher Server

 Rancherd does not use cert-manager to provision certs. Instead RancherD allows you to bring your own self-signed or trusted certs by storing the .pem files in `/etc/rancher/ssl/`. When doing this you should also set the `publicCA` parameter to `true` in your HelmChartConfig. For more information on the HelmChartConfig, refer to the section about [customizing the RancherD Helm chart.](#customizing-the-rancherd-helm-chart)

@@ -28,7 +28,7 @@ CA Certificate(self-signed): `/etc/rancher/ssl/cacerts.pem`

 Additional CA Certificate: `/etc/ssl/certs/ca-additional.pem`

-# Node Taints
+## Node Taints

 By default, server nodes will be schedulable and thus your workloads can get launched on them. If you wish to have a dedicated control plane where no user workloads will run, you can use taints. The node-taint parameter will allow you to configure nodes with taints. Here is an example of adding a node taint to the `config.yaml`:

@@ -36,7 +36,8 @@ By default, server nodes will be schedulable and thus your workloads can get lau
 node-taint:
  - "CriticalAddonsOnly=true:NoExecute"
 ```
-# Customizing the RancherD Helm Chart
+
+## Customizing the RancherD Helm Chart

 Rancher is launched as a [Helm](https://helm.sh/) chart using the cluster’s [Helm integration.](https://docs.rke2.io/helm/) This means that you can easily customize the application through a manifest file describing your custom parameters.

@@ -83,7 +84,7 @@ Put this manifest on your host in `/var/lib/rancher/rke2/server/manifests` befor
 | `useBundledSystemChart`        | false                                                 | ***bool*** - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations.                     |
 | `publicCA`                     | false                                                 | ***bool*** - Set to true if your cert is signed by a public CA                                                                                                                                               |

-# RancherD Server CLI Options
+## RancherD Server CLI Options

 The command to run the Rancher management server is:

@@ -227,9 +228,7 @@ It can be run with the following options:
 |  `--cluster-reset`  | Forget all peers and become sole member of a new cluster |
 | `--secrets-encryption`  | Enable Secret encryption at rest |

-
-
-# RancherD Agent CLI Options
+## RancherD Agent CLI Options

 The following command is used to run the RancherD agent:

@@ -8,7 +8,7 @@ In [clusters launched by RKE](../../../pages-for-subheaders/launch-kubernetes-wi
 - [Editing Clusters with YAML](#editing-clusters-with-yaml)
 - [Updating ingress-nginx](#updating-ingress-nginx)

-# Configuration Options in the Rancher UI
+## Configuration Options in the Rancher UI

 To edit your cluster, open the **Global** view, make sure the **Clusters** tab is selected, and then select **&#8942; > Edit** for the cluster that you want to edit.

@@ -58,7 +58,7 @@ If you enable **Pod Security Policy Support**, use this drop-down to choose the

 If you're using a cloud provider to host cluster nodes launched by RKE, enable [this option](../../../pages-for-subheaders/set-up-cloud-providers.md) so that you can use the cloud provider's native features. If you want to store persistent data for your cloud-hosted cluster, this option is required.

-# Editing Clusters with YAML
+## Editing Clusters with YAML

 Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the options available in an RKE installation, except for system_images configuration, by specifying them in YAML.

@@ -71,7 +71,7 @@ For an example of RKE config file syntax, see the [RKE documentation](https://ra

 For the complete reference of configurable options for RKE Kubernetes clusters in YAML, see the [RKE documentation.](https://rancher.com/docs/rke/latest/en/config-options/)

-# Updating ingress-nginx
+## Updating ingress-nginx

 Clusters that were created before Kubernetes 1.16 will have an `ingress-nginx` `updateStrategy` of `OnDelete`. Clusters that were created with Kubernetes 1.16 or newer will have `RollingUpdate`.

@@ -21,7 +21,7 @@ For further details on configuring OpenLDAP, refer to the [official documentatio
 3. Once the user has been found, he is authenticated with another LDAP bind request using the user's DN and provided password.
 4. Once authentication succeeded, Rancher then resolves the group memberships both from the membership attribute in the user's object and by performing a group search based on the configured user mapping attribute.

-# OpenLDAP Server Configuration
+## OpenLDAP Server Configuration

 You will need to enter the address, port, and protocol to connect to your OpenLDAP server. `389` is the standard port for insecure traffic, `636` for TLS traffic.

@@ -44,7 +44,7 @@ If you are in doubt about the correct values to enter in the user/group Search B
 | User Search Base | Enter the Distinguished Name of the node in your directory tree from which to start searching for user objects. All users must be descendents of this base DN. For example: "ou=people,dc=acme,dc=com".|
 | Group Search Base | If your groups live under a different node than the one configured under `User Search Base` you will need to provide the Distinguished Name here. Otherwise leave this field empty. For example: "ou=groups,dc=acme,dc=com".|

-# User/Group Schema Configuration
+## User/Group Schema Configuration

 If your OpenLDAP directory deviates from the standard OpenLDAP schema, you must complete the **Customize Schema** section to match it.

@@ -145,7 +145,7 @@ kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-

 For details on installing Rancher with a private registry, see [Air Gapped Helm CLI Install](../../pages-for-subheaders/air-gapped-helm-cli-install.md).

-# External TLS Termination
+## 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.

@@ -4,14 +4,14 @@ title: TLS Settings

 Changing the default TLS settings depends on the chosen installation method.

-# Running Rancher in a highly available Kubernetes cluster
+## Running Rancher in a highly available Kubernetes cluster

 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:

 * nginx-ingress-controller (default for RKE1 and RKE2): [Default TLS Version and Ciphers](https://kubernetes.github.io/ingress-nginx/user-guide/tls/#default-tls-version-and-ciphers).
 * traefik (default for K3s): [TLS Options](https://doc.traefik.io/traefik/https/tls/#tls-options).

-# Running Rancher in a single Docker container
+## 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:

@@ -4,8 +4,7 @@ title: Tools for Logging, Monitoring, and Visibility

 Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently.

-
-# Logging
+## Logging

 Logging is helpful because it allows you to:

@@ -18,7 +17,8 @@ Logging is helpful because it allows you to:
 Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd.

 For more information, refer to the logging documentation [here.](../pages-for-subheaders/logging.md)
-# Monitoring and Alerts
+
+## Monitoring and Alerts

 Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution.

@@ -30,18 +30,19 @@ Alerts are rules that trigger those notifications. Before you can receive alerts

 For more information, refer to the monitoring documentation [here.](../pages-for-subheaders/monitoring-and-alerting.md)

-# Istio
+## Istio

 [Istio](https://istio.io/) is an open-source tool that makes it easier for DevOps teams to observe, control, troubleshoot, and secure the traffic within a complex network of microservices.

 Rancher's integration with Istio was improved in Rancher v2.5.

 For more information, refer to the Istio documentation [here.](../pages-for-subheaders/istio.md)
-# OPA Gatekeeper
+
+## OPA Gatekeeper

 [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is an open-source project that provides integration between OPA and Kubernetes to provide policy control via admission controller webhooks. For details on how to enable Gatekeeper in Rancher, refer to the [OPA Gatekeeper section.](../explanations/integrations-in-rancher/opa-gatekeeper.md)

-# CIS Scans
+## CIS Scans

 Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark.

@@ -4,7 +4,7 @@ title: Architecture Recommendations

 Kubernetes cluster. If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters)

-# Separation of Rancher and User Clusters
+## Separation of Rancher and User Clusters

 A user cluster is a downstream Kubernetes cluster that runs your apps and services.

@@ -14,7 +14,7 @@ If Rancher is intended to manage downstream Kubernetes clusters, the Kubernetes

 ![Separation of Rancher Server from User Clusters](/img/rancher-architecture-separation-of-rancher-server.svg)

-# Why HA is Better for Rancher in Production
+## Why HA is Better for Rancher in Production

 We recommend installing the Rancher server on a high-availability Kubernetes cluster, primarily because it protects the Rancher server data. In a high-availability installation, a load balancer serves as the single point of contact for clients, distributing network traffic across multiple servers in the cluster and helping to prevent any one server from becoming a point of failure.

@@ -36,7 +36,7 @@ In an RKE installation, the cluster data is replicated on each of three etcd nod

 ![Architecture of an RKE Kubernetes cluster running the Rancher management server](/img/rke-server-storage.svg)

-# Recommended Load Balancer Configuration for Kubernetes Installations
+## Recommended Load Balancer Configuration for Kubernetes Installations

 We recommend the following configurations for the load balancer and Ingress controllers:

@@ -49,13 +49,13 @@ We recommend the following configurations for the load balancer and Ingress cont

 ![Rancher HA](/img/ha/rancher2ha.svg)

-# Environment for Kubernetes Installations
+## Environment for Kubernetes Installations

 It is strongly recommended to install Rancher on a Kubernetes cluster on hosted infrastructure such as Amazon's EC2 or Google Compute Engine.

 For the best performance and greater security, we recommend a dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) for running your workloads.

-# Recommended Node Roles for Kubernetes Installations
+## Recommended Node Roles for Kubernetes Installations

 The below recommendations apply when Rancher is installed on a K3s Kubernetes cluster or an RKE Kubernetes cluster.

@@ -97,7 +97,7 @@ Because no additional workloads will be deployed on the Rancher server cluster,

 For more best practices for downstream clusters, refer to the [production checklist](../../pages-for-subheaders/checklist-for-production-ready-clusters.md) or our [best practices guide.](../../pages-for-subheaders/best-practices.md)

-# Architecture for an Authorized Cluster Endpoint
+## Architecture for an Authorized Cluster Endpoint

 If you are using an [authorized cluster endpoint,](../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) we recommend creating an FQDN pointing to a load balancer which balances traffic across your nodes with the `controlplane` role.

@@ -17,7 +17,7 @@ The following descriptions correspond to the numbers in the diagram above:
 3. [Node Agents](#3-node-agents)
 4. [Authorized Cluster Endpoint](#4-authorized-cluster-endpoint)

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

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

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

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

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

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

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

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

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

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

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

@@ -71,11 +71,11 @@ Like the authorized cluster endpoint, the `kube-api-auth` authentication service

 > **Example scenario:** Let's say that the Rancher server is located in the United States, and User Cluster 1 is located in Australia. A user, Alice, also lives in Australia. Alice can manipulate resources in User Cluster 1 by using the Rancher UI, but her requests will have to be sent from Australia to the Rancher server in the United States, then be proxied back to Australia, where the downstream user cluster is. The geographical distance may cause significant latency, which Alice can reduce by using the authorized cluster endpoint.

-With this endpoint enabled for the downstream cluster, Rancher generates an extra Kubernetes context in the kubeconfig file in order to connect directly to the cluster. This file has the credentials for `kubectl` and `helm`. 
+With this endpoint enabled for the downstream cluster, Rancher generates an extra Kubernetes context in the kubeconfig file in order to connect directly to the cluster. This file has the credentials for `kubectl` and `helm`.

 You will need to use a context defined in this kubeconfig file to access the cluster if Rancher goes down. Therefore, we recommend exporting the kubeconfig file so that if Rancher goes down, you can still use the credentials in the file to access your cluster. For more information, refer to the section on accessing your cluster with [kubectl and the kubeconfig file.](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md)

-# Important Files
+## Important Files

 The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster:

@@ -87,7 +87,7 @@ The files mentioned below are needed to maintain, troubleshoot and upgrade your

 For more information on connecting to a cluster without the Rancher authentication proxy and other configuration options, refer to the [kubeconfig file](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) documentation.

-# Tools for Provisioning Kubernetes Clusters
+## Tools for Provisioning Kubernetes Clusters

 The tools that Rancher uses to provision downstream user clusters depends on the type of cluster that is being provisioned.

@@ -113,7 +113,7 @@ Rancher provisions this type of cluster using [kontainer-engine.](https://github

 In this type of cluster, Rancher connects to a Kubernetes cluster that has already been set up. Therefore, Rancher does not provision Kubernetes, but only sets up the Rancher agents to communicate with the cluster.

-# Rancher Server Components and Source Code
+## Rancher Server Components and Source Code

 This diagram shows each component that the Rancher server is composed of:

@@ -15,7 +15,7 @@ The following commands are available:
 | [stats](#stats) | Stream system metrics from nodes.
 | [remove](#remove) | Remove Kubernetes resources created by Rancher.

-# Download System Tools
+## Download System Tools

 You can download the latest version of System Tools from the [GitHub releases page](https://github.com/rancher/system-tools/releases/latest). Download the version of `system-tools` for the OS that you are using to interact with the cluster.

@@ -38,7 +38,7 @@ After you download the tools, complete the following actions:
    chmod +x system-tools
    ```

-# Logs
+## Logs

 The logs subcommand will collect log files of core Kubernetes cluster components from nodes in [Rancher-launched Kubernetes clusters](../pages-for-subheaders/launch-kubernetes-with-rancher.md) or nodes on an [RKE Kubernetes cluster that Rancher is installed on.](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md). See [Troubleshooting](../troubleshooting.md) for a list of core Kubernetes cluster components.

@@ -58,7 +58,7 @@ The following are the options for the logs command:
 | `--output <FILENAME>, -o cluster-logs.tar`             | Name of the created tarball containing the logs. If no output filename is defined, the options defaults to `cluster-logs.tar`.
 | `--node <NODENAME>, -n node1`                         | Specify the nodes to collect the logs from. If no node is specified, logs from all nodes in the cluster will be collected.

-# Stats
+## Stats

 The stats subcommand will display system metrics from nodes in [Rancher-launched Kubernetes clusters](../pages-for-subheaders/launch-kubernetes-with-rancher.md) or nodes in an [RKE Kubernetes cluster that Rancher is installed on.](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md).

@@ -78,7 +78,7 @@ The following are the options for the stats command:
 | `--node <NODENAME>, -n node1`                          | Specify the nodes to display the system metrics from. If no node is specified, logs from all nodes in the cluster will be displayed.
 | `--stats-command value, -s value`                      | The command to run to display the system metrics. If no command is defined, the options defaults to `/usr/bin/sar -u -r -F 1 1`.

-# Remove
+## Remove

 >**Warning:** This command will remove data from your etcd nodes. Make sure you have created a [backup of etcd](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) before executing the command.

@@ -4,7 +4,7 @@ title: Troubleshooting Controlplane Nodes

 This section applies to nodes with the `controlplane` role.

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

 There are three specific containers launched on nodes with the `controlplane` role:

@@ -26,7 +26,7 @@ f3d287ca4549        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."
 bdf3898b8063        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."   3 hours ago         Up 3 hours                              kube-controller-manager
 ```

-# Controlplane Container Logging
+## Controlplane Container Logging

 > **Note:** If you added multiple nodes with the `controlplane` role, both `kube-controller-manager` and `kube-scheduler` use a leader election process to determine the leader. Only the current leader will log the performed actions. See [Kubernetes leader election](../other-troubleshooting-tips/kubernetes-resources.md#kubernetes-leader-election) how to retrieve the current leader.

@@ -4,7 +4,7 @@ title: Troubleshooting nginx-proxy

 The `nginx-proxy` container is deployed on every node that does not have the `controlplane` role. It provides access to all the nodes with the `controlplane` role by dynamically generating the NGINX configuration based on available nodes with the `controlplane` role.

-# Check if the Container is Running
+## Check if the Container is Running

 The container is called `nginx-proxy` and should have status `Up`. The duration shown after `Up` is the time the container has been running.

@@ -20,7 +20,7 @@ CONTAINER ID        IMAGE                       COMMAND                  CREATED
 c3e933687c0e        rancher/rke-tools:v0.1.15   "nginx-proxy CP_HO..."   3 hours ago         Up 3 hours                              nginx-proxy
 ```

-# Check Generated NGINX Configuration
+## Check Generated NGINX Configuration

 The generated configuration should include the IP addresses of the nodes with the `controlplane` role. The configuration can be checked using the following command:

@@ -59,7 +59,7 @@ stream {
 }
 ```

-# nginx-proxy Container Logging
+## nginx-proxy Container Logging

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

@@ -4,7 +4,7 @@ title: Troubleshooting Worker Nodes and Generic Components

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

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

 There are two specific containers launched on nodes with the `worker` role:

@@ -24,7 +24,7 @@ CONTAINER ID        IMAGE                                COMMAND
 a30717ecfb55        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."   3 hours ago         Up 3 hours                              kubelet
 ```

-# Container Logging
+## Container Logging

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

@@ -6,7 +6,6 @@ The commands/steps listed on this page can be used to check the most important K

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI.

-
 ## Nodes

 ### Get nodes
@@ -128,7 +127,7 @@ Retrieve generated configuration in each pod:
 kubectl -n ingress-nginx get pods -l app=ingress-nginx --no-headers -o custom-columns=.NAME:.metadata.name | while read pod; do kubectl -n ingress-nginx exec $pod -- cat /etc/nginx/nginx.conf; done
 ```

-# Rancher agents
+## Rancher agents

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