Fix tabs: add import statements, specify value, spacing

2026-09-26 13:08:11 +00:00 · 2022-07-14 20:14:23 -07:00
parent afbabffdeb
commit c55f4b2931
122 changed files with 1162 additions and 712 deletions
@@ -6,6 +6,9 @@ aliases:
  - /rancher/v2.x/en/admin-settings/authentication/keycloak/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 If your organization uses Keycloak Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.

 ## Prerequisites
@@ -37,11 +40,13 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati
 ## Getting the IDP Metadata

 <Tabs>
-<TabItem label="Keycloak 5 and earlier">
+<TabItem value="Keycloak 5 and earlier">
+
 To get the IDP metadata, export a `metadata.xml` file from your Keycloak client.
 From the **Installation** tab, choose the **SAML Metadata IDPSSODescriptor** format option and download your file.
+
 </TabItem>
-<TabItem label="Keycloak 6-13">
+<TabItem value="Keycloak 6-13">

 1. From the **Configure** section, click the **Realm Settings** tab.
 1. Click the **General** tab.
@@ -80,7 +85,7 @@ You are left with something similar as the example below:
 ```

 </TabItem>
-<TabItem label="Keycloak 14+">
+<TabItem value="Keycloak 14+">

 1. From the **Configure** section, click the **Realm Settings** tab.
 1. Click the **General** tab.
@@ -5,6 +5,9 @@ aliases:
  - /rancher/v2.x/en/admin-settings/rbac/global-permissions/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 _Permissions_ are individual access rights that you can assign when selecting a custom permission for a user.

 Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are three default global permissions: `Administrator`, `Standard User` and `User-base`.
@@ -48,7 +51,7 @@ CATTLE_RESTRICTED_DEFAULT_ADMIN=true
 The permissions for the `restricted-admin` role differ based on the Rancher version.

 <Tabs>
-<TabItem label="v2.5.7+">
+<TabItem value="v2.5.7+">

 The `restricted-admin` permissions are as follows:

@@ -57,7 +60,7 @@ The `restricted-admin` permissions are as follows:
 - Can create other restricted admins.

 </TabItem>
-<TabItem label="v2.5.0-v2.5.6">
+<TabItem value="v2.5.0-v2.5.6">

 The `restricted-admin` permissions are as follows:

@@ -7,6 +7,9 @@ aliases:
  - /rancher/v2.x/en/cis-scans/v2.5/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark.

 The `rancher-cis-benchmark` app leverages <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench,</a> an open-source tool from Aqua Security, to check clusters for CIS Kubernetes Benchmark compliance. Also, to generate a cluster-wide report, the application utilizes <a href="https://github.com/vmware-tanzu/sonobuoy" target="_blank">Sonobuoy</a> for report aggregation.
@@ -42,7 +45,8 @@ Support for alerting for the cluster scan results is now also available from Ran
 In Rancher v2.4, permissive and hardened profiles were included. In Rancher v2.5.0 and in v2.5.4, more profiles were included.

 <Tabs>
-<TabItem label="Profiles in v2.5.4">
+<TabItem value="Profiles in v2.5.4">
+
 - Generic CIS 1.5
 - Generic CIS 1.6
 - RKE permissive 1.5
@@ -53,13 +57,16 @@ In Rancher v2.4, permissive and hardened profiles were included. In Rancher v2.5
 - GKE
 - RKE2 permissive 1.5
 - RKE2 permissive 1.5
+
 </TabItem>
-<TabItem label="Profiles in v2.5.0-v2.5.3">
+<TabItem value="Profiles in v2.5.0-v2.5.3">
+
 - Generic CIS 1.5
 - RKE permissive
 - RKE hardened
 - EKS
 - GKE
+
 </TabItem>
 </Tabs>
 <br/>
@@ -68,7 +75,7 @@ In Rancher v2.4, permissive and hardened profiles were included. In Rancher v2.5
 The default profile and the supported CIS benchmark version depends on the type of cluster that will be scanned and the Rancher version:

 <Tabs>
-<TabItem label="v2.5.4">
+<TabItem value="v2.5.4">

 The `rancher-cis-benchmark` supports the CIS 1.6 Benchmark version.

@@ -78,7 +85,7 @@ The `rancher-cis-benchmark` supports the CIS 1.6 Benchmark version.
 - For cluster types other than RKE, RKE2, EKS and GKE, the Generic CIS 1.5 profile will be used by default.

 </TabItem>
-<TabItem label="v2.5.0-v2.5.3">
+<TabItem value="v2.5.0-v2.5.3">

 The `rancher-cis-benchmark` supports the CIS 1.5 Benchmark version.

@@ -97,7 +104,7 @@ The Center for Internet Security is a 501(c\)(3) non-profit organization, formed

 CIS Benchmarks are best practices for the secure configuration of a target system. CIS Benchmarks are developed through the generous volunteer efforts of subject matter experts, technology vendors, public and private community members, and the CIS Benchmark Development team.

-The official Benchmark documents are available through the CIS website. The sign-up form to access the documents is 
+The official Benchmark documents are available through the CIS website. The sign-up form to access the documents is
 <a href="https://learn.cisecurity.org/benchmarks" target="_blank">here.</a>

 # About the Generated Report
@@ -136,7 +143,8 @@ Refer to <a href="{{<baseurl>}}/rancher/v2.5/en/security/" target="_blank">the t
 The following profiles are available:

 <Tabs>
-<TabItem label="Profiles in v2.5.4">
+<TabItem value="Profiles in v2.5.4">
+
 - Generic CIS 1.5
 - Generic CIS 1.6
 - RKE permissive 1.5
@@ -147,13 +155,16 @@ The following profiles are available:
 - GKE
 - RKE2 permissive 1.5
 - RKE2 permissive 1.5
+
 </TabItem>
-<TabItem label="Profiles in v2.5.0-v2.5.3">
+<TabItem value="Profiles in v2.5.0-v2.5.3">
+
 - Generic CIS 1.5
 - RKE permissive
 - RKE hardened
 - EKS
 - GKE
+
 </TabItem>
 </Tabs>

@@ -242,7 +253,7 @@ To run a ClusterScan on a schedule,
 1. Choose a **Retention** count, which indicates the number of reports maintained for this recurring scan. By default this count is 3. When this retention limit is reached, older reports will get purged.
 1. Click **Create.**

-**Result:** The scan runs and reschedules to run according to the cron schedule provided. The **Next Scan** value indicates the next time this scan will run again. 
+**Result:** The scan runs and reschedules to run according to the cron schedule provided. The **Next Scan** value indicates the next time this scan will run again.

 A report is generated with the scan results every time the scan runs. To see the latest results, click the name of the scan that appears.

@@ -294,7 +305,7 @@ _Available as of v2.5.4_

 Alerts can be configured to be sent out for a scan that runs on a schedule.

-> **Prerequisite:** 
+> **Prerequisite:**
 >
 > Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/configuration/alertmanager/)
 >
@@ -321,7 +332,7 @@ The `rancher-cis-benchmark` application supports two types of alerts:
 - Alert on scan completion: This alert is sent out when the scan run finishes. The alert includes details including the ClusterScan's name and the ClusterScanProfile name.
 - Alert on scan failure: This alert is sent out if there are some test failures in the scan run or if the scan is in a `Fail` state.

-> **Prerequisite:** 
+> **Prerequisite:**
 >
 > Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/configuration/alertmanager/)
 >
@@ -343,9 +354,9 @@ To configure alerts for a scan that runs on a schedule,

 A report is generated with the scan results every time the scan runs. To see the latest results, click the name of the scan that appears.

-### Creating a Custom Benchmark Version for Running a Cluster Scan 
+### Creating a Custom Benchmark Version for Running a Cluster Scan
 _Available as of v2.5.4_
- 
+
 There could be some Kubernetes cluster setups that require custom configurations of the Benchmark tests. For example, the path to the Kubernetes config files or certs might be different than the standard location where the upstream CIS Benchmarks look for them.

 It is now possible to create a custom Benchmark Version for running a cluster scan using the `rancher-cis-benchmark` application.
@@ -7,6 +7,9 @@ aliases:
  - /rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 This section describes how to disconnect a node from a Rancher-launched Kubernetes cluster and remove all of the Kubernetes components from the node. This process allows you to use the node for other purposes.

 When you use Rancher to install Kubernetes on new nodes in an infrastructure provider, resources (containers/virtual network interfaces) and configuration items (certificates/configuration files) are created.
@@ -59,7 +62,8 @@ For registered clusters, the process for removing Rancher is a little different.
 After the registered cluster is detached from Rancher, the cluster's workloads will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.

 <Tabs>
-<TabItem label="By UI / API">
+<TabItem value="By UI / API">
+
 >**Warning:** This process will remove data from your cluster. Make sure you have created a backup of files you want to keep before executing the command, as data will be lost.

 After you initiate the removal of a registered cluster using the Rancher UI (or API), the following events occur.
@@ -72,8 +76,10 @@ After you initiate the removal of a registered cluster using the Rancher UI (or

 **Result:** All components listed for registered clusters in [What Gets Removed?](#what-gets-removed) are deleted.

+
 </TabItem>
-<TabItem label="By Script">
+<TabItem value="By Script">
+
 Rather than cleaning registered cluster nodes using the Rancher UI, you can run a script instead.

 >**Prerequisite:**
@@ -4,8 +4,11 @@ shortTitle: EKS Cluster Configuration
 weight: 2
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 <Tabs>
-<TabItem label="Rancher v2.5.6+">
+<TabItem value="Rancher v2.5.6+">

 ### Account Access

@@ -101,7 +104,7 @@ For more information on EKS control plane logging, refer to the official [docume

 <a id="managed-node-groups-2-5-6"></a>

-Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters. 
+Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters.

 For more information about how node groups work and how they are configured, refer to the [EKS documentation.](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)

@@ -151,9 +154,8 @@ The following settings are also configurable. All of these except for the "Node
 | Labels | Kubernetes labels applied to the nodes in the managed node group. Note: Invalid labels can prevent upgrades or can prevent Rancher from starting. For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) |
 | Tags | These are tags for the managed node group and do not propagate to any of the associated resources. |

-
 </TabItem>
-<TabItem label="Rancher v2.5.0-v2.5.5">
+<TabItem value="Rancher v2.5.0-v2.5.5">

 ### Changes in Rancher v2.5

@@ -271,7 +273,7 @@ For more information on EKS control plane logging, refer to the official [docume

 <a id="managed-node-groups-2-5"></a>

-Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters. 
+Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters.

 For more information about how node groups work and how they are configured, refer to the [EKS documentation.](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)

@@ -284,8 +286,7 @@ Amazon will use the [EKS-optimized AMI](https://docs.aws.amazon.com/eks/latest/u
 | Minimum ASG Size | The minimum number of instances. This setting won't take effect until the [Cluster Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html) is installed. |

 </TabItem>
-<TabItem label="Rancher prior to v2.5">
-
+<TabItem value="Rancher prior to v2.5">

 ### Account Access

@@ -393,12 +394,10 @@ User Data | Custom commands can to be passed to perform automated configuration
 </TabItem>
 </Tabs>

-
-
 ### Configuring the Refresh Interval

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 The `eks-refresh-cron` setting is deprecated. It has been migrated to the `eks-refresh` setting, which is an integer representing seconds.

@@ -411,9 +410,9 @@ If the `eks-refresh-cron` setting was previously set, the migration will happen
 The shorter the refresh window, the less likely any race conditions will occur, but it does increase the likelihood of encountering request limits that may be in place for AWS APIs.

 </TabItem>
-<TabItem label="Before v2.5.8">
+<TabItem value="Before v2.5.8">

-It is possible to change the refresh interval through the setting `eks-refresh-cron`. This setting accepts values in the Cron format. The default is `*/5 * * * *`. 
+It is possible to change the refresh interval through the setting `eks-refresh-cron`. This setting accepts values in the Cron format. The default is `*/5 * * * *`.

 The shorter the refresh window, the less likely any race conditions will occur, but it does increase the likelihood of encountering request limits that may be in place for AWS APIs.

@@ -4,8 +4,11 @@ shortTitle: GKE Cluster Configuration
 weight: 3
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 # Changes in v2.5.8

@@ -303,8 +306,7 @@ The syncing interval can be changed by running `kubectl edit setting gke-refresh
 The shorter the refresh window, the less likely any race conditions will occur, but it does increase the likelihood of encountering request limits that may be in place for GCP APIs.

 </TabItem>
