From b96fb448ea9045786047df319f0364beacb2c16a Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 31 Mar 2020 13:43:51 -0700 Subject: [PATCH] Edit note on backing up K3s before upgrading --- .../v2.x/en/cluster-provisioning/imported-clusters/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md b/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md index 010f949eabe..89b5174c57e 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md @@ -84,7 +84,7 @@ When a K3s cluster is imported, Rancher will recognize it as K3s, and the Ranche ### Configuring K3s Cluster Upgrades -> **Important:** Before upgrading the Kubernetes version of a high-availability K3s cluster, back up the database in whichever way is recommended by the relational database provider. If the upgrade fails, restore the cluster from the snapshot. +> **Important:** 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. The **concurrency** is the maximum number of nodes that are permitted to be unavailable during an upgrade. If number of unavailable nodes is larger than the **concurrency,** the upgrade will fail. If an upgrade fails, you may need to repair or remove failed nodes before the upgrade can succeed.