關於節點數擴充升級

本文會簡要介紹標準滾動式更新，然後詳細說明激增更新，這是一種特殊的滾動式更新。與標準滾動式更新相比，突波更新可讓您設定更新速度。您也可以透過節點數擴充更新，控管更新對工作負載造成的干擾。

如要瞭解如何為 GKE on AWS 啟用及設定大量更新，請參閱「設定節點集區的大量更新」。

標準滾動式更新的運作方式

部分節點集區更新 (例如修改節點集區的註解) 不需要重新啟動節點，因此不會觸發滾動更新。如果 GKE on AWS 可以在不重新啟動或重新建立資源的情況下，將變更套用至節點集區，就會這麼做，以避免服務中斷。

不過，在 GKE on AWS 中，節點集區的大部分更新通常會終止現有節點，並使用更新後的設定啟動新節點。終止現有節點的程序可能會中斷工作負載。

根據預設，GKE on AWS 會執行標準滾動式更新。這個方法會一次更新一個節點，並使用「先終止再建立」的方式取代節點：先終止節點，然後啟動新的更新節點。這樣可將中斷情況降到最低，因為在任何指定時間，系統只會終止並取代一個節點。

以下是 GKE on AWS 在標準滾動式更新期間採取的步驟：

從節點集區選取節點，並將節點標示為無法使用，確保不會有新的 Pod 在該節點上啟動，這項動作稱為「封鎖」。
將受限節點中的作用中 Pod 重新排程到叢集內其他可用的節點。如果其他節點有足夠的容量，就會容納遭逐出的 Pod。否則，叢集自動調度器 (在標準滾動更新期間仍處於啟用狀態) 會開始向上擴充，並佈建額外節點，確保有足夠容量可排程遭逐出的 Pod。如要瞭解在此程序中採取哪些措施來保護工作負載，請參閱「調整大小期間的工作負載保護措施」。
終止已限制的節點。
以具有更新設定的新節點取代受限節點。
對新上線的節點執行健康狀態檢查。如果節點集區未通過健康狀態檢查，系統會標示 DEGRADED 狀態。執行 gcloud container aws node-pools describe 指令即可查看這個狀態。節點集區標示為 DEGRADED 後，系統可能不會將新 Pod 排定到該集區的節點上。
持續逐一更新節點，直到集區中的所有節點都更新完畢為止。

尖峰時段更新的運作方式

在 GKE on AWS 中，標準滾動式方法會一次更新一個節點。節點數擴充更新是滾動式更新的一種形式，可讓您同時更新多個節點。因此，節點數擴充更新比標準的滾動更新更快。不過，同時更新多個節點可能會中斷工作負載。為減輕這類影響，突波更新提供多種選項，可調整工作負載的中斷程度。

尖峰更新與標準滾動更新的另一個差異，在於節點的取代方式。標準滾動更新會使用「先終止再建立」策略取代節點。視所選設定而定，尖峰更新可使用「先建立再終止」策略、「先終止再建立」策略，甚至是兩者的組合。

在大量更新中，叢集自動調整功能扮演的角色比標準滾動更新更重要，因此在下列 GKE on AWS 於大量更新期間執行的動作清單中，這項功能會特別顯眼：

建立新的自動調度資源群組：GKE on AWS 會根據更新指令指定的修改項目，佈建新的節點，並將這些新節點指派給新的 AWS 自動調度資源群組 (ASG)。
叢集自動配置器行為：當突增更新開始時，系統會為新的自動調度資源群組啟用叢集自動配置器。原始自動調度資源群組的叢集自動調度器已停用。這樣一來，任何擴充作業都只會以新群組為目標。
節點更換：視節點數擴充更新參數而定，系統會採用不同的節點更換策略：
- 「create before terminate」：當 max-surge-update 參數設為大於零的值時，系統會啟用這項策略。系統會在新的 ASG 中產生新節點，然後終止原始 ASG 中的舊節點，盡量減少服務中斷情形。
- 「terminate before create」：當 max-surge-update 參數設為零，且 max-unavailable-update 參數的值大於零時，系統會觸發這個方法。系統會先終止原始 ASG 中的節點，然後在新 ASG 中建立新節點。
節點集區大小調整：更新期間，節點集區大小 (也就是舊 ASG 和新 ASG 中的節點總和) 可能會高於或低於更新開始前節點集區中的原始節點數量。具體來說，GKE on AWS 的目標是將節點總數維持在 (original_count - max-unavailable-update) 到 (original_count + max-surge-update) 的範圍內。舊 ASG (original_count) 中的節點最終會由新 ASG 中的更新節點取代。如果叢集自動調度器偵測到 Pod 無法排定，可能會在新 ASG 中啟動更多節點，但會維持在 min-nodes 和 max-nodes 定義的限制內。