-<TabItem label="Rancher before v2.5.8">
-
+<TabItem value="Rancher before v2.5.8">

 # Labels & Annotations

@@ -315,7 +317,7 @@ Invalid labels can prevent upgrades or can prevent Rancher from starting. For de
 # Kubernetes Options

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

 For [regional clusters,](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#regional_clusters) you can select a region. For more information about available regions and zones, refer to [this section](https://cloud.google.com/compute/docs/regions-zones#available). The first part of each zone name is the name of the region.

@@ -327,7 +329,7 @@ Each region in Compute engine contains a number of zones.
 For more information about available regions and zones, refer to [these docs.](https://cloud.google.com/compute/docs/regions-zones#available)

 ### Additional Zones
-For zonal clusters, you can select additional zones to create a [multi-zone cluster.](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#multi-zonal_clusters) 
+For zonal clusters, you can select additional zones to create a [multi-zone cluster.](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#multi-zonal_clusters)

 ### Kubernetes Version
 Link to list of GKE kubernetes versions
@@ -405,7 +407,7 @@ Standard persistent disks are backed by standard hard disk drives (HDD), while S
 The size in GB of the [root disk.](https://cloud.google.com/compute/docs/disks)

 ### Local SSD disks
-Configure each node's local SSD disk storage in GB. 
+Configure each node's local SSD disk storage in GB.

 Local SSDs are physically attached to the server that hosts your VM instance. Local SSDs have higher throughput and lower latency than standard persistent disks or SSD persistent disks. The data that you store on a local SSD persists only until the instance is stopped or deleted. For more information, see [this section.](https://cloud.google.com/compute/docs/disks#localssds)

@@ -449,5 +451,6 @@ Access scopes are the legacy method of specifying permissions for your nodes.
 - **Set access for each API:** Alternatively, you can choose to set specific scopes that permit access to the particular API methods that the service will call.

 For more information, see the [section about enabling service accounts for a VM.](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances)
+
 </TabItem>
 </Tabs>
@@ -2,8 +2,11 @@
 headless: true
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 | Action | Rancher Launched Kubernetes Clusters |  EKS and GKE Clusters<sup>1</sup> | Other Hosted Kubernetes Clusters | Non-EKS or GKE Registered Clusters |
 | --- | --- | ---| ---|----|
@@ -32,7 +35,7 @@ headless: true
 4. For registered clusters using etcd as a control plane, snapshots must be taken manually outside of the Rancher UI to use for backup and recovery.

 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">

 | Action | Rancher Launched Kubernetes Clusters | Hosted Kubernetes Clusters | Registered EKS Clusters | All Other Registered Clusters |
 | --- | --- | ---| ---|----|
@@ -58,6 +61,5 @@ headless: true

 3. For registered clusters using etcd as a control plane, snapshots must be taken manually outside of the Rancher UI to use for backup and recovery.

-
 </TabItem>
 </Tabs>
@@ -8,8 +8,11 @@ aliases:
  - /rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 - [Prerequisites](#prerequisites)
 - [Provisioning a GKE Cluster](#provisioning-a-gke-cluster)
@@ -30,7 +33,7 @@ The service account requires the following roles:

 - **Compute Viewer:** `roles/compute.viewer`
 - **Project Viewer:** `roles/viewer`
- **Kubernetes Engine Admin:** `roles/container.admin` 
+- **Kubernetes Engine Admin:** `roles/container.admin`
 - **Service Account User:** `roles/iam.serviceAccountUser`

 [Google Documentation: Creating and Enabling Service Accounts](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances)
@@ -79,7 +82,7 @@ Your cluster is created and assigned a state of **Provisioning.** Rancher is sta

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

-**Active** clusters are assigned two Projects: 
+**Active** clusters are assigned two Projects:

 - `Default`, containing the `default` namespace
 - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
@@ -104,9 +107,8 @@ The GKE provisioner can synchronize the state of a GKE cluster between Rancher a

 For information on configuring the refresh interval, see [this section.]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/#configuring-the-refresh-interval)

-
 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">

 # Prerequisites

@@ -120,7 +122,7 @@ The service account requires the following roles:

 - **Compute Viewer:** `roles/compute.viewer`
 - **Project Viewer:** `roles/viewer`
- **Kubernetes Engine Admin:** `roles/container.admin` 
+- **Kubernetes Engine Admin:** `roles/container.admin`
 - **Service Account User:** `roles/iam.serviceAccountUser`

 [Google Documentation: Creating and Enabling Service Accounts](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances)
@@ -145,7 +147,7 @@ Use Rancher to set up and configure your Kubernetes cluster.

 	>**Note:** After submitting your private key, you may have to enable the Google Kubernetes Engine API. If prompted, browse to the URL displayed in the Rancher UI to enable the API.

-6. Select your cluster options, node options and security options. For help, refer to the [GKE Cluster Configuration Reference.](#gke-before-v2-5-8) 
+6. Select your cluster options, node options and security options. For help, refer to the [GKE Cluster Configuration Reference.](#gke-before-v2-5-8)
 9. Review your options to confirm they're correct. Then click **Create**.

 **Result:** You have successfully deployed a GKE cluster.
@@ -154,7 +156,7 @@ Your cluster is created and assigned a state of **Provisioning.** Rancher is sta

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

-**Active** clusters are assigned two Projects: 
+**Active** clusters are assigned two Projects:

 - `Default`, containing the `default` namespace
 - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
@@ -5,6 +5,9 @@ aliases:
  - /rancher/v2.x/en/cluster-provisioning/node-requirements/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 This page describes the requirements for the Rancher managed Kubernetes clusters where your apps and services will be installed. These downstream clusters should be separate from the three-node cluster running Rancher.

 > 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.]({{<baseurl>}}/rancher/v2.5/en/installation/requirements/)
@@ -33,7 +36,7 @@ For information on how to install Docker, refer to the official [Docker document
 Some distributions of Linux derived from RHEL, including Oracle Linux, may have default firewall rules that block communication with Helm. We recommend disabling firewalld. For Kubernetes 1.19, firewalld must be turned off.

 >**Note:** In RHEL 8.4, two extra services are included on the NetworkManager: `nm-cloud-setup.service` and `nm-cloud-setup.timer`. These services add a routing table that interferes with the CNI plugin's configuration. If these services are enabled, you must disable them using the command below, and then reboot the node to restore connectivity:
->  
+>
 >  ```
   systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
   reboot
@@ -48,7 +51,7 @@ SUSE Linux may have a firewall that blocks all ports by default. In that situati
 When [Launching Kubernetes with Rancher]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/) using Flatcar Container Linux nodes, it is required to use the following configuration in the [Cluster Config File]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/#cluster-config-file)

 <Tabs>
-<TabItem label="Canal">
+<TabItem value="Canal">

 ```yaml
 rancher_kubernetes_engine_config:
@@ -63,9 +66,9 @@ rancher_kubernetes_engine_config:
      extra_args:
        flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
 ```
-</TabItem>

-<TabItem label="Calico">
+</TabItem>
+<TabItem value="Calico">

 ```yaml
 rancher_kubernetes_engine_config:
@@ -80,6 +83,7 @@ rancher_kubernetes_engine_config:
      extra_args:
        flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
 ```
+
 </TabItem>
 </Tabs>

@@ -7,6 +7,9 @@ aliases:
  - /rancher/v2.x/en/cluster-provisioning/registered-clusters/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 The cluster registration feature replaced the feature to import clusters.

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

 <Tabs>
-<TabItem label="v2.5.9+">
+<TabItem value="v2.5.9+">

 ### Kubernetes Node Roles

@@ -52,7 +55,7 @@ If you are registering a K3s cluster, make sure the `cluster.yml` is readable. I
 EKS clusters must have at least one managed node group to be imported into Rancher or provisioned from Rancher successfully.

 </TabItem>
-<TabItem label="Rancher before v2.5.9">
+<TabItem value="Rancher before v2.5.9">

 ### Permissions

@@ -121,7 +124,7 @@ $ curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -s -

 ### Configuring an Imported EKS Cluster with Terraform

-You should define **only** the minimum fields that Rancher requires when importing an EKS cluster with Terraform. This is important as Rancher will overwrite what was in the EKS cluster with any config that the user has provided. 
+You should define **only** the minimum fields that Rancher requires when importing an EKS cluster with Terraform. This is important as Rancher will overwrite what was in the EKS cluster with any config that the user has provided.

 >**Warning:** Even a small difference between the current EKS cluster and a user-provided config could have unexpected results.

@@ -152,7 +155,7 @@ resource "rancher2_cluster" "my-eks-to-import" {
 The control that Rancher has to manage a registered cluster depends on the type of cluster.

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 - [Changes in v2.5.8](#changes-in-v2-5-8)
 - [Features for All Registered Clusters](#2-5-8-features-for-all-registered-clusters)
@@ -196,9 +199,8 @@ When you delete an EKS cluster or GKE cluster that was created in Rancher, the c

 The capabilities for registered clusters are listed in the table on [this page.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/)

-
 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">

 - [Features for All Registered Clusters](#before-2-5-8-features-for-all-registered-clusters)
 - [Additional Features for Registered K3s Clusters](#before-2-5-8-additional-features-for-registered-k3s-clusters)
@@ -236,11 +238,10 @@ Amazon EKS clusters can now be registered in Rancher. For the most part, registe
 When you delete an EKS cluster that was created in Rancher, the cluster is destroyed. When you delete an EKS cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher.

 The capabilities for registered EKS clusters are listed in the table on [this page.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/)
+
 </TabItem>
 </Tabs>

-
-
 # Configuring K3s Cluster Upgrades

 > It is a Kubernetes best practice to back up the cluster before upgrading. When upgrading a high-availability K3s cluster with an external database, back up the database in whichever way is recommended by the relational database provider.
@@ -256,7 +257,7 @@ Also in the K3s documentation, nodes with the worker role are called agent nodes

 # Debug Logging and Troubleshooting for Registered K3s Clusters

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

 To enable debug logging on the system upgrade controller deployment, edit the [configmap](https://github.com/rancher/system-upgrade-controller/blob/50a4c8975543d75f1d76a8290001d87dc298bdb4/manifests/system-upgrade-controller.yaml#L32) to set the debug environment variable to true. Then restart the `system-upgrade-controller` pod.

@@ -298,7 +299,7 @@ This example annotation indicates that a pod security policy is enabled:
 The following annotation indicates Ingress capabilities. Note that that the values of non-primitive objects need to be JSON encoded, with quotations escaped.

 ```
-"capabilities.cattle.io/ingressCapabilities": "[  
+"capabilities.cattle.io/ingressCapabilities": "[
  {
    "customDefaultBackend":true,
    "ingressProvider":"asdf"
@@ -5,6 +5,9 @@ aliases:
  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/options/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 When Rancher installs Kubernetes, it uses [RKE]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/) as the Kubernetes distribution.

 This section covers the configuration options that are available in Rancher for a new or existing RKE Kubernetes cluster.
@@ -71,12 +74,12 @@ When Weave is selected as network provider, Rancher will automatically enable en
 Project network isolation is used to enable or disable communication between pods in different projects.

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 To enable project network isolation as a cluster option, you will need to use any RKE network plugin that supports the enforcement of Kubernetes network policies, such as Canal or the Cisco ACI plugin.

 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">

 To enable project network isolation as a cluster option, you will need to use Canal as the CNI.

@@ -294,7 +297,7 @@ Option to enable or disable [Cluster Monitoring]({{<baseurl>}}/rancher/v2.5/en/m

 Option to enable or disable Project Network Isolation.

-Before Rancher v2.5.8, project network isolation is only available if you are using the Canal network plugin for RKE. 
+Before Rancher v2.5.8, project network isolation is only available if you are using the Canal network plugin for RKE.

 In v2.5.8+, project network isolation is available if you are using any RKE network plugin that supports the enforcement of Kubernetes network policies, such as Canal or the Cisco ACI plugin.

@@ -5,6 +5,9 @@ aliases:
  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 When provisioning a [custom cluster]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/custom-nodes) using Rancher, Rancher uses RKE (the Rancher Kubernetes Engine) to install Kubernetes on your existing nodes.

 In a Windows cluster provisioned with Rancher, the cluster must contain both Linux and Windows nodes. The Kubernetes controlplane can only run on Linux nodes, and the Windows nodes can only have the worker role. Windows nodes can only be used for deploying workloads.
@@ -36,13 +39,15 @@ The general node requirements for networking, operating systems, and Docker are
 ### OS and Docker Requirements

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 Our support for Windows Server and Windows containers match the Microsoft official lifecycle for LTSC (Long-Term Servicing Channel) and SAC (Semi-Annual Channel).

 For the support lifecycle dates for Windows Server, see the [Microsoft Documentation.](https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info)
+
 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">
+
 In order to add Windows worker nodes to a cluster, the node must be running one of the following Windows Server versions and the corresponding version of Docker Engine - Enterprise Edition (EE):

 - Nodes with Windows Server core version 1809 should use Docker EE-basic 18.09 or Docker EE-basic 19.03.
@@ -52,6 +57,7 @@ In order to add Windows worker nodes to a cluster, the node must be running one
 >
 > - If you are using AWS, Rancher recommends _Microsoft Windows Server 2019 Base with Containers_ as the Amazon Machine Image (AMI).
 > - If you are using GCE, Rancher recommends _Windows Server 2019 Datacenter for Containers_ as the OS image.
+
 </TabItem>
 </Tabs>

@@ -214,13 +220,13 @@ The first node in your cluster should be a Linux host has both the **Control Pla
 1. SSH into your Linux host and run the command that you copied to your clipboard.
 1. When you are finished provisioning your Linux node(s), select **Done**.

-**Result:** 
+**Result:**

 Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.

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

-**Active** clusters are assigned two Projects: 
+**Active** clusters are assigned two Projects:

 - `Default`, containing the `default` namespace
 - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
@@ -4,6 +4,9 @@ shortTitle: GKE
 weight: 5
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 In this section, you'll learn how to install Rancher using Google Kubernetes Engine.

 If you already have a GKE Kubernetes cluster, skip to the step about [installing an ingress.](#7-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/#install-the-rancher-helm-chart)
@@ -59,8 +62,8 @@ To install `gcloud` and `kubectl`, perform the following steps:
    ```
    source ~/.bash_profile
    ```
-    
-   
+
+

 # 3. Configure the gcloud CLI

@@ -70,7 +73,7 @@ To install `gcloud` and `kubectl`, perform the following steps:
 - Using gcloud config, to individually set your project ID, zone, and region.

 <Tabs>
-<TabItem label="Using gloud init">
+<TabItem value="Using gloud init">

 1. Run gcloud init and follow the directions:

@@ -85,7 +88,8 @@ To install `gcloud` and `kubectl`, perform the following steps:
 2. Follow the instructions to authorize gcloud to use your Google Cloud account and select the new project that you created.

 </TabItem>
-<TabItem label="Using gcloud config">
+<TabItem value="Using gcloud config">
+
 </TabItem>
 </Tabs>

@@ -11,6 +11,9 @@ aliases:
  - /rancher/v2.x/en/installation/install-rancher-on-k8s/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 In this section, you'll learn how to deploy Rancher on a Kubernetes cluster using the Helm CLI.

 - [Prerequisites](#prerequisites)
@@ -160,8 +163,7 @@ The exact command to install Rancher differs depending on the certificate config
 However, irrespective of the certificate configuration, the name of the Rancher installation in the `cattle-system` namespace should always be `rancher`.

 <Tabs>
-<TabItem label="Rancher-generated Certificates">
-
+<TabItem value="Rancher-generated Certificates">

 The default is for Rancher to generate a self-signed CA, and uses `cert-manager` to issue the certificate for access to the Rancher server interface.

@@ -188,7 +190,7 @@ deployment "rancher" successfully rolled out
 ```

 </TabItem>
-<TabItem label="Let's Encrypt">
+<TabItem value="Let's Encrypt">

 This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA.

@@ -223,7 +225,7 @@ deployment "rancher" successfully rolled out
 ```

 </TabItem>
-<TabItem label="Certificates from Files">
+<TabItem value="Certificates from Files">
 In this option, Kubernetes secrets are created from your own certificates for Rancher to use.

 When you run this command, the `hostname` option must match the `Common Name` or a `Subject Alternative Names` entry in the server certificate, or the Ingress controller will fail to configure correctly.
@@ -257,6 +259,7 @@ helm install rancher rancher-<CHART_REPO>/rancher \
 ```

 Now that Rancher is deployed, see [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.5/en/installation/resources/encryption/tls-secrets/) to publish the certificate files so Rancher and the Ingress controller can use them.
+
 </TabItem>
 </Tabs>

@@ -4,6 +4,9 @@ shortTitle: Air Gap Upgrade
 weight: 1
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 > These instructions assume you have already followed the instructions for a Kubernetes upgrade on [this page,]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades/) including the prerequisites, up until step 3. Upgrade Rancher.

 ### Rancher Helm Template Options
@@ -23,7 +26,7 @@ Placeholder | Description
 ### Option A: Default Self-signed Certificate

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 ```
 helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -37,7 +40,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
 ```

 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">

 ```plain
 helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -52,14 +55,10 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
 </TabItem>
 </Tabs>

-
-
 ### Option B: Certificates from Files using Kubernetes Secrets

-
 <Tabs>
-<TabItem label="Rancher v2.5.8+">
-
+<TabItem value="Rancher v2.5.8+">

 ```plain
 helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -87,8 +86,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
 ```

 </TabItem>
-<TabItem label="Rancher before v2.5.8">
-
+<TabItem value="Rancher before v2.5.8">

 ```plain
 helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -112,6 +110,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
 --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
 --set useBundledSystemChart=true # Use the packaged Rancher system charts
 ```
+
 </TabItem>
 </Tabs>

@@ -11,13 +11,16 @@ aliases:
  - /rancher/v2.x/en/installation/other-installation-methods/air-gap/install-rancher/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 This section is about how to deploy Rancher for your air gapped environment in a high-availability Kubernetes installation. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy.

 ### Privileged Access for Rancher v2.5+

 When the Rancher server is deployed in the Docker container, a local Kubernetes cluster is installed within the container for Rancher to use. Because many features of Rancher run as deployments, and privileged mode is required to run containers within containers, you will need to install Rancher with the `--privileged` option.

-# Docker Instructions 
+# Docker Instructions

 If you want to continue the air gapped installation using Docker commands, skip the rest of this page and follow the instructions on [this page.](./docker-install-commands)

@@ -139,7 +142,8 @@ Placeholder | Description
 `<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">
+
 ```plain
 helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
    --no-hooks \ # prevent files for Helm hooks from being generated
@@ -152,8 +156,9 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
 ```

 **Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.5.8`
+
 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">

 ```plain
 helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -166,6 +171,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
 ```

 **Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.5.6`
+
 </TabItem>
 </Tabs>

@@ -189,7 +195,7 @@ Render the Rancher template, declaring your chosen options. Use the reference ta
 | `<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.         |

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 ```plain
   helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -219,8 +225,9 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
 **Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.3.6`

 Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.5/en/installation/resources/encryption/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
+
 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">


 ```plain
@@ -249,6 +256,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
 **Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.3.6`

 Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.5/en/installation/resources/encryption/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
+
 </TabItem>
 </Tabs>

@@ -6,6 +6,9 @@ aliases:
  - /rancher/v2.x/en/installation/other-installation-methods/air-gap/launch-kubernetes/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 > Skip this section if you are installing Rancher on a single node with Docker.

 This section describes how to install a Kubernetes cluster according to our [best practices for the Rancher server environment.]({{<baseurl>}}/rancher/v2.5/en/overview/architecture-recommendations/#environment-for-kubernetes-installations) This cluster should be dedicated to run only the Rancher server.
@@ -15,7 +18,7 @@ As of Rancher v2.5, Rancher can be installed on any Kubernetes cluster, includin
 The steps to set up an air-gapped Kubernetes cluster on RKE or K3s are shown below.

 <Tabs>
-<TabItem label="K3s">
+<TabItem value="K3s">

 In this guide, we are assuming you have created your nodes in your air gapped environment and have a secure Docker private registry on your bastion server.

@@ -95,7 +98,7 @@ The node-token is on the server at `/var/lib/rancher/k3s/server/node-token`

 When you installed K3s on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/k3s/k3s.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.

-To use this `kubeconfig` file, 
+To use this `kubeconfig` file,

 1. Install [kubectl,](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) a Kubernetes command-line tool.
 2. Copy the file at `/etc/rancher/k3s/k3s.yaml` and save it to the directory `~/.kube/config` on your local machine.
@@ -138,8 +141,10 @@ Upgrading an air-gap environment can be accomplished in the following manner:
 1. Download the new air-gap images (tar file) from the [releases](https://github.com/rancher/k3s/releases) page for the version of K3s you will be upgrading to. Place the tar in the `/var/lib/rancher/k3s/agent/images/` directory on each node. Delete the old tar file.
 2. Copy and replace the old K3s binary in `/usr/local/bin` on each node. Copy over the install script at https://get.k3s.io (as it is possible it has changed since the last release). Run the script again just as you had done in the past with the same environment variables.
 3. Restart the K3s service (if not restarted automatically by installer).
+
 </TabItem>
-<TabItem label="RKE">
+<TabItem value="RKE">
+
 We will create a Kubernetes cluster using Rancher Kubernetes Engine (RKE). Before being able to start your Kubernetes cluster, you’ll need to install RKE and create a RKE config file.

 ### 1. Install RKE
@@ -211,6 +216,7 @@ Save a copy of the following files in a secure location:
 - `rancher-cluster.yml`: The RKE cluster configuration file.
 - `kube_config_cluster.yml`: The [Kubeconfig file]({{<baseurl>}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
 - `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{<baseurl>}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains the current state of the cluster including the RKE configuration and the certificates.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
+
 </TabItem>
 </Tabs>

@@ -10,6 +10,9 @@ aliases:
  - /rancher/v2.x/en/installation/other-installation-methods/air-gap/populate-private-registry/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 This section describes how to set up your private registry so that when you install Rancher, Rancher will pull all the required images from this registry.

 By default, all images used to [provision Kubernetes clusters]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/) or launch any tools in Rancher, e.g. monitoring and logging, are pulled from Docker Hub. In an air gapped installation of Rancher, you will need a private registry that is located somewhere accessible by your Rancher server. Then, you will load the registry with all the images.
@@ -25,7 +28,7 @@ The steps in this section differ depending on whether or not you are planning to
 > If the registry has certs, follow [this K3s documentation](https://rancher.com/docs/k3s/latest/en/installation/private-registry/) about adding a private registry. The certs and registry configuration files need to be mounted into the Rancher container.

 <Tabs>
-<TabItem label="Linux Only Clusters">
+<TabItem value="Linux Only Clusters">

 For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.

@@ -56,7 +59,7 @@ If you will use ARM64 hosts, the registry must support manifests. As of April 20

 > Skip this step if you are using your own certificates, or if you are terminating TLS on an external load balancer.

-In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://hub.helm.sh/charts/jetstack/cert-manager) image to `rancher-images.txt` as well. 
+In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://hub.helm.sh/charts/jetstack/cert-manager) image to `rancher-images.txt` as well.

 1.  Fetch the latest `cert-manager` Helm chart and parse the template for image details:

@@ -109,8 +112,9 @@ The `rancher-images.txt` is expected to be on the workstation in the same direct
   ```plain
   ./rancher-load-images.sh --image-list ./rancher-images.txt --registry <REGISTRY.YOURDOMAIN.COM:PORT>
   ```
+
 </TabItem>
-<TabItem label="Linux and Windows Clusters">
+<TabItem value="Linux and Windows Clusters">

 For Rancher servers that will provision Linux and Windows clusters, there are distinctive steps to populate your private registry for the Windows images and the Linux images. Since a Windows cluster is a mix of Linux and Windows nodes, the Linux images pushed into the private registry are manifests.

@@ -287,7 +291,6 @@ The image list, `rancher-images.txt` or `rancher-windows-images.txt`, is expecte
   --registry <REGISTRY.YOURDOMAIN.COM:PORT>
 ```

-
 </TabItem>
 </Tabs>

@@ -6,6 +6,9 @@ aliases:
  - /rancher/v2.x/en/installation/other-installation-methods/air-gap/prepare-nodes/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 In this section, you will provision the underlying infrastructure for your Rancher management server in an air gapped environment. You will also set up the private Docker registry that must be available to your Rancher node(s).

 An air gapped environment is an environment where the Rancher server is installed offline or behind a firewall.
@@ -15,7 +18,8 @@ The infrastructure depends on whether you are installing Rancher on a K3s Kubern
 As of Rancher v2.5, Rancher can be installed on any Kubernetes cluster. The RKE and K3s Kubernetes infrastructure tutorials below are still included for convenience.

 <Tabs>
-<TabItem label="K3s">
+<TabItem value="K3s">
+
 We recommend setting up the following infrastructure for a high-availability installation:

 - **Two Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
@@ -85,8 +89,9 @@ Rancher supports air gap installs using a private registry. You must have your o
 In a later step, when you set up your K3s Kubernetes cluster, you will create a [private registries configuration file]({{<baseurl>}}/k3s/latest/en/installation/private-registry/) with details from this registry.

 If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
+
 </TabItem>
-<TabItem label="RKE">
+<TabItem value="RKE">

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

@@ -149,8 +154,10 @@ In a later step, when you set up your RKE Kubernetes cluster, you will create a

 If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)

+
 </TabItem>
-<TabItem label="Docker">
+<TabItem value="Docker">
+
 > The Docker installation is for Rancher users that are wanting to test out Rancher. Since there is only one node and a single Docker container, if the node goes down, you will lose all the data of your Rancher server.
 >
 > As of Rancher v2.5, the Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster.]({{<baseurl>}}/rancher/v2.5/en/backups/migrating-rancher)
@@ -10,6 +10,9 @@ aliases:
  - /rancher/v2.x/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 The following instructions will guide you through upgrading a Rancher server that was installed with Docker.

 # Prerequisites
@@ -131,7 +134,7 @@ To see the command to use when starting the new Rancher server container, choose
 - Docker Upgrade for Air Gap Installs

 <Tabs>
-<TabItem label="Docker Upgrade">
+<TabItem value="Docker Upgrade">

 Select which option you had installed Rancher server

@@ -249,7 +252,7 @@ As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/
 {{% /accordion %}}

 </TabItem>
-<TabItem label="Docker Air Gap Upgrade">
+<TabItem value="Docker Air Gap Upgrade">

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

@@ -342,6 +345,7 @@ docker run -d --volumes-from rancher-data \
 ```
 As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
 {{% /accordion %}}
+
 </TabItem>
 </Tabs>

@@ -6,6 +6,9 @@ aliases:
  - /rancher/v2.x/en/installation/requirements/ports/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes.

 - [Rancher Nodes](#rancher-nodes)
@@ -281,7 +284,8 @@ When using the [AWS EC2 node driver]({{<baseurl>}}/rancher/v2.5/en/cluster-provi
 SUSE Linux may have a firewall that blocks all ports by default. To open the ports needed for adding the host to a custom cluster,

 <Tabs>
-<TabItem label="SLES 15 / openSUSE Leap 15">
+<TabItem value="SLES 15 / openSUSE Leap 15">
+
 1. SSH into the instance.
 1. Start YaST in text mode:
 ```
@@ -299,8 +303,10 @@ UDP Ports

 1. When all required ports are enter, select **Accept**.

+
 </TabItem>
-<TabItem label="SLES 12 / openSUSE Leap 42">
+<TabItem value="SLES 12 / openSUSE Leap 42">
+
 1. SSH into the instance.
 1. Edit /`etc/sysconfig/SuSEfirewall2` and open the required ports. In this example, ports 9796 and 10250 are also opened for monitoring:
  ```
@@ -312,6 +318,7 @@ UDP Ports
  ```
  SuSEfirewall2
  ```
+
 </TabItem>
 </Tabs>

@@ -6,6 +6,9 @@ aliases:
  - /rancher/v2.x/en/installation/resources/choosing-version/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 This section describes how to choose a Rancher version.

 For a high-availability installation of Rancher, which is recommended for production, the Rancher server is installed using a **Helm chart** on a Kubernetes cluster. Refer to the [Helm version requirements]({{<baseurl>}}/rancher/v2.5/en/installation/options/helm-version) to choose a version of Helm to install Rancher.
@@ -17,7 +20,7 @@ The Helm chart version also applies to RancherD installs because RancherD instal
 > **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.

 <Tabs>
-<TabItem label="Helm Charts">
+<TabItem value="Helm Charts">

 When installing, upgrading, or rolling back Rancher Server when it is [installed on a Kubernetes cluster]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/), Rancher server is installed using a Helm chart on a Kubernetes cluster. Therefore, as you prepare to install or upgrade a high availability Rancher configuration, you must add a Helm chart repository that contains the charts for installing Rancher.

@@ -80,8 +83,10 @@ After installing Rancher, if you want to change which Helm chart repository to i
    ```

 4. Continue to follow the steps to [upgrade Rancher]({{<baseurl>}}/rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha) from the new Helm chart repository.
+
 </TabItem>
-<TabItem label="Docker Images">
+<TabItem value="Docker Images">
+
 When performing [Docker installs]({{<baseurl>}}/rancher/v2.5/en/installation/single-node), upgrades, or rollbacks, you can use _tags_ to install a specific version of Rancher.

 ### Server Tags
@@ -99,5 +104,5 @@ Rancher Server is distributed as a Docker image, which have tags attached to the
 > - The `master` tag or any tag with `-rc` or another suffix is meant for the Rancher testing team to validate. You should not use these tags, as these builds are not officially supported.
 > - Want to install an alpha review for preview? Install using one of the alpha tags listed on our [announcements page](https://forums.rancher.com/c/announcements) (e.g., `v2.2.0-alpha1`). Caveat: Alpha releases cannot be upgraded to or from any other release.

-</TabItem> 
+</TabItem>
 </Tabs>
@@ -6,6 +6,10 @@ aliases:
  - /rancher/v2.5/en/admin-settings/feature-flags/
  - /rancher/v2.x/en/installation/resources/feature-flags/
 ---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 Rancher includes some features that are experimental and disabled by default. You might want to enable these features, for example, if you decide that the benefits of using an [unsupported storage type]({{<baseurl>}}/rancher/v2.5/en/installation/options/feature-flags/enable-not-default-storage-drivers) outweighs the risk of using an untested feature. Feature flags were introduced to allow you to try these features that are not enabled by default.

 The features can be enabled in three ways:
@@ -78,7 +82,7 @@ Here is an example of a command for passing in the feature flag names when rende
 The Helm 3 command is as follows:

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 ```
 helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -92,8 +96,9 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
  --set 'extraEnv[0].name=CATTLE_FEATURES'
  --set 'extraEnv[0].value=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true'
 ```
+
 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">

 ```
 helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -106,6 +111,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
  --set 'extraEnv[0].name=CATTLE_FEATURES'
  --set 'extraEnv[0].value=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true'
 ```
+
 </TabItem>
 </Tabs>

@@ -9,19 +9,22 @@ aliases:
  - /rancher/v2.x/en/istio/v2.5/configuration-reference/enable-istio-with-psp/
 ---

-If you have restrictive Pod Security Policies enabled, then Istio may not be able to function correctly, because it needs certain permissions in order to install itself and manage pod infrastructure. In this section, we will configure a cluster with PSPs enabled for an Istio install, and also set up the Istio CNI plugin. 
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+If you have restrictive Pod Security Policies enabled, then Istio may not be able to function correctly, because it needs certain permissions in order to install itself and manage pod infrastructure. In this section, we will configure a cluster with PSPs enabled for an Istio install, and also set up the Istio CNI plugin.

 The Istio CNI plugin removes the need for each application pod to have a privileged `NET_ADMIN` container. For further information, see the [Istio CNI Plugin docs](https://istio.io/docs/setup/additional-setup/cni). Please note that the [Istio CNI Plugin is in alpha](https://istio.io/about/feature-stages/).

 The steps differ based on the Rancher version.

 <Tabs>
-<TabItem label="v2.5.4+">
+<TabItem value="v2.5.4+">

 > **Prerequisites:**
 >
 > - The cluster must be an RKE Kubernetes cluster.
-> - The cluster must have been created with a default PodSecurityPolicy. 
+> - The cluster must have been created with a default PodSecurityPolicy.
 >
 > To enable pod security policy support when creating a Kubernetes cluster in the Rancher UI, go to <b>Advanced Options.</b> In the <b>Pod Security Policy Support</b> section, click <b>Enabled.</b> Then select a default pod security policy.

@@ -60,12 +63,12 @@ Istio should install successfully with the CNI enabled in the cluster.
 Verify that the CNI is working by deploying a [sample application](https://istio.io/latest/docs/examples/bookinfo/) or deploying one of your own applications.

 </TabItem>
-<TabItem label="v2.5.0-v2.5.3">
+<TabItem value="v2.5.0-v2.5.3">

 > **Prerequisites:**
 >
 > - The cluster must be an RKE Kubernetes cluster.
-> - The cluster must have been created with a default PodSecurityPolicy. 
+> - The cluster must have been created with a default PodSecurityPolicy.
 >
 > To enable pod security policy support when creating a Kubernetes cluster in the Rancher UI, go to <b>Advanced Options.</b> In the <b>Pod Security Policy Support</b> section, click <b>Enabled.</b> Then select a default pod security policy.

@@ -9,6 +9,9 @@ aliases:
  - /rancher/v2.x/en/istio/v2.5/resources/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 This section describes the minimum recommended computing resources for the Istio components in a cluster.

 The CPU and memory allocations for each component are [configurable.](#configuring-resource-allocations)
@@ -22,7 +25,7 @@ The table below shows a summary of the minimum recommended resource requests and
 In Kubernetes, the resource request indicates that the workload will not be deployed on a node unless the node has at least the specified amount of memory and CPU available. If the workload surpasses the limit for CPU or memory, it can be terminated or evicted from the node. For more information on managing resource limits for containers, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)

 <Tabs>
-<TabItem label="v2.5.6+">
+<TabItem value="v2.5.6+">

 | Workload   | CPU - Request  | Memory - Request  |  CPU - Limit  |  Memory - Limit |
 |----------------------|---------------|------------|-----------------|-------------------|
@@ -33,7 +36,7 @@ In Kubernetes, the resource request indicates that the workload will not be depl
 | **Totals:** | **710m** | **2314Mi** | **6000m** | **3072Mi** |

 </TabItem>
-<TabItem label="v2.5.0-v2.5.5">
+<TabItem value="v2.5.0-v2.5.5">

 Workload | CPU - Request | Memory - Request | CPU - Limit | Mem - Limit | Configurable
 ---------:|---------------:|---------------:|-------------:|-------------:|-------------:
@@ -46,9 +49,6 @@ Totals: | 1710m | 3304Mi | >8800m | >6048Mi | -
 </TabItem>
 </Tabs>

-
-
-
 # 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.
@@ -3,6 +3,9 @@ title: Flows and ClusterFlows
 weight: 1
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/)

 - [Configuration](#configuration)
@@ -11,7 +14,7 @@ For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai
 # Configuration

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 - [Flows](#flows-2-5-8)
  - [Matches](#matches-2-5-8)
@@ -73,8 +76,9 @@ Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way

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

+
 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">

 - [Flows](#flows-2-5-0)
  - [Matches](#matches-2-5-0)
@@ -3,6 +3,9 @@ title: Outputs and ClusterOutputs
 weight: 2
 ---

+import Tabs from '@theme/Tabs';
+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)
@@ -15,7 +18,7 @@ For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Ban
 # Configuration

 <Tabs>
-<TabItem label="v2.5.8+">
+<TabItem value="v2.5.8+">

 - [Outputs](#outputs-2-5-8)
 - [ClusterOutputs](#clusteroutputs-2-5-8)
@@ -32,7 +35,7 @@ The `Output` resource defines where your `Flows` can send the log messages. `Out

 The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.

-You can use secrets in these definitions, but they must also be in the same namespace. 
+You can use secrets in these definitions, but they must also be in the same namespace.

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

@@ -69,8 +72,7 @@ For example configuration for each logging plugin supported by the logging opera
 For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)

 </TabItem>
-<TabItem label="Rancher before v2.5.8">
-
+<TabItem value="Rancher before v2.5.8">

 - [Outputs](#outputs-2-5-0)
 - [ClusterOutputs](#clusteroutputs-2-5-0)
@@ -81,9 +83,9 @@ For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](htt

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

-The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it. 
+The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.

-You can use secrets in these definitions, but they must also be in the same namespace. 
+You can use secrets in these definitions, but they must also be in the same namespace.

 `Outputs` are configured in YAML. For the details of `Output` custom resource, see [OutputSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/output_types/)

@@ -7,11 +7,14 @@ weight: 15
 aliases:
  - /rancher/v2.5/en/dashboard/logging
  - /rancher/v2.5/en/logging/v2.5
-  - /rancher/v2.5/en/cluster-admin/tools/logging 
+  - /rancher/v2.5/en/cluster-admin/tools/logging
  - /rancher/v2.x/en/logging/
  - /rancher/v2.x/en/logging/v2.5/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging solution in place of the former, in-house solution.

 For an overview of the changes in v2.5, see [this section.]({{<baseurl>}}/rancher/v2.5/en/logging/architecture/#changes-in-rancher-v2-5) For information about migrating from Logging V1, see [this page.](./migrating)
@@ -81,17 +84,21 @@ For a list of options that can be configured when the logging application is ins
 ### Windows Support

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">
+
 As of Rancher v2.5.8, logging support for Windows clusters has been added and logs can be collected from Windows nodes.

 For details on how to enable or disable Windows node logging, see [this section.](./helm-chart-options/#enable-disable-windows-node-logging)

+
 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">
+
 Clusters with Windows workers support exporting logs from Linux nodes, but Windows node logs are currently unable to be exported.
 Only Linux node logs are able to be exported.

 To allow the logging pods to be scheduled on Linux nodes, tolerations must be added to the pods. Refer to the [Working with Taints and Tolerations]({{<baseurl>}}/rancher/v2.5/en/logging/taints-tolerations/) section for details and an example.
+
 </TabItem>
 </Tabs>

@@ -3,11 +3,14 @@ title: Working with Taints and Tolerations
 weight: 6
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 "Tainting" a Kubernetes node causes pods to repel running on that node.

 Unless the pods have a `toleration` for that node's taint, they will run on other nodes in the cluster.

-[Taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) can work in conjunction with the `nodeSelector` [field](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) within the `PodSpec`, which enables the *opposite* effect of a taint. 
+[Taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) can work in conjunction with the `nodeSelector` [field](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) within the `PodSpec`, which enables the *opposite* effect of a taint.

 Using `nodeSelector` gives pods an affinity towards certain nodes.

@@ -20,13 +23,16 @@ Both provide choice for the what node(s) the pod will run on.
 ### Default Implementation in Rancher's Logging Stack

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">
+
 By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
 The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
 Moreover, most logging stack pods run on Linux only and have a `nodeSelector` added to ensure they run on Linux nodes.

+
 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">
+
 By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
 The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
 Moreover, we can populate the `nodeSelector` to ensure that our pods *only* run on Linux nodes.
@@ -5,6 +5,9 @@ aliases:
  - /rancher/v2.x/en/monitoring-alerting/v2.5/configuration/prometheusrules/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 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.]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/how-monitoring-works)
@@ -17,7 +20,7 @@ _Available as of v2.5.4_

 To create rule groups in the Rancher UI,

-1. Click **Cluster Explorer > Monitoring** and click **Prometheus Rules.** 
+1. Click **Cluster Explorer > Monitoring** and click **Prometheus Rules.**
 1. Click **Create.**
 1. Enter a **Group Name.**
 1. Configure the rules. In Rancher's UI, we expect a rule group to contain either alert rules or recording rules, but not both. For help filling out the forms, refer to the configuration options below.
@@ -45,7 +48,8 @@ For examples, refer to the Prometheus documentation on [recording rules](https:/
 # Configuration

 <Tabs>
-<TabItem label="Rancher v2.5.4">
+<TabItem value="Rancher v2.5.4">
+
 Rancher v2.5.4 introduced the capability to configure PrometheusRules by filling out forms in the Rancher UI.


@@ -73,7 +77,7 @@ Rancher v2.5.4 introduced the capability to configure PrometheusRules by filling

 ### Recording Rules

-[Recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/#recording-rules) allow you to precompute frequently needed or computationally expensive PromQL (Prometheus Query Language) expressions and save their result as a new set of time series. 
+[Recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/#recording-rules) allow you to precompute frequently needed or computationally expensive PromQL (Prometheus Query Language) expressions and save their result as a new set of time series.

 | Field | Description |
 |-------|----------------|
@@ -82,7 +86,9 @@ Rancher v2.5.4 introduced the capability to configure PrometheusRules by filling
 | Labels |   Labels to add or overwrite before storing the result.     |

 </TabItem>
-<TabItem label="Rancher v2.5.0-v2.5.3">
+<TabItem value="Rancher v2.5.0-v2.5.3">
+
 For Rancher v2.5.0-v2.5.3, PrometheusRules must be configured in YAML. 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/)
+
 </TabItem>
 </Tabs>
@@ -10,6 +10,9 @@ aliases:
  - /rancher/v2.5/en/monitoring-alerting/configuration/alertmanager
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configuration/#configuration-file) Secret contains the configuration of an Alertmanager instance that sends out notifications based on alerts it receives from Prometheus.

 > This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../how-monitoring-works/#3-how-alertmanager-works)
@@ -43,7 +46,7 @@ _Available as of v2.5.4_

 To create notification receivers in the Rancher UI,

-1. Click **Cluster Explorer > Monitoring** and click **Receiver.** 
+1. Click **Cluster Explorer > Monitoring** and click **Receiver.**
 2. Enter a name for the receiver.
 3. Configure one or more providers for the receiver. For help filling out the forms, refer to the configuration options below.
 4. Click **Create.**
@@ -73,7 +76,7 @@ Rancher v2.5.8 added Microsoft Teams and SMS as configurable receivers in the Ra
 Rancher v2.5.4 introduced the capability to configure receivers by filling out forms in the Rancher UI.

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 The following types of receivers can be configured in the Rancher UI:

@@ -93,7 +96,7 @@ The custom receiver option can be used to configure any receiver in YAML that ca
 | Field | Type | Description |
 |------|--------------|------|
 | URL | String   |  Enter your Slack webhook URL. For instructions to create a Slack webhook, see the [Slack documentation.](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack)  |
-| Default Channel |  String   |  Enter the name of the channel that you want to send alert notifications in the following format: `#<channelname>`. | 
+| Default Channel |  String   |  Enter the name of the channel that you want to send alert notifications in the following format: `#<channelname>`. |
 | Proxy URL   |    String    |  Proxy for the webhook notifications.  |
 | Enable Send Resolved Alerts |   Bool    |  Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |

@@ -102,7 +105,7 @@ The custom receiver option can be used to configure any receiver in YAML that ca
 | Field | Type | Description |
 |------|--------------|------|
 | Default Recipient Address |   String    |   The email address that will receive notifications.    |
-| Enable Send Resolved Alerts |  Bool    |   Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). | 
+| Enable Send Resolved Alerts |  Bool    |   Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |

 SMTP options:

@@ -121,7 +124,7 @@ SMTP options:
 | Integration Type | String | `Events API v2` or `Prometheus`. |
 | Default Integration Key | String |  For instructions to get an integration key, see the [PagerDuty documentation.](https://www.pagerduty.com/docs/guides/prometheus-integration-guide/)  |
 | Proxy URL | String |  Proxy for the PagerDuty notifications.  |
-| Enable Send Resolved Alerts |  Bool    |   Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). | 
+| Enable Send Resolved Alerts |  Bool    |   Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |

 # Opsgenie

@@ -230,7 +233,7 @@ url http://rancher-alerting-drivers-sachet.ns-1.svc:9876/alert
 <!-- https://github.com/messagebird/sachet -->

 </TabItem>
-<TabItem label="Rancher v2.5.4-2.5.7">
+<TabItem value="Rancher v2.5.4-2.5.7">

 The following types of receivers can be configured in the Rancher UI:

@@ -248,7 +251,7 @@ The custom receiver option can be used to configure any receiver in YAML that ca
 | Field | Type | Description |
 |------|--------------|------|
 | URL | String   |  Enter your Slack webhook URL. For instructions to create a Slack webhook, see the [Slack documentation.](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack)  |
-| Default Channel |  String   |  Enter the name of the channel that you want to send alert notifications in the following format: `#<channelname>`. | 
+| Default Channel |  String   |  Enter the name of the channel that you want to send alert notifications in the following format: `#<channelname>`. |
 | Proxy URL   |    String    |  Proxy for the webhook notifications.  |
 | Enable Send Resolved Alerts |   Bool    |  Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |

@@ -257,7 +260,7 @@ The custom receiver option can be used to configure any receiver in YAML that ca
 | Field | Type | Description |
 |------|--------------|------|
 | Default Recipient Address |   String    |   The email address that will receive notifications.    |
-| Enable Send Resolved Alerts |  Bool    |   Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). | 
+| Enable Send Resolved Alerts |  Bool    |   Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |

 SMTP options:

@@ -276,7 +279,7 @@ SMTP options:
 | Integration Type | String | `Events API v2` or `Prometheus`. |
 | Default Integration Key | String |  For instructions to get an integration key, see the [PagerDuty documentation.](https://www.pagerduty.com/docs/guides/prometheus-integration-guide/)  |
 | Proxy URL | String |  Proxy for the PagerDuty notifications.  |
-| Enable Send Resolved Alerts |  Bool    |   Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). | 
+| Enable Send Resolved Alerts |  Bool    |   Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |

 ### Opsgenie {#opsgenie-254-257}

@@ -306,8 +309,9 @@ Opsgenie Responders:
 The YAML provided here will be directly appended to your receiver within the Alertmanager Config Secret.

 </TabItem>
-<TabItem label="Rancher v2.5.0-2.5.3">
+<TabItem value="Rancher v2.5.0-2.5.3">
 The Alertmanager must be configured in YAML, as shown in these [examples.](#example-alertmanager-configs)
+
 </TabItem>
 </Tabs>

@@ -326,11 +330,11 @@ You can also set up multiple receivers by using the `continue` option for a rout
 To set up notifications via Slack, the following Alertmanager Config YAML can be placed into the `alertmanager.yaml` key of the Alertmanager Config Secret, where the `api_url` should be updated to use your Webhook URL from Slack:

 ```yaml
-route:  
+route:
  group_by: ['job']
  group_wait: 30s
  group_interval: 5m
-  repeat_interval: 3h 
+  repeat_interval: 3h
  receiver: 'slack-notifications'
 receivers:
 - name: 'slack-notifications'
@@ -4,6 +4,9 @@ shortTitle: Routes
 weight: 5
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 The route configuration is the section of the Alertmanager custom resource that controls how the alerts fired by Prometheus are grouped and filtered before they reach the receiver.

 When a Route is changed, the Prometheus Operator regenerates the Alertmanager custom resource to reflect the changes.
@@ -37,7 +40,7 @@ Labels should be used for identifying information that can affect the routing of
 Annotations should be used for information that does not affect who receives the alert, such as a runbook url or error message.

 <Tabs>
-<TabItem label="Rancher v2.5.4+">
+<TabItem value="Rancher v2.5.4+">

 ### Receiver
 The route needs to refer to a [receiver](#receiver-configuration) that has already been configured.
@@ -68,7 +71,9 @@ match_re:
 ```

 </TabItem>
-<TabItem label="Rancher v2.5.0-2.5.3">
+<TabItem value="Rancher v2.5.0-2.5.3">
+
 The Alertmanager must be configured in YAML, as shown in this [example.](../examples/#alertmanager-config)
+
 </TabItem>
 </Tabs>
@@ -3,6 +3,9 @@ title: Enable Monitoring
 weight: 1
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 As an [administrator]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/global-permissions/) or [cluster owner]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), you can configure Rancher to deploy Prometheus to monitor your Kubernetes cluster.

 This page describes how to enable monitoring and alerting within a cluster using the new monitoring application.
@@ -33,7 +36,7 @@ For more information about the default limits, see [this page.]({{<baseurl>}}/ra
 # Install the Monitoring Application

 <Tabs>
-<TabItem label="Rancher v2.5.8">
+<TabItem value="Rancher v2.5.8">

 ### Enable Monitoring for use without SSL

@@ -71,7 +74,7 @@ key.pfx=`base64-content`
 Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`.

 </TabItem>
-<TabItem label="Rancher v2.5.0-2.5.7">
+<TabItem value="Rancher v2.5.0-2.5.7">

 1. In the Rancher UI, go to the cluster where you want to install monitoring and click **Cluster Explorer.**
 1. Click **Apps.**
@@ -82,5 +85,4 @@ Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`.
 **Result:** The monitoring app is deployed in the `cattle-monitoring-system` namespace.

 </TabItem>
-
 </Tabs>
@@ -6,6 +6,9 @@ aliases:
  - /rancher/v2.x/en/monitoring-alerting/v2.5/persist-grafana/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 To allow the Grafana dashboard to persist after the Grafana instance restarts, add the dashboard configuration JSON into a ConfigMap. ConfigMaps also allow the dashboards to be deployed with a GitOps or CD based approach. This allows the dashboard to be put under version control.

 - [Creating a Persistent Grafana Dashboard](#creating-a-persistent-grafana-dashboard)
@@ -14,10 +17,10 @@ To allow the Grafana dashboard to persist after the Grafana instance restarts, a
 # Creating a Persistent Grafana Dashboard

 <Tabs>
-<TabItem label="Rancher v2.5.8+">
+<TabItem value="Rancher v2.5.8+">

 > **Prerequisites:**
-> 
+>
 > - The monitoring application needs to be installed.
 > - To create the persistent dashboard, you must have at least the **Manage Config Maps** Rancher RBAC permissions assigned to you in the project or namespace that contains the Grafana Dashboards. This correlates to the `monitoring-dashboard-edit` or `monitoring-dashboard-admin` Kubernetes native RBAC Roles exposed by the Monitoring chart.
 > - To see the links to the external monitoring UIs, including Grafana dashboards, you will need at least a [project-member role.]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/rbac/#users-with-rancher-cluster-manager-based-permissions)
@@ -39,7 +42,7 @@ To use your own dashboard:

 ### 2. Create a ConfigMap using the Grafana JSON model

-Create a ConfigMap in the namespace that contains your Grafana Dashboards (e.g. cattle-dashboards by default). 
+Create a ConfigMap in the namespace that contains your Grafana Dashboards (e.g. cattle-dashboards by default).

 The ConfigMap should look like this:

@@ -85,9 +88,10 @@ grafana.sidecar.dashboards.searchNamespace=ALL
 Note that the RBAC roles exposed by the Monitoring chart to add Grafana Dashboards are still restricted to giving permissions for users to add dashboards in the namespace defined in `grafana.dashboards.namespace`, which defaults to `cattle-dashboards`.

 </TabItem>
-<TabItem label="Rancher before v2.5.8">
+<TabItem value="Rancher before v2.5.8">
+
 > **Prerequisites:**
-> 
+>
 > - The monitoring application needs to be installed.
 > - You must have the cluster-admin ClusterRole permission.

@@ -2,10 +2,13 @@
 title: Pipelines
 weight: 10
 aliases:
-  - /rancher/v2.5/en/k8s-in-rancher/pipelines  
+  - /rancher/v2.5/en/k8s-in-rancher/pipelines
  - /rancher/v2.x/en/pipelines/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 > As of Rancher v2.5, Git-based deployment pipelines are now deprecated. We recommend handling pipelines with Rancher Continuous Delivery powered by [Fleet]({{<baseurl>}}/rancher/v2.5/en/deploy-across-clusters/fleet), available in Cluster Explorer.
 >
 >**Notice:** Fleet does not replace Rancher pipelines; the distinction is that Rancher pipelines are now powered by Fleet.
@@ -19,7 +22,7 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins
 - Build your application from code to image.
 - Validate your builds.
 - Deploy your build images to your cluster.
- Run unit tests.  
+- Run unit tests.
 - Run regression tests.

 >**Note:** Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses.
@@ -95,7 +98,8 @@ Before you can start configuring a pipeline for your repository, you must config
 Select your provider's tab below and follow the directions.

 <Tabs>
-<TabItem label="GitHub">
+<TabItem value="GitHub">
+
 1. From the **Global** view, navigate to the project that you want to configure pipelines.

 1. Select **Tools > Pipelines** in the navigation bar.
@@ -109,7 +113,7 @@ Select your provider's tab below and follow the directions.
 1. Click **Authenticate**.

 </TabItem>
-<TabItem label="GitLab">
+<TabItem value="GitLab">

 1. From the **Global** view, navigate to the project that you want to configure pipelines.

@@ -124,10 +128,11 @@ Select your provider's tab below and follow the directions.
 1. Click **Authenticate**.

 >**Note:**
-> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.  
+> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
 > 2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
+
 </TabItem>
-<TabItem label="Bitbucket Cloud">
+<TabItem value="Bitbucket Cloud">

 1. From the **Global** view, navigate to the project that you want to configure pipelines.

@@ -142,7 +147,7 @@ Select your provider's tab below and follow the directions.
 1. Click **Authenticate**.

 </TabItem>
-<TabItem label="Bitbucket Server">
+<TabItem value="Bitbucket Server">

 1. From the **Global** view, navigate to the project that you want to configure pipelines.

@@ -162,6 +167,7 @@ Select your provider's tab below and follow the directions.
 > 1. Setup Rancher server with a certificate from a trusted CA.
 > 1. If you're using self-signed certificates, import Rancher server's certificate to the Bitbucket server. For instructions, see the Bitbucket server documentation for [configuring self-signed certificates](https://confluence.atlassian.com/bitbucketserver/if-you-use-self-signed-certificates-938028692.html).
 >
+
 </TabItem>
 </Tabs>

@@ -206,7 +212,7 @@ Now that repositories are added to your project, you can start configuring the p

 1. Set up the trigger rules for the pipeline.

-1. Enter a **Timeout** for the pipeline. 
+1. Enter a **Timeout** for the pipeline.

 1. When all the stages and steps are configured, click **Done**.

@@ -6,6 +6,9 @@ aliases:
  - /rancher/v2.x/en/pipelines/storage/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 The pipelines' 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.

 This section assumes that you understand how persistent storage works in Kubernetes. For more information, refer to the section on [how storage works.]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/volumes-and-storage/how-storage-works/)
@@ -26,35 +29,26 @@ This section assumes that you understand how persistent storage works in Kuberne
    - **Add Volume > Use an existing persistent volume (claim)**

 1.  Complete the form that displays to choose a persistent volume for the internal Docker registry.
-<Tabs>
-<TabItem label="Add a new persistent volume">
-<br/>
-1. Enter a **Name** for the volume claim.
+    <Tabs>
+      <TabItem value="Add a new persistent volume">

-1. Select a volume claim **Source**:
+        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**.

-    - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
+      </TabItem>
+      <TabItem value="Use an existing persistent volume">

-    - 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. 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. Click **Define**.
-
-</TabItem>
-
-<TabItem label="Use an existing persistent volume">
-<br/>
-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>
-
-</Tabs>
+      </TabItem>
+    </Tabs>

 1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container.

@@ -70,34 +64,26 @@ This section assumes that you understand how persistent storage works in Kuberne
    - **Add Volume > Use an existing persistent volume (claim)**

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

-<TabItem label="Add a new persistent volume">
-<br/>
-1. Enter a **Name** for the volume claim.
+        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. Select a volume claim **Source**:
+      </TabItem>
+      <TabItem value="Use an existing persistent volume">

-    - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
+        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**.

-    - 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 label="Use an existing persistent volume">
-<br/>
-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>
-</Tabs>
+      </TabItem>
+    </Tabs>

 1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container.

@@ -5,12 +5,16 @@ aliases:
  - /rancher/v2.x/en/user-settings/preferences/
 ---

+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 Each user can choose preferences to personalize their Rancher experience. To change preference settings, open the **User Settings** menu and then select **Preferences**.

 The preferences available will differ depending on whether the **User Settings** menu was accessed while on the Cluster Manager UI or the Cluster Explorer UI.

 <Tabs>
-<TabItem label="Cluster Manager">
+<TabItem value="Cluster Manager">
+
 ## Theme

 Choose your background color for the Rancher UI. If you choose **Auto**, the background color changes from light to dark at 6 PM, and then changes back at 6 AM.
@@ -23,8 +27,10 @@ This section displays the **Name** (your display name) and **Username** (your lo

 On pages that display system objects like clusters or deployments in a table, you can set the number of objects that display on the page before you must paginate. The default setting is `50`.

+
 </TabItem>
-<TabItem label="Cluster Explorer">
+<TabItem value="Cluster Explorer">
+
 ## Theme

 Choose your background color for the Rancher UI. If you choose **Auto**, the background color changes from light to dark at 6 PM, and then changes back at 6 AM.