Google Distributed Cloud 叢集升級最佳做法

本文說明升級 Google Distributed Cloud 的最佳做法和注意事項。您將瞭解如何為叢集升級做準備，以及升級前應遵循的最佳做法。這些最佳做法有助於降低叢集升級相關風險。

如果您有多個環境 (例如測試、開發和生產)，建議先從最不重要的環境 (例如測試) 開始，並驗證升級功能。確認升級成功後，請繼續下一個環境。重複這個程序，直到升級實際工作環境為止。這種做法可讓您從一個關鍵點移至下一個關鍵點，並驗證升級和工作負載是否都正常運作。

升級檢查清單

為盡量順利完成升級程序，請先檢查並完成下列事項，再開始升級叢集：

規劃升級作業

更新作業可能會造成中斷。升級前，請仔細規劃，確保環境和應用程式已準備就緒。您可能也需要在正常營業時間過後，流量最少時排定升級作業。

預估時間投入量並規劃維護期間

根據預設，系統會平行升級所有節點集區。但每個節點集區內的節點會依序升級，因為每個節點都必須排空並重建。因此，升級總時間取決於最大節點集區中的節點數量。如要粗略估算升級時間，請將 15 分鐘乘以最大節點集區中的節點數。舉例來說，如果最大集區中有 10 個節點，升級總時間約為 15 * 10 = 150 分鐘或 2.5 小時。

以下幾種方法可縮短升級時間，並簡化升級規劃和排程：

• 在 1.28 以上版本中，您可以為個別節點集區設定 maxSurge 值，加快升級速度。使用 maxSurge 升級節點時，升級多個節點所需的時間，與升級單一節點相同。

• 如果叢集版本為 1.16 以上，升級節點集區時可以略過次要版本。執行跳過版本升級，可將節點集區依序升級兩個版本所需的時間減半。此外，略過版本升級可讓您延長升級間隔，以維持使用支援版本。減少升級次數可降低工作負載中斷情形，並縮短驗證時間。詳情請參閱「升級節點集區時略過版本」。

• 您可以分別升級使用者叢集的控制層和節點集區。有了這項彈性，您就能規劃多個較短的維護時間，而不是一個較長的維護時間，藉此升級整個叢集。詳情請參閱「升級節點集區」。

備份使用者和管理員叢集

開始升級前，請先備份使用者和管理員叢集。

使用者叢集備份是使用者叢集 etcd 儲存空間的快照。etcd 儲存空間包含管理叢集狀態所需的所有 Kubernetes 物件和自訂物件。快照包含重建叢集元件和工作負載所需的資料。詳情請參閱如何備份使用者叢集。

使用 Google Distributed Cloud 1.8 以上版本時，您可以在管理叢集設定檔中，透過 clusterBackup.datastore 設定自動備份。如要在現有叢集中啟用這項功能，請編輯管理員叢集設定檔並新增 clusterBackup.datastore 欄位，然後執行 gkectl update admin。

啟用 clusterBackup.datastore 後，系統會自動在設定的 vSphere 資料儲存庫中備份管理員叢集。etcd每當管理員叢集有變更時，系統就會重複執行這項備份程序。啟動叢集升級時，系統會先執行備份工作，再升級叢集。

如要還原管理員叢集備份，請參閱「使用 gkectl 備份及還原管理員叢集」。

查看 PodDisruptionBudgets 的使用情形

在 Kubernetes 中，PodDisruptionBudgets (PDB) 可協助避免不必要的應用程式停機或中斷。PDB 會指示排程器一律讓一定數量的 Pod 保持運作，即使其他 Pod 可能會失敗也一樣。這項行為是提供應用程式可用性的實用方法。

1. 如要檢查叢集中設定了哪些 PDB，請使用 kubectl get pdb 指令：

   kubectl get pdb -A --kubeconfig KUBECONFIG
   

   將 KUBECONFIG 替換為 kubeconfig 檔案的名稱。

   以下輸出內容範例顯示名為 istio-ingress、istiod 和 kube-dns 的 PDB：

   NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
   gke-system    istio-ingress   1               N/A               1                     16d
   gke-system    istiod          1               N/A               1                     16d
   kube-system   kube-dns        1               N/A               1                     16d
   

