Fix tables of contents, headers and formatting

2026-09-24 20:18:18 +00:00 · 2022-09-10 00:26:51 -07:00
parent 11ebb7d341
commit 5fdfa52386
336 changed files with 1249 additions and 3710 deletions
@@ -15,7 +15,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.

@@ -39,13 +39,13 @@ To see all libraries/projects used in Rancher, see the [`go.mod` file](https://g
 ![Rancher diagram](/img/ranchercomponentsdiagram-2.6.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.

@@ -128,7 +128,7 @@ Please remove any sensitive data as it will be publicly viewable.
      - `/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.

@@ -14,11 +14,6 @@ When a cluster scan is run, you need to select a Profile which points to a speci

 Follow all the steps below to add a custom Benchmark Version and run a scan using it.

-1. [Prepare the Custom Benchmark Version ConfigMap](#1-prepare-the-custom-benchmark-version-configmap)
-2. [Add a Custom Benchmark Version to a Cluster](#2-add-a-custom-benchmark-version-to-a-cluster)
-3. [Create a New Profile for the Custom Benchmark Version](#3-create-a-new-profile-for-the-custom-benchmark-version)
-4. [Run a Scan Using the Custom Benchmark Version](#4-run-a-scan-using-the-custom-benchmark-version)
-
 ### 1. Prepare the Custom Benchmark Version ConfigMap

 To create a custom benchmark version, first you need to create a ConfigMap containing the benchmark version's config files and upload it to your Kubernetes cluster where you want to run the scan.
@@ -19,7 +19,7 @@ Note: If you were using the `cis-edit` role added in Rancher v2.5 setup, it has
 Rancher v2.5.2 because it essentially is same as `cis-admin`. If you happen to create any clusterrolebindings
 for `cis-edit`, please update them to use `cis-admin` ClusterRole instead.

-# Cluster-Admin Access
+## Cluster-Admin Access

 Rancher CIS Scans is a cluster-admin only feature by default.
 This means only the Rancher global admins, and the cluster’s cluster-owner can:
@@ -32,7 +32,7 @@ This means only the Rancher global admins, and the cluster’s cluster-owner can
 - View and Download the ClusterScanReport created after the ClusterScan is complete


-# Summary of Default Permissions for Kubernetes Default Roles
+## Summary of Default Permissions for Kubernetes Default Roles

 The rancher-cis-benchmark creates three `ClusterRoles` and adds the CIS Benchmark CRD access to the following default K8s `ClusterRoles`:

@@ -7,7 +7,7 @@ This section lists the tests that are skipped in the permissive test profile for

 > All the tests that are skipped and not applicable on this page will be counted as Not Applicable in the v2.5 generated report. The skipped test count will only mention the user-defined skipped tests. This allows user-skipped tests to be distinguished from the tests that are skipped by default in the RKE permissive test profile.

-# CIS Benchmark v1.5
+## CIS Benchmark v1.5

 ### CIS Benchmark v1.5 Skipped Tests

@@ -25,7 +25,7 @@ When adding Fleet agent environment variables for the proxy, replace <PROXY_IP>
 | `HTTPS_PROXY` | http://<PROXY_IP>:8888
 | `NO_PROXY`     | 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local |

-# Setting Environment Variables in the Rancher UI
+## Setting Environment Variables in the Rancher UI

 To add the environment variable to an existing cluster,

@@ -38,7 +38,7 @@ To add the environment variable to an existing cluster,

 **Result:** The Fleet agent works behind a proxy.

-# Setting Environment Variables on Private Nodes
+## Setting Environment Variables on Private Nodes

 For private nodes and private clusters, the proxy environment variables need to be set on the nodes themselves, as well as configured from the Rancher UI.

@@ -9,10 +9,6 @@ This ensures you can view traffic, metrics and graphs for resources deployed in

 If you would like to limit Prometheus to specific namespaces, set `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`. Once you do this, you will need to add additional configuration to continue to monitor your resources.

- [Limiting Monitoring to Specific Namespaces by Setting ignoreNamespaceSelectors to True](#limiting-monitoring-to-specific-namespaces-by-setting-ignorenamespaceselectors-to-true)
- [Enabling Prometheus to Detect Resources in Other Namespaces](#enabling-prometheus-to-detect-resources-in-other-namespaces)
- [Monitoring Specific Namespaces: Create a Service Monitor or Pod Monitor](#monitoring-specific-namespaces-create-a-service-monitor-or-pod-monitor)
- [Monitoring Across Namespaces: Set ignoreNamespaceSelectors to False](#monitoring-across-namespaces-set-ignorenamespaceselectors-to-false)

 ### Limiting Monitoring to Specific Namespaces by Setting ignoreNamespaceSelectors to True

@@ -27,7 +27,7 @@ In Kubernetes, the resource request indicates that the workload will not deploye
 | proxy          |  10m         | 10mi            | 2000m        | 1024mi   |
 | **Totals:** | **710m** | **2314Mi** | **6000m** | **3072Mi** |

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

@@ -5,7 +5,7 @@ weight: 4

 This section describes how to uninstall Istio in a cluster or disable a namespace, or workload.

-# Uninstall Istio in a Cluster
+## Uninstall Istio in a Cluster

 To uninstall Istio,

@@ -29,7 +29,7 @@ You can no longer disable and re-enable your Istio installation. If you would li

 This could mean a few things. You either selected all the apps in the `istio-system` namespace and deleted them at the same time, or you deleted `rancher-istio` chart dependencies prior to deleting the `rancher-istio` chart. Since the uninstall did not complete properly, you will have resources remaining in the `istio-system` namespace that you will need to manually clean up. Another option to avoid manual clean up is to install `rancher-istio` again, then uninstall it in the correct order.

-# Disable Istio in a Namespace
+## Disable Istio in a Namespace

 1. Click **☰ > Cluster Management**.
 1. Go to the cluster that you created and click **Explore**.
@@ -38,6 +38,6 @@ This could mean a few things. You either selected all the apps in the `istio-sys

 **Result:** When workloads are deployed in this namespace, they will not have the Istio sidecar.

-# Remove the Istio Sidecar from a Workload
+## Remove the Istio Sidecar from a Workload

 Disable Istio in the namespace, then redeploy the workloads with in it. They will be deployed without the Istio sidecar.
@@ -5,18 +5,8 @@ weight: 1

 For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/flow/)

- [Configuration](#configuration)
- [YAML Example](#yaml-example)

-# Configuration
-
- [Flows](#flows)
-  - [Matches](#matches)
-  - [Filters](#filters)
-  - [Outputs](#outputs)
- [ClusterFlows](#clusterflows)
-
-# Flows
+## Flows

 A `Flow` defines which logs to collect and filter and which output to send the logs to.

@@ -50,7 +40,7 @@ This `Output` will receive logs from the `Flow`. Because the `Flow` is a namespa

 `Outputs` can be referenced when filling out the `Flow` or `ClusterFlow` forms in the Rancher UI.

-# ClusterFlows
+## ClusterFlows

 Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way that they are configured for `Flows`. The key difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces.

@@ -58,7 +48,7 @@ Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way

 After `ClusterFlow` selects logs from all namespaces in the cluster, logs from the cluster will be collected and logged to the selected `ClusterOutput`.

-# YAML Example
+## YAML Example

 The following example `Flow` transforms the log messages from the default namespace and sends them to an S3 `Output`:

@@ -5,19 +5,7 @@ weight: 2

 For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/)

- [Configuration](#configuration)
- [YAML Examples](#yaml-examples)
-  - [Cluster Output to ElasticSearch](#cluster-output-to-elasticsearch)
-  - [Output to Splunk](#output-to-splunk)
-  - [Output to Syslog](#output-to-syslog)
-  - [Unsupported Outputs](#unsupported-outputs)
-
-# Configuration
-
- [Outputs](#outputs)
- [ClusterOutputs](#clusteroutputs)
-
-# Outputs
+## Outputs

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

@@ -53,7 +41,7 @@ The Rancher UI provides forms for configuring the `Output` type, target, and acc

 For example configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/)

-# ClusterOutputs
+## ClusterOutputs

 `ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator.

@@ -61,7 +49,7 @@ For example configuration for each logging plugin supported by the logging opera

 For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)

-# YAML Examples
+## YAML Examples

 Once logging is installed, you can use these examples to help craft your own logging pipeline.

@@ -4,12 +4,6 @@ shortTitle: Helm Chart Options
 weight: 4
 ---

- [Enable/Disable Windows Node Logging](#enable-disable-windows-node-logging)
- [Working with a Custom Docker Root Directory](#working-with-a-custom-docker-root-directory)
- [Adding NodeSelector Settings and Tolerations for Custom Taints](#adding-nodeselector-settings-and-tolerations-for-custom-taints)
- [Enabling the Logging Application to Work with SELinux](#enabling-the-logging-application-to-work-with-selinux)
- [Additional Logging Sources](#additional-logging-sources)
- [Systemd Configuration](#systemd-configuration)

 ### Enable/Disable Windows Node Logging

@@ -6,20 +6,7 @@ Starting in v2.5, the logging feature available within Rancher has been complete

 Among the many features and changes in the new logging functionality is the removal of project-specific logging configurations. Instead, one now configures logging at the namespace level. Cluster-level logging remains available, but configuration options differ. 

- [Installation](#installation)
-  - [Terminology](#terminology)
- [Cluster Logging](#cluster-logging)
- [Project Logging](#project-logging)
- [Output Configuration](#output-configuration)
-  - [Elasticsearch](#elasticsearch)
-  - [Splunk](#splunk)
-  - [Kafka](#kafka)
-  - [Fluentd](#fluentd)
-  - [Syslog](#syslog)
- [Custom Log Fields](#custom-log-fields)
- [System Logging](#system-logging)
-
-# Installation
+## Installation

 To install logging in Rancher v2.5+, refer to the [installation instructions](../../../pages-for-subheaders/logging.md#enabling-logging).

@@ -51,7 +38,7 @@ There are four key concepts to understand for v2.5+ logging:

    `ClusterFlows` serve the same function as `Flows`, but at the cluster level. They are used to configure log collection for an entire cluster, instead of on a per-namespace level. `ClusterFlows` are also where mutations and filters are defined, same as `Flows` (in functionality).

-# Cluster Logging
+## Cluster Logging

 To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs. 

@@ -71,7 +58,7 @@ In legacy logging, in order to collect logs from across the entire cluster, one

 This will result in logs from all sources in the cluster (all pods, and all system components) being collected and sent to the `Output` or `Outputs` you defined in the `ClusterFlow`. 

-# Project Logging
+## Project Logging

 Logging in v2.5+ is not project-aware. This means that in order to collect logs from pods running in project namespaces, you will need to define `Flows` for those namespaces. 

@@ -91,7 +78,7 @@ To collect logs from a project, repeat the above steps for every namespace withi

 :::

-# Output Configuration
+## Output Configuration
 In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+. 


@@ -110,7 +97,7 @@ In legacy logging, there are five logging destinations to choose from: Elasticse

 In legacy logging, indices were automatically created according to the format in the "Index Patterns" section. In v2.5 logging, default behavior has been changed to logging to a single index. You can still configure index pattern functionality on the `Output` object by editing as YAML and inputting the following values:

-```
+```yaml
 ...
 spec:
  elasticsearch:
@@ -179,11 +166,11 @@ _(1) These values are to be specified as paths to files. Those files must be mou

 As of v2.5.2, syslog is not currently supported for `Outputs` using v2.5+ logging. 

-# Custom Log Fields
+## Custom Log Fields

 In order to add custom log fields, you will need to add the following YAML to your `Flow` configuration:

-```
+```yaml
 ...
 spec:
  filters:
@@ -194,7 +181,7 @@ spec:

 (replace `foo: "bar"` with custom log fields you wish to add)

-# System Logging
+## System Logging

 In legacy logging, collecting logs from system components was accomplished by checking a box labeled "Include System Log" when setting up cluster logging. In v2.5+ logging, system logs are gathered in one of two ways:

@@ -20,6 +20,7 @@ With Longhorn, you can:
 - Upgrade Longhorn without disrupting persistent volumes

 <figcaption>Longhorn Dashboard</figcaption>
+
 ![Longhorn Dashboard](/img/longhorn-screenshot.png)

 ### Installing Longhorn with Rancher
@@ -3,11 +3,8 @@ title: Built-in Dashboards
 weight: 3
 ---

- [Grafana UI](#grafana-ui)
- [Alertmanager UI](#alertmanager-ui)
- [Prometheus UI](#prometheus-ui)

-# Grafana UI
+## Grafana UI

 [Grafana](https://grafana.com/grafana/) allows you to query, visualize, alert on and understand your metrics no matter where they are stored. Create, explore, and share dashboards with your team and foster a data driven culture.

@@ -26,7 +23,7 @@ To create a persistent Grafana dashboard, see [this page.](../../../how-to-guide
 For information about role-based access control for Grafana, see [this section.](rbac-for-monitoring.md#role-based-access-control-for-grafana)


-# Alertmanager UI
+## Alertmanager UI

 When `rancher-monitoring` is installed, the Prometheus Alertmanager UI is deployed, allowing you to view your alerts and the current Alertmanager configuration.

@@ -66,7 +63,7 @@ For more information on configuring Alertmanager in Rancher, see [this page.](..
 To see alerts that are fired by default, go to the Alertmanager UI and click **Expand all groups**.


-# Prometheus UI
+## Prometheus UI

 By default, the [kube-state-metrics service](https://github.com/kubernetes/kube-state-metrics) provides a wealth of information about CPU and memory utilization to the monitoring application. These metrics cover Kubernetes resources across namespaces. This means that in order to see resource metrics for a service, you don't need to create a new ServiceMonitor for it. Because the data is already in the time series database, you can go to the Prometheus UI and run a PromQL query to get the information. The same query can be used to configure a Grafana dashboard to show a graph of those metrics over time.

@@ -78,6 +75,7 @@ To see the Prometheus UI, install `rancher-monitoring`. Then:
 1. Click **Prometheus Graph**.

 <figcaption>Prometheus Graph UI</figcaption>
+
 ![Prometheus Graph UI](/img/prometheus-graph-ui.png)

 ### Viewing the Prometheus Targets
@@ -3,13 +3,8 @@ title: How Monitoring Works
 weight: 1
 ---

-1. [Architecture Overview](#1-architecture-overview)
-2. [How Prometheus Works](#2-how-prometheus-works)
-3. [How Alertmanager Works](#3-how-alertmanager-works)
-4. [Monitoring V2 Specific Components](#4-monitoring-v2-specific-components)
-5. [Scraping and Exposing Metrics](#5-scraping-and-exposing-metrics)

-# 1. Architecture Overview
+## 1. Architecture Overview

 _**The following sections describe how data flows through the Monitoring V2 application:**_

@@ -67,7 +62,7 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
 <figcaption>How data flows through the monitoring application:</figcaption>


-# 2. How Prometheus Works
+## 2. How Prometheus Works

 ### Storing Time Series Data

@@ -111,7 +106,7 @@ The Rule file adds labels and annotations to alerts before firing them, dependin

 - Annotations denote information that doesn't affect where an alert is routed, for example, a runbook or an error message.

-# 3. How Alertmanager Works
+## 3. How Alertmanager Works

 The Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of the following tasks:

@@ -139,7 +134,7 @@ By editing the forms in the Rancher UI, you can set up a Receiver resource with

 By editing custom YAML in the Alertmanager or Receiver configuration, you can also send alerts to multiple notification systems. For more information, see the section on configuring [Receivers.](../../../reference-guides/monitoring-v2-configuration/receivers.md#configuring-multiple-receivers)

-# 4. Monitoring V2 Specific Components
+## 4. Monitoring V2 Specific Components

 Prometheus Operator introduces a set of [Custom Resource Definitions](https://github.com/prometheus-operator/prometheus-operator#customresourcedefinitions) that allow users to deploy and manage Prometheus and Alertmanager instances by creating and modifying those custom resources on a cluster.

@@ -185,7 +180,7 @@ Since the metrics for Kubernetes components are generally exposed on the host ne

 Refer to [Scraping Metrics with PushProx](#scraping-metrics-with-pushprox) for more.

-# 5. Scraping and Exposing Metrics
+## 5. Scraping and Exposing Metrics

 ### Defining what Metrics are Scraped

@@ -7,70 +7,8 @@ The PromQL expressions in this doc can be used to configure alerts.

 For more information about querying the Prometheus time series database, refer to the official [Prometheus documentation.](https://prometheus.io/docs/prometheus/latest/querying/basics/)

-<!-- TOC -->

- [Cluster Metrics](#cluster-metrics)
-  - [Cluster CPU Utilization](#cluster-cpu-utilization)
-  - [Cluster Load Average](#cluster-load-average)
-  - [Cluster Memory Utilization](#cluster-memory-utilization)
-  - [Cluster Disk Utilization](#cluster-disk-utilization)
-  - [Cluster Disk I/O](#cluster-disk-i-o)
-  - [Cluster Network Packets](#cluster-network-packets)
-  - [Cluster Network I/O](#cluster-network-i-o)
- [Node Metrics](#node-metrics)
-  - [Node CPU Utilization](#node-cpu-utilization)
-  - [Node Load Average](#node-load-average)
-  - [Node Memory Utilization](#node-memory-utilization)
-  - [Node Disk Utilization](#node-disk-utilization)
-  - [Node Disk I/O](#node-disk-i-o)
-  - [Node Network Packets](#node-network-packets)
-  - [Node Network I/O](#node-network-i-o)
- [Etcd Metrics](#etcd-metrics)
-  - [Etcd Has a Leader](#etcd-has-a-leader)
-  - [Number of Times the Leader Changes](#number-of-times-the-leader-changes)
-  - [Number of Failed Proposals](#number-of-failed-proposals)
-  - [GRPC Client Traffic](#grpc-client-traffic)
-  - [Peer Traffic](#peer-traffic)
-  - [DB Size](#db-size)
-  - [Active Streams](#active-streams)
-  - [Raft Proposals](#raft-proposals)
-  - [RPC Rate](#rpc-rate)
-  - [Disk Operations](#disk-operations)
-  - [Disk Sync Duration](#disk-sync-duration)
- [Kubernetes Components Metrics](#kubernetes-components-metrics)
-  - [API Server Request Latency](#api-server-request-latency)
-  - [API Server Request Rate](#api-server-request-rate)
-  - [Scheduling Failed Pods](#scheduling-failed-pods)
-  - [Controller Manager Queue Depth](#controller-manager-queue-depth)
-  - [Scheduler E2E Scheduling Latency](#scheduler-e2e-scheduling-latency)
-  - [Scheduler Preemption Attempts](#scheduler-preemption-attempts)
-  - [Ingress Controller Connections](#ingress-controller-connections)
-  - [Ingress Controller Request Process Time](#ingress-controller-request-process-time)
- [Rancher Logging Metrics](#rancher-logging-metrics)
-  - [Fluentd Buffer Queue Rate](#fluentd-buffer-queue-rate)
-  - [Fluentd Input Rate](#fluentd-input-rate)
-  - [Fluentd Output Errors Rate](#fluentd-output-errors-rate)
-  - [Fluentd Output Rate](#fluentd-output-rate)
- [Workload Metrics](#workload-metrics)
-  - [Workload CPU Utilization](#workload-cpu-utilization)
-  - [Workload Memory Utilization](#workload-memory-utilization)
-  - [Workload Network Packets](#workload-network-packets)
-  - [Workload Network I/O](#workload-network-i-o)
-  - [Workload Disk I/O](#workload-disk-i-o)
- [Pod Metrics](#pod-metrics)
-  - [Pod CPU Utilization](#pod-cpu-utilization)
-  - [Pod Memory Utilization](#pod-memory-utilization)
-  - [Pod Network Packets](#pod-network-packets)
-  - [Pod Network I/O](#pod-network-i-o)
-  - [Pod Disk I/O](#pod-disk-i-o)
- [Container Metrics](#container-metrics)
-  - [Container CPU Utilization](#container-cpu-utilization)
-  - [Container Memory Utilization](#container-memory-utilization)
-  - [Container Disk I/O](#container-disk-i-o)
-
-<!-- /TOC -->
-
-# Cluster Metrics
+## Cluster Metrics

 ### Cluster CPU Utilization

@@ -121,7 +59,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
 | Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |

-# Node Metrics
+## Node Metrics

 ### Node CPU Utilization

@@ -172,7 +110,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
 | Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |

-# Etcd Metrics
+## Etcd Metrics

 ### Etcd Has a Leader

@@ -242,7 +180,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | <table><tr><td>wal</td><td>`histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le))`</td></tr><tr><td>db</td><td>`histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le))`</td></tr></table> |
 | Summary | <table><tr><td>wal</td><td>`sum(histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le)))`</td></tr><tr><td>db</td><td>`sum(histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le)))`</td></tr></table> |

-# Kubernetes Components Metrics
+## Kubernetes Components Metrics

 ### API Server Request Latency

@@ -300,7 +238,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | `topk(10, histogram_quantile(0.95,sum by (le, host, path)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` |
 | Summary | `topk(10, histogram_quantile(0.95,sum by (le, host)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` |

-# Rancher Logging Metrics
+## Rancher Logging Metrics


 ### Fluentd Buffer Queue Rate
@@ -331,7 +269,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | `sum(rate(fluentd_output_status_num_records_total[5m])) by (instance)` |
 | Summary | `sum(rate(fluentd_output_status_num_records_total[5m]))` |

-# Workload Metrics
+## Workload Metrics

 ### Workload CPU Utilization

@@ -368,7 +306,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
 | Summary | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |

-# Pod Metrics
+## Pod Metrics

 ### Pod CPU Utilization

@@ -405,7 +343,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`</td></tr></table> |
 | Summary | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |

-# Container Metrics
+## Container Metrics

 ### Container CPU Utilization

@@ -5,18 +5,8 @@ weight: 2
 ---
 This section describes the expectations for RBAC for Rancher Monitoring.

- [Cluster Admins](#cluster-admins)
- [Users with Kubernetes ClusterRole-based Permissions](#users-with-kubernetes-clusterrole-based-permissions)
-  - [Users with Kubernetes Admin/Edit Permissions](#users-with-kubernetes-admin-edit-permissions)
-  - [Users with Kubernetes View Permissions](#users-with-kubernetes-view-permissions)
-  - [Additional Monitoring Roles](#additional-monitoring-roles)
-  - [Additional Monitoring ClusterRoles](#additional-monitoring-clusterroles)
- [Users with Rancher Based Permissions](#users-with-rancher-based-permissions)
-  - [Differences in 2.5.x](#differences-in-2-5-x)
-  - [Assigning Additional Access](#assigning-additional-access)
- [Role-based Access Control for Grafana](#role-based-access-control-for-grafana)

-# Cluster Admins
+## Cluster Admins

 By default, only those with the cluster-admin `ClusterRole` should be able to:

@@ -27,7 +17,7 @@ By default, only those with the cluster-admin `ClusterRole` should be able to:
 - Persist new Grafana dashboards or datasources via creating ConfigMaps in the appropriate namespace
 - Expose certain Prometheus metrics to the k8s Custom Metrics API for HPA via a Secret in the `cattle-monitoring-system` namespace

-# Users with Kubernetes ClusterRole-based Permissions
+## Users with Kubernetes ClusterRole-based Permissions

 The `rancher-monitoring` chart installs the following three `ClusterRoles`. By default, they aggregate into the corresponding k8s `ClusterRoles`:

@@ -92,7 +82,7 @@ An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a

 * **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes. You will need to fill in the name below, and name is case-sensitive. 

-```
+```yaml
 # monitoring-config-view-role-binding.yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: RoleBinding
@@ -114,7 +104,7 @@ subjects:
  * **`kubectl apply -f monitoring-config-view-role-binding.yaml`
 

-# Users with Rancher Based Permissions
+## Users with Rancher Based Permissions

 The relationship between the default roles deployed by Rancher (i.e. cluster-owner, cluster-member, project-owner, project-member), the default Kubernetes roles, and the roles deployed by the rancher-monitoring chart are detailed in the table below:

@@ -161,7 +151,7 @@ If cluster-admins would like to provide additional admin/edit access to users ou



-# Role-based Access Control for Grafana
+## Role-based Access Control for Grafana

 Rancher allows any users who are authenticated by Kubernetes and have access the Grafana service deployed by the Rancher Monitoring chart to access Grafana via the Rancher Dashboard UI. By default, all users who are able to access Grafana are given the [Viewer](https://grafana.com/docs/grafana/latest/permissions/organization_roles/#viewer-role) role, which allows them to view any of the default dashboards deployed by Rancher.

@@ -8,17 +8,14 @@ _Available as of v2.5.8_

 Starting at Monitoring V2 14.5.100 (used by default in Rancher 2.5.8), Monitoring V2 can now be deployed on a Windows cluster and will scrape metrics from Windows nodes using [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter) (previously named `wmi_exporter`).

- [Comparison to Monitoring V1](#comparison-to-monitoring-v1)
- [Cluster Requirements](#cluster-requirements)
-  - [Upgrading Existing Clusters to wins v0.1.0](#upgrading-existing-clusters-to-wins-v0-1-0)

-# Comparison to Monitoring V1
+## Comparison to Monitoring V1

 Unlike Monitoring V1 for Windows, metrics collected by `windows_exporter` will be labeled as `windows_` instead of `wmi_` in accordance to a naming change from upstream from `wmi_exporter` to `windows_exporter`.

 In addition, Monitoring V2 for Windows will no longer require users to keep port 9796 open on Windows hosts since the host metrics will published directly onto a port exposed on the windows-exporter Pod. This feature was powered by recent changes made by `wins` v0.1.0 to support publishing ports exposed on the hostNetwork on Pods that use wins to run a privileged Windows binary as a host process.

-# Cluster Requirements
+## Cluster Requirements

 Monitoring V2 for Windows can only scrape metrics from Windows hosts that have a minimum `wins` version of v0.1.0.  To be able to fully deploy Monitoring V2 for Windows, all of your hosts must meet this requirement.

@@ -16,13 +16,13 @@ OPA provides a high-level declarative language that lets you specify policy as c

 To read more about OPA, please refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/)

-# How the OPA Gatekeeper Integration Works
+## How the OPA Gatekeeper Integration Works

 Kubernetes provides the ability to extend API server functionality via admission controller webhooks, which are invoked whenever a resource is created, updated or deleted. Gatekeeper is installed as a validating webhook and enforces policies defined by Kubernetes custom resource definitions. In addition to the admission control usage, Gatekeeper provides the capability to audit existing resources in Kubernetes clusters and mark current violations of enabled policies.

 OPA Gatekeeper is made available via Rancher's Helm system chart, and it is installed in a namespace named `gatekeeper-system.`

-# Enabling OPA Gatekeeper in a Cluster
+## Enabling OPA Gatekeeper in a Cluster

 :::note

@@ -48,7 +48,7 @@ The OPA Gatekeeper Helm chart can be installed from **Apps & Marketplace**.

 **Result:** OPA Gatekeeper is deployed in your Kubernetes cluster.

-# Constraint Templates
+## Constraint Templates

 [Constraint templates](https://github.com/open-policy-agent/gatekeeper#constraint-templates) are Kubernetes custom resources that define the schema and Rego logic of the OPA policy to be applied by Gatekeeper. For more information on the Rego policy language, refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/policy-language/)

@@ -58,7 +58,7 @@ To list the constraint templates installed in the cluster, go to the left side m

 Rancher also provides the ability to create your own constraint templates by importing YAML definitions.
   
-# Creating and Configuring Constraints
+## Creating and Configuring Constraints

 [Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together.

@@ -84,7 +84,7 @@ To limit the scope of the constraint only to user namespaces, always specify the

 Also, the constraint may interfere with other Rancher functionality and deny system workloads from being deployed. To avoid this, exclude all Rancher-specific namespaces from your constraints.
   
-# Enforcing Constraints in your Cluster
+## Enforcing Constraints in your Cluster

 When the **Enforcement Action** is **Deny,** the constraint is immediately enabled and will deny any requests that violate the policy defined. By default, the enforcement value is **Deny**.

@@ -92,7 +92,7 @@ When the **Enforcement Action** is **Dryrun,** then any resources that violate t

 To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny**. 

-# Audit and Violations in your Cluster
+## Audit and Violations in your Cluster

 OPA Gatekeeper runs a periodic audit to check if any existing resource violates any enforced constraint. The audit-interval (default 300s) can be configured while installing Gatekeeper.

@@ -102,7 +102,7 @@ Also under **Constraints,** the number of violations of the constraint can be fo

 The detail view of each constraint lists information about the resource that violated the constraint.

-# Disabling Gatekeeper
+## Disabling Gatekeeper

 1. Navigate to the cluster's Dashboard view
 1. On the left side menu, expand the cluster menu and click on **OPA Gatekeeper**.
@@ -5,11 +5,6 @@ weight: 8010

 This page is intended to answer questions about what happens if you don't want Rancher anymore, if you don't want a cluster to be managed by Rancher anymore, or if the Rancher server is deleted.

- [If the Rancher server is deleted, what happens to the workloads in my downstream clusters?](#if-the-rancher-server-is-deleted-what-happens-to-the-workloads-in-my-downstream-clusters)
- [If the Rancher server is deleted, how do I access my downstream clusters?](#if-the-rancher-server-is-deleted-how-do-i-access-my-downstream-clusters)
- [What if I don't want Rancher anymore?](#what-if-i-don-t-want-rancher-anymore)
- [What if I don't want my registered cluster managed by Rancher?](#what-if-i-don-t-want-my-registered-cluster-managed-by-rancher)
- [What if I don't want my RKE cluster or hosted Kubernetes cluster managed by Rancher?](#what-if-i-don-t-want-my-rke-cluster-or-hosted-kubernetes-cluster-managed-by-rancher)

 ### If the Rancher server is deleted, what happens to the workloads in my downstream clusters?

@@ -15,13 +15,6 @@ Make sure that your node fulfills the general [installation requirements.](../..

 ## Installation Outline

-<!-- TOC -->
-
- [1. Provision Linux Host](#1-provision-linux-host)
- [2. Choose an SSL Option and Install Rancher](#2-choose-an-ssl-option-and-install-rancher)
- [3. Configure Load Balancer](#3-configure-load-balancer)
-
-<!-- /TOC -->

 ## 1. Provision Linux Host

@@ -34,7 +34,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`:

@@ -44,7 +44,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:

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

@@ -3,7 +3,7 @@ title: "Running on ARM64 (Experimental)"
 weight: 3
 ---

-:::caution:
+:::caution

 Running on an ARM64 platform is currently an experimental feature and is not yet officially supported in Rancher. Therefore, we do not recommend using ARM64 based nodes in a production environment.

@@ -21,6 +21,7 @@ The following options are available when using an ARM64 platform:
    --privileged \
    rancher/rancher:vX.Y.Z
  ```
+
 :::note

 To check if your specific released version is compatible with the ARM64 architecture, you may navigate to your
@@ -10,7 +10,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

 :::caution

@@ -24,7 +24,7 @@ Deploying to Microsoft Azure will incur charges.
 - 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:

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

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

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

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

@@ -94,7 +94,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:

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

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

@@ -12,10 +12,8 @@ The second is a guide for installing an EKS cluster with an ingress by using com

 If you already have an EKS Kubernetes cluster, skip to the step about [installing an ingress.](#5-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)

- [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/)

@@ -41,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.

@@ -11,13 +11,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:

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

@@ -65,7 +65,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:

@@ -93,7 +93,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:

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

@@ -129,7 +129,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=<VERSION>
 ```

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

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

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

@@ -156,7 +156,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:

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

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

@@ -3,11 +3,8 @@ title: Rollbacks
 weight: 3
 ---

- [Rolling Back to Rancher v2.5.0+](#rolling-back-to-rancher-v2-5-0)
- [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.

@@ -102,7 +99,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](../../../../versioned_docs/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.

@@ -114,6 +111,6 @@ Managed clusters are authoritative for their state. This means restoring the Ran

 :::

-# 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](../../../../versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
@@ -8,12 +8,8 @@ For the instructions to upgrade Rancher installed with Docker, refer to [this pa

 To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.

- [Prerequisites](#prerequisites)
- [Upgrade Outline](#upgrade-outline)
- [Known Upgrade Issues](#known-upgrade-issues)
- [RKE Add-on Installs](#rke-add-on-installs)

-# Prerequisites
+## Prerequisites

 ### Access to kubeconfig

@@ -47,22 +43,18 @@ 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:

- [1. Back up your Kubernetes cluster that is running Rancher server](#1-back-up-your-kubernetes-cluster-that-is-running-rancher-server)
- [2. Update the Helm chart repository](#2-update-the-helm-chart-repository)
- [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 restore 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.

@@ -115,7 +107,7 @@ You'll use the backup as a restore point if something goes wrong during upgrade.
    helm fetch rancher-<CHART_REPO>/rancher --version=v2.4.11
    ```

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

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

@@ -143,7 +135,7 @@ There will be more values that are listed with this command. This is just an exa

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

-### Steps to Upgrade Rancher
+#### Steps to Upgrade Rancher

 Upgrade Rancher to the latest version with all your settings.

@@ -172,7 +164,7 @@ helm upgrade rancher rancher-<CHART_REPO>/rancher \
  --version=2.4.5
 ```

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

 Log into Rancher to confirm that the upgrade succeeded.

@@ -184,6 +176,6 @@ See [Restoring Cluster Networking](../../../../versioned_docs/version-2.0-2.4/ge

 :::

-# 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)
@@ -45,7 +45,7 @@ Create the registries.yaml file at `/etc/rancher/k3s/registries.yaml`. This will

 The registries.yaml file should look like this before plugging in the necessary information:

-```
+```yaml
 ---
 mirrors:
  customreg:
@@ -109,7 +109,7 @@ To use this `kubeconfig` file,
 2. Copy the file at `/etc/rancher/k3s/k3s.yaml` and save it to the directory `~/.kube/config` on your local machine.
 3. In the kubeconfig file, the `server` directive is defined as localhost. Configure the server as the DNS of your load balancer, referring to port 6443. (The Kubernetes API server will be reached at port 6443, while the Rancher server will be reached at ports 80 and 443.) Here is an example `k3s.yaml`:

-```
+```yaml
 apiVersion: v1
 clusters:
 - cluster:
@@ -9,22 +9,15 @@ 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.

-This section describes installing Rancher:
-
- [1. Add the Helm Chart Repository](#1-add-the-helm-chart-repository)
- [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration)
- [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.

@@ -55,7 +48,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.

@@ -72,7 +65,7 @@ If you want terminate SSL/TLS externally, see [TLS termination on an External Lo
 | 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.

@@ -82,11 +75,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.
@@ -97,7 +90,7 @@ Recent changes to cert-manager require an upgrade. If you are upgrading Rancher

 :::

-### 1. Add the cert-manager repo
+##### 1. Add the cert-manager repo

 From a system connected to the internet, add the cert-manager repo to Helm:

@@ -106,7 +99,7 @@ helm repo add jetstack https://charts.jetstack.io
 helm repo update
 ```

-### 2. Fetch the cert-manager chart
+##### 2. Fetch the cert-manager chart

 Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).

@@ -120,7 +113,7 @@ New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommen
 helm fetch jetstack/cert-manager --version v1.7.1
 ```

-### 3. Render the cert-manager template
+##### 3. Render the cert-manager template

 Render the cert-manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.

@@ -133,14 +126,14 @@ helm template cert-manager ./cert-manager-v1.7.1.tgz --output-dir . \
    --set startupapicheck.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-ctl
 ```

-### 4. Download the cert-manager CRD
+##### 4. Download the cert-manager CRD

 Download the required CRD file for cert-manager:
   ```plain
   curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
   ```

-### 5. Render the Rancher template
+##### 5. Render the Rancher template

 Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.

@@ -165,14 +158,14 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \

 **Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.5.8`

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


-### 1. Create secrets
+##### 1. Create secrets

 Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher.

-### 2. Render the Rancher template
+##### 2. Render the Rancher template

 Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.

@@ -211,7 +204,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following

 Then refer to [Adding TLS Secrets](../../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them.

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

@@ -219,7 +212,7 @@ Use `kubectl` to create namespaces and apply the rendered manifests.

 If you choose to use self-signed certificates in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), install cert-manager.

-### For Self-Signed Certificate Installs, Install Cert-manager
+#### For Self-Signed Certificate Installs, Install Cert-manager

 <details id="install-cert-manager">
  <summary>Click to expand</summary>
@@ -227,14 +220,13 @@ If you choose to use self-signed certificates in [B. Choose your SSL Configurati
 If you are using self-signed certificates, install cert-manager:

 1. Create the namespace for cert-manager.
-```plain
-kubectl create namespace cert-manager
-```
-
-1. Create the cert-manager CustomResourceDefinitions (CRDs).
-```plain
-kubectl apply -f cert-manager/cert-manager-crd.yaml
-```
+    ```plain
+    kubectl create namespace cert-manager
+    ```
+2. Create the cert-manager CustomResourceDefinitions (CRDs).
+    ```plain
+    kubectl apply -f cert-manager/cert-manager-crd.yaml
+    ```

    :::note

@@ -242,14 +234,14 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml

    :::

-1. Launch cert-manager.
-```plain
-kubectl apply -R -f ./cert-manager
-```
+3. Launch cert-manager.
+    ```plain
+    kubectl apply -R -f ./cert-manager
+    ```

 </details>

-### Install Rancher with kubectl
+#### Install Rancher with kubectl

 ```plain
 kubectl create namespace cattle-system
@@ -263,7 +255,7 @@ If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/

 :::

-# Additional Resources
+## Additional Resources

 These resources could be helpful when installing Rancher:

@@ -178,7 +178,7 @@ Your registry must support manifests. As of April 2020, Amazon Elastic Container

 Append your private registry address to the `allow-nondistributable-artifacts` config field in the Docker daemon (`C:\ProgramData\Docker\config\daemon.json`). Since the base image of Windows images are maintained by the `mcr.microsoft.com` registry, this step is required as the layers in the Microsoft registry are missing from Docker Hub and need to be pulled into the private registry.

-   ```
+   ```json
   {
     ...
     "allow-nondistributable-artifacts": [
@@ -5,8 +5,6 @@ weight: 200

 Once the infrastructure is ready, you can continue with setting up an RKE cluster to install Rancher in.

-### Installing Docker
-
 First, you have to install Docker and setup the HTTP proxy on all three Linux nodes. For this perform the following steps on all three nodes.

 For convenience, export the IP address and port of your proxy into an environment variable and set up the HTTP_PROXY variables for your current shell:
@@ -105,7 +103,7 @@ sudo ./get_helm.sh

 Next, create a YAML file that describes the RKE cluster. Ensure that the IP addresses of the nodes and the SSH username are correct. For more information on the cluster YAML, have a look at the [RKE documentation](https://rancher.com/docs/rke/latest/en/example-yamls/).

-```
+```yml
 nodes:
  - address: 10.0.1.200
    user: ubuntu
@@ -14,12 +14,12 @@ The following instructions will guide you through upgrading a Rancher server tha

 :::

-# Prerequisites
+## Prerequisites

 - **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#known-upgrade-issues)** section 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>`).

@@ -31,7 +31,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:

@@ -55,18 +55,10 @@ 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 

-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:
-
- [1. Create a copy of the data from your Rancher server container](#1-create-a-copy-of-the-data-from-your-rancher-server-container)
- [2. Create a backup tarball](#2-create-a-backup-tarball)
- [3. Pull the new Docker image](#3-pull-the-new-docker-image)
- [4. Start the new Rancher server container](#4-start-the-new-rancher-server-container)
- [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
+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.
+### 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.

@@ -82,13 +74,11 @@ 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>).

    This tarball will serve as a rollback point if something goes wrong during upgrade. Use the following command, replacing each placeholder.
-
-
    ```
    docker run --volumes-from rancher-data -v "$PWD:/backup" --rm busybox tar zcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
    ```
@@ -104,7 +94,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.

@@ -116,7 +106,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.

@@ -142,7 +132,7 @@ To see the command to use when starting the new Rancher server container, choose

 Select which option you had installed Rancher server

-### Option A: Default Self-Signed Certificate
+#### Option A: Default Self-Signed Certificate

 <details id="option-a">
  <summary>Click to expand</summary>
@@ -165,10 +155,10 @@ Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-s

 </details>

-### Option B: Bring Your Own Certificate: Self-Signed
+#### Option B: Bring Your Own Certificate: Self-Signed

 <details id="option-b">
-  <summary>Click to expand</summary>
+<summary>Click to expand</summary>

 If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.

@@ -201,7 +191,7 @@ Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-s

 </details>

-### Option C: Bring Your Own Certificate: Signed by Recognized CA
+#### Option C: Bring Your Own Certificate: Signed by Recognized CA

 <details id="option-c">
  <summary>Click to expand</summary>
@@ -235,7 +225,7 @@ docker run -d --volumes-from rancher-data \
 Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)
 </details>

-### Option D: Let's Encrypt Certificate
+#### Option D: Let's Encrypt Certificate

 <details id="option-d">
  <summary>Click to expand</summary>
@@ -280,7 +270,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher

 When starting the new Rancher server container, choose from the following options:

-### Option A: Default Self-Signed Certificate
+#### Option A: Default Self-Signed Certificate

 <details id="option-a">
  <summary>Click to expand</summary>
@@ -305,7 +295,7 @@ Placeholder | Description
 Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)
 </details>

-### Option B: Bring Your Own Certificate: Self-Signed
+#### Option B: Bring Your Own Certificate: Self-Signed

 <details id="option-b">
  <summary>Click to expand</summary>
@@ -341,7 +331,7 @@ docker run -d --restart=unless-stopped \
 Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)
 </details>

-### Option C: Bring Your Own Certificate: Signed by Recognized CA
+#### Option C: Bring Your Own Certificate: Signed by Recognized CA

 <details id="option-c">
  <summary>Click to expand</summary>
@@ -388,7 +378,7 @@ privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-s

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

@@ -398,10 +388,10 @@ See [Restoring Cluster Networking](../../../../../versioned_docs/version-2.0-2.4

 :::

-# 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).
@@ -99,6 +99,7 @@ Because the rancher-alpha repository contains only alpha charts, switching betwe

 </TabItem>
 <TabItem value="Docker Images">
+
 When performing [Docker installs](../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md), upgrades, or rollbacks, you can use _tags_ to install a specific version of Rancher.

 ### Server Tags
@@ -7,33 +7,19 @@ Following an upgrade to the latest version of Rancher, downstream Kubernetes clu

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

-This section covers the following topics:

- [New Features](#new-features)
- [Tested Kubernetes Versions](#tested-kubernetes-versions)
- [How Upgrades Work](#how-upgrades-work)
- [Recommended Best Practice for Upgrades](#recommended-best-practice-for-upgrades)
- [Upgrading the Kubernetes Version](#upgrading-the-kubernetes-version)
- [Rolling Back](#rolling-back)
- [Configuring the Upgrade Strategy](#configuring-the-upgrade-strategy)
-  - [Configuring the Maximum Unavailable Worker Nodes in the Rancher UI](#configuring-the-maximum-unavailable-worker-nodes-in-the-rancher-ui)
-  - [Enabling Draining Nodes During Upgrades from the Rancher UI](#enabling-draining-nodes-during-upgrades-from-the-rancher-ui)
-  - [Maintaining Availability for Applications During Upgrades](#maintaining-availability-for-applications-during-upgrades)
-  - [Configuring the Upgrade Strategy in the cluster.yml](#configuring-the-upgrade-strategy-in-the-cluster-yml)
- [Troubleshooting](#troubleshooting)
-
-# Tested Kubernetes Versions
+## Tested Kubernetes Versions

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

-# How Upgrades Work
+## How Upgrades Work

 RKE v1.1.0 changed the way that clusters are upgraded.

 In this section of the [RKE documentation,](https://rancher.com/docs/rke/latest/en/upgrades/how-upgrades-work) you'll learn what happens when you edit or upgrade your RKE Kubernetes cluster.


-# Recommended Best Practice for Upgrades
+## Recommended Best Practice for Upgrades

 When upgrading the Kubernetes version of a cluster, we recommend that you:

@@ -43,7 +29,7 @@ When upgrading the Kubernetes version of a cluster, we recommend that you:

 The restore operation will work on a cluster that is not in a healthy or active state.

-# Upgrading the Kubernetes Version
+## Upgrading the Kubernetes Version

 :::note Prerequisites:

@@ -59,14 +45,14 @@ 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:

 - [Backing up a cluster](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md#how-snapshots-work)
 - [Restoring a cluster from backup](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md#restoring-a-cluster-from-a-snapshot)

-# Configuring the Upgrade Strategy
+## Configuring the Upgrade Strategy

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

@@ -122,7 +108,7 @@ More advanced upgrade strategy configuration options are available by editing th

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

-# Troubleshooting
+## Troubleshooting

 If a node doesn't come up after an upgrade, the `rke up` command errors out.

@@ -6,20 +6,6 @@ The [Divio documentation system](https://documentation.divio.com/) is a software

 In our docs, we have used this guideline to craft a unique set of docs which include [getting started](../../getting-started.md), [how-to guides](../../how-to-guides.md) (including [new](../../pages-for-subheaders/new-user-guides.md) and [advanced user guides](../../pages-for-subheaders/advanced-user-guides.md)), [reference guides](../../reference-guides.md), [explanations](../../explanations.md), an [FAQ section](../../faq.md), [troubleshooting tips](../../troubleshooting.md), and the ability to [contribute to Rancher](../../contribute-to-rancher.md). 

- [Getting Started](#getting-started)
- [How-to Guides](#how-to-guides)
-    - [New User Guides](#new-user-guides)
-    - [Advanced User Guides](#advanced-user-guides)
- [Reference Guides](#reference-guides)
- [Explanations](#explanations)
-    - [Integrations in Rancher](#integrations-in-rancher)    
- [Other Docs Categories](#other-docs-categories)
-    - [FAQ](#faq)
-    - [Troubleshooting](#troubleshooting)
-    - [Contribute to Rancher](#contribute-to-rancher)
- [Overlapping of Categories](#overlapping-of-categories)
- [New Structure Goals](#new-structure-goals)
-

 ## Getting Started

@@ -28,7 +28,7 @@ Deploying to Amazon AWS will incur charges.

 The AWS module just creates an EC2 KeyPair, an EC2 SecurityGroup and an EC2 instance. A simple policy would be:

-```
+```json
 {
    "Version": "2012-10-17",
    "Statement": [
@@ -50,17 +50,18 @@ The AWS module just creates an EC2 KeyPair, an EC2 SecurityGroup and an EC2 inst
 3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.

 4. Edit `terraform.tfvars` and customize the following variables:
+
    - `aws_access_key` - Amazon AWS Access Key
    - `aws_secret_key` - Amazon AWS Secret Key
    - `rancher_server_admin_password` - Admin password for created Rancher server

-5. **Optional:** Modify optional variables within `terraform.tfvars`.
-See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) for more information.
+5. **Optional:** Modify optional variables within `terraform.tfvars`. See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) for more information.
 Suggestions include:
-    - `aws_region` - Amazon AWS region, choose the closest instead of the default (`us-east-1`)
-    - `prefix` - Prefix for all created resources
-    - `instance_type` - EC2 instance size used, minimum is `t3a.medium` but `t3a.large` or `t3a.xlarge` could be used if within budget
-    - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster
+
+   - `aws_region` - Amazon AWS region, choose the closest instead of the default (`us-east-1`)
+   - `prefix` - Prefix for all created resources
+   - `instance_type` - EC2 instance size used, minimum is `t3a.medium` but `t3a.large` or `t3a.xlarge` could be used if within budget
+   - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster

 6. Run `terraform init`.

@@ -43,13 +43,12 @@ Deploying to Microsoft Azure will incur charges.
    - `rancher_server_admin_password` - Admin password for created Rancher server

 5. **Optional:** Modify optional variables within `terraform.tfvars`.
-See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) for more information.
-Suggestions include:
-    - `azure_location` - Microsoft Azure region, choose the closest instead of the default (`East US`)
-    - `prefix` - Prefix for all created resources
-    - `instance_type` - Compute instance size used, minimum is `Standard_DS2_v2` but `Standard_DS2_v3` or `Standard_DS3_v2` could be used if within budget
-    - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster
-    - `windows_admin_password` - The admin password of the windows worker node
+See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) for more information. Suggestions include:
+   - `azure_location` - Microsoft Azure region, choose the closest instead of the default (`East US`)
+   - `prefix` - Prefix for all created resources
+   - `instance_type` - Compute instance size used, minimum is `Standard_DS2_v2` but `Standard_DS2_v3` or `Standard_DS3_v2` could be used if within budget
+   - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster
+   - `windows_admin_password` - The admin password of the windows worker node

 6. Run `terraform init`.

@@ -37,11 +37,10 @@ Deploying to DigitalOcean will incur charges.
    - `rancher_server_admin_password` - Admin password for created Rancher server

 5. **Optional:** Modify optional variables within `terraform.tfvars`.
-See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) for more information.
-Suggestions include:
-    - `do_region` - DigitalOcean region, choose the closest instead of the default (`nyc1`)
-    - `prefix` - Prefix for all created resources
-    - `droplet_size` - Droplet size used, minimum is `s-2vcpu-4gb` but `s-4vcpu-8gb` could be used if within budget
+See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) for more information. Suggestions include:
+   - `do_region` - DigitalOcean region, choose the closest instead of the default (`nyc1`)
+   - `prefix` - Prefix for all created resources
+   - `droplet_size` - Droplet size used, minimum is `s-2vcpu-4gb` but `s-4vcpu-8gb` could be used if within budget

 6. Run `terraform init`.

@@ -20,18 +20,6 @@ The intent of these guides is to quickly launch a sandbox that you can use to ev

 This Quick Start Guide is divided into different tasks for easier consumption.

-<!-- TOC -->
-
-
-1. [Provision a Equinix Metal Host](#1-provision-a-equinix-metal-host)
-
-1. [Install Rancher](#2-install-rancher)
-
-1. [Log In](#3-log-in)
-
-1. [Create the Cluster](#4-create-the-cluster)
-
-<!-- /TOC -->
 <br/>

 ## Prerequisites
@@ -40,10 +40,10 @@ Deploying to Google GCP will incur charges.
 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp) for more information.
 Suggestions include:
-    - `gcp_region` - Google GCP region, choose the closest instead of the default (`us-east4`)
-    - `gcp_zone` - Google GCP zone, choose the closest instead of the default (`us-east4-a`)
-    - `prefix` - Prefix for all created resources
-    - `machine_type` - Compute instance size used, minimum is `n1-standard-1` but `n1-standard-2` or `n1-standard-4` could be used if within budget
+   - `gcp_region` - Google GCP region, choose the closest instead of the default (`us-east4`)
+   - `gcp_zone` - Google GCP zone, choose the closest instead of the default (`us-east4-a`)
+   - `prefix` - Prefix for all created resources
+   - `machine_type` - Compute instance size used, minimum is `n1-standard-1` but `n1-standard-2` or `n1-standard-4` could be used if within budget

 6. Run `terraform init`.

@@ -39,9 +39,10 @@ Deploying to Hetzner Cloud will incur charges.
 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Hetzner Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/hcloud) for more information.
 Suggestions include:
-    - `prefix` - Prefix for all created resources
-    - `instance_type` - Instance type, minimum required is `cx21`
-    - `hcloud_location` - Hetzner Cloud location, choose the closest instead of the default (`fsn1`)
+
+   - `prefix` - Prefix for all created resources
+   - `instance_type` - Instance type, minimum required is `cx21`
+   - `hcloud_location` - Hetzner Cloud location, choose the closest instead of the default (`fsn1`)

 6. Run `terraform init`.

@@ -45,7 +45,7 @@ From the **Workloads** page, click the link underneath your workload. If your de

 When using a cloud-hosted virtual machine, you may not have access to the port running the container. In this event, you can test Nginx in an ssh session on the local machine using `Execute Shell`. Use the port number after the `:` in the link under your workload if available, which is `31568` in this example.

-```sh
+```html
 gettingstarted@rancher:~$ curl http://localhost:31568
 <!DOCTYPE html>
 <html>
@@ -28,7 +28,6 @@ For this workload, you'll be deploying the application Rancher Hello-World.
 * Your workload is deployed. This process might take a few minutes to complete.
 * When your workload completes deployment, it's assigned a state of **Active**. You can view this status from the project's **Workloads** page.

-<br/>
 ### 2. Expose The Application Via An Ingress

 Now that the application is up and running, it needs to be exposed so that other services can connect.
@@ -34,15 +34,6 @@ Before you start, we recommend creating an empty text file. You can use this fil

 :::

-<!-- TOC -->
-
- [1. Register Rancher with Azure](#1-register-rancher-with-azure)
- [2. Create a new client secret](#2-create-a-new-client-secret)
- [3. Set Required Permissions for Rancher](#3-set-required-permissions-for-rancher)
- [4. Copy Azure Application Data](#5-copy-azure-application-data)
- [5. Configure Azure AD in Rancher](#6-configure-azure-ad-in-rancher)
-
-<!-- /TOC -->

 #### 1. Register Rancher with Azure

@@ -11,11 +11,6 @@ You can [save the configuration of an existing cluster as an RKE template.](#con

 You can't change a cluster to use a different RKE template. You can only update the cluster to a new revision of the same template.

-This section covers the following topics:
-
- [Creating a cluster from an RKE template](#creating-a-cluster-from-an-rke-template)
- [Updating a cluster created with an RKE template](#updating-a-cluster-created-with-an-rke-template)
- [Converting an existing cluster to use an RKE template](#converting-an-existing-cluster-to-use-an-rke-template)

 ### Creating a Cluster from an RKE Template

@@ -15,7 +15,7 @@ Users can only create new templates if the administrator [gives them permission.

 After a cluster is created with an RKE template, the cluster creator cannot edit settings that are defined in the template. The only way to change those settings after the cluster is created is to [upgrade the cluster to a new revision](apply-templates.md#updating-a-cluster-created-with-an-rke-template) of the same template. If cluster creators want to change template-defined settings, they would need to contact the template owner to get a new revision of the template. For details on how template revisions work, refer to the [documentation on revising templates.](manage-rke1-templates.md#updating-a-template)

-# Requiring New Clusters to Use an RKE Template
+## Requiring New Clusters to Use an RKE Template

 You might want to require new clusters to use a template to ensure that any cluster launched by a [standard user](../manage-role-based-access-control-rbac/global-permissions.md) will use the Kubernetes and/or Rancher settings that are vetted by administrators.

@@ -33,7 +33,7 @@ To require new clusters to use an RKE template, administrators can turn on RKE t
    
 **Result:** All clusters provisioned by Rancher must use a template, unless the creator is an administrator.

-# Disabling RKE Template Enforcement
+## Disabling RKE Template Enforcement

 To allow new clusters to be created without an RKE template, administrators can turn off RKE template enforcement with the following steps:

@@ -11,7 +11,7 @@ These example scenarios describe how an organization could use templates to stan
 - **Sharing ownership of a template:** When a template owner no longer wants to maintain a template, or wants to delegate ownership of the template, this scenario describes how [template ownership can be shared.](#allowing-other-users-to-control-and-share-a-template)


-# Enforcing a Template Setting for Everyone
+## Enforcing a Template Setting for Everyone

 Let's say there is an organization in which the administrators decide that all new clusters should be created with Kubernetes version 1.14.

@@ -27,7 +27,7 @@ Let's say there is an organization in which the administrators decide that all n

 In this way, the administrators enforce the Kubernetes version across the organization, while still allowing end users to configure everything else.

-# Templates for Basic and Advanced Users
+## Templates for Basic and Advanced Users

 Let's say an organization has both basic and advanced users. Administrators want the basic users to be required to use a template, while the advanced users and administrators create their clusters however they want.

@@ -42,7 +42,7 @@ Let's say an organization has both basic and advanced users. Administrators want

 **Result:** All Rancher users, except for administrators, are required to use a template when creating a cluster. Everyone has access to the restrictive template, but only advanced users have permission to use the more permissive template. The basic users are more restricted, while advanced users have more freedom when configuring their Kubernetes clusters.

-# Updating Templates and Clusters Created with Them
+## Updating Templates and Clusters Created with Them

 Let's say an organization has a template that requires clusters to use Kubernetes v1.14. However, as time goes on, the administrators change their minds. They decide they want users to be able to upgrade their clusters to use newer versions of Kubernetes.

@@ -54,7 +54,7 @@ The template owner has several options for allowing the cluster creators to upgr
 - **Allow any Kubernetes version on the template:** When creating a template revision, the template owner can also mark the the Kubernetes version as **Allow User Override** using the switch near that setting on the Rancher UI. This will allow clusters that upgrade to this template revision to use any version of Kubernetes.
 - **Allow the latest minor Kubernetes version on the template:** The template owner can also create a template revision in which the Kubernetes version is defined as **Latest v1.14 (Allows patch version upgrades)**. This means clusters that use that revision will be able to get patch version upgrades, but major version upgrades will not be allowed.

-# Allowing Other Users to Control and Share a Template
+## Allowing Other Users to Control and Share a Template

 Let's say Alice is a Rancher administrator. She owns an RKE template that reflects her organization's agreed-upon best practices for creating a cluster.

@@ -29,7 +29,7 @@ Terraform allows you to:
 - Incorporate infrastructure changes into standard development practices
 - Prevent configuration drift, in which some servers become configured differently than others

-# How Does Terraform Work?
+## How Does Terraform Work?

 Terraform is written in files with the extension `.tf`. It is written in HashiCorp Configuration Language, which is a declarative language that lets you define the infrastructure you want in your cluster, the cloud provider you are using, and your credentials for the provider. Then Terraform makes API calls to the provider in order to efficiently create that infrastructure.

@@ -39,7 +39,7 @@ Then Terraform calls the Rancher API to provision your infrastructure, and Ranch

 When you need to make changes to your infrastructure, instead of manually updating the servers, you can make changes in the Terraform configuration files. Then those files can be committed to version control, validated, and reviewed as necessary. Then when you run `terraform apply`, the changes would be deployed.

-# Tips for Working with Terraform
+## Tips for Working with Terraform

 - There are examples of how to provide most aspects of a cluster in the [documentation for the Rancher 2 provider.](https://www.terraform.io/docs/providers/rancher2/)

@@ -51,7 +51,7 @@ When you need to make changes to your infrastructure, instead of manually updati

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

-# Tip for Creating CIS Benchmark Compliant Clusters
+## Tip for Creating CIS Benchmark Compliant Clusters

 This section describes one way that you can make security and compliance-related config files standard in your clusters.

@@ -63,7 +63,7 @@ Then you would make sure that the `kube-api-server` flag in your RKE template us

 In this way, you can create flags that comply with the CIS benchmark.

-# Resources
+## Resources

 - [Terraform documentation](https://www.terraform.io/docs/)
 - [Rancher2 Terraform provider documentation](https://www.terraform.io/docs/providers/rancher2/)
@@ -11,20 +11,6 @@ Template revisions can be used in two ways: to create a new cluster, or to upgra

 The template owner has full control over template revisions, and can create new revisions to update the template, delete or disable revisions that should not be used to create clusters, and choose which template revision is the default.

-This section covers the following topics:
-
- [Prerequisites](#prerequisites)
- [Creating a template](#creating-a-template)
- [Updating a template](#updating-a-template)
- [Deleting a template](#deleting-a-template)
- [Creating a revision based on the default revision](#creating-a-revision-based-on-the-default-revision)
- [Creating a revision based on a cloned revision](#creating-a-revision-based-on-a-cloned-revision)
- [Disabling a template revision](#disabling-a-template-revision)
- [Re-enabling a disabled template revision](#re-enabling-a-disabled-template-revision)
- [Setting a template revision as default](#setting-a-template-revision-as-default)
- [Deleting a template revision](#deleting-a-template-revision)
- [Upgrading a cluster to use a new template revision](#upgrading-a-cluster-to-use-a-new-template-revision)
- [Exporting a running cluster to a new RKE template and revision](#exporting-a-running-cluster-to-a-new-rke-template-and-revision)

 ### Prerequisites

@@ -7,17 +7,8 @@ _Pod Security Policies_ (or PSPs) are objects that control security-sensitive as

 If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message of `Pod <NAME> is forbidden: unable to validate...`.

- [How PSPs Work](#how-psps-work)
- [Default PSPs](#default-psps)
-  - [Restricted-NoRoot](#restricted-noroot)
-  - [Restricted](#restricted)
-  - [Unrestricted](#unrestricted)
- [Creating PSPs](#creating-psps)
-  - [Requirements](#requirements)
-  - [Creating PSPs in the Rancher UI](#creating-psps-in-the-rancher-ui)
- [Configuration](#configuration)

-# How PSPs Work
+## How PSPs Work

 You can assign PSPs at the cluster or project level.

@@ -31,7 +22,7 @@ Any workloads that are already running in a cluster or project before a PSP is a

 Read more about Pod Security Policies in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).

-# Default PSPs
+## Default PSPs

 Rancher ships with three default Pod Security Policies (PSPs): the `restricted-noroot`, `restricted` and `unrestricted` policies.

@@ -50,7 +41,7 @@ This policy is a relaxed version of the `restricted-noroot` policy, with almost

 This policy is equivalent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project.

-# Creating PSPs
+## Creating PSPs

 Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file.

@@ -73,6 +64,6 @@ We recommend adding PSPs during cluster and project creation instead of adding i
 1. Complete each section of the form. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for more information on what each policy does.
 1. Click **Create**.

-# Configuration
+## Configuration

 The Kubernetes documentation on PSPs is [here](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
@@ -8,13 +8,7 @@ import TabItem from '@theme/TabItem';

 Rancher v2.6 introduced the ability to customize Rancher’s branding and navigation links.

- [Changing Brand Settings](#changing-brand-settings)
- [Brand Configuration](#brand-configuration)
- [Custom Navigation Links](#custom-navigation-links)
- [Link Configuration](#link-configuration)
- [Link Examples](#link-examples)
-
-# Changing Brand Settings
+## Changing Brand Settings

 :::note Prerequisite:

@@ -27,7 +21,7 @@ To configure the brand settings,
 1. Click **☰ > Global settings**.
 2. Click **Branding**.

-# Brand Configuration
+## Brand Configuration

 ### Private Label Company Name

@@ -67,7 +61,7 @@ To configure banner settings,
 </TabItem>
 </Tabs>

-# Custom Navigation Links
+## Custom Navigation Links

 In this section, you'll learn how to configure the links in the left navigation bar of the **Cluster Dashboard**. To get to the cluster dashboard,

@@ -101,7 +95,7 @@ You will need to have at least cluster member or project member permissions.
    For more details on setting up links, including optional fields, see [Link Configuration.](#link-configuration)
 6. Click **Create**.

-# Link Configuration
+## Link Configuration

 ### `name`

@@ -13,7 +13,7 @@ For instructions on setting up a private registry with command line options duri

 If your private registry requires credentials, it cannot be used as the default registry. There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry with credentials, you will have to [pass in the registry credentials through the advanced cluster options](#setting-a-private-registry-with-credentials-when-deploying-a-cluster) every time you create a new cluster.

-# Setting a Private Registry with No Credentials as the Default Registry
+## Setting a Private Registry with No Credentials as the Default Registry

 1. Log into Rancher and configure the default administrator password.
 1. Click **☰ > Global Settings**.
@@ -22,7 +22,7 @@ If your private registry requires credentials, it cannot be used as the default

 **Result:** Rancher will use your private registry to pull system images.

-# Setting a Private Registry with Credentials when Deploying a Cluster
+## Setting a Private Registry with Credentials when Deploying a Cluster

 You can follow these steps to configure a private registry when you create a cluster:

@@ -5,16 +5,7 @@ weight: 100

 Cluster templates encompass both Kubernetes configuration and node pool configuration, allowing a single template to contain all the information Rancher needs to provision new nodes in a cloud provider and install Kubernetes on those nodes.

- [Overview](#overview)
- [RKE2 Cluster Template](#rke2-cluster-template)
- [Adding a Cluster Template to Rancher](#adding-a-cluster-template-to-rancher)
- [Creating a Cluster from a Cluster Template](#creating-a-cluster-from-a-cluster-template)
- [Updating a Cluster Created from a Cluster Template](#updating-a-cluster-created-from-a-cluster-template)
- [Deploying Clusters from a Template with Fleet](#deploying-clusters-from-a-template-with-fleet)
- [Uninstalling Cluster Templates](#uninstalling-cluster-templates)
- [Configuration Options](#configuration-options)
-
-# Overview
+## Overview

 Cluster templates are provided as Helm charts. To use them, you will need to clone and fork the templates, change them according to your use case, and then install the Helm charts on the Rancher management cluster. When the Helm chart is installed on the Rancher management cluster, a new cluster resource is created, which Rancher uses to provision the new cluster.

@@ -28,11 +19,11 @@ Cluster templates can use any Kubernetes distribution. For now, we provide an ex

 Rancher doesn't manage version control for cluster templates. Version control is handled in the repository containing the template's Helm chart.

-# RKE2 Cluster Template
+## RKE2 Cluster Template

 The example repository for an RKE2 cluster template is [here](https://github.com/rancher/cluster-template-examples). As of Rancher v2.6.0, we provide an RKE2 cluster template and may add more in the future.

-# Adding a Cluster Template to Rancher
+## Adding a Cluster Template to Rancher

 In this section, you'll learn how to add the cluster template to the `local` cluster's chart repo list. The result is that Rancher will include the cluster template as an option when users install new Kubernetes clusters.

@@ -64,7 +55,7 @@ If you are a restricted admin and don’t have access to the `local` cluster, yo

 :::

-# Creating a Cluster from a Cluster Template
+## Creating a Cluster from a Cluster Template

 :::note Prerequisites:

@@ -81,11 +72,11 @@ If you are a restricted admin and don’t have access to the `local` cluster, yo

 **Result:** After Rancher provisions the new cluster, it is managed in the same way as any other Rancher-launched Kubernetes cluster. You can configure any options through the UI if the cluster template has options for the user to choose from.

-# Updating a Cluster Created from a Cluster Template
+## Updating a Cluster Created from a Cluster Template

 You can update any clusters using a template from the **Apps & Marketplace > Installed Apps** page, given there is a new version of a template being used by those clusters.

-# Deploying Clusters from a Template with Fleet
+## Deploying Clusters from a Template with Fleet

 :::note Prerequisites:

@@ -104,7 +95,7 @@ You can update any clusters using a template from the **Apps & Marketplace > Ins

 **Result:** After Rancher provisions the new cluster, it is managed by Fleet.

-# Uninstalling Cluster Templates
+## Uninstalling Cluster Templates

 1. Click **☰ > Cluster Management**.
 1. Go to the `local` cluster and click **Apps & Marketplace > Chart Repositories.**
@@ -115,7 +106,7 @@ You can update any clusters using a template from the **Apps & Marketplace > Ins

 An admin with access to the `local` cluster can also remove a cluster deployed via cluster templates through the **Apps & Marketplace > Installed Apps** page.

-# Configuration Options
+## Configuration Options

 Cluster templates are flexible enough that they can be used to configure all of the following options:

@@ -137,21 +137,21 @@ _Project roles_ are roles that can be used to grant users access to a project. T

    These users can manage project-scoped resources like namespaces and workloads, but cannot manage other project members.

-    :::note
+:::note

-    By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
+By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.

-    :::
+:::

 - **Read Only:**

    These users can view everything in the project but cannot create, update, or delete anything.

-    :::note danger
+:::danger

-    Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `owner` or `member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
+Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `owner` or `member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.

-    :::
+:::

 #### Custom Project Roles

@@ -7,29 +7,21 @@ Within Rancher, _roles_ determine what actions a user can make within a cluster

 Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access.

-:::tip
+:::danger

 It is possible for a custom role to enable privilege escalation. For details, see [this section.](#privilege-escalation)

 :::

-This section covers the following topics:

- [Prerequisites](#prerequisites)
- [Creating a custom role](#creating-a-custom-role)
- [Creating a custom role that inherits from another role](#creating-a-custom-role-that-inherits-from-another-role)
- [Deleting a custom role](#deleting-a-custom-role)
- [Assigning a custom role to a group](#assigning-a-custom-role-to-a-group)
- [Privilege escalation](#privilege-escalation)
-
-# Prerequisites
+## Prerequisites

 To complete the tasks on this page, one of the following permissions are required:

 - [Administrator Global Permissions](global-permissions.md).
 - [Custom Global Permissions](global-permissions.md#custom-global-permissions) with the [Manage Roles](global-permissions.md) role assigned.

-# Creating A Custom Role
+## Creating A Custom Role

 While Rancher comes out-of-the-box with a set of default user roles, you can also create default custom roles to provide users with very specific permissions within Rancher.

@@ -61,7 +53,7 @@ The steps to add custom roles differ depending on the version of Rancher.

 1.  Click **Create**.

-# Creating a Custom Role that Inherits from Another Role
+## Creating a Custom Role that Inherits from Another Role

 If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom role in which all of the rules from another role, such as the administrator role, are copied into a new role. This allows you to only configure the variations between the existing role and the new role.

@@ -80,7 +72,7 @@ To create a custom role based on an existing role,
 1. Optional: Assign the role as default.
 1. Click **Create**.

-# Deleting a Custom Role
+## Deleting a Custom Role

 When deleting a custom role, all global role bindings with this custom role are deleted.

@@ -95,7 +87,7 @@ To delete a custom role,
 2. Go to the custom global role that should be deleted and click **⋮ (…) > Delete**.
 3. Click **Delete**.

-# Assigning a Custom Role to a Group
+## Assigning a Custom Role to a Group

 If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom role. When the role is assigned to a group, the users in the group have the appropriate level of access the first time they sign into Rancher.

@@ -124,6 +116,6 @@ To assign a custom role to a group, follow these steps:

 **Result:** The custom role will take effect when the users in the group log into Rancher.

-# Privilege Escalation
+## Privilege Escalation

 The `Configure Catalogs` custom permission is powerful and should be used with caution. When an admin assigns the  `Configure Catalogs` permission to a standard user, it could result in privilege escalation in which the user could give themselves admin access to Rancher provisioned clusters. Anyone with this permission should be considered equivalent to an admin.
@@ -11,26 +11,13 @@ Global Permissions define user authorization outside the scope of any particular

 - **Restricted Admin:** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster.

- <a id="user"></a>**Standard User:** These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters.
+- **Standard User:** These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters.

 - **User-Base:** User-Base users have login-access only.

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

-This section covers the following topics:
-
- [Restricted Admin](#restricted-admin)
- [Global permission assignment](#global-permission-assignment)
-  - [Global permissions for new local users](#global-permissions-for-new-local-users)
-  - [Global permissions for users with external authentication](#global-permissions-for-users-with-external-authentication)
- [Custom global permissions](#custom-global-permissions)
-  - [Custom global permissions reference](#custom-global-permissions-reference)
-  - [Configuring default global permissions for new users](#configuring-default-global-permissions)
-  - [Configuring global permissions for existing individual users](#configuring-global-permissions-for-existing-individual-users)
-  - [Configuring global permissions for groups](#configuring-global-permissions-for-groups)
-  - [Refreshing group memberships](#refreshing-group-memberships)
-
-# 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.

@@ -104,7 +91,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.

@@ -136,7 +123,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.

@@ -8,12 +8,6 @@ This section describes how to manipulate your downstream Kubernetes cluster with

 For more information on using kubectl, see [Kubernetes Documentation: Overview of kubectl](https://kubernetes.io/docs/reference/kubectl/overview/).

- [Accessing clusters with kubectl shell in the Rancher UI](#accessing-clusters-with-kubectl-shell-in-the-rancher-ui)
- [Accessing clusters with kubectl from your workstation](#accessing-clusters-with-kubectl-from-your-workstation)
- [Note on Resources created using kubectl](#note-on-resources-created-using-kubectl)
- [Authenticating Directly with a Downstream Cluster](#authenticating-directly-with-a-downstream-cluster)
-  - [Connecting Directly to Clusters with FQDN Defined](#connecting-directly-to-clusters-with-fqdn-defined)
-  - [Connecting Directly to Clusters without FQDN Defined](#connecting-directly-to-clusters-without-fqdn-defined)


 ### Accessing Clusters with kubectl Shell in the Rancher UI
@@ -50,7 +44,7 @@ These instructions assume that you have already created a Kubernetes cluster, an

 Rancher will discover and show resources created by `kubectl`. However, these resources might not have all the necessary annotations on discovery. If an operation (for instance, scaling the workload) is done to the resource using the Rancher UI/API, this may trigger recreation of the resources due to the missing annotations. This should only happen the first time an operation is done to the discovered resource.

-# Authenticating Directly with a Downstream Cluster
+## Authenticating Directly with a Downstream Cluster

 This section intended to help you set up an alternative method to access an [RKE cluster.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)

@@ -9,7 +9,7 @@ _Pod Security Policies_ are objects that control security-sensitive aspects of p

 When you create a new cluster with RKE, you can configure it to apply a PSP immediately. As you create the cluster, use the **Cluster Options** to enable a PSP. The PSP assigned to the cluster will be the default PSP for projects within the cluster.

-:::Prerequisite:
+:::note Prerequisite:

 Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md).

@@ -18,15 +18,8 @@ For dynamic storage provisioning, your application will need to use a PVC that i

 For more information, refer to the [official Kubernetes documentation on storage](https://kubernetes.io/docs/concepts/storage/volumes/)

-This section covers the following topics:

- [About persistent volume claims](#about-persistent-volume-claims)
-  - [PVCs are required for both new and existing persistent storage](#pvcs-are-required-for-both-new-and-existing-persistent-storage)
- [Setting up existing storage with a PVC and PV](#setting-up-existing-storage-with-a-pvc-and-pv)
- - [Binding PVs to PVCs](#binding-pvs-to-pvcs)
- [Provisioning new storage with a PVC and storage class](#provisioning-new-storage-with-a-pvc-and-storage-class)
-
-# About Persistent Volume Claims
+## About Persistent Volume Claims

 Persistent volume claims (PVCs) are objects that request storage resources from your cluster. They're similar to a voucher that your deployment can redeem for storage access. A PVC is mounted into a workloads as a volume so that the workload can claim its specified share of the persistent storage.

@@ -46,7 +39,7 @@ Rancher lets you create as many PVCs within a project as you'd like.

 You can mount PVCs to a deployment as you create it, or later, after the deployment is running.

-# Setting up Existing Storage with a PVC and PV
+## Setting up Existing Storage with a PVC and PV

 Your pods can store data in [volumes,](https://kubernetes.io/docs/concepts/storage/volumes/) but if the pod fails, that data is lost. To solve this issue, Kubernetes offers persistent volumes (PVs), which are Kubernetes resources that correspond to external storage disks or file systems that your pods can access. If a pod crashes, its replacement pod can access the data in persistent storage without any data loss.

@@ -70,7 +63,7 @@ In other words, you can create unlimited PVCs, but they will only be bound to PV

 To dynamically provision new storage, the PVC mounted in the pod would have to correspond to a storage class instead of a persistent volume.

-# Provisioning New Storage with a PVC and Storage Class
+## Provisioning New Storage with a PVC and Storage Class

 Storage Classes allow you to create PVs dynamically without having to create persistent storage in an infrastructure provider first.

@@ -5,28 +5,12 @@ weight: 10

 These instructions are about using the external Ceph driver in an RKE2 cluster. If you are using RKE, additional steps are required. For details, refer to [this section.](#using-the-ceph-driver-with-rke)

- [Requirements](#requirements)
- [Using the Ceph Driver with RKE](#using-the-ceph-driver-with-rke)
- [Installing the ceph-csi driver on an RKE2 cluster](#installing-the-ceph-csi-driver-on-an-rke2-cluster)
- [Install the ceph-csi driver using Helm](#install-the-ceph-csi-driver-using-helm)
- [Creating RBD Ceph Resources](#creating-rbd-ceph-resources)
- [Configure RBD Ceph Access Secrets](#configure-rbd-ceph-access-secrets)
-  - [User Account](#user-account)
-  - [Admin Account](#admin-account)
- [Create RBD Testing Resources](#create-rbd-testing-resources)
-  - [Using RBD in Pods](#using-rbd-in-pods)
-  - [Using RBD in Persistent Volumes](#using-rbd-in-persistent-volumes)
-  - [Using RBD in Storage Classes](#using-rbd-in-storage-classes)
-  - [RKE2 Server/Master Provisioning](#rke2-server-master-provisioning)
-  - [RKE2 Agent/Worker provisioning](#rke2-agent-worker-provisioning)
- [Tested Versions](#tested-versions)
- [Troubleshooting](#troubleshooting)

-# Requirements
+## Requirements

 Make sure ceph-common and xfsprogs packages are installed on SLE worker nodes.

-# Using the Ceph Driver with RKE
+## Using the Ceph Driver with RKE

 The resources below are fully compatible with RKE based clusters, but there is a need to do an additional kubelet configuration for RKE.

@@ -45,7 +29,7 @@ services:

 For more information about the `extra_binds` directive, refer to [this section.](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/#extra-binds)

-# Installing the ceph-csi driver on an RKE2 cluster
+## Installing the ceph-csi driver on an RKE2 cluster

 :::note

@@ -77,7 +61,7 @@ min_mon_release 15 (octopus)

 Later you'll need the fsid and mon addresses values.

-# Install the ceph-csi Driver Using Helm
+## Install the ceph-csi Driver Using Helm

 Run these commands:

@@ -119,7 +103,7 @@ helm upgrade \
  --namespace ceph-csi-rbd ceph-csi-rbd ceph-csi/ceph-csi-rbd --values ceph-csi-rbd-values.yaml
 ```

-# Creating RBD Ceph Resources
+## Creating RBD Ceph Resources

 ```
 # Create a ceph pool:
@@ -147,7 +131,7 @@ QVFCK0hDVmdXSjQ1T0JBQXBrc0VtcVhlZFpjc0JwaStIcmU5M3c9PQ==
 echo "myPoolAdmin" | tr -d '\n' | base64
 bXlQb29sQWRtaW4=
 ```
-# Configure RBD Ceph Access Secrets
+## Configure RBD Ceph Access Secrets

 ### User Account

@@ -189,11 +173,11 @@ EOF
 kubectl apply -f ceph-admin-secret.yaml
 ```

-# Create RBD Testing Resources
+## Create RBD Testing Resources

 ### Using RBD in Pods

-```
+```yaml
 # pod
 cat > ceph-rbd-pod-inline.yaml << EOF
 apiVersion: v1
@@ -231,7 +215,7 @@ kubectl exec pod/ceph-rbd-pod-inline -- df -k | grep rbd

 ### Using RBD in Persistent Volumes

-```
+```yaml
 # pod-pvc-pv
 cat > ceph-rbd-pod-pvc-pv-allinone.yaml << EOF
 apiVersion: v1
@@ -294,7 +278,7 @@ kubectl exec pod/ceph-rbd-pod-pvc-pv -- df -k | grep rbd

 This example is for dynamic provisioning. The ceph-csi driver is needed.

-```
+```yaml
 # pod-pvc-sc
 cat > ceph-rbd-pod-pvc-sc-allinone.yaml <<EOF
 apiVersion: storage.k8s.io/v1
@@ -386,7 +370,7 @@ systemctl enable --now rke2-agent.service

 To import the cluster into Rancher, click **☰ > Cluster Management**. Then on the **Clusters** page, click **Import Existing**. Then run the provided kubectl command on the server/master node.

-# Tested Versions
+## Tested Versions

 OS for running RKE2 nodes: JeOS SLE15-SP2 with installed kernel-default-5.3.18-24.49

@@ -401,7 +385,7 @@ version.BuildInfo{Version:"3.4.1", GitCommit:"c4e74854886b2efe3321e185578e6db9be

 Kubernetes version on RKE2 cluster: v1.19.7+rke2r1

-# Troubleshooting
+## Troubleshooting

 In case you are using SUSE's ceph-rook based on SES7, it might be useful to expose the monitors on hostNetwork by editing `rook-1.4.5/ceph/cluster.yaml` and setting `spec.network.hostNetwork=true`.

@@ -7,11 +7,6 @@ To provide stateful workloads with vSphere storage, we recommend creating a vSph

 In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.](../../../../../pages-for-subheaders/vsphere-cloud-provider.md)

- [Prerequisites](#prerequisites)
- [Creating a StorageClass](#creating-a-storageclass)
- [Creating a Workload with a vSphere Volume](#creating-a-workload-with-a-vsphere-volume)
- [Verifying Persistence of the Volume](#verifying-persistence-of-the-volume)
- [Why to Use StatefulSets Instead of Deployments](#why-to-use-statefulsets-instead-of-deployments)

 ### Prerequisites

@@ -7,18 +7,8 @@ This guide will show you how to install and use [Kubernetes cluster-autoscaler](

 We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.

- [Prerequisites](#prerequisites)
- [1. Create a Custom Cluster](#1-create-a-custom-cluster)
- [2. Configure the Cloud Provider](#2-configure-the-cloud-provider)
- [3. Deploy Nodes](#3-deploy-nodes)
- [4. Install cluster-autoscaler](#4-install-cluster-autoscaler)
-  - [Parameters](#parameters)
-  - [Deployment](#deployment)
- [Testing](#testing)
-  - [Generating Load](#generating-load)
-  - [Checking Scale](#checking-scale)

-# Prerequisites
+## Prerequisites

 These elements are required to follow this guide:

@@ -11,26 +11,8 @@ If you want to manage the _cluster_ and not individual nodes, see [Editing Clust

 :::

-This section covers the following topics:

- [Node options available for each cluster creation option](#node-options-available-for-each-cluster-creation-option)
-  - [Nodes hosted by an infrastructure provider](#nodes-hosted-by-an-infrastructure-provider)
-  - [Nodes provisioned by hosted Kubernetes providers](#nodes-provisioned-by-hosted-kubernetes-providers)
-  - [Registered nodes](#registered-nodes)
- [Managing and editing individual nodes](#managing-and-editing-individual-nodes)
- [Viewing a node in the Rancher API](#viewing-a-node-in-the-rancher-api)
- [Deleting a node](#deleting-a-node)
- [Scaling nodes](#scaling-nodes)
- [SSH into a node hosted by an infrastructure provider](#ssh-into-a-node-hosted-by-an-infrastructure-provider)
- [Cordoning a node](#cordoning-a-node)
- [Draining a node](#draining-a-node)
-  - [Aggressive and safe draining options](#aggressive-and-safe-draining-options)
-  - [Grace period](#grace-period)
-  - [Timeout](#timeout)
-  - [Drained and cordoned state](#drained-and-cordoned-state)
- [Labeling a node to be ignored by Rancher](#labeling-a-node-to-be-ignored-by-rancher)
-
-# 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.

@@ -71,7 +53,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:

@@ -82,11 +64,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 **⋮** 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.

@@ -98,11 +80,11 @@ If your cluster is hosted by an infrastructure provider, and you want to scale y

 :::

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

@@ -117,11 +99,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.

@@ -170,7 +152,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.

@@ -14,18 +14,9 @@ As of Rancher v2.6, projects are de-emphasized on the UI because it is no longer

 :::

-This section describes how projects and namespaces work with Rancher. It covers the following topics:
+This section describes how projects and namespaces work with Rancher.

- [About namespaces](#about-namespaces)
- [About projects](#about-projects)
-  - [The cluster's default project](#the-cluster-s-default-project)
-  - [The system project](#the-system-project)
- [Project authorization](#project-authorization)
- [Pod security policies](#pod-security-policies)
- [Creating projects](#creating-projects)
- [Switching between clusters and projects](#switching-between-clusters-and-projects)
-
-# About Namespaces
+## About Namespaces

 A namespace is a concept introduced by Kubernetes. According to the [official Kubernetes documentation on namespaces,](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)

@@ -67,7 +58,7 @@ If your permissions are restricted to the project level, it is better to [create

 If a standard user is a project owner, the user will be able to create namespaces within that project. The Rancher UI will prevent that user from creating namespaces outside the scope of the projects they have access to. 

-# About Projects
+## About Projects

 In terms of hierarchy:

@@ -117,18 +108,18 @@ In RKE clusters where the project network isolation option is enabled, the `syst

 :::

-# Project Authorization
+## Project Authorization

 Standard users are only authorized for project access in two situations:

 - An administrator, cluster owner or cluster member explicitly adds the standard user to the project's **Members** tab.
 - Standard users can access projects that they create themselves.

-# Pod Security Policies
+## Pod Security Policies

 Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) at the project level in addition to the cluster level. However, as a best practice, we recommend applying Pod Security Policies at the cluster level.

-# Creating Projects
+## Creating Projects

 This section describes how to create a new project with a name and with optional pod security policy, members, and resource quotas.

@@ -13,7 +13,7 @@ weight: 2043

    - OR, apply the following YAML:

-    ```
+    ```yaml
    rancher_kubernetes_engine_config:
      services:
        kube_api:
@@ -5,16 +5,8 @@ weight: 9

 If you previously enabled Monitoring, Alerting, or Notifiers in Rancher before v2.5, there is no automatic upgrade path for switching to the new monitoring/alerting solution. Before deploying the new monitoring solution via Cluster Explore, you will need to disable and remove all existing custom alerts, notifiers and monitoring installations for the whole cluster and in all projects.

- [Monitoring Before Rancher v2.5](#monitoring-before-rancher-v2-5)
- [Monitoring and Alerting via Cluster Explorer in Rancher v2.5](#monitoring-and-alerting-via-cluster-explorer-in-rancher-v2-5)
- [Changes to Role-based Access Control](#changes-to-role-based-access-control)
- [Migrating from Monitoring V1 to Monitoring V2](#migrating-from-monitoring-v1-to-monitoring-v2)
-  - [Migrating Grafana Dashboards](#migrating-grafana-dashboards)
-  - [Migrating Alerts](#migrating-alerts)
-  - [Migrating Notifiers](#migrating-notifiers)
-  - [Migrating for RKE Template Users](#migrating-for-rke-template-users)

-# Monitoring Before Rancher v2.5
+## Monitoring Before Rancher v2.5

 As of v2.2.0, the global view in the legacy Rancher UI allowed users to enable Monitoring & Alerting V1 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) independently within a cluster. 

@@ -24,7 +16,7 @@ Monitoring V1 could be configured on both a cluster-level and on a project-level

 When Alerts or Notifiers are enabled, Alerting V1 deploys [Prometheus Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) and a set of Rancher controllers onto a cluster that allows users to define alerts and configure alert-based notifications via Email, Slack, PagerDuty, etc. Users can choose to create different types of alerts depending on what needs to be monitored (e.g. System Services, Resources, CIS Scans, etc.); however, PromQL Expression-based alerts can only be created if Monitoring V1 is enabled.

-# Monitoring and Alerting via Cluster Explorer in Rancher 2.5
+## Monitoring and Alerting via Cluster Explorer in Rancher 2.5

 As of v2.5.0, Rancher's Cluster Explorer now allows users to enable Monitoring & Alerting V2 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) together within a cluster. 

@@ -34,13 +26,13 @@ Monitoring V2 can only be configured on the cluster level. Project-level monitor

 For more information on how to configure Monitoring & Alerting V2, see [this page.](../../../pages-for-subheaders/monitoring-v2-configuration-guides.md)

-# Changes to Role-based Access Control
+## Changes to Role-based Access Control

 Project owners and members no longer get access to Grafana or Prometheus by default. If view-only users had access to Grafana, they would be able to see data from any namespace. For Kiali, any user can edit things they don’t own in any namespace.

 For more information about role-based access control in `rancher-monitoring`, refer to [this page.](../../../explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md)

-# Migrating from Monitoring V1 to Monitoring V2
+## Migrating from Monitoring V1 to Monitoring V2

 While there is no automatic migration available, it is possible to manually migrate custom Grafana dashboards and alerts that were created in Monitoring V1 to Monitoring V2.

@@ -3,10 +3,8 @@ title: Enable Prometheus Federator
 weight: 1
 ---

- [Requirements](#requirements)
- [Install the Prometheus Federator Application](#install-the-prometheus-federator-application)

-# Requirements
+## Requirements

 By default, Prometheus Federator is configured and intended to be deployed alongside [rancher-monitoring](https://rancher.com/docs/rancher/v2.6/en/monitoring-alerting/), which deploys Prometheus Operator alongside a Cluster Prometheus that each Project Monitoring Stack is configured to federate namespace-scoped metrics from by default.

@@ -18,7 +16,7 @@ The default configuration should already be compatible with your rancher-monitor
 - [Configure rancher-monitoring to only watch for resources created by the Helm chart itself](#configure-rancher-monitoring-to-only-watch-for-resources-created-by-the-helm-chart-itself).
 - [Increase the CPU / memory limits of the Cluster Prometheus](#increase-the-cpu--memory-limits-of-the-cluster-prometheus).

-## Ensure the cattle-monitoring-system namespace is placed into the System Project (or a similarly locked down Project that has access to other Projects in the cluster)
+### Ensure the cattle-monitoring-system namespace is placed into the System Project (or a similarly locked down Project that has access to other Projects in the cluster)

 ![Select Projects-Namespaces](/img/install-in-system-project.png)

@@ -37,7 +35,7 @@ Prometheus Operator's security model expects that the namespace it is deployed i

        ![Move to a New Project](/img/move-to-new-project.png)

-## Configure rancher-monitoring to only watch for resources created by the Helm chart itself
+### Configure rancher-monitoring to only watch for resources created by the Helm chart itself

 Since each Project Monitoring Stack will watch the other namespaces and collect additional custom workload metrics or dashboards already, it's recommended to configure the following settings on all selectors to ensure that the Cluster Prometheus Stack only monitors resources created by the Helm Chart itself:

@@ -61,7 +59,7 @@ If you don't want to allow users to be able to create ServiceMonitors and PodMon

 :::

-## Increase the CPU / memory limits of the Cluster Prometheus
+### Increase the CPU / memory limits of the Cluster Prometheus

 Depending on a cluster's setup, it's generally recommended to give a large amount of dedicated memory to the Cluster Prometheus to avoid restarts due to out-of-memory errors (OOMKilled) usually caused by churn created in the cluster that causes a large number of high cardinality metrics to be generated and ingested by Prometheus within one block of time. This is one of the reasons why the default Rancher Monitoring stack expects around 4GB of RAM to be able to operate in a normal-sized cluster. However, when introducing Project Monitoring Stacks that are all sending `/federate` requests to the same Cluster Prometheus and are reliant on the Cluster Prometheus being "up" to federate that system data on their namespaces, it's even more important that the Cluster Prometheus has an ample amount of CPU / memory assigned to it to prevent an outage that can cause data gaps across all Project Prometheis in the cluster.

@@ -71,7 +69,7 @@ There are no specific recommendations on how much memory the Cluster Prometheus

 :::

-# Install the Prometheus Federator Application
+## Install the Prometheus Federator Application

 1. Click **☰ > Cluster Management**.
 1. Go to the cluster that you want to install Prometheus Federator and click **Explore**.
@@ -3,9 +3,6 @@ title: Setting up Prometheus Federator for a Workload
 weight: 4
 ---

- [Display CPU and Memory Metrics for a Workload](#display-cpu-and-memory-metrics-for-a-workload)
- [Setting up Metrics Beyond CPU and Memory](#setting-up-metrics-beyond-cpu-and-memory)
-<!-- - [Custom Metrics](#custom-metrics) -->

 ### Display CPU and Memory Metrics for a Workload

@@ -3,8 +3,6 @@ title: Setting up Monitoring for a Workload
 weight: 4
 ---

- [Display CPU and Memory Metrics for a Workload](#display-cpu-and-memory-metrics-for-a-workload)
- [Setting up Metrics Beyond CPU and Memory](#setting-up-metrics-beyond-cpu-and-memory)

 If you only need CPU and memory time series for the workload, you don't need to deploy a ServiceMonitor or PodMonitor because the monitoring application already collects metrics data on resource usage by default.

@@ -13,7 +13,7 @@ This section assumes familiarity with how monitoring components work together. F

 :::

-# About the Alertmanager Custom Resource
+## About the Alertmanager Custom Resource

 By default, Rancher Monitoring deploys a single Alertmanager onto a cluster that uses a default Alertmanager Config Secret.

@@ -9,20 +9,6 @@ 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.

-This section covers the following topics:
-
- [How snapshots work](#how-snapshots-work)
- [Configuring recurring snapshots](#configuring-recurring-snapshots)
- [One-time snapshots](#one-time-snapshots)
- [Snapshot backup targets](#snapshot-backup-targets)
-  - [Local backup target](#local-backup-target)
-  - [S3 backup target](#s3-backup-target)
-  - [Using a custom CA certificate for S3](#using-a-custom-ca-certificate-for-s3)
-  - [IAM Support for storing snapshots in S3](#iam-support-for-storing-snapshots-in-s3)
- [Viewing available snapshots](#viewing-available-snapshots)
- [Safe timestamps](#safe-timestamps)
- [Enabling snapshot features for clusters created before Rancher v2.2.0](#enabling-snapshot-features-for-clusters-created-before-rancher-v2-2-0)
-
 # How Snapshots Work

 ### Snapshot Components
@@ -9,13 +9,6 @@ Rancher recommends enabling the [ability to set up recurring snapshots of etcd](

 Clusters can also be restored to a prior Kubernetes version and cluster configuration.

-This section covers the following topics:
-
- [Viewing Available Snapshots](#viewing-available-snapshots)
- [Restoring a Cluster from a Snapshot](#restoring-a-cluster-from-a-snapshot)
- [Recovering etcd without a Snapshot](#recovering-etcd-without-a-snapshot)
- [Enabling snapshot features for clusters created before Rancher v2.2.0](#enabling-snapshot-features-for-clusters-created-before-rancher-v2-2-0)
-
 ## Viewing Available Snapshots

 The list of all available snapshots for the cluster is available.
@@ -7,20 +7,12 @@ Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters.

 Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.

- [Architecture](#architecture)
- [Accessing Fleet in the Rancher UI](#accessing-fleet-in-the-rancher-ui)
- [Windows Support](#windows-support)
- [GitHub Repository](#github-repository)
- [Using Fleet Behind a Proxy](#using-fleet-behind-a-proxy)
- [Helm Chart Dependencies](#helm-chart-dependencies)
- [Troubleshooting](#troubleshooting)
- [Documentation](#documentation)

-# Architecture
+## Architecture

 For information about how Fleet works, see [this page.](../../../explanations/integrations-in-rancher/fleet-gitops-at-scale/architecture.md)

-# Accessing Fleet in the Rancher UI
+## Accessing Fleet in the Rancher UI

 Fleet comes preinstalled in Rancher and is managed by the **Continous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting/).

@@ -41,27 +33,27 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:

 1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.

-# Windows Support
+## Windows Support

 For details on support for clusters with Windows nodes, see [this page.](../../../explanations/integrations-in-rancher/fleet-gitops-at-scale/windows-support.md)


-# GitHub Repository
+## GitHub Repository

 The Fleet Helm charts are available [here.](https://github.com/rancher/fleet/releases/latest)


-# Using Fleet Behind a Proxy
+## Using Fleet Behind a Proxy

 For details on using Fleet behind a proxy, see [this page.](../../../explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md)

-# Helm Chart Dependencies
+## Helm Chart Dependencies

 In order for Helm charts with dependencies to deploy successfully, you must run a manual command (as listed below), as it is up to the user to fulfill the dependency list. If you do not do this and proceed to clone your repository and run `helm install`, your installation will fail because the dependencies will be missing.

 The Helm chart in the git repository must include its dependencies in the charts subdirectory. You must either manually run `helm dependencies update $chart` OR run `helm dependencies build $chart` locally, then commit the complete charts directory to your git repository. Note that you will update your commands with the applicable parameters.

-# Troubleshooting
+## Troubleshooting

 ---
 * **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator](../backup-restore-and-disaster-recovery/back-up-rancher.md#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place.
@@ -71,6 +63,6 @@ By default, user-defined secrets are not backed up in Fleet. It is necessary to

 ---

-# Documentation
+## Documentation

 The Fleet documentation is at [https://fleet.rancher.io/.](https://fleet.rancher.io/)
@@ -11,22 +11,7 @@ Any Helm charts from a global catalog can be used to deploy and manage multi-clu

 After creating a multi-cluster application, you can program a global DNS entry to make it easier to access the application.

- [Prerequisites](#prerequisites)
- [Launching a multi-cluster app](#launching-a-multi-cluster-app)
- [Multi-cluster app configuration options](#multi-cluster-app-configuration-options)
-  - [Targets](#targets)
-  - [Upgrades](#upgrades)
-  - [Roles](#roles)
- [Application configuration options](#application-configuration-options)
-  - [Using a questions.yml file](#using-a-questions-yml-file)
-  - [Key value pairs for native Helm charts](#key-value-pairs-for-native-helm-charts)
-  - [Members](#members)
-  - [Overriding application configuration options for specific projects](#overriding-application-configuration-options-for-specific-projects)
- [Upgrading multi-cluster app roles and projects](#upgrading-multi-cluster-app-roles-and-projects)
- [Multi-cluster application management](#multi-cluster-application-management)
- [Deleting a multi-cluster application](#deleting-a-multi-cluster-application)
-
-# Prerequisites
+## Prerequisites

 ### Permissions

@@ -43,7 +28,7 @@ Because multi-cluster apps were deprecated and replaced with Fleet in Rancher v2
 1. Click **Feature Flags**.
 1. Go to the `legacy` feature flag and click **Activate**.

-# Launching a Multi-Cluster App
+## Launching a Multi-Cluster App

 1. In the upper left corner, click **☰ > Multi-cluster Apps**.
 1. Click **Launch**.
@@ -58,7 +43,7 @@ Because multi-cluster apps were deprecated and replaced with Fleet in Rancher v2

 **Result**: Your application is deployed to your chosen namespace. You can view the application status from the project's:

-# Multi-cluster App Configuration Options
+## Multi-cluster App Configuration Options

 Rancher has divided the configuration option for the multi-cluster application into several sections.

@@ -94,7 +79,7 @@ There are some applications like _Grafana_ or _Datadog_ that require access to s

 :::

-# Application Configuration Options
+## Application Configuration Options

 For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://helm.sh/docs/intro/using_helm/#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm.

@@ -146,7 +131,7 @@ The ability to use the same configuration to deploy the same application across

 	- **Answer**: Enter the answer that you want to be used instead.

-# Upgrading Multi-Cluster App Roles and Projects
+## Upgrading Multi-Cluster App Roles and Projects

 - **Changing Roles on an existing Multi-Cluster app**
 The creator and any users added with the access-type "owner" to a multi-cluster app, can upgrade its Roles. When adding a new Role, we check if the user has that exact role in all current target projects. These checks allow the same relaxations for global admins, cluster owners and project-owners as described in the installation section for the field `Roles`.
@@ -156,7 +141,7 @@ The creator and any users added with the access-type "owner" to a multi-cluster
 2. We do not do these membership checks when removing target projects. This is because the caller's permissions could have with respect to the target project, or the project could have been deleted and hence the caller wants to remove it from targets list.


-# Multi-Cluster Application Management
+## Multi-Cluster Application Management

 One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of management. Multi-cluster applications can be cloned, upgraded or rolled back.

@@ -174,7 +159,7 @@ The `legacy` feature flag needs to be enabled.
   * **Upgrade**: Upgrade your multi-cluster application to change some part of the configuration. When performing an upgrade for multi-cluster application, the [upgrade strategy](#upgrades) can be modified if you have the correct [access type](#members).
   * **Rollback**: Rollback your application to a specific version. If after an upgrade, there are issues for your multi-cluster application for one or more of your [targets](#targets), Rancher has stored up to 10 versions of the multi-cluster application. Rolling back a multi-cluster application reverts the application for **all** target clusters and projects, not just the targets(s) affected by the upgrade issue.

-# Deleting a Multi-Cluster Application
+## Deleting a Multi-Cluster Application

 :::note Prerequisite:

@@ -11,15 +11,7 @@ For a complete walkthrough of developing charts, see the [Chart Template Develop

 :::

- [Chart types](#chart-types)
-  - [Helm charts](#helm-charts)
-  - [Rancher charts](#rancher-charts)
- [Chart directory structure](#chart-directory-structure)
- [Additional Files for Rancher Charts](#additional-files-for-rancher-charts)
-  - [questions.yml](#questions-yml)
-  - [Min/Max Rancher versions](#min-max-rancher-versions)
-  - [Question variable reference](#question-variable-reference)
- [Tutorial: Example Custom Chart Creation](#tutorial-example-custom-chart-creation)
+

 # Chart Types

@@ -11,20 +11,13 @@ 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

-Configuring an Amazon NLB is a multistage process:

-1. [Create Target Groups](#1-create-target-groups)
-2. [Register Targets](#2-register-targets)
-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.

@@ -42,7 +35,7 @@ Health checks are handled differently based on the Ingress. For details, refer t

 :::

-### Target Group (TCP port 443)
+#### Target Group (TCP port 443)

 Configure the first target group according to the table below.

@@ -67,7 +60,7 @@ Health check settings:

 Click **Create target group** to create the second target group, regarding TCP port 80.

-### Target Group (TCP port 80)
+#### Target Group (TCP port 80)

 Configure the second target group according to the table below.

@@ -91,7 +84,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.

@@ -115,7 +108,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).

@@ -11,7 +11,7 @@ The recommended infrastructure for the Rancher-only Kubernetes cluster differs d

 These nodes must be in the same region. You may place these servers in separate availability zones (datacenter).

-::
+:::

 To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:

@@ -36,6 +36,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx.
    :::

    <figcaption>Example NGINX config</figcaption>
+    
    ```
    worker_processes 4;
    worker_rlimit_nofile 40000;
@@ -5,7 +5,7 @@ weight: 1

 There are three roles that can be assigned to nodes: `etcd`, `controlplane` and `worker`. 

-# Separating Worker Nodes from Nodes with Other Roles
+## Separating Worker Nodes from Nodes with Other Roles

 When designing your cluster(s), you have two options:

@@ -21,7 +21,7 @@ Therefore, each node should have one of the following role configurations:
  * Both `etcd` and `controlplane`
  * `worker`

-# Recommended Number of Nodes with Each Role
+## Recommended Number of Nodes with Each Role

 The cluster should have:

@@ -69,6 +69,6 @@ You may have noticed that our [Kubernetes Install](../../../../pages-for-subhead
 * It maintains multiple instances of the master components by having multiple `controlplane` nodes.
 * No other workloads than Rancher itself should be created on this cluster.

-# References
+## References

 * [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components)
@@ -10,7 +10,7 @@ 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.

@@ -20,7 +20,7 @@ Nodes with the `etcd` role are shown as `Unschedulable` in the UI, meaning no po

 :::

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

@@ -42,10 +42,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)
@@ -18,7 +18,7 @@ If you are using Calico,
 1. Click **☰ > Cluster Management**.
 1. On the **Clusters** page, go to the custom cluster and click **⋮ > Edit YAML.* Enter the following configuration:

-    ```
+    ```yaml
    rancher_kubernetes_engine_config:
      cloud_provider:
        name: gce
@@ -40,7 +40,7 @@ If you are using Canal or Flannel,
 1. Click **☰ > Cluster Management**.
 1. On the **Clusters** page, go to the custom cluster and click **⋮ > Edit YAML.* Enter the following configuration:

-    ```
+    ```yaml
    rancher_kubernetes_engine_config:
      cloud_provider: 
        name: gce
@@ -7,14 +7,8 @@ Creating virtual machines in a repeatable and reliable fashion can often be diff

 In order to leverage the template to create new VMs, Rancher has some [specific requirements](#requirements) that the VM must have pre-installed. After you configure the VM with these requirements, you will next need to [prepare the VM](#preparing-your-vm) before [creating the template](#creating-a-template). Finally, once preparation is complete, the VM can be [converted to a template](#converting-to-a-template) and [moved into a content library](#moving-to-a-content-library), ready for Rancher node pool usage.

- [Requirements](#requirements)
- [Creating a Template](#creating-a-template)
- [Preparing Your VM](#preparing-your-vm)
- [Converting to a Template](#converting-to-a-template)
- [Moving to a content library](#moving-to-a-content-library)
- [Other Resources](#other-resources)

-# Requirements
+## Requirements

 There is specific tooling required for both Linux and Windows VMs to be usable by the vSphere node driver. The most critical dependency is [cloud-init](https://cloud-init.io/) for Linux and [cloudbase-init](https://cloudbase.it/cloudbase-init/) for Windows. Both of these are used for provisioning the VMs by configuring the hostname and by setting up the SSH access and the default Rancher user. Users can add additional content to these as desired if other configuration is needed. In addition, other requirements are listed below for reference.

@@ -59,16 +53,16 @@ The list of packages that need to be installed on the template is as follows:

 :::

-# Creating a Template
+## Creating a Template

 You may either manually create your VM or you can utilize [other alternatives](#alternatives-to-manual-creation) to create your VM.

-## Manual Creation
+### Manual Creation
 1. Manually create your VM by following [these instructions](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-AE8AFBF1-75D1-4172-988C-378C35C9FAF2.html) from VMware. Once you have a VM running, you can manually install the dependencies listed above to configure the VM correctly for the vSphere node driver.
 2. Customize as needed based on your specific environment and requirements.
 3. Proceed with the final preparation before creating your template.

-## Alternatives to Manual Creation
+### Alternatives to Manual Creation

 Other alternative options to create VMs are listed below:

@@ -79,17 +73,17 @@ Other alternative options to create VMs are listed below:

 Packer is a frequently-used alternative. Refer to this [reference](https://github.com/vmware-samples/packer-examples-for-vsphere) for examples of its usage with vSphere.

-# Preparing Your VM
+## Preparing Your VM

 After creating a VM with all the required dependencies (and any additional required items), you must perform the most critical step next: preparing the VM to be turned into a template. This preparation will reset critical data such as the VM hostname, IPs, etc., to prevent that information from being brought into a new VM. If you fail to perform this step, you could create a VM with the same hostname, IP address, etc.

 Note that these preparatory steps differ between Linux and Windows.

-## Linux Preparation
+### Linux Preparation

 The commands below will reset your VM in Linux:

-```Bash
+```bash
 # Cleaning logs.
 if [ -f /var/log/audit/audit.log ]; then
  cat /dev/null > /var/log/audit/audit.log
@@ -132,7 +126,7 @@ hostnamectl set-hostname localhost
 cloud-init clean -s -l
 ```

-## Windows Preparation
+### Windows Preparation

 Windows has a utility called [sysprep](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation) that is used to generalize an image and reset the same items listed above for Linux. The command is as follows:

@@ -140,7 +134,7 @@ Windows has a utility called [sysprep](https://docs.microsoft.com/en-us/windows-
 sysprep.exe /generalize /shutdown /oobe
 ```

-# Converting to a Template
+## Converting to a Template

 1. Shut down and stop the VM.
 2. Right-click on the VM in the inventory list and select **Template**.
@@ -150,7 +144,7 @@ sysprep.exe /generalize /shutdown /oobe

 For additional information on converting a VM to a template, see the [VMware guide](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-5B3737CC-28DB-4334-BD18-6E12011CDC9F.html).

-# Moving to a Content library
+## Moving to a Content library

 Rancher has the ability to use templates provided by a content library. Content libraries store and manage content within vSphere, and they also offer the ability to publish and share that content.

@@ -159,7 +153,7 @@ Below are some helpful links on content libraries:
 * [Create a content library](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-2A0F1C13-7336-45CE-B211-610D39A6E1F4.html)
 * [Clone the template to the content library](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-AC1545F0-F8BA-4CD2-96EB-21B3DFAA1DC1.html)

-# Other Resources
+## Other Resources

 Here is a list of additional resources that may be useful:

@@ -47,7 +47,7 @@ The free ESXi license does not support API access. The vSphere servers must have

 If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate ESXi hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes.

-# Creating a vSphere Cluster
+## Creating a vSphere Cluster

 The a vSphere cluster is created in Rancher depends on the Rancher version.

@@ -104,7 +104,7 @@ You can access your cluster after its state is updated to **Active**.
 - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces


-# 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:

@@ -10,29 +10,30 @@ In order to have the Azure platform create the required storage resources, follo
 1.  [Configure the Azure cloud provider.](../set-up-cloud-providers/other-cloud-providers/azure.md)
 1.  Configure `kubectl` to connect to your cluster.
 1.  Copy the `ClusterRole` and `ClusterRoleBinding` manifest for the service account:
-
-        ---
-        apiVersion: rbac.authorization.k8s.io/v1
+      ```yml
+      ---
+      apiVersion: rbac.authorization.k8s.io/v1
+      kind: ClusterRole
+      metadata:
+        name: system:azure-cloud-provider
+      rules:
+      - apiGroups: ['']
+        resources: ['secrets']
+        verbs:     ['get','create']
+      ---
+      apiVersion: rbac.authorization.k8s.io/v1
+      kind: ClusterRoleBinding
+      metadata:
+        name: system:azure-cloud-provider
+      roleRef:
        kind: ClusterRole
-        metadata:
-          name: system:azure-cloud-provider
-        rules:
-        - apiGroups: ['']
-          resources: ['secrets']
-          verbs:     ['get','create']
-        ---
-        apiVersion: rbac.authorization.k8s.io/v1
-        kind: ClusterRoleBinding
-        metadata:
-          name: system:azure-cloud-provider
-        roleRef:
-          kind: ClusterRole
-          apiGroup: rbac.authorization.k8s.io
-          name: system:azure-cloud-provider
-        subjects:
-        - kind: ServiceAccount
-          name: persistent-volume-binder
-          namespace: kube-system
+        apiGroup: rbac.authorization.k8s.io
+        name: system:azure-cloud-provider
+      subjects:
+      - kind: ServiceAccount
+        name: persistent-volume-binder
+        namespace: kube-system
+      ```

 1.  Create these in your cluster using one of the follow command.

@@ -7,23 +7,6 @@ weight: 3

 This document covers how end users can migrate their Windows workloads from RKE1 to RKE2.

- [RKE1 Windows Scheduling](#rke1-windows-scheduling)
- [RKE2 Windows Scheduling](#rke2-windows-scheduling)
- [Example Migrations](#example-migrations)
-  - [RKE1 to RKE2 Windows Workload](#rke1-to-rke2-windows-workload)
-  - [RKE1 Windows Cluster Linux-Only Deployment](#rke1-windows-cluster-linux-only-deployment)
- [RKE1 Windows-Supported Windows Server Versions](#rke1-windows-supported-windows-server-versions)
-  - [Long-Term Servicing Channel (LTSC)](#long-term-servicing-channel-ltsc)
-  - [Semi-Annual Channel (SAC)](#semi-annual-channel-sac)
- [RKE2 Windows-Supported Windows Server Versions](#rke2-windows-supported-windows-server-versions)
-  - [Long-Term Servicing Channel in RKE2](#long-term-servicing-channel-in-rke2)
- [Kubernetes Version Support](#kubernetes-version-support)
-  - [Rancher 2.5 vs. Rancher 2.6 Support Matrix for Windows Clusters](#rancher-2-5-vs-rancher-2-6-support-matrix-for-windows-clusters)
-  - [Rancher 2.5 vs. Rancher 2.6 Supported Kubernetes Versions for Provisioning RKE1 and RKE2 Windows Clusters](#rancher-2-5-vs-rancher-2-6-supported-kubernetes-versions-for-provisioning-rke1-and-rke2-windows-clusters)
- [Guiding Migrations of Workloads to RKE2 Windows](#guiding-migrations-of-workloads-to-rke2-windows)
-  - [In-Place Upgrade of Rancher 2.5](#in-place-upgrade-of-rancher-2-5)
-  - [Migrating Windows Workloads to a new Rancher environment](#migrating-windows-workloads-to-a-new-rancher-environment)
-
 ## RKE1 Windows Scheduling

 RKE1 Windows workload scheduling is based on taints and tolerations.
@@ -14,14 +14,7 @@ If Rancher is installed on a high-availability Kubernetes cluster, the Rancher s

 :::

-Make sure the nodes for the Rancher server fulfill the following requirements:
-
- [Operating systems and container runtime requirements](#operating-systems-and-container-runtime-requirements)
- [Hardware Requirements](#hardware-requirements)
- [Networking Requirements](#networking-requirements)
- [Optional: Security Considerations](#optional-security-considerations)
-
-# Operating Systems and Container Runtime Requirements
+## Operating Systems and Container Runtime Requirements

 Rancher should work with any modern Linux distribution and any modern Docker version. Linux is required for the etcd and controlplane nodes of all downstream clusters. Worker nodes may run Linux or [Windows Server.](#windows-nodes)

@@ -107,7 +100,7 @@ Nodes with Windows Server must run Docker Enterprise Edition.

 Windows nodes can be used for worker nodes only. See [Configuring Custom Clusters for Windows](../../../pages-for-subheaders/use-windows-clusters.md)

-# Hardware Requirements
+## Hardware Requirements

 The hardware requirements for nodes with the `worker` role mostly depend on your workloads. The minimum to run the Kubernetes node components is 1 CPU (core) and 1GB of memory.

@@ -117,7 +110,7 @@ For hardware recommendations for large Kubernetes clusters, refer to the officia

 For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation.](https://etcd.io/docs/v3.4.0/op-guide/hardware/)

-# Networking Requirements
+## Networking Requirements

 For a production cluster, we recommend that you restrict traffic by opening only the ports defined in the port requirements below.

@@ -127,7 +120,7 @@ For a breakdown of the port requirements for etcd nodes, controlplane nodes, and

 Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements](../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#downstream-kubernetes-cluster-nodes).

-# Optional: Security Considerations
+## Optional: Security Considerations

 If you want to provision a Kubernetes cluster that is compliant with the CIS (Center for Internet Security) Kubernetes Benchmark, we recommend to following our hardening guide to configure your nodes before installing Kubernetes.

@@ -7,15 +7,8 @@ The cluster registration feature replaced the feature to import clusters.

 The control that Rancher has to manage a registered cluster depends on the type of cluster. For details, see [Management Capabilities for Registered Clusters.](#management-capabilities-for-registered-clusters)

- [Prerequisites](#prerequisites)
- [Registering a Cluster](#registering-a-cluster)
- [Management Capabilities for Registered Clusters](#management-capabilities-for-registered-clusters)
- [Configuring K3s Cluster Upgrades](#configuring-k3s-cluster-upgrades)
- [Debug Logging and Troubleshooting for Registered K3s Clusters](#debug-logging-and-troubleshooting-for-registered-k3s-clusters)
- [Authorized Cluster Endpoint Support for RKE2 and K3s Clusters](#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters)
- [Annotating Registered Clusters](#annotating-registered-clusters)

-# Prerequisites
+## Prerequisites

 ### Kubernetes Node Roles

@@ -45,7 +38,7 @@ If you are registering a K3s cluster, make sure the `cluster.yml` is readable. I

 EKS clusters must have at least one managed node group to be imported into Rancher or provisioned from Rancher successfully.

-# Registering a Cluster
+## Registering a Cluster

 1. Click **☰ > Cluster Management**.
 1. On the **Clusters** page, **Import Existing**.
@@ -121,7 +114,7 @@ resource "rancher2_cluster" "my-eks-to-import" {
 }
 ```

-# Management Capabilities for Registered Clusters
+## Management Capabilities for Registered Clusters

 The control that Rancher has to manage a registered cluster depends on the type of cluster.

@@ -160,7 +153,7 @@ When you delete an EKS cluster or GKE cluster that was created in Rancher, the c

 The capabilities for registered clusters are listed in the table on [this page.](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)

-# Configuring K3s Cluster Upgrades
+## Configuring K3s Cluster Upgrades

 :::tip

@@ -177,7 +170,7 @@ In the K3s documentation, controlplane nodes are called server nodes. These node

 Also in the K3s documentation, nodes with the worker role are called agent nodes. Any workloads or pods that are deployed in the cluster can be scheduled to these nodes by default.

-# Debug Logging and Troubleshooting for Registered K3s Clusters
+## Debug Logging and Troubleshooting for Registered K3s Clusters

 Nodes are upgraded by the system upgrade controller running in the downstream cluster. Based on the cluster configuration, Rancher deploys two [plans](https://github.com/rancher/system-upgrade-controller#example-upgrade-plan) to upgrade K3s nodes: one for controlplane nodes and one for workers. The system upgrade controller follows the plans and upgrades the nodes.

@@ -199,7 +192,7 @@ If the cluster becomes stuck in upgrading, restart the `system-upgrade-controlle

 To prevent issues when upgrading, the [Kubernetes upgrade best practices](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) should be followed.

-# Authorized Cluster Endpoint Support for RKE2 and K3s Clusters
+## Authorized Cluster Endpoint Support for RKE2 and K3s Clusters

 _Available as of v2.6.3_

@@ -218,29 +211,31 @@ Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and
 ###### **Manual steps to be taken on the control plane of each downstream cluster to enable ACE:**

 1. Create a file at `/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml` with the following contents:
-
-        apiVersion: v1
-        kind: Config
-        clusters:
-        - name: Default
-          cluster:
-            insecure-skip-tls-verify: true
-            server: http://127.0.0.1:6440/v1/authenticate
-        users:
-        - name: Default
-          user:
-            insecure-skip-tls-verify: true
-        current-context: webhook
-        contexts:
-        - name: webhook
-          context:
-            user: Default
-            cluster: Default
+    ```yaml
+    apiVersion: v1
+    kind: Config
+    clusters:
+    - name: Default
+      cluster:
+        insecure-skip-tls-verify: true
+        server: http://127.0.0.1:6440/v1/authenticate
+    users:
+    - name: Default
+      user:
+        insecure-skip-tls-verify: true
+    current-context: webhook
+    contexts:
+    - name: webhook
+      context:
+        user: Default
+        cluster: Default
+    ```

 1. Add the following to the config file (or create one if it doesn’t exist); note that the default location is `/etc/rancher/{rke2,k3s}/config.yaml`:
-
-        kube-apiserver-arg:
-            - authentication-token-webhook-config-file=/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml
+    ```yaml
+    kube-apiserver-arg:
+        - authentication-token-webhook-config-file=/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml
+    ```

 1. Run the following commands:

@@ -249,13 +244,13 @@ Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and

 1. Finally, you **must** go back to the Rancher UI and edit the imported cluster there to complete the ACE enablement. Click on **⋮ > Edit Config**, then click the **Networking** tab under Cluster Configuration. Finally, click the **Enabled** button for **Authorized Endpoint**. Once the ACE is enabled, you then have the option of entering a fully qualified domain name (FQDN) and certificate information.

-      :::note
+:::note

-      The <b>FQDN</b> field is optional, and if one is entered, it should point to the downstream cluster. Certificate information is only needed if there is a load balancer in front of the downstream cluster that is using an untrusted certificate. If you have a valid certificate, then nothing needs to be added to the <b>CA Certificates</b> field.
+The <b>FQDN</b> field is optional, and if one is entered, it should point to the downstream cluster. Certificate information is only needed if there is a load balancer in front of the downstream cluster that is using an untrusted certificate. If you have a valid certificate, then nothing needs to be added to the <b>CA Certificates</b> field.

-      :::
+:::

-# Annotating Registered Clusters
+## Annotating Registered Clusters

 For all types of registered Kubernetes clusters except for K3s Kubernetes clusters, Rancher doesn't have any information about how the cluster is provisioned or configured.

@@ -267,13 +262,13 @@ By annotating a registered cluster, it is possible to indicate to Rancher that a

 This example annotation indicates that a pod security policy is enabled:

-```
+```json
 "capabilities.cattle.io/pspEnabled": "true"
 ```

 The following annotation indicates Ingress capabilities. Note that that the values of non-primitive objects need to be JSON encoded, with quotations escaped.

-```
+```json
 "capabilities.cattle.io/ingressCapabilities": "[
  {
    "customDefaultBackend":true,
@@ -6,18 +6,8 @@ weight: 2115

 You can use Rancher to create a cluster hosted in Microsoft Azure Kubernetes Service (AKS).

- [Prerequisites in Microsoft Azure](#prerequisites-in-microsoft-azure)
- [Setting Up the Service Principal with the Azure Command Line Tool](#setting-up-the-service-principal-with-the-azure-command-line-tool)
-  - [Setting Up the Service Principal from the Azure Portal](#setting-up-the-service-principal-from-the-azure-portal)
- [1. Create the AKS Cloud Credentials](#1-create-the-aks-cloud-credentials)
- [2. Create the AKS Cluster](#2-create-the-aks-cluster)
- [Role-based Access Control](#role-based-access-control)
- [AKS Cluster Configuration Reference](#aks-cluster-configuration-reference)
- [Private Clusters](#private-clusters)
- [Syncing](#syncing)
- [Programmatically Creating AKS Clusters](#programmatically-creating-aks-clusters)

-# Prerequisites in Microsoft Azure
+## Prerequisites in Microsoft Azure

 :::caution

@@ -104,7 +94,7 @@ To give role-based access to your service principal,

 **Result:** Your service principal now has access to AKS.

-# 1. Create the AKS Cloud Credentials
+## 1. Create the AKS Cloud Credentials

 1. In the Rancher UI, click **☰ > Cluster Management**.
 1. Click **Cloud Credentials**.
@@ -113,7 +103,7 @@ To give role-based access to your service principal,
 1. Fill out the form. For help with filling out the form, see the [configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md#cloud-credentials)
 1. Click **Create**.

-# 2. Create the AKS Cluster
+## 2. Create the AKS Cluster

 Use Rancher to set up and configure your Kubernetes cluster.

@@ -127,16 +117,16 @@ Use Rancher to set up and configure your Kubernetes cluster.

 You can access your cluster after its state is updated to **Active**.

-# Role-based Access Control
+## Role-based Access Control
 When provisioning an AKS cluster in the Rancher UI, RBAC is not configurable because it is required to be enabled.

 RBAC is required for AKS clusters that are registered or imported into Rancher.

-# AKS Cluster Configuration Reference
+## AKS Cluster Configuration Reference

 For more information about how to configure AKS clusters from the Rancher UI, see the [configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md)

-# Private Clusters
+## Private Clusters

 Typically, AKS worker nodes do not get public IPs, regardless of whether the cluster is private. In a private cluster, the control plane does not have a public endpoint.

@@ -154,12 +144,12 @@ Please be aware that when registering an existing AKS cluster, the cluster might

 For more information about connecting to an AKS private cluster, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/private-clusters#options-for-connecting-to-the-private-cluster)

-# Syncing
+## Syncing

 The AKS provisioner can synchronize the state of an AKS cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md)

 For information on configuring the refresh interval, see [this section.](../../../../pages-for-subheaders/gke-cluster-configuration.md#configuring-the-refresh-interval)

-# Programmatically Creating AKS Clusters
+## Programmatically Creating AKS Clusters

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

 You can use Rancher to create a cluster hosted in Alibaba Cloud Kubernetes (ACK). Rancher has already implemented and packaged the [cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md) for ACK, but by default, this cluster driver is `inactive`. In order to launch ACK clusters, you will need to [enable the ACK cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning ACK clusters.

-# Prerequisites Outside of Rancher
+## Prerequisites Outside of Rancher

 :::caution

@@ -26,7 +26,7 @@ Deploying to ACK will incur charges.

 4. In Alibaba Cloud, create an [SSH key pair](https://www.alibabacloud.com/help/doc-detail/51793.html). This key is used to access nodes in the Kubernetes cluster.

-# Prerequisite in Rancher
+## Prerequisite in Rancher

 You will need to enable the Alibaba ACK cluster driver:

@@ -36,7 +36,7 @@ You will need to enable the Alibaba ACK cluster driver:

 When the cluster driver is finished downloading, you will be able to create Alibaba ACK clusters in Rancher.

-# Create an ACK Cluster
+## Create an ACK Cluster

 1. Click **☰ > Cluster Management**.
 1. From the **Clusters** page, click **Create**.
@@ -4,15 +4,8 @@ shortTitle: Google Kubernetes Engine
 weight: 2105
 ---

- [Prerequisites](#prerequisites)
- [Provisioning a GKE Cluster](#provisioning-a-gke-cluster)
- [Private Clusters](#private-clusters)
- [Configuration Reference](#configuration-reference)
- [Updating Kubernetes Version](#updating-kubernetes-version)
- [Syncing](#syncing)
- [Programmatically Creating GKE Clusters](#programmatically-creating-gke-clusters)

-# Prerequisites
+## Prerequisites

 Some setup in Google Kubernetes Engine is required.

@@ -39,7 +32,7 @@ To create a new project, refer to the Google cloud documentation [here.](https:/

 To get the project ID of an existing project, refer to the Google cloud documentation [here.](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects)

-# Provisioning a GKE Cluster
+## Provisioning a GKE Cluster

 :::caution

@@ -82,14 +75,14 @@ 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

-# Private Clusters
+## Private Clusters

 Private GKE clusters are supported. 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)

-# Configuration Reference
+## Configuration Reference

 For details on configuring GKE clusters in Rancher, see [this page.](../../../../pages-for-subheaders/gke-cluster-configuration.md)
-# Updating Kubernetes Version
+## Updating Kubernetes Version

 The Kubernetes version of a cluster can be upgraded to any version available in the region or zone fo the GKE cluster. Upgrading the master Kubernetes version does not automatically upgrade worker nodes. Nodes can be upgraded independently.

@@ -99,12 +92,12 @@ GKE has removed basic authentication in 1.19+. In order to upgrade a cluster to

 :::

-# Syncing
+## Syncing

 The GKE provisioner can synchronize the state of a GKE cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md)

 For information on configuring the refresh interval, see [this section.](../../../../pages-for-subheaders/gke-cluster-configuration.md#configuring-the-refresh-interval)

-# Programmatically Creating GKE Clusters
+## Programmatically Creating GKE Clusters

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

 You can use Rancher to create a cluster hosted in Huawei Cloud Container Engine (CCE). Rancher has already implemented and packaged the [cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md) for CCE, but by default, this cluster driver is `inactive`. In order to launch CCE clusters, you will need to [enable the CCE cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning CCE clusters.

-# Prerequisites in Huawei
+## Prerequisites in Huawei

 :::caution

@@ -18,7 +18,7 @@ Deploying to CCE will incur charges.

 2. Create an [Access Key ID and Secret Access Key](https://support.huaweicloud.com/en-us/usermanual-iam/en-us_topic_0079477318.html).

-# Prerequisite in Rancher
+## Prerequisite in Rancher

 You will need to enable the Huawei CCE cluster driver:

@@ -28,11 +28,11 @@ You will need to enable the Huawei CCE cluster driver:

 When the cluster driver is finished downloading, you will be able to create Huawei CCE clusters in Rancher.

-# Limitations
+## Limitations

 Huawei CCE service doesn't support the ability to create clusters with public access through their API. You are required to run Rancher in the same VPC as the CCE clusters that you want to provision.

-# Create the CCE Cluster
+## Create the CCE Cluster

 1. From the **Clusters** page, click **Create**.
 1. Click **Huawei CCE**.
@@ -53,7 +53,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

-# Huawei CCE Configuration
+## Huawei CCE Configuration

 |Settings|Description|
 |---|---|
@@ -76,7 +76,7 @@ If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, n

 :::

-# Node Configuration
+## Node Configuration

 |Settings|Description|
 |---|---|
@@ -6,7 +6,7 @@ weight: 2125

 You can use Rancher to create a cluster hosted in Tencent Kubernetes Engine (TKE). Rancher has already implemented and packaged the [cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md) for TKE, but by default, this cluster driver is `inactive`. In order to launch TKE clusters, you will need to [enable the TKE cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning TKE clusters.

-# Prerequisites in Tencent
+## Prerequisites in Tencent

 :::caution

@@ -22,7 +22,7 @@ Deploying to TKE will incur charges.

 4. Create a [SSH key pair](https://intl.cloud.tencent.com/document/product/213/6092). This key is used to access the nodes in the Kubernetes cluster.

-# Prerequisite in Rancher
+## Prerequisite in Rancher

 You will need to enable the Tencent TKE cluster driver:

@@ -32,7 +32,7 @@ You will need to enable the Tencent TKE cluster driver:

 When the cluster driver is finished downloading, you will be able to create Tencent TKE clusters in Rancher.

-# Create a TKE Cluster
+## Create a TKE Cluster

 1. From the **Clusters** page, click **Create**.

@@ -115,7 +115,7 @@ The secret has to be created in the same namespace where the workload gets deplo

 Below is an example `pod.yml` for a workload that uses an image from a private registry. In this example, the pod uses an image from Quay.io, and the .yml specifies the path to the image. The pod authenticates with the registry using credentials stored in a Kubernetes secret called `testquay`, which is specified in `spec.imagePullSecrets` in the `name` field:

-```
+```yaml
 apiVersion: v1
 kind: Pod
 metadata:
@@ -4,12 +4,6 @@ description: Ingress configuration
 weight: 9999
 ---

- [NGINX Ingress controller changes in Kubernetes v1.21](#nginx-ingress-controller-changes-in-Kubernetes-v1-21)
- [Specify a hostname to use](#specify-a-hostname-to-use)
- [Use as the default backend](#use-as-the-default-backend)
- [Certificates](#certificates)
- [Labels and Annotations](#labels-and-annotations)
-
 ### NGINX Ingress controller changes in Kubernetes v1.21

 For Kubernetes v1.21 and up, the NGINX Ingress controller no longer runs in hostNetwork but uses hostPorts for port 80 and port 443. This was done so the admission webhook can be configured to be accessed using ClusterIP so it can only be reached inside the cluster.
@@ -36,15 +36,15 @@ Deploy a workload to run an application in one or more containers.

    - **Scaling/Upgrade Policy**

-        :::note Amazon Note for Volumes:
-        
-        To mount an Amazon EBS volume:
-        
-        - In [Amazon AWS](https://aws.amazon.com/), the nodes must be in the same Availability Zone and possess IAM permissions to attach/unattach volumes.
-        
-        - The cluster must be using the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws) option. For more information on enabling this option see [Creating an Amazon EC2 Cluster](../../kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) or [Creating a Custom Cluster](../../../../pages-for-subheaders/use-existing-nodes.md).
+    :::note Amazon Note for Volumes:
+    
+    To mount an Amazon EBS volume:
+    
+    - In [Amazon AWS](https://aws.amazon.com/), the nodes must be in the same Availability Zone and possess IAM permissions to attach/unattach volumes.
+    
+    - The cluster must be using the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws) option. For more information on enabling this option see [Creating an Amazon EC2 Cluster](../../kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) or [Creating a Custom Cluster](../../../../pages-for-subheaders/use-existing-nodes.md).

-        :::
+    :::
        
 1. Click **Show Advanced Options** and configure:

@@ -26,7 +26,7 @@ The core features of RKE templates allow DevOps and security teams to:
 - Control which users can create templates
 - Require users to create clusters from a template

-# Configurable Settings
+## Configurable Settings

 RKE templates can be created in the Rancher UI or defined in YAML format. They can define all the same parameters that can be specified when you use Rancher to provision custom nodes or nodes from an infrastructure provider:

@@ -42,7 +42,7 @@ RKE templates can be created in the Rancher UI or defined in YAML format. They c

 The [add-on section](#add-ons) of an RKE template is especially powerful because it allows a wide range of customization options.

-# Scope of RKE Templates
+## Scope of RKE Templates

 RKE templates are supported for Rancher-provisioned clusters. The templates can be used to provision custom clusters or clusters that are launched by an infrastructure provider.

@@ -53,7 +53,7 @@ RKE templates can be created from scratch to pre-define cluster configuration. T
 The settings of an existing cluster can be [saved as an RKE template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#converting-an-existing-cluster-to-use-an-rke-template) This creates a new template and binds the cluster settings to the template, so that the cluster can only be upgraded if the [template is updated](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#updating-a-template), and the cluster is upgraded to [use a newer version of the template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#upgrading-a-cluster-to-use-a-new-template-revision) The new template can also be used to create new clusters.


-# Example Scenarios
+## Example Scenarios
 When an organization has both basic and advanced Rancher users, administrators might want to give the advanced users more options for cluster creation, while restricting the options for basic users.

 These [example scenarios](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md) describe how an organization could use templates to standardize cluster creation.
@@ -65,7 +65,7 @@ Some of the example scenarios include the following:
 - **Updating template settings:** If an organization's security and DevOps teams decide to embed best practices into the required settings for new clusters, those best practices could change over time. If the best practices change, [a template can be updated to a new revision](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md#updating-templates-and-clusters-created-with-them) and clusters created from the template can [upgrade to the new version](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#upgrading-a-cluster-to-use-a-new-template-revision) of the template.
 - **Sharing ownership of a template:** When a template owner no longer wants to maintain a template, or wants to share ownership of the template, this scenario describes how [template ownership can be shared.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md#allowing-other-users-to-control-and-share-a-template)

-# Template Management
+## Template Management

 When you create an RKE template, it is available in the Rancher UI from the **Cluster Management** view under **RKE Templates**. When you create a template, you become the template owner, which gives you permission to revise and share the template. You can share the RKE templates with specific users or groups, and you can also make it public.

@@ -88,7 +88,7 @@ The documents in this section explain the details of RKE template management:

 An [example YAML configuration file for a template](../reference-guides/rke1-template-example-yaml.md) is provided for reference.

-# Applying Templates
+## Applying Templates

 You can [create a cluster from a template](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#creating-a-cluster-from-an-rke-template) that you created, or from a template that has been [shared with you.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/access-or-share-templates.md)

@@ -98,13 +98,13 @@ RKE templates can be created from scratch to pre-define cluster configuration. T

 You can [save the configuration of an existing cluster as an RKE template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#converting-an-existing-cluster-to-use-an-rke-template) Then the cluster's settings can only be changed if the template is updated.

-# Standardizing Hardware
+## Standardizing Hardware

 RKE templates are designed to standardize Kubernetes and Rancher settings. If you want to standardize your infrastructure as well, one option is to use RKE templates [in conjunction with other tools](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md).

 Another option is to use [cluster templates,](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-cluster-templates.md) which include node pool configuration options, but don't provide configuration enforcement.

-# YAML Customization
+## YAML Customization

 If you define an RKE template as a YAML file, you can modify this [example RKE template YAML](../reference-guides/rke1-template-example-yaml.md). The YAML in the RKE template uses the same customization that Rancher uses when creating an RKE cluster, but since the YAML is located within the context of a Rancher provisioned cluster, you will need to nest the RKE template customization under the `rancher_kubernetes_engine_config` directive in the YAML.

@@ -5,20 +5,8 @@ weight: 2110
 ---
 Amazon EKS provides a managed control plane for your Kubernetes cluster. Amazon EKS runs the Kubernetes control plane instances across multiple Availability Zones to ensure high availability. Rancher provides an intuitive user interface for managing and deploying the Kubernetes clusters you run in Amazon EKS. With this guide, you will use Rancher to quickly and easily launch an Amazon EKS Kubernetes cluster in your AWS account. For more information on Amazon EKS, see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html).

- [Prerequisites in Amazon Web Services](#prerequisites-in-amazon-web-services)
-  - [Amazon VPC](#amazon-vpc)
-  - [IAM Policies](#iam-policies)
- [Create the EKS Cluster](#create-the-eks-cluster)
- [EKS Cluster Configuration Reference](#eks-cluster-configuration-reference)
- [Architecture](#architecture)
- [AWS Service Events](#aws-service-events)
- [Security and Compliance](#security-and-compliance)
- [Tutorial](#tutorial)
- [Minimum EKS Permissions](#minimum-eks-permissions)
- [Syncing](#syncing)
- [Troubleshooting](#troubleshooting)
- [Programmatically Creating EKS Clusters](#programmatically-creating-eks-clusters)
-# Prerequisites in Amazon Web Services
+
+## Prerequisites in Amazon Web Services

 :::caution

@@ -51,7 +39,7 @@ It's important to regularly rotate your access and secret keys. See this [docume
 For more detailed information on IAM policies for EKS, refer to the official [documentation on Amazon EKS IAM Policies, Roles, and Permissions](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html).


-# Create the EKS Cluster
+## Create the EKS Cluster

 Use Rancher to set up and configure your Kubernetes cluster.

@@ -74,11 +62,11 @@ 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

-# EKS Cluster Configuration Reference
+## EKS Cluster Configuration Reference

 For the full list of EKS cluster configuration options, see [this page.](../reference-guides/cluster-configuration/rancher-server-configuration/eks-cluster-configuration.md)

-# Architecture
+## Architecture

 The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two Kubernetes clusters: one created by RKE and another created by EKS.

@@ -86,31 +74,31 @@ The figure below illustrates the high-level architecture of Rancher 2.x. The fig

 ![Architecture](/img/rancher-architecture-rancher-api-server.svg)

-# AWS Service Events
+## AWS Service Events

 To find information on any AWS Service events, please see [this page](https://status.aws.amazon.com/).

-# Security and Compliance
+## Security and Compliance

 By default only the IAM user or role that created a cluster has access to it. Attempting to access the cluster with any other user or role without additional configuration will lead to an error. In Rancher, this means using a credential that maps to a user or role that was not used to create the cluster will cause an unauthorized error. For example, an EKSCtl cluster will not register in Rancher unless the credentials used to register the cluster match the role or user used by EKSCtl. Additional users and roles can be authorized to access a cluster by being added to the aws-auth configmap in the kube-system namespace. For a more in-depth explanation and detailed instructions, please see this [documentation](https://aws.amazon.com/premiumsupport/knowledge-center/amazon-eks-cluster-access/).

 For more information on security and compliance with your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/shared-responsibilty.html).

-# Tutorial
+## Tutorial

 This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-rancher/) on the AWS Open Source Blog will walk you through how to set up an EKS cluster with Rancher, deploy a publicly accessible app to test the cluster, and deploy a sample project to track real-time geospatial data using a combination of other open-source software such as Grafana and InfluxDB.

-# Minimum EKS Permissions
+## Minimum EKS Permissions

 See [this page](../reference-guides/amazon-eks-permissions/minimum-eks-permissions.md) for the minimum set of permissions necessary to use all functionality of the EKS driver in Rancher.

-# Syncing
+## Syncing

 The EKS provisioner can synchronize the state of an EKS cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.](../reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md)

 For information on configuring the refresh interval, refer to [this section.](../reference-guides/cluster-configuration/rancher-server-configuration/eks-cluster-configuration.md#configuring-the-refresh-interval)

-# Troubleshooting
+## Troubleshooting

 If your changes were overwritten, it could be due to the way the cluster data is synced with EKS. Changes shouldn't be made to the cluster from another source, such as in the EKS console, and in Rancher within a five-minute span. For information on how this works and how to configure the refresh interval, refer to [Syncing.](#syncing)

@@ -118,6 +106,6 @@ If an unauthorized error is returned while attempting to modify or register the

 For any issues or troubleshooting details for your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html).

-# Programmatically Creating EKS Clusters
+## Programmatically Creating EKS Clusters

 The most common way to programmatically deploy EKS clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
@@ -9,22 +9,12 @@ The `rancher-backup` operator is used to backup and restore Rancher on any Kuber

 The backup-restore operator needs to be installed in the local cluster, and only backs up the Rancher app. The backup and restore operations are performed only in the local Kubernetes cluster.

- [Backup and Restore for Rancher installed with Docker](#backup-and-restore-for-rancher-installed-with-docker)
- [How Backups and Restores Work](#how-backups-and-restores-work)
- [Installing the rancher-backup Operator](#installing-the-rancher-backup-operator)
-  - [Installing rancher-backup with the Rancher UI](#installing-rancher-backup-with-the-rancher-ui)
-  - [RBAC](#rbac)
- [Backing up Rancher](#backing-up-rancher)
- [Restoring Rancher](#restoring-rancher)
- [Migrating Rancher to a New Cluster](#migrating-rancher-to-a-new-cluster)
- [Default Storage Location Configuration](#default-storage-location-configuration)
-  - [Example values.yaml for the rancher-backup Helm Chart](#example-values-yaml-for-the-rancher-backup-helm-chart)

-# Backup and Restore for Rancher installed with Docker
+## Backup and Restore for Rancher installed with Docker

 For Rancher installed with Docker, refer to [this page](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md) to perform backups and [this page](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md) to perform restores.

-# How Backups and Restores Work
+## How Backups and Restores Work

 The `rancher-backup` operator introduces three custom resources: Backups, Restores, and ResourceSets. The following cluster-scoped custom resource definitions are added to the cluster:

@@ -48,7 +38,7 @@ Refer [here](../how-to-guides/new-user-guides/backup-restore-and-disaster-recove

 :::

-# Installing the rancher-backup Operator
+## Installing the rancher-backup Operator

 The `rancher-backup` operator can be installed from the Rancher UI, or with the Helm CLI. In both cases, the `rancher-backup` Helm chart is installed on the Kubernetes cluster running the Rancher server. It is a cluster-admin only feature and available only for the **local** cluster.  (*If you do not see `rancher-backup` in the Rancher UI, you may have selected the wrong cluster.*)

@@ -83,19 +73,19 @@ Only the rancher admins and the local cluster’s cluster-owner can:
 * Perform a backup or restore by creating a Backup CR and Restore CR respectively
 * List backups/restores performed so far

-# Backing up Rancher
+## Backing up Rancher

 A backup is performed by creating a Backup custom resource. For a tutorial, refer to [this page.](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md)

-# Restoring Rancher
+## Restoring Rancher

 A restore is performed by creating a Restore custom resource. For a tutorial, refer to [this page.](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher.md)

-# Migrating Rancher to a New Cluster
+## Migrating Rancher to a New Cluster

 A migration is performed by following [these steps.](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)

-# Default Storage Location Configuration
+## Default Storage Location Configuration

 Configure a storage location where all backups are saved by default. You will have the option to override this with each backup, but will be limited to using an S3-compatible or Minio object store.

--- a/Show More
+++ b/Show More