說明程序的範例

如要進一步瞭解尖峰時段價格更新的運作方式，請參考以下範例。假設您有一個包含 5 個節點的節點集區，並執行下列指令：

  gcloud container aws node-pools update production-node-pool
      --cluster my-cluster \
      --location us-west1 \
      --max-surge-update 2 \
      --max-unavailable-update 1 \
      --node-version 1.27.6-gke.700

在本範例中，max-surge-update 設為 2，max-unavailable-update 設為 1，且您要提供新的節點集區版本 (也就是變更節點集區中節點執行的 GKE 版本)。

執行這個指令會觸發大量更新，而 GKE on AWS 會執行下列動作：

由於 max-surge-update 的值等於 2，因此會建立 2 個額外節點。
將這 2 個額外節點指派給新的 AWS 自動調整規模群組。
這些新節點運作後，系統會從原始自動調度群組中移除節點。AWS 上的 GKE 最多會關閉 3 個節點 (max-surge-update 和 max-unavailable-update 的總和)，但會確保任何時間最多只有一個節點無法使用 (因為 max-unavailable-update 值為 1)。
重複上述步驟，直到節點集區中的所有節點都更新為新的 GKE 版本為止。

更新期間，節點集區會包含 4 到 7 個運作中的節點。

執行尖峰更新前的注意事項

執行大量更新前，請注意下列事項：

在這個激增步驟中建立的其他執行個體，可能會超過 AWS 執行個體配額限制。如果配額不足，且無法佈建這些額外執行個體，更新作業可能會失敗。
如果 max-unavailable-update 設為 0，Pod 遭到撤銷並重新排程到較新的節點時，工作負載仍可能中斷。
可同時更新的節點數量上限等於 max-surge-update 和 max-unavailable-update 的總和，但不得超過 20 個。

根據需求選擇合適的加成設定

標準滾動式更新通常採用「先終止再建立」的方法，但突增更新更具彈性。視設定而定，尖峰更新可採用「先建立再終止」策略、「先終止再建立」策略，或兩者兼具。本節說明各種設定，協助您為工作負載選擇最佳方法。

下表列出三個設定範例，並強調這些設定對更新速度和工作負載潛在干擾的影響：

名稱	說明	設定
平衡設定 (預設)	平衡：速度較慢，但干擾最少。	maxSurge=1, maxUnavailable=0
快速更新，不需額外資源	快速，沒有尖峰資源，最擾亂。	maxSurge=0, maxUnavailable=20
快速更新，干擾較少	速度快、資源充足，且干擾較少。	maxSurge=20, maxUnavailable=0

下表中的各項設定將在後續章節中說明。

平衡設定 (預設)

如要使用尖峰更新功能，最簡單的方法是使用 max-surge-update=1 和 max-unavailable-update=0 的預設設定。這項設定會在更新期間，只將 1 個擴充節點新增至節點集區，且一次只更新 1 個節點，並採用「先建立再終止」的做法。相較於標準的非大量更新，這項方法較不會造成中斷，可加快更新期間的 Pod 重新啟動作業，且進展更為保守。標準的非大量更新相當於 (max-surge-update=0, max-unavailable-update=1)。

請注意，採用平衡設定可能會導致額外費用，因為更新期間會暫時新增節點。這個額外節點啟用時會產生費用，因此與沒有尖峰節點的方法相比，整體支出會略為增加。

快速更新，無須額外資源

如果工作負載可容許中斷，或許適合採用較快速的更新方法。設定 max-surge-update=0 和 max-unavailable-update=20 即可達成此目的。採用這項設定後，系統就能同時更新 20 個節點，不必新增任何突增節點。這個更新方法採用「先終止再建立」的做法。由於程序中不會導入額外的尖峰節點，因此這種方法也最符合成本效益，可避免與臨時節點相關的額外費用。

快速更新，減少干擾

如果工作負載容易受到中斷影響，您可以透過下列設定提高更新速度：max-surge-update=20 和 max-unavailable-update=0。這項設定會以「先建立再終止」的方式，平行更新 20 個節點。

不過，如果您為工作負載設定 PodDisruptionBudgets (PDB)，更新的整體速度可能會受到限制。這是因為 PDB 會限制在任何特定時刻可排空的 Pod 數量。雖然 Pod 中斷預算的設定可能有所不同，但如果您為節點集區上執行的一或多個工作負載建立 Pod 中斷預算，且 maxUnavailable 等於 1，則一次只能逐出這些工作負載的一個 Pod，進而限制整個更新作業的平行處理。

請注意，在更新程序開始時啟動多個尖峰節點，可能會導致費用暫時增加，尤其是與更新期間未新增或新增較少節點的設定相比時。

後續步驟