在上表中，每個 PDB 都指定至少必須有一個 Pod 可用。節點排空時，這項可用性在升級期間至關重要。

檢查無法滿足的 PDB。舉例來說，如果 Deployment 只包含 1 個副本，您可能會將最低可用性設為 1。在這個範例中，資源控制器無法滿足 PDB，因此排空作業遭到中斷。

為確保 PDB 不會干擾升級程序，請在開始升級前檢查特定叢集上的所有 PDB。您可能需要與開發團隊和應用程式擁有者協調，在叢集升級期間暫時變更或停用 PDB。

Google Distributed Cloud 會在升級程序中執行預檢，警告您 PDB。不過，您也應手動驗證 PDB，確保升級過程順利。如要進一步瞭解 PDB，請參閱「為應用程式指定中斷預算」。

查看可用的 IP 位址

升級使用者叢集和非高可用性管理員叢集 (即非高可用性管理員叢集) 時，請注意下列 IP 位址事項：

• 叢集升級程序會建立新節點並排空資源，然後刪除舊節點。建議您一律為叢集保留 N+1 個 IP 位址，其中 N 是叢集中的節點數量。這項建議僅適用於非高可用性管理員叢集 (只有一個控制層節點) 和使用者叢集。

• 使用靜態 IP 位址時，IP 位址區塊檔案中必須列出必要的 IP 位址。

  • 升級非高可用性管理員叢集時，請在管理員叢集使用的 IP 區塊檔案中新增額外的 IP 位址。這個檔案的路徑必須在管理員叢集設定檔的 network.ipMode.ipBlockFilePath 欄位中指定。
  • 升級使用者叢集時，請在使用者叢集使用的 IP 區塊檔案中新增額外 IP 位址。這個檔案的路徑必須在使用者叢集設定檔的 network.ipMode.ipBlockFilePath 欄位中指定。

• 如果您使用 DHCP，請確保新 VM 在升級期間，可以在適用的子網路中取得額外的 IP 租用。

  如要新增 IP 位址，請更新 IP 區塊檔案，然後執行 gkectl update 指令。詳情請參閱「規劃 IP 位址」。

• 如果您使用靜態 IP 位址，並想加快使用者叢集升級程序，請在 IP 位址區塊檔案中列出足夠的 IP 位址，讓每個節點集區都能使用額外的 IP 位址。這個方法可讓程序加快 VM 新增和移除程序，因為這是以每個節點集區為基礎執行。

  雖然這個方法是加快升級使用者叢集的好選擇，但請先考量 vSphere 環境的資源和效能可用性，再繼續操作。

• 如果整個使用者叢集只有一個備用 IP，即使使用多個節點集區，這項限制也會導致升級程序一次只能升級一個 VM。

高可用性管理員叢集升級時，不需要 N+1 個 IP 位址。高可用性管理員叢集中的三個控制層節點會逐一重建，確保不需要額外的 IP 位址。

查看叢集使用率

請確認節點排空時可以撤離 Pod，且升級叢集有足夠的資源來管理升級作業。如要查看叢集的目前資源用量，您可以使用 Google Cloud Observability 中的自訂資訊主頁，或直接在叢集上使用 kubectl top nodes 等指令。

針對叢集執行的指令會顯示目前叢集資源用量的快照。資訊主頁可提供更詳細的資源耗用情況。這項資源用量資料有助於判斷升級時機，例如週末或晚上，以盡量減少中斷，具體取決於執行的工作負載和用途。

管理員叢集升級的時間可能不如使用者叢集重要，因為管理員叢集升級通常不會造成應用程式停機。不過，在開始升級管理員叢集之前，仍請務必檢查 vSphere 中是否有可用資源。此外，升級管理員叢集可能會有風險，因此建議在叢集管理存取權較不重要的使用期間進行升級。

詳情請參閱叢集升級期間會受到影響的服務。

檢查 vSphere 使用率

確認基礎 vSphere 基礎架構有足夠的資源。 如要查看這項資源用量，請在 vCenter 中選取叢集，然後查看「摘要」分頁。

「摘要」分頁會顯示整個叢集的記憶體、CPU 和儲存空間總用量。由於 Google Distributed Cloud 升級需要額外資源，您也應檢查叢集是否能處理這些額外資源要求。

