From ede45042e91687bff16aac5d1044882df77c7832 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 89b5174c57e..a765eaa6c49 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:** 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. +> 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.