Fix tables of contents, headers and formatting

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

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

-# Building
+## Building

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

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

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

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

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

-# Docs
+## Docs

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

@@ -12,10 +12,8 @@ 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 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.4](#cis-benchmark-v1-4)

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

 ### CIS Benchmark v1.5 Skipped Tests

@@ -61,7 +59,7 @@ All the tests that are skipped and not applicable on this page will be counted a
 | 4.1.10 |  Ensure that the kubelet configuration file ownership is set to root:root (Scored) |  Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time.     |
 | 4.2.12 |  Ensure that the RotateKubeletServerCertificate argument is set to true (Scored) |  Clusters provisioned by RKE handles certificate rotation directly through RKE.     |

-# CIS Benchmark v1.4
+## CIS Benchmark v1.4

 The skipped and not applicable tests for CIS Benchmark v1.4 are as follows:

@@ -15,68 +15,6 @@ The PromQL expressions in this doc can be used to configure [alerts.](../../../p

 For more information about querying Prometheus, 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

@@ -11,13 +11,6 @@ _Available as of v2.2.4_

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

-This section covers the following topics:
-
- [Monitoring scope](#monitoring-scope)
- [Permissions to configure project monitoring](#permissions-to-configure-project-monitoring)
- [Enabling project monitoring](#enabling-project-monitoring)
- [Project-level monitoring resource requirements](#project-level-monitoring-resource-requirements)
- [Project metrics](#project-metrics)

 ### Monitoring Scope

@@ -35,7 +35,7 @@ istio-pilot |discovery| 500m | 2048Mi | 1000m | 4096Mi | Y
 **Total**           | **-**        | **3950m**         | **5546Mi**        | **>12300m**         | **>14848Mi**         | **-**   


-# Configuring Resource Allocations
+## Configuring Resource Allocations

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

@@ -22,13 +22,6 @@ Rancher integrates with a variety of popular IT services, including:
 - **DingTalk**: (Available as of v2.4.6) Send alert notifications to DingTalk using a webhook.
 - **Microsoft Teams**: (Available as of v2.4.6) Send alert notifications to Teams using a webhook.

-This section covers the following topics:
-
- [Roles-based access control for notifiers](#roles-based-access-control-for-notifiers)
- [Adding notifiers](#adding-notifiers)
- [Configuration](#configuration)
- [Managing notifiers](#managing-notifiers)
- [Example payload for a webhook alert notifier](#example-payload-for-a-webhook-alert-notifier)

 # Roles-based Access Control for Notifiers

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

 > **Prerequisites:**
 >
@@ -39,7 +39,7 @@ OPA Gatekeeper is made available via Rancher's Helm system chart, and it is inst
 1. To install Gatekeeper with the default configuration, click on **Enable Gatekeeper (v0.1.0) with defaults.**
 1. To change any default configuration, click on **Customize Gatekeeper yaml configuration.**

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

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

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

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

@@ -89,7 +89,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.**
@@ -10,11 +10,6 @@ aliases:

 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 imported cluster managed by Rancher?](#what-if-i-don-t-want-my-imported-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?

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

@@ -29,22 +29,6 @@ In an HA setup that uses a layer 4 load balancer, the load balancer accepts Ranc

 Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete.

-<!-- TOC -->
-
- [1. Provision Linux Hosts](#1-provision-linux-hosts)
- [2. Configure Load Balancer](#2-configure-load-balancer)
- [3. Configure DNS](#3-configure-dns)
- [4. Install RKE](#4-install-rke)
- [5. Download RKE Config File Template](#5-download-rke-config-file-template)
- [6. Configure Nodes](#6-configure-nodes)
- [7. Configure Certificates](#7-configure-certificates)
- [8. Configure FQDN](#8-configure-fqdn)
- [9. Configure Rancher version](#9-configure-rancher-version)
- [10. Back Up Your RKE Config File](#10-back-up-your-rke-config-file)
- [11. Run RKE](#11-run-rke)
- [12. Back Up Auto-Generated Config File](#12-back-up-auto-generated-config-file)
-
-<!-- /TOC -->

 <br/>

@@ -29,23 +29,6 @@ In an HA setup that uses a layer 7 load balancer, the load balancer accepts Ranc

 Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete.

-<!-- TOC -->
-
- [1. Provision Linux Hosts](#1-provision-linux-hosts)
- [2. Configure Load Balancer](#2-configure-load-balancer)
- [3. Configure DNS](#3-configure-dns)
- [4. Install RKE](#4-install-rke)
- [5. Download RKE Config File Template](#5-download-rke-config-file-template)
- [6. Configure Nodes](#6-configure-nodes)
- [7. Configure Certificates](#7-configure-certificates)
- [8. Configure FQDN](#8-configure-fqdn)
- [9. Configure Rancher version](#9-configure-rancher-version)
- [10. Back Up Your RKE Config File](#10-back-up-your-rke-config-file)
- [11. Run RKE](#11-run-rke)
- [12. Back Up Auto-Generated Config File](#12-back-up-auto-generated-config-file)
-
-
-<!-- /TOC -->
 ## 1. Provision Linux Hosts

 Provision three Linux hosts according to our [Requirements](../../../../../pages-for-subheaders/installation-requirements.md).
@@ -87,7 +87,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
@@ -10,20 +10,6 @@ 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)

 # New Features

@@ -14,18 +14,6 @@ Howdy Partner! This tutorial walks you through:

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

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

@@ -23,16 +23,6 @@ Configuring Rancher to allow your users to authenticate with their Azure AD acco

 >**Tip:** Before you start, we recommend creating an empty text file. You can use this file to copy values from Azure that you'll paste into Rancher later.

-<!-- 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. Add a Reply URL](#4-add-a-reply-url)
- [5. Copy Azure Application Data](#5-copy-azure-application-data)
- [6. Configure Azure AD in Rancher](#6-configure-azure-ad-in-rancher)
-
-<!-- /TOC -->

 ### 1. Register Rancher with Azure

@@ -11,12 +11,6 @@ As of Rancher v2.3.3, you can [save the configuration of an existing cluster as

 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

 To add a cluster [hosted by an infrastructure provider](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) using an RKE template, use these steps:
@@ -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.

@@ -27,7 +27,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,21 +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

 You can create RKE templates if you have the **Create RKE Templates** permission, which can be [given by an administrator.](creator-permissions.md)
@@ -11,16 +11,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](#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.

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

 _Available as of v2.0.7_

@@ -51,7 +43,7 @@ This policy is based on the Kubernetes [example restricted policy](https://raw.g

 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.

@@ -76,7 +68,7 @@ We recommend adding PSPs during cluster and project creation instead of adding i
 3. 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.


-# Configuration
+## Configuration

 The Kubernetes documentation on PSPs is [here.](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)

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

@@ -32,7 +32,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 provision a cluster with Rancher:

@@ -12,13 +12,6 @@ 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.

-This section covers the following topics:
-
- [Prerequisites](#prerequisites)
- [Creating a custom role for a cluster or project](#creating-a-custom-role-for-a-cluster-or-project)
- [Creating a custom global role](#creating-a-custom-global-role)
- [Deleting a custom global role](#deleting-a-custom-global-role)
- [Assigning a custom global role to a group](#assigning-a-custom-global-role-to-a-group)

 ## Prerequisites

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

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

-This section covers the following topics:
-
- [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)

 # Global Permission Assignment

@@ -14,12 +14,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
@@ -52,7 +46,7 @@ This alternative method of accessing the cluster allows you to authenticate with

 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)

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

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

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

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

@@ -9,11 +9,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.](../../../../new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/vsphere.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:

@@ -10,24 +10,6 @@ After you launch a Kubernetes cluster in Rancher, you can manage individual node

 > If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters](../../../pages-for-subheaders/cluster-configuration.md#editing-clusters-with-yaml).

-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)
-  - [Imported nodes](#imported-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

@@ -15,16 +15,8 @@ A project is a group of namespaces, and it is a concept introduced by Rancher. P

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

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

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

@@ -115,18 +107,18 @@ The `system` project:
 >
 >The `system` project overrides the Project Network Isolation option so that it can communicate with other projects, collect logs, and check health.

-# 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/policluster-admin/pod-security-policy/) at the [project level](../manage-projects/manage-pod-security-policies.md) in addition to the [cluster level.](./add-a-pod-security-policy.md) 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.

@@ -194,7 +186,7 @@ To add a resource quota,
 | Project Limit           | The overall resource limit for the project.                                                              |
 | Namespace Default Limit | The default resource limit available for each namespace. This limit is propagated to each namespace in the project when created. The combined limit of all project namespaces shouldn't exceed the project limit.  |

-# Switching between Clusters and Projects
+## Switching between Clusters and Projects

 To switch between clusters and projects, use the **Global** drop-down available in the main menu.

@@ -14,12 +14,6 @@ Rancher recommends enabling the [ability to set up recurring snapshots of etcd](

 As of Rancher v2.4.0, 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

@@ -111,6 +105,6 @@ If the group of etcd nodes loses quorum, the Kubernetes cluster will report a fa

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

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

 If you have any Rancher launched Kubernetes clusters that were created before v2.2.0, after upgrading Rancher, you must [edit the cluster](../../../pages-for-subheaders/cluster-configuration.md) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots before v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI](restoring-etcd.md).
@@ -17,16 +17,6 @@ This will restore the Kubernetes configuration and the Rancher database and stat

 > **Note:** This document covers clusters set up with RKE >= v0.2.x, for older RKE versions refer to the [RKE Documentation](https://rancher.com/docs/rke/latest/en/etcd-snapshots/restoring-from-backup).

-## Restore Outline
-
-<!-- TOC -->
-
- [1. Preparation](#1-preparation)
- [2. Place Snapshot](#2-place-snapshot)
- [3. Configure RKE](#3-configure-rke)
- [4. Restore the Database and bring up the Cluster](#4-restore-the-database-and-bring-up-the-cluster)
-
-<!-- /TOC -->

 ### 1. Preparation

@@ -13,15 +13,6 @@ Rancher's catalog service requires any custom catalogs to be structured in a spe

 > For a complete walkthrough of developing charts, see the [Chart Template Developer's Guide](https://helm.sh/docs/chart_template_guide/) in the official Helm documentation.

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

@@ -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)
@@ -14,7 +14,7 @@ If you are using Calico,
 1. Go to the cluster view in the Rancher UI, and click **&#8942; > Edit.**
 1. Click **Edit as YAML,** and enter the following configuration:

-    ```
+    ```yaml
    rancher_kubernetes_engine_config:
      cloud_provider:
        name: gce
@@ -36,7 +36,7 @@ If you are using Canal or Flannel,
 1. Go to the cluster view in the Rancher UI, and click **&#8942; > Edit.**
 1. Click **Edit as YAML,** and enter the following configuration:

-    ```
+    ```yaml
    rancher_kubernetes_engine_config:
      cloud_provider: 
        name: gce
@@ -50,7 +50,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.

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



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

@@ -32,17 +32,6 @@ For a summary of Kubernetes features supported in Windows, see [Using Windows in

 When setting up a custom cluster with support for Windows nodes and containers, complete the series of tasks below.

-<!-- TOC -->
-
- [1. Provision Hosts](#1-provision-hosts)
- [2. Cloud-host VM Networking Configuration](#2-cloud-hosted-vm-networking-configuration)
- [3. Create the Custom Cluster](#3-create-the-custom-cluster)
- [4. Add Linux Host for Ingress Support](#4-add-linux-host-for-ingress-support)
- [5. Adding Windows Workers](#5-adding-windows-workers)
- [6. Cloud-host VM Routes Configuration](#6-cloud-hosted-vm-routes-configuration)
-
-<!-- /TOC -->
-
 ## 1. Provision Hosts

 To begin provisioning a custom cluster with Windows support, prepare your host servers. Provision three nodes according to our [requirements](../../../../../pages-for-subheaders/installation-requirements.md)—two Linux, one Windows. Your hosts can be:
@@ -10,14 +10,7 @@ This page describes the requirements for the Rancher managed Kubernetes clusters

 > If Rancher is installed on a high-availability Kubernetes cluster, the Rancher server three-node cluster and downstream clusters have different requirements. For Rancher installation requirements, refer to the node requirements in the [installation section.](../../../pages-for-subheaders/installation-requirements.md)

-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) The capability to use Windows worker nodes in downstream clusters was added in Rancher v2.3.0.

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

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

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

@@ -42,7 +42,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|
 |---|---|
@@ -61,7 +61,7 @@ You can access your cluster after its state is updated to **Active.**

 **Note:** If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that as of Rancher v2.3.0, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#config-file-structure-in-rancher-v2-3-0)

-# Node Configuration
+## Node Configuration

 |Settings|Description|
 |---|---|
@@ -69,7 +69,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:
@@ -13,17 +13,6 @@ This document will also show you how to link the workloads and services that you

 ![Resolve Link Directive](/img/resolve-links.png)

-## In This Document
-
-<!-- TOC -->
-
-
- [Service Discovery: Rancher v1.6 vs. v2.x](#service-discovery-rancher-v1-6-vs-v2-x)
- [Service Discovery Within and Across Namespaces](#service-discovery-within-and-across-namespaces)
- [Container Discovery](#container-discovery)
- [Service Name Alias Creation](#service-name-alias-creation)
-
-<!-- /TOC -->

 ## Service Discovery: Rancher v1.6 vs. v2.x

@@ -14,18 +14,6 @@ Use this document to correct workloads that list `ports` in `output.txt`. You ca
 ![Resolve Ports](/img/resolve-ports.png)


-## In This Document
-
-<!-- TOC -->
-
- [What's Different About Exposing Services in Rancher v2.x?](#what-s-different-about-exposing-services-in-rancher-v2-x)
- [HostPorts](#hostport)
- [Setting HostPort](#setting-hostport)
- [NodePorts](#nodeport)
- [Setting NodePort](#setting-nodeport)
-
-<!-- /TOC -->
-
 ## What's Different About Exposing Services in Rancher v2.x?

 In Rancher v1.6, we used the term _Port Mapping_ for exposing an IP address and port where your you and your users can access a service. 
@@ -6,18 +6,6 @@ aliases:
 ---
 Get started with your migration to Rancher v2.x by installing Rancher and configuring your new Rancher environment.

-## Outline
-
-<!-- TOC -->
-
- [A. Install Rancher v2.x](#a-install-rancher-v2-x)
- [B. Configure Authentication](#b-configure-authentication)
- [C. Provision a Cluster and Project](#c-provision-a-cluster-and-project)
- [D. Create Stacks](#d-create-stacks)
-
-
-<!-- /TOC -->
-
 ## A. Install Rancher v2.x

 The first step in migrating from v1.6 to v2.x is to install the Rancher v2.x Server side-by-side with your v1.6 Server, as you'll need your old install during the migration process. Due to the architecture changes between v1.6 and v2.x, there is no direct path for upgrade. You'll have to install v2.x independently and then migrate your v1.6 services to v2.x.
@@ -15,18 +15,6 @@ If you encounter the `output.txt` text below after parsing your v1.6 Compose fil

 ![Resolve Load Balancer Directive](/img/resolve-load-balancer.png)

-## In This Document
-
-<!-- TOC -->
-
- [Load Balancing Protocol Options](#load-balancing-protocol-options)
- [Load Balancer Deployment](#load-balancer-deployment)
- [Load Balancing Architecture](#load-balancing-architecture)
- [Ingress Caveats](#ingress-caveats)
- [Deploying Ingress](#deploying-ingress)
- [Rancher v2.x Load Balancing Limitations](#rancher-v2-x-load-balancing-limitations)
-
-<!-- /TOC -->

 ## Load Balancing Protocol Options

@@ -18,19 +18,6 @@ This command line interface tool will:

 - Parse Compose files that you’ve exported from your Rancher v1.6 stacks and converts them to Kubernetes manifests that Rancher v2.x can consume. The tool also outputs a list of directives present in the Compose files that cannot be converted automatically to Rancher v2.x. These are directives that you’ll have to manually configure using the Rancher v2.x UI.

-## Outline
-
-<!-- TOC -->
-
- [A. Download the migration-tools CLI](#a-download-the-migration-tools-cli)
- [B. Configure the migration-tools CLI](#b-configure-the-migration-tools-cli)
- [C. Run the migration-tools CLI](#c-run-the-migration-tools-cli)
- [D. Deploy Services Using Rancher CLI](#d-re-deploy-services-as-kubernetes-manifests)
- [What Now?](#what-now)
-
-
-<!-- /TOC -->
-

 ## A. Download the migration-tools CLI

@@ -20,15 +20,6 @@ For example, for the image below, we would configure liveness probes for the `we

 ![Resolve health_check](/img/resolve-health-checks.png)

-## In This Document
-
-<!-- TOC -->
-
- [Rancher v1.6 Health Checks](#rancher-v1-6-health-checks)
- [Rancher v2.x Health Checks](#rancher-v2-x-health-checks)
- [Configuring Probes in Rancher v2.x](#configuring-probes-in-rancher-v2-x)
-
-<!-- /TOC -->

 ## Rancher v1.6 Health Checks

@@ -17,22 +17,9 @@ You can schedule your migrated v1.6 services while editing a deployment. Schedul

 ![Workload Type and Node Scheduling Sections](/img/migrate-schedule-workloads.png)

-## In This Document

 <!-- NEED DOCS ABOUT CHANGING DEPLOYMENTS TO DAEMONSETS -->

-<!-- TOC -->
-
- [What's Different for Scheduling Services?](#whats-different-for-scheduling-services)
- [Node Scheduling Options](#node-scheduling-options)
- [Scheduling Pods to a Specific Node](#scheduling-pods-to-a-specific-node)
- [Scheduling Using Labels](#scheduling-using-labels)
- [Scheduling Pods Using Resource Constraints](#scheduling-pods-using-resource-constraints)
- [Preventing Scheduling Specific Services to Specific Nodes](#preventing-scheduling-specific-services-to-specific-nodes)
- [Scheduling Global Services](#scheduling-global-services)
-
-
-<!-- /TOC -->

 ## What's Different for Scheduling Services?

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

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

@@ -55,7 +55,7 @@ RKE templates can be created from scratch to pre-define cluster configuration. T
 As of v2.3.3, 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.
@@ -67,7 +67,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 **Global** view under **Tools > 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.

@@ -90,7 +90,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)

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

 As of Rancher v2.3.3, 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, you use RKE templates [in conjunction with other tools](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md).

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

@@ -11,22 +11,6 @@ aliases:

 To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. When an event occurs, your alert is triggered, and you are sent a notification. You can then, if necessary, follow up with corrective actions.

-This section covers the following topics:
-
- [About Alerts](#about-alerts)
-  - [Alert Event Examples](#alert-event-examples)
-  - [Alerts Triggered by Prometheus Queries](#alerts-triggered-by-prometheus-queries)
-  - [Urgency Levels](#urgency-levels)
-  - [Scope of Alerts](#scope-of-alerts)
-  - [Managing Cluster Alerts](#managing-cluster-alerts)
- [Adding Cluster Alerts](#adding-cluster-alerts)
- [Cluster Alert Configuration](#cluster-alert-configuration)
-  - [System Service Alerts](#system-service-alerts)
-  - [Resource Event Alerts](#resource-event-alerts)
-  - [Node Alerts](#node-alerts)
-  - [Node Selector Alerts](#node-selector-alerts)
-  - [CIS Scan Alerts](#cis-scan-alerts)
-  - [Metric Expression Alerts](#metric-expression-alerts)

 # About Alerts

@@ -29,12 +29,6 @@ Rancher supports integration with the following services:
 - Syslog
 - Fluentd

-This section covers the following topics:
-
- [How logging integrations work](#how-logging-integrations-work)
- [Requirements](#requirements)
- [Logging scope](#logging-scope)
- [Enabling cluster logging](#enabling-cluster-logging)

 # How Logging Integrations Work

@@ -16,15 +16,6 @@ _Available as of v2.2.0_

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

-This section covers the following topics:
-
- [About Prometheus](#about-prometheus)
- [Monitoring scope](#monitoring-scope)
- [Enabling cluster monitoring](#enabling-cluster-monitoring)
- [Resource consumption](#resource-consumption)
-  - [Resource consumption of Prometheus pods](#resource-consumption-of-prometheus-pods)
-  - [Resource consumption of other pods](#resource-consumption-of-other-pods)
-
 # About Prometheus

 Prometheus provides a _time series_ of your data, which is, according to [Prometheus documentation](https://prometheus.io/docs/concepts/data_model/):
@@ -13,16 +13,6 @@ If you also configure OpenLDAP as the back end to Shibboleth, it will return a S

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

-This section covers the following topics:
-
- [Setting up Shibboleth in Rancher](#setting-up-shibboleth-in-rancher)
-  - [Shibboleth Prerequisites](#shibboleth-prerequisites)
-  - [Configure Shibboleth in Rancher](#configure-shibboleth-in-rancher)
-  - [SAML Provider Caveats](#saml-provider-caveats)
- [Setting up OpenLDAP in Rancher](#setting-up-openldap-in-rancher)
-  - [OpenLDAP Prerequisites](#openldap-prerequisites)
-  - [Configure OpenLDAP in Rancher](#configure-openldap-in-rancher)
-  - [Troubleshooting](#troubleshooting)

 # Setting up Shibboleth in Rancher

@@ -17,19 +17,7 @@ Rancher provides the ability to use a catalog of Helm charts that make it easy t

 Rancher improves on Helm catalogs and charts. All native Helm charts can work within Rancher, but Rancher adds several enhancements to improve their user experience.

-This section covers the following topics:
-
- [Catalog scopes](#catalog-scopes)
- [Catalog Helm Deployment Versions](#catalog-helm-deployment-versions)
- [When to use Helm 3](#when-to-use-helm-3)
- [Helm 3 Backwards Compatibility](#helm-3-backwards-compatibility)
- [Built-in global catalogs](#built-in-global-catalogs)
- [Custom catalogs](#custom-catalogs)
- [Creating and launching applications](#creating-and-launching-applications)
- [Chart compatibility with Rancher](#chart-compatibility-with-rancher)
- [Global DNS](#global-dns)
-
-# Catalog Scopes
+## Catalog Scopes

 Within Rancher, you can manage catalogs at three different scopes. Global catalogs are shared across all clusters and project. There are some use cases where you might not want to share catalogs between different clusters or even projects in the same cluster. By leveraging cluster and project scoped catalogs, you will be able to provide applications for specific teams without needing to share them with all clusters and/or projects.

@@ -39,7 +27,7 @@ Global | All clusters and all projects can access the Helm charts in this catalo
 Cluster | All projects in the specific cluster can access the Helm charts in this catalog | v2.2.0 |
 Project | This specific cluster can access the Helm charts in this catalog |  v2.2.0 |

-# Catalog Helm Deployment Versions
+## Catalog Helm Deployment Versions

 _Applicable as of v2.4.0_

@@ -53,7 +41,7 @@ By default, catalogs are assumed to be deployed using Helm 2. If you run an app

 Charts that are specific to Helm 2 should only be added to a Helm 2 catalog, and Helm 3 specific charts should only be added to a Helm 3 catalog.

-# When to use Helm 3
+## When to use Helm 3

 _Applicable as of v2.4.0_

@@ -62,7 +50,7 @@ _Applicable as of v2.4.0_

 Overall Helm 3 is a movement towards a more standardized Kubernetes feel. As the Kubernetes community has evolved, standards and best practices have as well. Helm 3 is an attempt to adopt those practices and streamline how charts are maintained.

-# Helm 3 Backwards Compatibility
+## Helm 3 Backwards Compatibility

 _Applicable as of v2.4.0_

@@ -72,31 +60,25 @@ Helm 3 does not create a namespace for you, so you will have to provide an exist

 apiVersion `v2` is now reserved for Helm 3 charts. This apiVersion enforcement could cause issues as older versions of Helm 2 did not validate the apiVersion in the `Chart.yaml` file. In general, your Helm 2 chart’s apiVersion should be set to `v1` and your Helm 3 chart’s apiVersion should be set to `v2`. You can install charts with apiVersion `v1` with Helm 3, but you cannot install `v2` charts into Helm 2.

-# Built-in Global Catalogs
+## Built-in Global Catalogs

 Within Rancher, there are default catalogs packaged as part of Rancher. These can be enabled or disabled by an administrator. For details, refer to the section on managing [built-in global catalogs.](../how-to-guides/new-user-guides/helm-charts-in-rancher/built-in.md)

-# Custom Catalogs
+## Custom Catalogs

 There are two types of catalogs in Rancher: [Built-in global catalogs](../how-to-guides/new-user-guides/helm-charts-in-rancher/built-in.md) and [custom catalogs.](../how-to-guides/new-user-guides/helm-charts-in-rancher/adding-catalogs.md)

 Any user can create custom catalogs to add into Rancher.  Custom catalogs can be added into Rancher at the global level, cluster level, or project level. For details, refer to the [section on adding custom catalogs](../how-to-guides/new-user-guides/helm-charts-in-rancher/adding-catalogs.md) and the [catalog configuration reference.](../how-to-guides/new-user-guides/helm-charts-in-rancher/catalog-config.md)

-# Creating and Launching Applications
+## Creating and Launching Applications

-In Rancher, applications are deployed from the templates in a catalog. This section covers the following topics:
+In Rancher, applications are deployed from the templates in a catalog.

-* [Multi-cluster applications](../how-to-guides/new-user-guides/helm-charts-in-rancher/multi-cluster-apps.md)
-* [Creating catalog apps](../how-to-guides/new-user-guides/helm-charts-in-rancher/creating-apps.md)
-* [Launching catalog apps within a project](../how-to-guides/new-user-guides/helm-charts-in-rancher/launching-apps.md)
-* [Managing catalog apps](../how-to-guides/new-user-guides/helm-charts-in-rancher/managing-apps.md)
-* [Tutorial: Example custom chart creation](../how-to-guides/new-user-guides/helm-charts-in-rancher/tutorial.md)
-
-# Chart Compatibility with Rancher
+## Chart Compatibility with Rancher

 Charts now support the fields `rancher_min_version` and `rancher_max_version` in the [`questions.yml` file](https://github.com/rancher/integration-test-charts/blob/master/charts/chartmuseum/v1.6.0/questions.yml) to specify the versions of Rancher that the chart is compatible with. When using the UI, only app versions that are valid for the version of Rancher running will be shown. API validation is done to ensure apps that don't meet the Rancher requirements cannot be launched. An app that is already running will not be affected on a Rancher upgrade if the newer Rancher version does not meet the app's requirements.

-# Global DNS
+## Global DNS

 _Available as v2.2.0_

@@ -23,27 +23,6 @@ In a Kubernetes setup that uses a layer 4 load balancer, the load balancer accep
 <sup>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</sup>
 ![High-availability Kubernetes installation of Rancher](/img/ha/rancher2ha.svg)

-## Installation Outline
-
-Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete.
-
-<!-- TOC -->
-
- [1. Provision Linux Hosts](#1-provision-linux-hosts)
- [2. Configure Load Balancer](#2-configure-load-balancer)
- [3. Configure DNS](#3-configure-dns)
- [4. Install RKE](#4-install-rke)
- [5. Download RKE Config File Template](#5-download-rke-config-file-template)
- [6. Configure Nodes](#6-configure-nodes)
- [7. Configure Certificates](#7-configure-certificates)
- [8. Configure FQDN](#8-configure-fqdn)
- [9. Configure Rancher version](#9-configure-rancher-version)
- [10. Back Up Your RKE Config File](#10-back-up-your-rke-config-file)
- [11. Run RKE](#11-run-rke)
- [12. Back Up Auto-Generated Config File](#12-back-up-auto-generated-config-file)
-
-<!-- /TOC -->
-
 <br/>

 ## 1. Provision Linux Hosts
@@ -24,27 +24,6 @@ In an Kubernetes setup that uses a layer 7 load balancer, the load balancer acce
 <sup>Kubernetes Rancher install with layer 7 load balancer, depicting SSL termination at load balancer</sup>
 ![Rancher HA](/img/ha/rancher2ha-l7.svg)

-## Installation Outline
-
-Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete.
-
-<!-- TOC -->
-
- [1. Provision Linux Hosts](#1-provision-linux-hosts)
- [2. Configure Load Balancer](#2-configure-load-balancer)
- [3. Configure DNS](#3-configure-dns)
- [4. Install RKE](#4-install-rke)
- [5. Download RKE Config File Template](#5-download-rke-config-file-template)
- [6. Configure Nodes](#6-configure-nodes)
- [7. Configure Certificates](#7-configure-certificates)
- [8. Configure FQDN](#8-configure-fqdn)
- [9. Configure Rancher version](#9-configure-rancher-version)
- [10. Back Up Your RKE Config File](#10-back-up-your-rke-config-file)
- [11. Run RKE](#11-run-rke)
- [12. Back Up Auto-Generated Config File](#12-back-up-auto-generated-config-file)
-
-
-<!-- /TOC -->
 ## 1. Provision Linux Hosts

 Provision three Linux hosts according to our [Requirements](installation-requirements.md).
@@ -14,18 +14,6 @@ This section assumes a basic familiarity with Docker and Kubernetes. For a brief

 For a conceptual overview of how the Rancher server provisions clusters and what tools it uses to provision them, refer to the [architecture](rancher-manager-architecture.md) page.

-This section covers the following topics:
-
-<!-- TOC -->
-
- [Setting up clusters in a hosted Kubernetes provider](#setting-up-clusters-in-a-hosted-kubernetes-provider)
- [Launching Kubernetes with Rancher](#launching-kubernetes-with-rancher)
-  - [Launching Kubernetes and Provisioning Nodes in an Infrastructure Provider](#launching-kubernetes-and-provisioning-nodes-in-an-infrastructure-provider)
-  - [Launching Kubernetes on Existing Custom Nodes](#launching-kubernetes-on-existing-custom-nodes)
- [Importing Existing Clusters](#importing-existing-clusters)
-
-<!-- /TOC -->
-
 The following table summarizes the options and settings available for each cluster type:

 import ClusterCapabilitiesTable from '../shared-files/_cluster-capabilities-table.md';
@@ -26,25 +26,12 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins
 >- Still using v2.0.x? See the pipeline documentation for [previous versions](../reference-guides/pipelines/v2.0.x.md).
 >- Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses.

-This section covers the following topics:

- [Concepts](#concepts)
- [How Pipelines Work](#how-pipelines-work)
- [Roles-based Access Control for Pipelines](#roles-based-access-control-for-pipelines)
- [Setting up Pipelines](#setting-up-pipelines)
-  - [Configure version control providers](#1-configure-version-control-providers)
-  - [Configure repositories](#2-configure-repositories)
-  - [Configure the pipeline](#3-configure-the-pipeline)
- [Pipeline Configuration Reference](#pipeline-configuration-reference)
- [Running your Pipelines](#running-your-pipelines)
- [Triggering a Pipeline](#triggering-a-pipeline)
-  - [Modifying the Event Triggers for the Repository](#modifying-the-event-triggers-for-the-repository)
-
-# Concepts
+## Concepts

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

-# How Pipelines Work
+## How Pipelines Work

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

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

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

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

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

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

 Project members can only configure repositories and pipelines.

-# Setting up Pipelines
+## Setting up Pipelines

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

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


-# Pipeline Configuration Reference
+## Pipeline Configuration Reference

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

@@ -247,7 +234,7 @@ The configuration reference also covers how to configure:
 - Secrets


-# Running your Pipelines
+## Running your Pipelines

 Run your pipeline for the first time. From the project view in Rancher, go to **Resources > Pipelines.** (In versions before v2.3.0, go to the **Pipelines** tab.) Find your pipeline and select the vertical **&#8942; > Run**.

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

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

-# Triggering a Pipeline
+## Triggering a Pipeline

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

@@ -3,15 +3,7 @@ title: Tools for Logging, Monitoring, and More
 weight: 2525
 ---

-Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into following categories:
-<!-- TOC -->
-
- [Notifiers](#notifiers)
- [Alerts](#alerts)
- [Logging](#logging)
- [Monitoring](#monitoring)
-
-<!-- /TOC -->
+Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently.

 # Notifiers

@@ -20,13 +20,6 @@ This section describes how to set up a custom cluster.
 >
 >See [Configuring Custom Clusters for Windows](use-windows-clusters.md) before you start.

-<!-- TOC -->
-
- [1. Provision a Linux Host](#1-provision-a-linux-host)
- [2. Create the Custom Cluster](#2-create-the-custom-cluster)
- [3. Amazon Only: Tag Resources](#3-amazon-only-tag-resources)
-
-<!-- /TOC -->

 ### 1. Provision a Linux Host

@@ -11,19 +11,6 @@ One benefit of installing Kubernetes on node pools hosted by an infrastructure p

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

-This section covers the following topics:
-
- [Node templates](#node-templates)
-  - [Node labels](#node-labels)
-  - [Node taints](#node-taints)
-  - [Administrator control of node templates](#administrator-control-of-node-templates)
- [Node pools](#node-pools)
-  - [Node pool taints](#node-pool-taints)
-  - [About node auto-replace](#about-node-auto-replace)
-  - [Enabling node auto-replace](#enabling-node-auto-replace)
-  - [Disabling node auto-replace](#disabling-node-auto-replace)
- [Cloud credentials](#cloud-credentials)
- [Node drivers](#node-drivers)

 # Node Templates

@@ -20,14 +20,6 @@ For the full list of requirements, see [this section.](#requirements-for-windows

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

-This guide covers the following topics:
-
-<!-- TOC -->
-
- [Requirements](#requirements-for-windows-clusters)
- [Tutorial: How to Create a Cluster with Windows Support](#tutorial-how-to-create-a-cluster-with-windows-support)
- [Configuration for Storage Classes in Azure](#configuration-for-storage-classes-in-azure)
-<!-- /TOC -->

 # Requirements for Windows Clusters

@@ -112,13 +104,6 @@ When you provision a cluster with Rancher on existing nodes, you will add nodes

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

-<!-- TOC -->
-
-1. [Provision Hosts](#1-provision-hosts)
-1. [Create the Cluster on Existing Nodes](#2-create-the-cluster-on-existing-nodes)
-1. [Add Nodes to the Cluster](#3-add-nodes-to-the-cluster)
-1. [Optional: Configuration for Azure Files](#4-optional-configuration-for-azure-files)
-<!-- /TOC -->

 # 1. Provision Hosts

@@ -15,12 +15,7 @@ Rancher can provision nodes in vSphere and install Kubernetes on them. When crea

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

- [vSphere Enhancements in Rancher v2.3](#vsphere-enhancements-in-rancher-v2-3)
- [Creating a vSphere Cluster](#creating-a-vsphere-cluster)
- [Provisioning Storage](#provisioning-storage)
- [Enabling the vSphere Cloud Provider](#enabling-the-vsphere-cloud-provider)
-
-# vSphere Enhancements in Rancher v2.3
+## vSphere Enhancements in Rancher v2.3

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

@@ -52,15 +47,15 @@ In this YouTube video, we demonstrate how to set up a node template with the new

 <YouTube id="dPIwg6x1AlU"/>

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

 In [this section,](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md) you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in vSphere.

-# Provisioning Storage
+## Provisioning Storage

 For an example of how to provision storage in vSphere using Rancher, refer to [this section.](../how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md) In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/vsphere.md)

-# Enabling the vSphere Cloud Provider
+## Enabling the vSphere Cloud Provider

 When a cloud provider is set up in Rancher, the Rancher server can automatically provision new infrastructure for the cluster, including new nodes or persistent storage devices.

@@ -2,10 +2,6 @@
 title: kubectl Utility
 ---

- [kubectl](#kubectl)
-  - [kubectl Utility](#kubectl-utility)
-  - [Authentication with kubectl and kubeconfig Tokens with TTL](#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl)
-
 # kubectl

 Interact with Rancher using kubectl.
@@ -4,15 +4,6 @@ description: Interact with Rancher using command line interface (CLI) tools from
 weight: 21
 ---

- [Rancher CLI](#rancher-cli)
-  - [Download Rancher CLI](#download-rancher-cli)
-  - [Requirements](#requirements)
-  - [CLI Authentication](#cli-authentication)
-  - [Project Selection](#project-selection)
-  - [Commands](#commands)
-  - [Rancher CLI Help](#rancher-cli-help)
-  - [Limitations](#limitations) 
-
 The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.

 ### Download Rancher CLI
@@ -6,14 +6,8 @@ aliases:
  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/prior-to-2.0.4/
 ---

- [Account access](#account-access)
- [Scheduling](#scheduling)
- [Instance options](#instance-options)
- [Disk UUIDs](#disk-uuids)
- [Node Tags and Custom Attributes](#node-tags-and-custom-attributes)
- [Cloud Init](#cloud-init)

-# Account Access
+## Account Access
 In the **Account Access** section, enter the vCenter FQDN or IP address and the credentials for the vSphere user account.

 | Parameter                | Required | Description |
@@ -24,7 +18,7 @@ In the **Account Access** section, enter the vCenter FQDN or IP address and the
 | Password                 |   *      | User's password. |


-# Scheduling
+## Scheduling

 Choose what hypervisor the virtual machine will be scheduled to.

@@ -37,7 +31,7 @@ Choose what hypervisor the virtual machine will be scheduled to.
 | Data Store               |   *      | Datastore to store the VM disks. |
 | Folder                   |          | Name of a folder in the datacenter to create the VMs in. Must already exist. The folder name should be prefaced with `vm/` in your vSphere config file. |

-# Instance Options
+## Instance Options
 In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template.

 Only VMs booting from RancherOS ISO are supported.
@@ -54,7 +48,7 @@ Ensure that the OS ISO URL contains the URL of the VMware ISO release for Ranche
 | OS ISO URL               |   *      | URL of a RancherOS vSphere ISO file to boot the VMs from. You can find URLs for specific versions in the [Rancher OS GitHub Repo](https://github.com/rancher/os). |
 | Configuration Parameters |          | Additional configuration parameters for the VMs. These correspond to the [Advanced Settings](https://kb.vmware.com/s/article/1016098) in the vSphere console. Example use cases include providing RancherOS [guestinfo]({{<baseurl>}}/os/v1.x/en/installation/cloud/vmware-esxi/#vmware-guestinfo) parameters or enabling disk UUIDs for the VMs (`disk.EnableUUID=TRUE`). |

-# Disk UUIDs
+## Disk UUIDs

 In order to provision nodes with RKE, all nodes must be configured with disk UUIDs. Follow these instructions to enable UUIDs for the nodes in your vSphere cluster.

@@ -71,7 +65,7 @@ To enable disk UUIDs for all VMs created for a cluster,

 **Result:** The disk UUID is enabled in the vSphere node template.

-# Node Tags and Custom Attributes
+## Node Tags and Custom Attributes

 These attributes allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects.

@@ -83,7 +77,7 @@ Optionally, you can:

 > **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere.

-# Cloud Init
+## Cloud Init

 [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network.

@@ -5,13 +5,9 @@ weight: 4
 aliases:
  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.0.4/
 ---
- [Account access](#account-access)
- [Scheduling](#scheduling)
- [Instance options](#instance-options)
- [Node Tags and Custom Attributes](#node-tags-and-custom-attributes)
- [Cloud Init](#cloud-init)

-# Account Access
+
+## Account Access
 In the **Account Access** section, enter the vCenter FQDN or IP address and the credentials for the vSphere user account.

 | Parameter                | Required | Description |
@@ -21,7 +17,7 @@ In the **Account Access** section, enter the vCenter FQDN or IP address and the
 | Username                 |   *      | vCenter/ESXi user to authenticate with the server. |
 | Password                 |   *      | User's password. |

-# Scheduling
+## Scheduling

 Choose what hypervisor the virtual machine will be scheduled to. 

@@ -34,7 +30,7 @@ Choose what hypervisor the virtual machine will be scheduled to.
 | Data Store               |   *      | Datastore to store the VM disks. |
 | Folder                   |          | Name of a folder in the datacenter to create the VMs in. Must already exist. The folder name should be prefaced with `vm/` in your vSphere config file. |

-# Instance Options
+## Instance Options
 In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template.

 Only VMs booting from RancherOS ISO are supported.
@@ -50,7 +46,7 @@ Ensure that the OS ISO URL contains the URL of the VMware ISO release for Ranche
 | OS ISO URL               |   *      | URL of a RancherOS vSphere ISO file to boot the VMs from. You can find URLs for specific versions in the [Rancher OS GitHub Repo](https://github.com/rancher/os). |
 | Configuration Parameters |          | Additional configuration parameters for the VMs. These correspond to the [Advanced Settings](https://kb.vmware.com/s/article/1016098) in the vSphere console. Example use cases include providing RancherOS [guestinfo]({{<baseurl>}}/os/v1.x/en/installation/cloud/vmware-esxi/#vmware-guestinfo) parameters or enabling disk UUIDs for the VMs (`disk.EnableUUID=TRUE`). |

-# Node Tags and Custom Attributes
+## Node Tags and Custom Attributes

 These attributes allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects.

@@ -62,7 +58,7 @@ Optionally, you can:

 > **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere. 

-# Cloud Init
+## Cloud Init

 [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network.

@@ -5,13 +5,9 @@ weight: 3
 aliases:
  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.2.0/
 ---
- [Account Access](#account-access)
- [Scheduling](#scheduling)
- [Instance Options](#instance-options)
- [Node tags and custom attributes](#node-tags-and-custom-attributes)
- [Cloud Init](#cloud-init)

-# Account Access
+
+## Account Access

 | Parameter                | Required | Description |
 |:----------------------|:--------:|:-----|
@@ -25,7 +21,7 @@ Your cloud credential has these fields:
 | Port | Optional: configure configure the port of the vCenter or ESXi server. |
 | Username and password | Enter your vSphere login username and password. |

-# Scheduling
+## Scheduling
 Choose what hypervisor the virtual machine will be scheduled to. 

 | Parameter                | Required | Description |
@@ -37,7 +33,7 @@ Choose what hypervisor the virtual machine will be scheduled to.
 | Data Store               |   *      | Datastore to store the VM disks. |
 | Folder                   |          | Name of a folder in the datacenter to create the VMs in. Must already exist. The folder name should be prefaced with `vm/` in your vSphere config file. |

-# Instance Options
+## Instance Options

 In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template.

@@ -54,7 +50,7 @@ Ensure that the OS ISO URL contains the URL of the VMware ISO release for Ranche
 | OS ISO URL               |   *      | URL of a RancherOS vSphere ISO file to boot the VMs from. You can find URLs for specific versions in the [Rancher OS GitHub Repo](https://github.com/rancher/os). |
 | Configuration Parameters |          | Additional configuration parameters for the VMs. These correspond to the [Advanced Settings](https://kb.vmware.com/s/article/1016098) in the vSphere console. Example use cases include providing RancherOS [guestinfo]({{<baseurl>}}/os/v1.x/en/installation/cloud/vmware-esxi/#vmware-guestinfo) parameters or enabling disk UUIDs for the VMs (`disk.EnableUUID=TRUE`). |

-# Node Tags and Custom Attributes
+## Node Tags and Custom Attributes

 These attributes allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects.

@@ -66,7 +62,7 @@ Optionally, you can:

 > **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere. 

-# Cloud Init
+## Cloud Init
 [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network.

 You may specify the URL of a RancherOS cloud-config.yaml file in the the **Cloud Init** field. Refer to the [RancherOS Documentation](https://rancher.com/docs/os/v1.x/en/configuration/#cloud-config) for details on the supported configuration directives. Note that the URL must be network accessible from the VMs created by the template.
@@ -5,13 +5,8 @@ weight: 2
 aliases:
  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.3.0/
 ---
- [Account Access](#account-access)
- [Scheduling](#scheduling)
- [Instance Options](#instance-options)
- [Node tags and custom attributes](#node-tags-and-custom-attributes)
- [Cloud Init](#cloud-init)

-# Account Access
+## Account Access

 | Parameter                | Required | Description |
 |:----------------------|:--------:|:-----|
@@ -25,7 +20,7 @@ Your cloud credential has these fields:
 | Port | Optional: configure configure the port of the vCenter or ESXi server. |
 | Username and password | Enter your vSphere login username and password. |

-# Scheduling
+## Scheduling
 Choose what hypervisor the virtual machine will be scheduled to. 

 In the **Scheduling** section, enter: 
@@ -43,7 +38,7 @@ In the **Scheduling** section, enter:
 | Data Store               |   *      | Datastore to store the VM disks. |
 | Folder                   |          | Name of a folder in the datacenter to create the VMs in. Must already exist. The folder name should be prefaced with `vm/` in your vSphere config file. |

-# Instance Options
+## Instance Options

 In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template.

@@ -61,7 +56,7 @@ Ensure that the OS ISO URL contains the URL of the VMware ISO release for Ranche
 | Configuration Parameters |          | Additional configuration parameters for the VMs. These correspond to the [Advanced Settings](https://kb.vmware.com/s/article/1016098) in the vSphere console. Example use cases include providing RancherOS [guestinfo]({{<baseurl>}}/os/v1.x/en/installation/cloud/vmware-esxi/#vmware-guestinfo) parameters or enabling disk UUIDs for the VMs (`disk.EnableUUID=TRUE`). |


-# Node Tags and Custom Attributes
+## Node Tags and Custom Attributes

 These attributes allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects.

@@ -73,7 +68,7 @@ Optionally, you can:

 > **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere. 

-# Cloud Init
+## Cloud Init

 [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network.

@@ -5,14 +5,9 @@ weight: 1
 aliases:
  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.3.3/
 ---
- [Account Access](#account-access)
- [Scheduling](#scheduling)
- [Instance Options](#instance-options)
- [Networks](#networks)
- [Node tags and custom attributes](#node-tags-and-custom-attributes)
- [cloud-init](#cloud-init)

-# Account Access
+
+## Account Access

 | Parameter                | Required | Description |
 |:----------------------|:--------:|:-----|
@@ -26,7 +21,7 @@ Your cloud credential has these fields:
 | Port | Optional: configure configure the port of the vCenter or ESXi server. |
 | Username and password | Enter your vSphere login username and password. |

-# Scheduling
+## Scheduling

 Choose what hypervisor the virtual machine will be scheduled to. 

@@ -40,7 +35,7 @@ The fields in the **Scheduling** section should auto-populate with the data cent
 | Folder |    |  Name of a folder in the datacenter to create the VMs in. Must already exist. The VM folders in this dropdown menu directly correspond to your VM folders in vSphere. The folder name should be prefaced with `vm/` in your vSphere config file. |
 | Host |  | The IP of the host system to schedule VMs in. Leave this field blank for a standalone ESXi or for a cluster with DRS (Distributed Resource Scheduler). If specified, the host system's pool will be used and the **Resource Pool** parameter will be ignored.   |

-# Instance Options
+## Instance Options

 In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template.

@@ -68,11 +63,11 @@ Choose the way that the VM will be created:
 - **Clone an existing virtual machine:** In the **Virtual machine** field, choose an existing VM that the new VM will be cloned from.
 - **Install from boot2docker ISO:** Ensure that the **OS ISO URL** field contains the URL of a VMware ISO release for RancherOS (`rancheros-vmware.iso`). Note that this URL must be accessible from the nodes running your Rancher server installation.

-# Networks
+## Networks

 The node template now allows a VM to be provisioned with multiple networks. In the **Networks** field, you can now click **Add Network** to add any networks available to you in vSphere.

-# Node Tags and Custom Attributes
+## Node Tags and Custom Attributes

 Tags allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects.

@@ -82,7 +77,7 @@ In the custom attributes, Rancher will let you select all the custom attributes

 > **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere.

-# cloud-init
+## cloud-init

 [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network.

@@ -16,28 +16,8 @@ In Rancher v2.0.0-v2.2.x, the RKE cluster config file in Rancher is identical to

 This section is a cluster configuration reference, covering the following topics:

- [Rancher UI Options](#rancher-ui-options)
-  - [Kubernetes version](#kubernetes-version)
-  - [Network provider](#network-provider)
-  - [Kubernetes cloud providers](#kubernetes-cloud-providers)
-  - [Private registries](#private-registries)
-  - [Authorized cluster endpoint](#authorized-cluster-endpoint)
-  - [Node pools](#node-pools)
- [Advanced Options](#advanced-options)
-  - [NGINX Ingress](#nginx-ingress)
-  - [Node port range](#node-port-range)
-  - [Metrics server monitoring](#metrics-server-monitoring)
-  - [Pod security policy support](#pod-security-policy-support)
-  - [Docker version on nodes](#docker-version-on-nodes)
-  - [Docker root directory](#docker-root-directory)
-  - [Recurring etcd snapshots](#recurring-etcd-snapshots)
- [Cluster config file](#cluster-config-file)
-  - [Config file structure in Rancher v2.3.0+](#config-file-structure-in-rancher-v2-3-0)
-  - [Config file structure in Rancher v2.0.0-v2.2.x](#config-file-structure-in-rancher-v2-0-0-v2-2-x)
-  - [Default DNS provider](#default-dns-provider)
- [Rancher specific parameters](#rancher-specific-parameters)

-# Rancher UI Options
+## Rancher UI Options

 When creating a cluster using one of the options described in [Rancher Launched Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md), you can configure basic Kubernetes options using the **Cluster Options** section.

@@ -120,7 +100,7 @@ We recommend using a load balancer with the authorized cluster endpoint. For det

 For information on using the Rancher UI to set up node pools in an RKE cluster, refer to [this page.](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)

-# Advanced Options
+## Advanced Options

 The following options are available when you create clusters in the Rancher UI. They are located under **Advanced Options.**

@@ -152,7 +132,7 @@ If the nodes you are adding to the cluster have Docker configured with a non-def

 Option to enable or disable [recurring etcd snapshots](https://rancher.com/docs/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots).

-# Cluster Config File
+## Cluster Config File

 Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available](https://rancher.com/docs/rke/latest/en/config-options/) in an RKE installation, except for `system_images` configuration. The `system_images` option is not supported when creating a cluster with the Rancher UI or API.

@@ -8,22 +8,8 @@ aliases:

 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)
- [Architecture](#architecture)
- [Create the EKS Cluster](#create-the-eks-cluster)
- [EKS Cluster Configuration Reference](#eks-cluster-configuration-reference)
- [Troubleshooting](#troubleshooting)
- [AWS Service Events](#aws-service-events)
- [Security and Compliance](#security-and-compliance)
- [Tutorial](#tutorial)
- [Minimum EKS Permissions](#minimum-eks-permissions)
-  - [Service Role Permissions](#service-role-permissions)
-  - [VPC Permissions](#vpc-permissions)
- [Syncing](#syncing)

-# Prerequisites in Amazon Web Services
+## Prerequisites in Amazon Web Services

 >**Note**
 >Deploying to Amazon AWS will incur charges. For more information, refer to the [EKS pricing page](https://aws.amazon.com/eks/pricing/).
@@ -48,7 +34,7 @@ Rancher needs access to your AWS account in order to provision and administer yo

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

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

@@ -56,7 +42,7 @@ The figure below illustrates the high-level architecture of Rancher 2.x. The fig

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

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

 Use Rancher to set up and configure your Kubernetes cluster.

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


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

 ### Account Access

@@ -194,7 +180,7 @@ Custom AMI Override | If you want to use a custom [Amazon Machine Image](https:/
 Desired ASG Size | The number of instances that your cluster will provision.
 User Data | Custom commands can to be passed to perform automated configuration tasks **WARNING: Modifying this may cause your nodes to be unable to join the cluster.** _Note: Available as of v2.2.0_

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

@@ -202,21 +188,21 @@ If an unauthorized error is returned while attempting to modify or import the cl

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

-# 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 be imported in Rancher unless the credentials used to import 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

 Documented here is a minimum set of permissions necessary to use all functionality of the EKS driver in Rancher. Additional permissions are required for Rancher to provision the `Service Role` and `VPC` resources. Optionally these resources can be created **before** the cluster creation and will be selectable when defining the cluster configuration.

@@ -14,18 +14,8 @@ For help choosing a Helm chart version, refer to [this page.](../../getting-star

 For information on enabling experimental features, refer to [this page.](../../pages-for-subheaders/enable-experimental-features.md)

- [Common Options](#common-options)
- [Advanced Options](#advanced-options)
- [API Audit Log](#api-audit-log)
- [Setting Extra Environment Variables](#setting-extra-environment-variables)
- [TLS Settings](#tls-settings)
- [Customizing your Ingress](#customizing-your-ingress)
- [HTTP Proxy](#http-proxy)
- [Additional Trusted CAs](#additional-trusted-cas)
- [Private Registry and Air Gap Installs](#private-registry-and-air-gap-installs)
- [External TLS Termination](#external-tls-termination)

-### Common Options
+## Common Options

 | Option                    | Default Value | Description                                                                        |
 | ------------------------- | ------------- | ---------------------------------------------------------------------------------- |
@@ -37,7 +27,7 @@ For information on enabling experimental features, refer to [this page.](../../p

 <br/>

-### Advanced Options
+## Advanced Options

 | Option                         | Default Value                                         | Description                                                                                                                                       |
 | ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -5,34 +5,24 @@ weight: 4

 This page explains concepts related to Kubernetes that are important for understanding how Rancher works. The descriptions below provide a simplified interview of Kubernetes components. For more details, refer to the [official documentation on Kubernetes components.](https://kubernetes.io/docs/concepts/overview/components/)

-This section covers the following topics:

- [About Docker](#about-docker)
- [About Kubernetes](#about-kubernetes)
- [What is a Kubernetes Cluster?](#what-is-a-kubernetes-cluster)
- [Roles for Nodes in Kubernetes Clusters](#roles-for-nodes-in-kubernetes-clusters)
-  - [etcd Nodes](#etcd-nodes)
-  - [Controlplane Nodes](#controlplane-nodes)
-  - [Worker Nodes](#worker-nodes)
- [About Helm](#about-helm)
-
-# About Docker
+## About Docker

 Docker is the container packaging and runtime standard. Developers build container images from Dockerfiles and distribute container images from Docker registries. [Docker Hub](https://hub.docker.com) is the most popular public registry. Many organizations also set up private Docker registries. Docker is primarily used to manage containers on individual nodes.

 >**Note:** Although Rancher 1.6 supported Docker Swarm clustering technology, it is no longer supported in Rancher 2.x due to the success of Kubernetes.

-# About Kubernetes
+## About Kubernetes

 Kubernetes is the container cluster management standard. YAML files specify containers and other resources that form an application. Kubernetes performs functions such as scheduling, scaling, service discovery, health check, secret management, and configuration management.

-# What is a Kubernetes Cluster?
+## What is a Kubernetes Cluster?

 A cluster is a group of computers that work together as a single system.

 A _Kubernetes Cluster_ is a cluster that uses the [Kubernetes container-orchestration system](https://kubernetes.io/) to deploy, maintain, and scale Docker containers, allowing your organization to automate application operations.

-# Roles for Nodes in Kubernetes Clusters
+## Roles for Nodes in Kubernetes Clusters

 Each computing resource in a Kubernetes cluster is called a _node_. Nodes can be either bare-metal servers or virtual machines. Kubernetes classifies nodes into three types: _etcd_ nodes, _control plane_ nodes, and _worker_ nodes.

@@ -63,7 +53,7 @@ Each [worker node](https://kubernetes.io/docs/concepts/architecture/nodes/) runs

 Worker nodes also run storage and networking drivers, and ingress controllers when required. You create as many worker nodes as necessary to run your  [workloads](../pages-for-subheaders/workloads-and-pods.md).

-# About Helm
+## About Helm

 For high-availability installations of Rancher, Helm is the tool used to install Rancher on a Kubernetes cluster.

@@ -29,24 +29,24 @@ This section assumes that you understand how persistent storage works in Kuberne

 1.  Complete the form that displays to choose a persistent volume for the internal Docker registry.
    <Tabs>
-      <TabItem value="Add a new persistent volume">
+    <TabItem value="Add a new persistent volume">

-        1. Enter a **Name** for the volume claim.
-        1. Select a volume claim **Source**:
-            - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
-            - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
-        1. From the **Customize** section, choose the read/write access for the volume.
-        1. Click **Define**.
+      1. Enter a **Name** for the volume claim.
+      1. Select a volume claim **Source**:
+          - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
+          - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
+      1. From the **Customize** section, choose the read/write access for the volume.
+      1. Click **Define**.

-      </TabItem>
-      <TabItem value="Use an existing persistent volume">
+    </TabItem>
+    <TabItem value="Use an existing persistent volume">

-        1. Enter a **Name** for the volume claim.
-        1. Choose a **Persistent Volume Claim** from the drop-down.
-        1. From the **Customize** section, choose the read/write access for the volume.
-        1. Click **Define**.
+      1. Enter a **Name** for the volume claim.
+      1. Choose a **Persistent Volume Claim** from the drop-down.
+      1. From the **Customize** section, choose the read/write access for the volume.
+      1. Click **Define**.

-      </TabItem>
+    </TabItem>
    </Tabs>

 1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container.
@@ -64,24 +64,24 @@ This section assumes that you understand how persistent storage works in Kuberne

 1.  Complete the form that displays to choose a persistent volume for the internal Docker registry.
    <Tabs>
-      <TabItem value="Add a new persistent volume">
+    <TabItem value="Add a new persistent volume">

-        1. Enter a **Name** for the volume claim.
-        1. Select a volume claim **Source**:
-            - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
-            - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
-        1. From the **Customize** section, choose the read/write access for the volume.
-        1. Click **Define**.
+      1. Enter a **Name** for the volume claim.
+      1. Select a volume claim **Source**:
+          - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
+          - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
+      1. From the **Customize** section, choose the read/write access for the volume.
+      1. Click **Define**.

-      </TabItem>
-      <TabItem value="Use an existing persistent volume">
+    </TabItem>
+    <TabItem value="Use an existing persistent volume">

-        1. Enter a **Name** for the volume claim.
-        1. Choose a **Persistent Volume Claim** from the drop-down.
-        1. From the **Customize** section, choose the read/write access for the volume.
-        1. Click **Define**.
+      1. Enter a **Name** for the volume claim.
+      1. Choose a **Persistent Volume Claim** from the drop-down.
+      1. From the **Customize** section, choose the read/write access for the volume.
+      1. Click **Define**.

-      </TabItem>
+    </TabItem>
    </Tabs>

 1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container.
@@ -7,26 +7,8 @@ aliases:

 In this section, you'll learn how to configure pipelines.

- [Step Types](#step-types)
- [Step Type: Run Script](#step-type-run-script)
- [Step Type: Build and Publish Images](#step-type-build-and-publish-images)
- [Step Type: Publish Catalog Template](#step-type-publish-catalog-template)
- [Step Type: Deploy YAML](#step-type-deploy-yaml)
- [Step Type: Deploy Catalog App](#step-type-deploy-catalog-app)
- [Notifications](#notifications)
- [Timeouts](#timeouts)
- [Triggers and Trigger Rules](#triggers-and-trigger-rules)
- [Environment Variables](#environment-variables)
- [Secrets](#secrets)
- [Pipeline Variable Substitution Reference](#pipeline-variable-substitution-reference)
- [Global Pipeline Execution Settings](#global-pipeline-execution-settings)
-  - [Executor Quota](#executor-quota)
-  - [Resource Quota for Executors](#resource-quota-for-executors)
-  - [Custom CA](#custom-ca)
- [Persistent Data for Pipeline Components](#persistent-data-for-pipeline-components)
- [Example rancher-pipeline.yml](#example-rancher-pipeline-yml)

-# Step Types
+## Step Types

 Within each stage, you can add as many steps as you'd like. When there are multiple steps in one stage, they run concurrently.

@@ -82,7 +64,7 @@ stages:
        pushRemote: true
        registry: reg.example.com
 ```
-# Step Type: Run Script
+## Step Type: Run Script

 The **Run Script** step executes arbitrary commands in the workspace inside a specified container. You can use it to build, test and do more, given whatever utilities the base image provides. For your convenience, you can use variables to refer to metadata of a pipeline execution. Please refer to the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) for the list of available variables.

@@ -102,7 +84,7 @@ stages:
      image: golang
      shellScript: go build
 ```
-# Step Type: Build and Publish Images
+## Step Type: Build and Publish Images

 _Available as of Rancher v2.1.0_

@@ -154,7 +136,7 @@ stages:
      PLUGIN_INSECURE: "true"
 ```

-# Step Type: Publish Catalog Template
+## Step Type: Publish Catalog Template

 _Available as of v2.2.0_

@@ -212,7 +194,7 @@ stages:
      sourceKey: DEPLOY_KEY
 ```

-# Step Type: Deploy YAML
+## Step Type: Deploy YAML

 This step deploys arbitrary Kubernetes resources to the project. This deployment requires a Kubernetes manifest file to be present in the source code repository. Pipeline variable substitution is supported in the manifest file. You can view an example file at [GitHub](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml). Please refer to the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) for the list of available variables.

@@ -235,7 +217,7 @@ stages:
      path: ./deployment.yaml
 ```

-# Step Type :Deploy Catalog App
+## Step Type :Deploy Catalog App

 _Available as of v2.2.0_

@@ -283,7 +265,7 @@ stages:
      targetNamespace: test
 ```

-# Timeouts
+## Timeouts

 By default, each pipeline execution has a timeout of 60 minutes. If the pipeline execution cannot complete within its timeout period, the pipeline is aborted.

@@ -307,7 +289,7 @@ stages:
 timeout: 30
 ```

-# Notifications
+## Notifications

 You can enable notifications to any [notifiers](../../explanations/integrations-in-rancher/notifiers.md) based on the build status of a pipeline. Before enabling notifications, Rancher recommends [setting up notifiers](../../explanations/integrations-in-rancher/notifiers.md) so it will be easy to add recipients immediately.

@@ -358,7 +340,7 @@ notification:
  message: "my-message"
 ```

-# Triggers and Trigger Rules
+## Triggers and Trigger Rules

 After you configure a pipeline, you can trigger it using different methods:

@@ -382,12 +364,6 @@ If all conditions evaluate to `true`, then the pipeline/stage/step is executed.

 Wildcard character (`*`) expansion is supported in `branch` conditions.

-This section covers the following topics:
-
- [Configuring pipeline triggers](#configuring-pipeline-triggers)
- [Configuring stage triggers](#configuring-stage-triggers)
- [Configuring step triggers](#configuring-step-triggers)
- [Configuring triggers by YAML](#configuring-triggers-by-yaml)

 ### Configuring Pipeline Triggers

@@ -483,7 +459,7 @@ branch:
  exclude: [ dev ]
 ```

-# Environment Variables
+## Environment Variables

 When configuring a pipeline, certain [step types](#step-types) allow you to use environment variables to configure the step's script.

@@ -520,7 +496,7 @@ stages:
        SECOND_KEY: VALUE2
 ```

-# Secrets
+## Secrets

 If you need to use security-sensitive information in your pipeline scripts (like a password), you can pass them in using Kubernetes [secrets](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md).

@@ -563,7 +539,7 @@ stages:
        targetKey: ALIAS_ENV
 ```

-# Pipeline Variable Substitution Reference
+## Pipeline Variable Substitution Reference

 For your convenience, the following variables are available for your pipeline configuration scripts. During pipeline executions, these variables are replaced by metadata. You can reference them in the form of `${VAR_NAME}`.

@@ -582,7 +558,7 @@ Variable Name           | Description
 `CICD_REGISTRY`           | Address for the Docker registry for the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step.
 `CICD_IMAGE`              | Name of the image built from the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step. It does not contain the image tag.<br/><br/> [Example](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml)

-# Global Pipeline Execution Settings
+## Global Pipeline Execution Settings

 After configuring a version control provider, there are several options that can be configured globally on how pipelines are executed in Rancher. These settings can be edited by selecting **Tools > Pipelines** in the navigation bar. In versions before v2.2.0, you can select **Resources > Pipelines**.

@@ -649,12 +625,12 @@ If you want to use a version control provider with a certificate from a custom/i

 **Result:** Pipelines can be used and new pods will be able to work with the self-signed-certificate.

-# Persistent Data for Pipeline Components
+## Persistent Data for Pipeline Components

 The internal Docker registry and the Minio workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.

 For details on setting up persistent storage for pipelines, refer to [this page.](./configure-persistent-data.md)

-# Example rancher-pipeline.yml
+## Example rancher-pipeline.yml

 An example pipeline configuration file is on [this page.](./example-yaml.md)
@@ -5,19 +5,7 @@ aliases:
  - /rancher/v2.0-v2.4/en/toolcluster-admin/tools/notifiers-and-alerts/
 ---

-Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into following categories:
-
-<!-- TOC -->
-
- [Logging](#logging)
- [Monitoring](#monitoring)
- [Alerts](#alerts)
- [Notifiers](#notifiers)
- [Istio](#istio)
- [OPA Gatekeeper](#opa-gatekeeper)
- [CIS Scans](#cis-scans)
-
-<!-- /TOC -->
+Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently.


 # Logging
@@ -5,15 +5,6 @@ weight: 3

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

-This section covers the following topics:
-
- [Separation of Rancher and User Clusters](#separation-of-rancher-and-user-clusters)
- [Why HA is Better for Rancher in Production](#why-ha-is-better-for-rancher-in-production)
- [Recommended Load Balancer Configuration for Kubernetes Installations](#recommended-load-balancer-configuration-for-kubernetes-installations)
- [Environment for Kubernetes Installations](#environment-for-kubernetes-installations)
- [Recommended Node Roles for Kubernetes Installations](#recommended-node-roles-for-kubernetes-installations)
- [Architecture for an Authorized Cluster Endpoint](#architecture-for-an-authorized-cluster-endpoint)
-
 # Separation of Rancher and User Clusters

 A user cluster is a downstream Kubernetes cluster that runs your apps and services.
@@ -75,7 +75,7 @@ With this endpoint enabled for the downstream cluster, Rancher generates an extr

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

-# Important Files
+## Important Files

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

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

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

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

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

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

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

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

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

@@ -16,20 +16,8 @@ Before you can receive alerts, one or more [notifier](../../explanations/integra

 Only [administrators](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md), [cluster owners or members](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), or [project owners](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) can manage project alerts.

-This section covers the following topics:

- [Alerts scope](#alerts-scope)
- [Default project-level alerts](#default-project-level-alerts)
- [Adding project alerts](#adding-project-alerts)
- [Managing project alerts](#managing-project-alerts)
- [Project Alert Rule Configuration](#project-alert-rule-configuration)
-  - [Pod Alerts](#pod-alerts)
-  - [Workload Alerts](#workload-alerts)
-  - [Workload Selector Alerts](#workload-selector-alerts)
-  - [Metric Expression Alerts](#metric-expression-alerts)
-
-
-# Alerts Scope
+## Alerts Scope

 The scope for alerts can be set at either the [cluster level](../../pages-for-subheaders/cluster-alerts.md) or project level.

@@ -40,7 +28,7 @@ At the project level, Rancher monitors specific deployments and sends alerts for
 * Pod status
 * The Prometheus expression cross the thresholds

-# Default Project-level Alerts
+## Default Project-level Alerts

 When you enable monitoring for the project, some project-level alerts are provided. You can receive these alerts if a [notifier](../../explanations/integrations-in-rancher/notifiers.md) for them is configured at the cluster level.

@@ -51,7 +39,7 @@ When you enable monitoring for the project, some project-level alerts are provid

 For information on other default alerts, refer to the section on [cluster-level alerts.](../../explanations/integrations-in-rancher/cluster-alerts/default-alerts.md)

-# Adding Project Alerts
+## Adding Project Alerts

 >**Prerequisite:** Before you can receive project alerts, you must add a notifier.

@@ -75,7 +63,7 @@ For information on other default alerts, refer to the section on [cluster-level
 **Result:** Your alert is configured. A notification is sent when the alert is triggered.


-# Managing Project Alerts
+## Managing Project Alerts

 To manage project alerts, browse to the project that alerts you want to manage. Then select **Tools > Alerts**. In versions before v2.2.0, you can choose **Resources > Alerts**. You can:

@@ -86,14 +74,14 @@ To manage project alerts, browse to the project that alerts you want to manage.
 - Unmute muted alerts


-# Project Alert Rule Configuration
+## Project Alert Rule Configuration

 - [Pod Alerts](#pod-alerts)
 - [Workload Alerts](#workload-alerts)
 - [Workload Selector Alerts](#workload-selector-alerts)
 - [Metric Expression Alerts](#metric-expression-alerts)

-# Pod Alerts
+## Pod Alerts

 This alert type monitors for the status of a specific pod.

@@ -131,7 +119,7 @@ You can disable these advanced options when configuring a specific rule.
 - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
 - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.

-# Workload Alerts
+## Workload Alerts

 This alert type monitors for the availability of a workload.

@@ -165,7 +153,7 @@ You can disable these advanced options when configuring a specific rule.
 - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
 - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.

-# Workload Selector Alerts
+## Workload Selector Alerts

 This alert type monitors for the availability of all workloads marked with tags that you've specified.

@@ -199,7 +187,7 @@ You can disable these advanced options when configuring a specific rule.
 - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
 - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.

-# Metric Expression Alerts
+## Metric Expression Alerts
 _Available as of v2.2.4_

 If you enable [project monitoring](../../pages-for-subheaders/project-tools.md#monitoring), this alert type monitors for the overload from Prometheus expression querying.
@@ -1,5 +1,5 @@
 ---
-title: Example YAML
+title: RKE1 Example YAML
 weight: 60
 ---

@@ -5,25 +5,8 @@ weight: 1

 This section contains commands and tips for troubleshooting nodes with the `etcd` role.

-This page covers the following topics:

- [Checking if the etcd Container is Running](#checking-if-the-etcd-container-is-running)
- [etcd Container Logging](#etcd-container-logging)
- [etcd Cluster and Connectivity Checks](#etcd-cluster-and-connectivity-checks)
-  - [Check etcd Members on all Nodes](#check-etcd-members-on-all-nodes)
-  - [Check Endpoint Status](#check-endpoint-status)
-  - [Check Endpoint Health](#check-endpoint-health)
-  - [Check Connectivity on Port TCP/2379](#check-connectivity-on-port-tcp-2379)
-  - [Check Connectivity on Port TCP/2380](#check-connectivity-on-port-tcp-2380)
- [etcd Alarms](#etcd-alarms)
- [etcd Space Errors](#etcd-space-errors)
- [Log Level](#log-level)
- [etcd Content](#etcd-content)
-  - [Watch Streaming Events](#watch-streaming-events)
-  - [Query etcd Directly](#query-etcd-directly)
- [Replacing Unhealthy etcd Nodes](#replacing-unhealthy-etcd-nodes)
-
-# Checking if the etcd Container is Running
+## Checking if the etcd Container is Running

 The container for etcd should have status **Up**. The duration shown after **Up** is the time the container has been running.

@@ -37,7 +20,7 @@ CONTAINER ID        IMAGE                         COMMAND                  CREAT
 605a124503b9        rancher/coreos-etcd:v3.2.18   "/usr/local/bin/et..."   2 hours ago         Up 2 hours                              etcd
 ```

-# etcd Container Logging
+## etcd Container Logging

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

@@ -52,7 +35,7 @@ docker logs etcd
 | `rafthttp: request cluster ID mismatch` | The node with the etcd instance logging `rafthttp: request cluster ID mismatch` is trying to join a cluster that has already been formed with another peer. The node should be removed from the cluster, and re-added. |
 | `rafthttp: failed to find member` | The cluster state (`/var/lib/etcd`) contains wrong information to join the cluster. The node should be removed from the cluster, the state directory should be cleaned and the node should be re-added.

-# etcd Cluster and Connectivity Checks
+## etcd Cluster and Connectivity Checks

 The address where etcd is listening depends on the address configuration of the host etcd is running on. If an internal address is configured for the host etcd is running on, the endpoint for `etcdctl` needs to be specified explicitly. If any of the commands respond with `Error:  context deadline exceeded`, the etcd instance is unhealthy (either quorum is lost or the instance is not correctly joined in the cluster)

@@ -177,7 +160,7 @@ Validating connection to https://IP:2380/version
 {"etcdserver":"3.2.18","etcdcluster":"3.2.0"}
 ```

-# etcd Alarms
+## etcd Alarms

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

@@ -198,7 +181,7 @@ memberID:x alarm:NOSPACE
 memberID:x alarm:NOSPACE
 ```

-# etcd Space Errors
+## etcd Space Errors

 Related error messages are `etcdserver: mvcc: database space exceeded` or `applying raft message exceeded backend quota`. Alarm `NOSPACE` will be triggered.

@@ -298,7 +281,7 @@ docker exec etcd etcdctl alarm disarm
 docker exec etcd etcdctl alarm list
 ```

-# Log Level
+## Log Level

 The log level of etcd can be changed dynamically via the API. You can configure debug logging using the commands below.

@@ -324,7 +307,7 @@ Command when using etcd version lower than 3.3.x (Kubernetes 1.13.x and lower) a
 docker run --net=host -v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -XPUT -d '{"Level":"INFO"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) $(docker exec etcd printenv ETCDCTL_ENDPOINT)/config/local/log
 ```

-# etcd Content
+## etcd Content

 If you want to investigate the contents of your etcd, you can either watch streaming events or you can query etcd directly, see below for examples.

@@ -360,6 +343,6 @@ You can process the data to get a summary of count per key, using the command be
 docker exec etcd etcdctl get /registry --prefix=true --keys-only | grep -v ^$ | awk -F'/' '{ if ($3 ~ /cattle.io/) {h[$3"/"$4]++} else { h[$3]++ }} END { for(k in h) print h[k], k }' | sort -nr
 ```

-# Replacing Unhealthy etcd Nodes
+## Replacing Unhealthy etcd Nodes

 When a node in your etcd cluster becomes unhealthy, the recommended approach is to fix or remove the failed or unhealthy node before adding a new etcd node to the cluster.
@@ -7,31 +7,7 @@ The commands/steps listed on this page can be used to check the most important K

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

- [Nodes](#nodes)
-  - [Get nodes](#get-nodes)
-  - [Get node conditions](#get-node-conditions)
- [Kubernetes leader election](#kubernetes-leader-election)
-  - [Kubernetes controller manager leader](#kubernetes-controller-manager-leader)
-  - [Kubernetes scheduler leader](#kubernetes-scheduler-leader)
- [Ingress controller](#ingress-controller)
-  - [Pod details](#pod-details)
-  - [Pod container logs](#pod-container-logs)
-  - [Namespace events](#namespace-events)
-  - [Debug logging](#debug-logging)
-  - [Check configuration](#check-configuration)
- [Rancher agents](#rancher-agents)
-  - [cattle-node-agent](#cattle-node-agent)
-  - [cattle-cluster-agent](#cattle-cluster-agent)
- [Jobs and pods](#jobs-and-pods)
-  - [Check that pods or jobs have status Running/Completed](#check-that-pods-or-jobs-have-status-running-completed)
-  - [Describe pod](#describe-pod)
-  - [Pod container logs](#pod-container-logs)
-  - [Describe job](#describe-job)
-  - [Logs from the containers of pods of the job](#logs-from-the-containers-of-pods-of-the-job)
-  - [Evicted pods](#evicted-pods)
-  - [Job does not complete](#job-does-not-complete)
-
-# Nodes
+## Nodes

 ### Get nodes

@@ -76,7 +52,7 @@ Example output:
 worker-0: DiskPressure:True
 ```

-# Kubernetes leader election
+## Kubernetes leader election

 ### Kubernetes Controller Manager leader

@@ -96,7 +72,7 @@ kubectl -n kube-system get endpoints kube-scheduler -o jsonpath='{.metadata.anno
 {"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}>
 ```

-# Ingress Controller
+## Ingress Controller

 The default Ingress Controller is NGINX and is deployed as a DaemonSet in the `ingress-nginx` namespace. The pods are only scheduled to nodes with the `worker` role.

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

-# Rancher agents
+## Rancher agents

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

@@ -204,7 +180,7 @@ Check logging of cattle-cluster-agent pod:
 kubectl -n cattle-system logs -l app=cattle-cluster-agent
 ```

-# Jobs and Pods
+## Jobs and Pods

 ### Check that pods or jobs have status **Running**/**Completed**

@@ -19,31 +19,8 @@ You can configure the Kubernetes options one of two ways:

 The RKE cluster config options are nested under the `rancher_kubernetes_engine_config` directive. For more information, see the section about the [cluster config file.](#cluster-config-file)

-This section is a cluster configuration reference, covering the following topics:

- [Rancher UI Options](#rancher-ui-options)
-  - [Kubernetes version](#kubernetes-version)
-  - [Network provider](#network-provider)
-  - [Project network isolation](#project-network-isolation)
-  - [Kubernetes cloud providers](#kubernetes-cloud-providers)
-  - [Private registries](#private-registries)
-  - [Authorized cluster endpoint](#authorized-cluster-endpoint)
-  - [Node pools](#node-pools)
- [Advanced Options](#advanced-options)
-  - [NGINX Ingress](#nginx-ingress)
-  - [Node port range](#node-port-range)
-  - [Metrics server monitoring](#metrics-server-monitoring)
-  - [Pod security policy support](#pod-security-policy-support)
-  - [Docker version on nodes](#docker-version-on-nodes)
-  - [Docker root directory](#docker-root-directory)
-  - [Recurring etcd snapshots](#recurring-etcd-snapshots)
-  - [Agent Environment Variables](#agent-environment-variables)
- [Cluster config file](#cluster-config-file)
-  - [Config file structure in Rancher v2.3.0+](#config-file-structure-in-rancher-v2-3-0)
-  - [Default DNS provider](#default-dns-provider)
- [Rancher specific parameters](#rancher-specific-parameters)
-
-# Rancher UI Options
+## Rancher UI Options

 When creating a cluster using one of the options described in [Rancher Launched Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md), you can configure basic Kubernetes options using the **Cluster Options** section.

@@ -125,7 +102,7 @@ We recommend using a load balancer with the authorized cluster endpoint. For det

 For information on using the Rancher UI to set up node pools in an RKE cluster, refer to [this page.](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)

-# Advanced Options
+## Advanced Options

 The following options are available when you create clusters in the Rancher UI. They are located under **Advanced Options.**

@@ -164,7 +141,7 @@ _Available as of v2.5.6_
 Option to set environment variables for [rancher agents](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/about-rancher-agents.md). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.


-# Cluster Config File
+## Cluster Config File

 Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available](https://rancher.com/docs/rke/latest/en/config-options/) in an RKE installation, except for `system_images` configuration. The `system_images` option is not supported when creating a cluster with the Rancher UI or API.

@@ -19,11 +19,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.
@@ -23,7 +23,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:
@@ -36,7 +36,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`:

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

@@ -17,7 +17,7 @@ For public downstream clusters, it is sufficient to [set the required environmen

 For private nodes or private clusters, the environment variables need to be set on the nodes themselves. Then the environment variables are configured from the Rancher UI, typically when provisioning a custom cluster or when registering the private cluster. For an example of how to set the environment variables on Ubuntu node in a K3s Kubernetes cluster, see [this section.](#setting-environment-variables-on-private-nodes)

-# Required Environment Variables
+## Required Environment Variables

 When adding Fleet agent environment variables for the proxy, replace <PROXY_IP> with your private proxy IP.

@@ -27,7 +27,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,

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

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

 This limits monitoring to specific namespaces. 
@@ -8,7 +8,7 @@ aliases:

 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,

@@ -26,7 +26,7 @@ To uninstall Istio,

 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. From the **Cluster Explorer** view, use the side-nav to select **Namespaces** page 
 1. On the **Namespace** page, you will see a list of namespaces. Go to the namespace where you want to disable and click the select **Edit as Form** or **Edit as Yaml**
@@ -35,6 +35,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.
@@ -11,7 +11,7 @@ For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai
 - [Configuration](#configuration)
 - [YAML Example](#yaml-example)

-# Configuration
+## Configuration

 <Tabs>
 <TabItem value="Rancher v2.5.8+">
@@ -22,14 +22,14 @@ For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai
  - [Outputs](#outputs-2-5-8)
 - [ClusterFlows](#clusterflows-2-5-8)

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

 The `Flows` and `ClusterFlows` can now be configured by filling out forms in the Rancher UI.


 <a id="flows-2-5-8"></a>

-# Flows
+## Flows

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

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

 <a id="clusterflows-2-5-8"></a>

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

@@ -89,7 +89,7 @@ After `ClusterFlow` selects logs from all namespaces in the cluster, logs from t

 <a id="flows-2-5-0"></a>

-# Flows
+## Flows

 A `Flow` defines which logs to collect and filter and which `Output` to send the logs to. The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.

@@ -126,7 +126,7 @@ Because the `Flow` is a namespaced resource, the `Output` must reside in same na

 <a id="clusterflows-2-5-0"></a>

-# ClusterFlows
+## ClusterFlows

 Matches, filters and `Outputs` are also configured for `ClusterFlows`. The only difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces.

@@ -138,7 +138,7 @@ Matches, filters and `Outputs` are also configured for `ClusterFlows`. The only
 </Tabs>


-# YAML Example
+## YAML Example

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

@@ -8,14 +8,8 @@ import TabItem from '@theme/TabItem';

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

 <Tabs>
 <TabItem value="v2.5.8+">
@@ -23,7 +17,7 @@ For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Ban
 - [Outputs](#outputs-2-5-8)
 - [ClusterOutputs](#clusteroutputs-2-5-8)

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

 The `Outputs` and `ClusterOutputs` can now be configured by filling out forms in the Rancher UI.

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

 <a id="clusteroutputs-2-5-8"></a>

-# ClusterOutputs
+## ClusterOutputs

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

@@ -93,7 +87,7 @@ For examples of configuration for each logging plugin supported by the logging o

 <a id="clusteroutputs-2-5-0"></a>

-# ClusterOutputs
+## ClusterOutputs

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

@@ -107,7 +101,7 @@ For example configuration for each logging plugin supported by the logging opera
 </Tabs>


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

 ### Enable/Disable Windows Node Logging

@@ -11,20 +11,8 @@ Among the many features and changes in the new logging functionality is the remo

 > Note: The pre-v2.5 user interface is now referred to as the _Cluster Manager_. The v2.5+ dashboard is referred to as the _Cluster Explorer_.

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

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

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

@@ -84,7 +72,7 @@ This will result in logs from all sources in the namespace (pods) being collecte

 > To collect logs from a project, repeat the above steps for every namespace within the project. Alternatively, you can label your project workloads with a common label (e.g. `project=my-project`) and use a `ClusterFlow` to collect logs from all pods matching this label. 

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


@@ -103,7 +91,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:
@@ -172,7 +160,7 @@ _(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:

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

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

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

 ### New in Rancher v2.5
@@ -3,11 +3,7 @@ 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 +22,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.

@@ -52,13 +48,14 @@ To see the Alertmanager UI, go to the **Cluster Explorer.** In the top left corn
 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.

 To see the Prometheus UI, install `rancher-monitoring`. Then go to the **Cluster Explorer.** In the top left corner, click **Cluster Explorer > Monitoring.** Then 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

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

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

@@ -179,7 +117,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

@@ -249,7 +187,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

@@ -307,7 +245,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
@@ -338,7 +276,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

@@ -375,7 +313,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

@@ -412,7 +350,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

@@ -10,18 +10,7 @@ aliases:
 ---
 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 Cluster Manager Based Permissions](#users-with-rancher-cluster-manager-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:

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

@@ -97,7 +86,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 to attach to a user. 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
@@ -118,7 +107,7 @@ subjects:

  * **`kubectl apply -f monitoring-config-view-role-binding.yaml`

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

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

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

@@ -12,13 +12,13 @@ Starting at Monitoring V2 14.5.100 (used by default in Rancher 2.5.8), Monitorin
 - [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.

--- a/Show More
+++ b/Show More