一般來說，您的 vSphere 叢集必須能夠支援下列額外資源：

• 每個管理員叢集升級作業 +1 個 VM
• 每次升級使用者叢集時，每個節點集區會多出 1 個 VM

舉例來說，假設使用者叢集有 3 個節點集區，每個節點集區的節點都使用 8 個 vCPU 和 32 GB 以上的 RAM。由於系統預設會平行升級 3 個節點集區，因此升級程序會為 3 個額外緩衝節點耗用下列額外資源：

• 24 個 vCPU
• 96 GB RAM
• VM 磁碟空間 + 96 GB 的 vSwap

升級程序會使用 vSphere 複製作業建立 VM。從範本複製多部 VM 時，可能會導致 I/O 作業增加，進而對基礎儲存系統造成壓力。如果升級期間，基礎儲存子系統無法提供足夠效能，升級速度可能會大幅減緩。

雖然 vSphere 的設計可同時使用資源，並提供資源機制 (即使資源過度承諾也一樣)，但我們強烈建議不要過度承諾 VM 記憶體。記憶體過度承諾可能會導致嚴重的效能影響，進而影響整個叢集，因為 vSphere 會從資料儲存庫換出頁面，提供「缺少的 RAM」。這種行為可能會導致叢集升級期間發生問題，並對 vSphere 叢集上執行的其他 VM 造成效能影響。

如果可用資源已不足，請關閉不必要的 VM，以滿足這些額外需求，並避免效能受到影響。

檢查叢集健康狀態和設定

升級前，請在所有叢集上執行下列工具：

• gkectl diagnose 指令：gkectl diagnose確保所有叢集健康狀態良好。這項指令會執行進階檢查，例如找出設定不正確的節點，或 Pod 處於停滯狀態的節點。如果 gkectl diagnose 指令顯示 Cluster unhealthy 警告，請先修正問題，再嘗試升級。詳情請參閱「診斷叢集問題」。

• 升級前工具：除了檢查叢集健康狀態和設定外，升級前工具還會檢查叢集升級期間可能發生的已知問題。

此外，將使用者叢集升級至 1.29 以上版本時，建議您使用 --dry-run 旗標執行 gkectl upgrade cluster 指令。--dry-run 旗標會執行預檢，但不會啟動升級程序。雖然舊版 Google Distributed Cloud 會執行前置檢查，但無法與升級作業分開執行。加入 --dry-run 標記後，您就能在升級前，找出並修正預檢發現的使用者叢集問題。

使用部署作業，盡量減少應用程式中斷情形

由於更新期間需要排空節點，叢集升級可能會導致應用程式中斷。清空節點表示必須關閉所有正在執行的 Pod，並在叢集中的其餘節點上重新啟動。

如果可以，應用程式應使用 Deployments。採用這種做法時，應用程式會設計成可處理中斷情況。對於有多個副本的部署作業，影響應降至最低。如果應用程式未使用 Deployment，您仍可升級叢集。

此外，Deployment 也有相關規則，可確保一定數量的副本持續執行。這些規則稱為「Pod 中斷預算」(PDB)。PodDisruptionBudgets如果 Pod 必須因某種原因 (例如叢集節點升級或維護) 重新排程，您可以使用 PDB 限制工作負載的中斷情形，因此升級前請務必檢查 PDB。

使用高可用性負載平衡器配對

如果您在叢集上使用 Seesaw 做為負載平衡器，升級叢集時，系統會自動升級負載平衡器。升級作業可能會導致服務中斷。為減少升級和最終負載平衡器故障的影響，您可以使用高可用性配對 (HA 配對)。在此設定中，系統會建立及設定兩個負載平衡器 VM，以便容許容錯移轉至其他對等互連。

為提高服務可用性 (即 Kubernetes API 伺服器)，建議您一律在管理員叢集前使用 HA 配對。如要進一步瞭解 Seesaw 及其高可用性設定，請參閱 1.16 版說明文件「使用 Seesaw 進行套裝組合負載平衡」。

如要避免在高可用性配對升級期間發生服務中斷情形，叢集會在建立新的負載平衡器 VM 前啟動容錯移轉。如果使用者叢集只使用單一負載平衡器執行個體，負載平衡器升級完成前，服務會中斷。

