mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 20:48:11 +00:00
Updating tabs
This commit is contained in:
Jennifer Travinski
+6
-6
@@ -27,8 +27,8 @@ This section covers the following topics:
|
||||
|
||||
# How Snapshots Work
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.4.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.4.0+">
|
||||
|
||||
### Snapshot Components
|
||||
|
||||
@@ -84,8 +84,8 @@ On restore, the following process is used:
|
||||
4. The other etcd nodes download the snapshot and validate the checksum so that they all use the same snapshot for the restore.
|
||||
5. The cluster is restored and post-restore actions will be done in the cluster.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.4.0" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.4.0">
|
||||
When Rancher creates a snapshot, only the etcd data is included in the snapshot.
|
||||
|
||||
Because the Kubernetes version is not included in the snapshot, there is no option to restore a cluster to a different Kubernetes version.
|
||||
@@ -128,8 +128,8 @@ On restore, the following process is used:
|
||||
4. The other etcd nodes download the snapshot and validate the checksum so that they all use the same snapshot for the restore.
|
||||
5. The cluster is restored and post-restore actions will be done in the cluster.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Configuring Recurring Snapshots
|
||||
|
||||
|
||||
+6
-6
@@ -55,8 +55,8 @@ For imported clusters, the process for removing Rancher is a little different. Y
|
||||
|
||||
After the imported 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 imported 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 an imported cluster using the Rancher UI (or API), the following events occur.
|
||||
@@ -69,8 +69,8 @@ After you initiate the removal of an imported cluster using the Rancher UI (or A
|
||||
|
||||
**Result:** All components listed for imported clusters in [What Gets Removed?](#what-gets-removed) are deleted.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "By Script" %}}
|
||||
</TabItem>
|
||||
<TabItem label="By Script">
|
||||
Rather than cleaning imported cluster nodes using the Rancher UI, you can run a script instead. This functionality is available since `v2.1.0`.
|
||||
|
||||
>**Prerequisite:**
|
||||
@@ -100,8 +100,8 @@ Rather than cleaning imported cluster nodes using the Rancher UI, you can run a
|
||||
|
||||
**Result:** The script runs. All components listed for imported clusters in [What Gets Removed?](#what-gets-removed) are deleted.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Windows Nodes
|
||||
|
||||
|
||||
@@ -130,8 +130,8 @@ However, you can override the conditions draining when you initiate the drain. Y
|
||||
|
||||
The node draining options are different based on your version of Rancher.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.2.x+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.2.x+">
|
||||
There are two drain modes: aggressive and safe.
|
||||
|
||||
- **Aggressive Mode**
|
||||
@@ -143,8 +143,8 @@ There are two drain modes: aggressive and safe.
|
||||
- **Safe Mode**
|
||||
|
||||
If a node has standalone pods or ephemeral data it will be cordoned but not drained.
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.2.x" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.2.x">
|
||||
|
||||
The following list describes each drain option:
|
||||
|
||||
@@ -159,8 +159,8 @@ The following list describes each drain option:
|
||||
- **Even if there are pods using emptyDir**
|
||||
|
||||
If a pod uses emptyDir to store local data, you might not be able to safely delete it, since the data in the emptyDir will be deleted once the pod is removed from the node. Similar to the first option, Kubernetes expects the implementation to decide what to do with these pods. Choosing this option will delete these pods.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Grace Period
|
||||
|
||||
|
||||
+6
-6
@@ -32,8 +32,8 @@ If your Kubernetes cluster is broken, you can restore the cluster from a snapsho
|
||||
|
||||
Restores changed in Rancher v2.4.0.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.4.0+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.4.0+">
|
||||
|
||||
Snapshots are composed of the cluster data in etcd, the Kubernetes version, and the cluster configuration in the `cluster.yml.` These components allow you to select from the following options when restoring a cluster from a snapshot:
|
||||
|
||||
@@ -57,8 +57,8 @@ When rolling back to a prior Kubernetes version, the [upgrade strategy options](
|
||||
|
||||
**Result:** The cluster will go into `updating` state and the process of restoring the `etcd` nodes from the snapshot will start. The cluster is restored when it returns to an `active` state.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.4.0" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.4.0">
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
@@ -75,8 +75,8 @@ When rolling back to a prior Kubernetes version, the [upgrade strategy options](
|
||||
|
||||
**Result:** The cluster will go into `updating` state and the process of restoring the `etcd` nodes from the snapshot will start. The cluster is restored when it returns to an `active` state.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Recovering etcd without a Snapshot
|
||||
|
||||
|
||||
+6
-6
@@ -44,8 +44,8 @@ In this section of the [RKE documentation,]({{<baseurl>}}/rke/latest/en/upgrades
|
||||
|
||||
# Recommended Best Practice for Upgrades
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.4+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.4+">
|
||||
When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
|
||||
1. Take a snapshot.
|
||||
@@ -53,8 +53,8 @@ When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
1. If the upgrade fails, revert the cluster to the pre-upgrade Kubernetes version. This is achieved by selecting the **Restore etcd and Kubernetes version** option. This will return your cluster to the pre-upgrade kubernetes version before restoring the etcd snapshot.
|
||||
|
||||
The restore operation will work on a cluster that is not in a healthy or active state.
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.4" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.4">
|
||||
When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
|
||||
1. Take a snapshot.
|
||||
@@ -62,8 +62,8 @@ When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
1. If the upgrade fails, restore the cluster from the etcd snapshot.
|
||||
|
||||
The cluster cannot be downgraded to a previous Kubernetes version.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Upgrading the Kubernetes Version
|
||||
|
||||
|
||||
Reference in New Issue
Block a user