Updating tabs

versioned_docs/version-2.6/v2.6/en/cluster-admin/certificate-rotation/certificate-rotation.md

@@ -9,8 +9,8 @@ By default, Kubernetes clusters require certificates and Rancher launched Kubern
 
 Certificates can be rotated for the following services:
 
-{{% tabs %}}
-{{% tab "RKE" %}}
+<Tabs>
+<TabItem label="RKE">
 
 - etcd
 - kubelet (node certificate)
@@ -20,8 +20,8 @@ Certificates can be rotated for the following services:
 - kube-scheduler
 - kube-controller-manager
 
-{{% /tab %}}
-{{% tab "RKE2" %}}
+</TabItem>
+<TabItem label="RKE2">
 
 - admin
 - api-server
@@ -35,8 +35,8 @@ Certificates can be rotated for the following services:
 - kubelet
 - kube-proxy
 
-{{% /tab %}}
-{{% /tabs %}}
+</TabItem>
+</Tabs>
 
 > **Note:** For users who didn't rotate their webhook certificates, and they have expired after one year, please see this [page]({{<baseurl>}}/rancher/v2.6/en/troubleshooting/expired-webhook-certificates/) for help.
 
@@ -58,15 +58,15 @@ Rancher launched Kubernetes clusters have the ability to rotate the auto-generat
 
 ### Additional Notes
 
-{{% tabs %}}
-{{% tab "RKE" %}}
+<Tabs>
+<TabItem label="RKE">
 
 Even though the RKE CLI can use custom certificates for the Kubernetes cluster components, Rancher currently doesn't allow the ability to upload these in Rancher launched Kubernetes clusters.
 
-{{% /tab %}}
-{{% tab "RKE2" %}}
+</TabItem>
+<TabItem label="RKE2">
 
 In RKE2, both etcd and control plane nodes are treated as the same `server` concept. As such, when rotating certificates of services specific to either of these components will result in certificates being rotated on both. The certificates will only change for the specified service, but you will see nodes for both components go into an updating state. You may also see worker only nodes go into an updating state. This is to restart the workers after a certificate change to ensure they get the latest client certs.
 
-{{% /tab %}}
-{{% /tabs %}}
+</TabItem>
+</Tabs>

versioned_docs/version-2.6/v2.6/en/cluster-admin/cleaning-cluster-nodes/cleaning-cluster-nodes.md

@@ -55,8 +55,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 %}}
-{{% tab "By UI / API" %}}
+<Tabs>
+<TabItem label="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.
@@ -69,8 +69,8 @@ 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.
 
-{{% /tab %}}
-{{% tab "By Script" %}}
+</TabItem>
+<TabItem label="By Script">
 Rather than cleaning registered cluster nodes using the Rancher UI, you can run a script instead.
 
 >**Prerequisite:**
@@ -100,8 +100,8 @@ Rather than cleaning registered cluster nodes using the Rancher UI, you can run
 
 **Result:** The script runs. All components listed for registered clusters in [What Gets Removed?](#what-gets-removed) are deleted.
 
-{{% /tab %}}
-{{% /tabs %}}
+</TabItem>
+</Tabs>
 
 ### Windows Nodes