Convert h1 to h2 (2.5)

2026-09-27 05:28:22 +00:00 · 2022-10-28 17:09:19 -07:00
parent 15a1e067a6
commit bb76e99d20
87 changed files with 319 additions and 336 deletions
@@ -8,7 +8,7 @@ Only admins of the G Suite domain have access to the Admin SDK. Therefore, only

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

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

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

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

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

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

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

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

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

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

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

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

-# Configuration
+## Configuration

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

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

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

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

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

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

-# Restricted Admin
+## Restricted Admin

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

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

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

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

-# Global Permission Assignment
+## Global Permission Assignment

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

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

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

-# Custom Global Permissions
+## Custom Global Permissions

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

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

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

-# Additional Config Options
+## Additional Config Options

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

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

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

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

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

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

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

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

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

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

-# Example Istio Gateway
+## Example Istio Gateway

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

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

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

-# Troubleshooting
+## Troubleshooting

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

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

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

-# Testing
+## Testing

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

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


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

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

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

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

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

 Editing a node lets you:

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

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

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

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

-# Deleting a Node
+## Deleting a Node

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

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

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

-# Scaling Nodes
+## Scaling Nodes

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

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

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

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

-# Cordoning a Node
+## Cordoning a Node

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

-# Draining a Node
+## Draining a Node

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

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

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

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

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

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

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

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

-# Known Issues
+## Known Issues

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

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

 You can enable monitoring with or without SSL.

-# Requirements
+## Requirements

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

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

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

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

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

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

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

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

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

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

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

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

 _Available as of v2.5.4_

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

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

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

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

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

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

-# Configuration
+## Configuration

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

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

-# How Snapshots Work
+## How Snapshots Work

 ### Snapshot Components

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

-# Configuring Recurring Snapshots
+## Configuring Recurring Snapshots

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

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

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

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

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

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

-# Snapshot Backup Targets
+## Snapshot Backup Targets

 Rancher supports two different backup targets:

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

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

-# Viewing Available Snapshots
+## Viewing Available Snapshots

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

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

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

-# Safe Timestamps
+## Safe Timestamps

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

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

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

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

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

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

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

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

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

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

 Configuring an Amazon NLB is a multistage process:

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

-# Requirements
+## Requirements

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

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

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

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

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

 Next, add your Linux nodes to both target groups.

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

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

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

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

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

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

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

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

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

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

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

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

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

-# Prerequisites
+## Prerequisites

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

 Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/) To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script.
-# Installing Kubernetes
+
+## Installing Kubernetes

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

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

-# Installing Kubernetes
+## Installing Kubernetes

 ### Required CLI Tools

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

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

-# Prerequisites
+## Prerequisites

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

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

 Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/) To specify the RKE2 version, use the INSTALL_RKE2_VERSION environment variable when running the RKE2 installation script.
-# Installing Kubernetes
+
+## Installing Kubernetes

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

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

-# etcd
+## etcd

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

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

-# controlplane
+## controlplane

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

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

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

-# worker
+## worker

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

-# References
+## References

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

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

-# Prerequisites
+## Prerequisites

 The vSphere versions supported:

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

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

-# Installation
+## Installation

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

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


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

 The CSI chart by default creates a storageClass.

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

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

-# Prerequisites
+## Prerequisites

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

-# Migration
+## Migration

 ### 1. Install the CPI plugin

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

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

-### Prerequisites
+## Prerequisites

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

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

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

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

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

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

-# IAM Policies
+## IAM Policies

 ### Example IAM Policy

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

-# Preparation in Azure
+## Preparation in Azure

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

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

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

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


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

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

-# Creating a Registry
+## Creating a Registry

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

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

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

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

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


-# Ingress Rule Configuration
+## Ingress Rule Configuration

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

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

-# Creating Secrets
+## Creating Secrets

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

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

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

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

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