如果使用者叢集本身也設定為高可用性，建議您使用 HA 負載平衡器配對。本系列最佳做法指南假設高可用性使用者叢集使用高可用性負載平衡器配對。

如果您使用 MetalLB 做為套裝組合負載平衡器，則無需進行升級前設定。叢集升級程序期間，系統會升級負載平衡器。

決定如何升級每個使用者叢集

在 1.14 以上版本中，您可以選擇整體升級使用者叢集 (也就是升級叢集中的控制層和所有節點集區)，也可以升級使用者叢集的控制層，並讓節點集區維持目前版本。如要瞭解為何可能需要個別升級控制層，請參閱「使用者叢集升級」。

在多叢集環境中，請追蹤已升級的使用者叢集，並記錄其版本號碼。如果您決定分別升級控制層和節點集區，請記錄每個叢集中的控制層和各個節點集區版本。

檢查使用者和管理員叢集版本

檢查叢集節點的版本：

您可以使用 kubectl 取得叢集節點的版本，但 kubectl 會傳回 Kubernetes 版本。如要取得 Kubernetes 版本的對應 Google Distributed Cloud 版本，請參閱「版本管理」。

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

將 USER_CLUSTER_KUBECONFIG 替換為使用者叢集的 kubeconfig 檔案路徑。

檢查是否需要輪替 CA 憑證

升級期間會輪替葉子憑證，但不會輪替 CA 憑證。 您必須至少每五年手動輪替一次 CA 憑證。 詳情請參閱「輪替使用者叢集憑證授權單位」和「輪替管理員叢集 CA 憑證」。

叢集類型之間的差異

叢集可分為兩種類型：

• 使用者叢集
• 管理員叢集

視建立使用者叢集的方式而定，叢集可能同時包含工作站節點和控制層節點 (Controlplane V2)，或只包含工作站節點 (kubeception)。透過 kubeception，使用者叢集的控制層會在管理員叢集的一或多個節點上執行。在上述兩種情況下，您都可以從執行工作負載的節點集區，分別升級使用者叢集的控制層 (1.14 以上版本)。

使用者叢集升級與管理員叢集升級的不同影響

Google Distributed Cloud 升級程序會執行節點排空程序，從節點中移除所有 Pod。這個程序會為每個清空的背景工作節點建立新的 VM，並將其新增至叢集。接著，系統會從 VMware 的清單中移除排空的節點。在這個過程中，系統會停止在這些節點上執行的所有工作負載，並在叢集中的其他可用節點上重新啟動。

視所選工作負載架構而定，這個程序可能會影響應用程式的可用性。為避免叢集的資源能力負擔過重，Google Distributed Cloud 會一次升級一個節點。

使用者叢集服務中斷

下表說明就地升級使用者叢集的影響：

• *：PDB 可能會導致升級失敗或停止。
• 影響：升級完成前，服務中斷情形明顯。
• 不受影響：服務可能會短暫中斷，但幾乎不會察覺。

使用者叢集控制層節點 (無論是在管理員叢集 (kubeception) 或使用者叢集本身 (Controlplane V2) 上執行) 都不會執行任何使用者工作負載。升級期間，系統會排空這些控制層節點，然後相應更新。

在高可用性 (HA) 控制層環境中，升級使用者叢集的控制層不會中斷使用者工作負載。在高可用性環境中，升級管理員叢集不會中斷使用者工作負載。如果使用者叢集使用 Controlplane V2，升級控制層時不會中斷使用者工作負載。

在非高可用性控制層環境中升級時，控制層無法控制 Pod 擴縮、復原或部署作業。升級期間，控制層會短暫中斷，如果使用者工作負載處於擴縮、部署或復原狀態，可能會受到影響。也就是說，在非高可用性環境中升級時，推出作業會失敗。

為提升可用性，並減少升級期間對正式環境使用者叢集的干擾，建議您使用三個控制層節點 (高可用性模式)。

管理員叢集發生中斷

下表說明就地升級管理員叢集的影響：

• 影響：升級完成前，服務中斷情形明顯。
• 不受影響：服務可能會短暫中斷，但幾乎不會察覺。

後續步驟

• 升級叢集或節點集區