本文講述了升級 RKE 叢集時，RKE 內部發生的事項，使用者輸入升級 RKE 叢集的命令rke up以後，etcd 節點、controlplane 節點、worker 節點和外掛在升級的過程中經歷了哪些步驟。

RKE v1.1.0 及以上的升級流程

概述

RKE v1.1.0 及以上的版本提供了以下新功能：

• 支援不宕機升級，編輯或升級叢集時，不會影響叢集內的應用。

• 支援手動指定單個節點，並單獨升級這個節點。

• 支援使用包含老版本的 Kubernetes 叢集快照，將叢集使用的 Kubernetes 恢復到先前的版本。這個功能使升級叢集的過程變得更加安全。如果某次升級的過程中，叢集中有些節點無法完成更新，導致該節點內的 pods 和應用無法訪問，您可以將已經完成升級的叢集所使用的 Kubernetes 降級為升級前使用的版本。

使用預設配置選項，輸入rke up命令更新叢集時，會依次觸發以下事項：

1. 逐個更新每個節點的 etcd plane。

2. 逐個更新 controlplane 節點，包括 controlplane 元件和 controlplane 節點的 worker plane 元件。

3. 逐個更新每個 etcd 節點的 worker plane 元件。

4. 批量更新 worker 節點，您可以配置每批更新的節點數量。在批量更新 worker 節點的過程中，可能會有部分節點不可用，為了降低這部分節點對於升級的影響，您可以配置最大不可用節點數量。預設的最大不可用節點數量是總節點數量的 10%，最小值為 1，如果是小數則向下取整至最近的一個整數

   ，詳情請參考下文。

5. 更新每個外掛。

下文講述執行rke up命令以後，每一種類的節點和外掛是如何運作的。這些資訊可以幫助您更好地理解和使用升級策略，在升級出現問題時，也能夠幫助您進行問題排查。

etcd 節點升級流程

升級叢集的第一步是逐個升級 etcd 節點。

RKE 叢集內的任何一個 etcd 節點在升級的過程中失效，會導致叢集升級失敗。叢集的升級狀態會停滯在"升級中"，無法繼續執行其他 etcd 節點、controlplane 節點、worker 節點和外掛的升級。

如果您的叢集升級狀態一直停留在“升級中”，很有可能是因為在升級 etcd 節點的過程中出現了節點失效的事件，針對這種情況進行問題排查時，請首先檢查該叢集中是否有 etcd 節點已經失效（node failures）。

controlplane 節點升級流程

RKE 支援逐個升級和批量升級 controlplane 節點。RKE controlplane 節點的預設升級策略是逐個升級。您需要配置最大不可用節點數max_unavailable_controlplane，才可以使用批量升級 controlplane 節點的功能。只要失效的 controlplane 節點數量或百分比沒有達到最大不可用節點的限制，Rancher 會繼續升級 controlplane 節點，然後升級 worker 節點。

max_unavailable_controlplane的取值範圍可以是百分比，也可以是正整數。系統會使用該數字判斷每一次升級是否成功。使用百分時，表示的數量是節點總數*百分比，然後向下取整；如果向下取整後的結果是 0~1 之間的任意小數，則會取 1 作為最後的結果。使用正整數時，請注意該數字不能大於或等於節點總數，否則在極端情況下，例如一個批次的節點全部失效，且max_unavailable_controlplane大於或等於節點總數，即使所有節點都升級失敗，仍然會被判定為升級成功。這種取值沒有意義，不僅沒有簡化升級流程，還給後續的問題排查添加了難度。

舉個例子，如果您有 9 個 controlplane 節點，max_unavailable_controlplane設定為 25%，則每一次升級的節點數量是 2，因為 9 * 25% = 2.22，向下取整得 2 。如果您有 3 個 controlplane 節點，max_unavailable_controlplane設定為 1%，則每次升級的節點數量是 1，因為系統要求每次升級的節點數量不小於 1。

配置批量升級和max_unavailable_controlplane的目的是，先完成一部分 controlplane 節點的升級，再針對剩餘有問題的 controlplane 節點進行排查，然後重複升級和問題排查的過程，直至完成所有 controlplane 節點升級。相比逐個升級節點而言，批量升級效率更高，max_unavailable_controlplane提升了升級的容錯率，不會因為單個節點失效，排查不出問題，而導致後面的所有節點都無法升級。

如果任意一個 controlplane 節點無法升級，升級流程就會停滯在這個階段，無法進行 worker 節點升級。

Worker 節點的升級流程

RKE 預設升級 worker 節點的方式是批量升級。每次批量升級的節點數量由cluster.yml檔案中的最大不可用節點max_unavailable_worker決定。

最大不可用節點max_unavailable_worker可以是百分比，也可以是正整數，預設值是 10%，代表的意思是節點總數的 10%，遇到小數時向下取整。系統會使用該數字判斷每一次升級是否成功。使用百分時，表示的數量是節點總數*百分比，然後向下取整；如果向下取整後的結果是 0~1 之間的任意小數，則會取 1 作為最後的結果。

舉個例子，如果您有 11 個 worker 節點，max_unavailable_worker設定為 25%，每一次升級的節點數量是 2，因為 11 * 25% = 2.75，向下取整得 2 。如果您有 3 個 worker 節點，max_unavailable_worker設定為 1%，每次升級的節點數量是 1，因為系統要求每次升級的節點數量不小於 1。

當同一批升級的所有節點的狀態轉為Ready時，會開始下一批節點升級。如果kubelet和kube-proxy已經啟動了，就代表節點的狀態已經變為Ready。

RKE 會在開始升級之前掃描叢集，尋找關機或無法連線的宿主機。如果不可用的節點超出max_unavailable_worker設定的值，會停止升級。

RKE 會在開始升級之前將節點標記為不可用，完成升級後將節點重新標記為可用。您也可以將 RKE 配置為升級前驅逐 pods。

RKE 首先升級節點，然後升級外掛。只要不可用的節點沒有超出限制，RKE 在完成節點升級後會開始升級外掛。例如，如果一個叢集有兩個 worker 節點，升級的時候其中一個節點不可用，而最大不可用節點的數量大於 1，則不會導致升級失敗，完成 1 個節點的升級後，RKE 會開始升級外掛。

外掛的升級流程

您在 pods 中部署的應用是否可用，取決於 RKE 外掛是否可用。RKE 外掛用於部署幾個叢集元件，包括網路外掛，Ingress Controller，DNS 提供商，和 metrics server。

因為 RKE 外掛對於允許叢集接受流量來說是至關重要的，您需要批量升級外掛以保持可用性。您需要在cluster.yml檔案中為每個外掛配置最大不可用副本數量以保證在升級的過程中有足夠可用副本保持叢集可用。

配置外掛的例子，請檢視RKE 外掛配置選項。