本文說明如何在多叢集 Google Kubernetes Engine (GKE) 環境中設計、規劃及實作升級作業。雖然本文件使用多叢集 Ingress 進行升級，但這些概念可套用至其他解決方案。本文適用於負責維護 GKE 叢集車隊的 Google Cloud 管理員。
GKE 叢集生命週期管理
叢集生命週期管理可定義為維護 Kubernetes 叢集機群健康狀態和最新狀態所需的策略和規劃，且不得違反服務 SLO。只要有適當的策略和規劃，叢集生命週期管理應該是例行、可預期且平穩的。
如要進一步瞭解如何管理叢集的 GKE 版本，請參閱「關於 GKE 叢集升級」。如要進一步瞭解如何在叢集生命週期內管理所有類型的變更，請參閱「管理叢集生命週期變更，盡可能減少服務中斷情形」。
GKE 多叢集生命週期管理
本節說明各種 GKE 多叢集生命週期管理策略，以及如何規劃這些策略。
規劃和設計注意事項
選取叢集生命週期管理策略時，GKE 多叢集架構扮演重要角色。在討論這些策略之前，請務必先討論某些設計決策，這些決策可能會影響叢集生命週期管理策略，或受到該策略影響。
叢集類型
如果您使用 GKE 自動升級功能做為叢集生命週期管理策略，叢集類型可能很重要。舉例來說，區域叢集有多個控制層節點，控制層節點會一次自動升級一個，而可用區叢集只有一個控制層節點。如果您未使用 GKE 自動升級功能，且將所有 Kubernetes 叢集視為可拋棄式基礎架構，那麼在決定叢集生命週期管理策略時，選擇哪種叢集可能就不是那麼重要。您可以將下一節中討論的策略套用至任何類型的叢集。
叢集位置和足跡
決定叢集位置和規模時，請考量下列因素：
- 叢集必須位於的可用區和區域。
- 所需叢集的數量和大小。
第一個因素通常很容易解決，因為區域和地區是由您的業務和為使用者提供服務的地區決定。
解決叢集數量和大小問題通常屬於下列類別，各有優缺點：
- 少量的大型叢集。您可以選擇使用區域叢集提供的備援和復原能力，並在每個區域放置一 (或兩) 個大型區域叢集。這種做法的好處是管理多個叢集的作業負擔較低。缺點是影響範圍廣泛，因此可能一次影響大量服務。
- 大量小型叢集。您可以建立大量小型叢集，將服務分散到多個叢集，減少叢集影響範圍。這種方法也很適合用於生命週期較短的暫時性叢集 (例如執行批次工作負載的叢集)。這種做法的缺點是營運負擔較高，因為需要升級的叢集較多。控制層節點數量增加也可能導致額外費用。您可以透過自動化、可預測的排程和策略，以及受影響團隊和服務之間的謹慎協調，抵銷成本和高營運費用。
本文不會推薦其中一種方法，而是提供選項。 在某些情況下，您可以針對不同類別的服務，同時選擇這兩種設計模式。
無論選擇哪種設計，都可以使用下列策略。
處理能力規劃
規劃容量時，請務必考量所選叢集生命週期策略。容量規劃必須考量下列正常服務負載和維護事件：
- 叢集升級等預定事件
- 非預期事件，例如叢集服務中斷、設定推送錯誤和推出錯誤
規劃容量時，您必須考量任何全部或部分中斷。如果設計時只考量預定維護事件，則所有分散式服務都必須比需求多一個叢集，這樣您才能一次從輪替中移除一個叢集進行升級，而不會降低服務品質。這種方法也稱為「N+1 處理能力規劃」。如果您針對預定和非預定的維護事件進行設計，則所有分散式服務都必須有兩個 (或更多) 額外的叢集，才能提供預期的容量，一個用於預定事件，另一個用於非預定事件，以防在預定維護期間發生。這種做法也稱為「N+2 容量規劃」。
在多叢集架構中，經常會使用「排空」和「溢出」這兩個詞彙。這些字詞是指在升級和維護事件期間，從叢集移除 (或排空) 流量，並將流量重新導向 (或溢出) 至其他叢集的程序。這項程序是透過多叢集 Ingress 等網路解決方案或其他負載平衡方法完成。謹慎使用排空和溢出功能，是某些叢集生命週期管理策略的核心。規劃容量時，請務必考量排空和溢出。舉例來說，如果單一叢集耗盡資源，您必須考量其他叢集是否有足夠容量，可處理額外溢出的流量。其他考量包括可用區或區域是否有足夠容量，或是是否需要將流量傳送至其他區域 (如果每個區域使用單一區域叢集)。下圖顯示流量從一個叢集移除 (有時稱為「耗盡叢集」)，並傳送至執行相同分散式服務的另一個叢集。
叢集和分散式服務
服務導向叢集設計規定，叢集架構 (數量、大小和位置) 取決於需要在叢集上執行的服務。因此，叢集的位置取決於需要分散式服務的位置。決定分散式服務的放置位置時，請考量下列事項：
- 地點規定。服務需要從哪些區域提供？
- 重要性。服務可用性對業務有多重要？
- SLO。服務的服務水準目標為何 (通常以重要性為依據)？
- 韌性。服務需要多大的復原能力？是否需要承受叢集、可用區，甚至是區域故障？
規劃叢集升級時，您必須考量單一叢集在排空時影響的服務數量，並將這些服務溢出至其他適當的叢集。叢集可以是單一或多個租戶。單一租戶叢集只會提供單一服務，或一組服務代表的產品。單一租戶叢集不會與其他服務或產品共用叢集。多租戶叢集可執行許多通常會劃分為命名空間的服務和產品。
對團隊的影響
叢集事件不僅會影響服務，也可能影響團隊。舉例來說，DevOps 團隊可能需要在叢集升級期間，重新導向或停止 CI/CD 管道。同樣地，支援團隊也可以收到預定停機時間的快訊。您必須採用自動化和工具，盡量減少對多個團隊的影響。通知所有團隊後，叢集或叢集群組升級應視為例行作業，不會發生任何問題。
時間、排程和協調
Kubernetes 每季會發布新的次要版本，並維護最近三個版本。您必須審慎規劃叢集升級的時間和排程。 服務擁有者、服務營運者和平台管理員必須就升級時間達成協議。規劃升級時，請考量下列問題：
- 你多久升級一次？您是每季升級，還是按照其他時間表升級？
- 何時升級？您是否會在業務放緩的季度初，或在產業淡季期間升級？
- 什麼時候不該升級？您是否已明確規劃何時不升級，例如避開黑色星期五、網購星期一等大規模活動，或高知名度會議和其他產業特定活動。
請務必制定策略，並與服務擁有者、營運和支援團隊清楚溝通。升級作業應順利完成，所有人都應瞭解叢集升級的時間和方式。這需要與所有相關團隊明確協調。單一服務有多個團隊與其互動。一般來說，這些團隊可分為以下幾類：
- 服務開發人員：負責建立服務，並將商業邏輯編碼至服務中。
- 服務營運商，負責安全可靠地執行服務。營運人員可能由多個團隊組成，例如政策或安全管理員、網路管理員和支援團隊。
在叢集升級期間，所有人都必須保持聯絡，以便採取適當行動。其中一種做法是比照規劃服務中斷事件的方式，規劃升級作業。您有事件指揮官、聊天室和事後檢討 (即使沒有使用者受到影響)。詳情請參閱「事件應變」。
GKE 叢集生命週期策略
本節將討論 GKE 多叢集架構中常用的主要叢集生命週期管理策略。請注意，一種策略無法適用於所有情況，您可能會為不同類別的服務和業務需求選擇多種策略。
滾動式升級
下圖顯示滾動升級策略。
使用負載平衡器，將一個 GKE 叢集的所有流量排空並升級。排出的流量負載會溢出至其他 GKE 叢集。
在本文討論的策略中，滾動升級是最簡單且最具成本效益的策略。一開始，您有 n 個叢集執行 old_ver (或目前正式發布) 版本。然後一次排空 m 個叢集，其中 m 小於 n。然後刪除並以新版本重新建立叢集，或升級排空的叢集。
決定要刪除還是升級新叢集，取決於叢集大小，以及您是否認為叢集是不可變更的基礎架構。不可變動的基礎架構規定，您應建立新叢集，而非持續升級叢集 (這可能會隨著時間產生非預期的結果)，並避免任何無法預測的設定漂移。
如果您使用 GKE，可以透過單一指令或 API 呼叫建立 GKE 叢集。新叢集策略要求您將整個叢集設定 (叢集資訊清單) 儲存在叢集外部，通常是在 Git 中。然後在新叢集上使用相同的設定範本。如果是新叢集，請確認 CI/CD 管道指向正確的叢集。正確設定叢集後，您就可以將流量慢慢推回叢集，同時監控服務的 SLO。
所有叢集都會重複這個程序。您可以根據容量規劃，一次升級多個叢集，而不會違反服務級別目標。
如果您重視簡便性和成本，更勝於復原能力，請使用滾動升級策略。採用這項策略時，您絕不會超出所有分散式服務的 GKE 叢集必要容量。
下圖比較多叢集架構中，GKE 叢集升級期間的時間軸和服務容量需求。
上圖顯示在整個 GKE 升級過程中，支援服務的容量絕不會低於必要容量。當要升級的 GKE 叢集退出輪替時，其他叢集會擴充資源來支援負載。
藍綠升級
下圖顯示藍綠升級策略。
在上圖中，系統新增了執行新版本的 GKE 叢集。接著，負載平衡器會將流量傳送至新叢集，同時慢慢耗盡其中一個舊叢集，直到沒有流量傳送至該叢集為止。接著即可移除完全排空的舊叢集。其餘叢集也可按照相同程序處理。
藍綠升級策略可提供額外的彈性。這項策略與滾動式升級類似，但成本較高。唯一不同的是，您會先建立新版 m 叢集 (其中 m 小於或等於 n)，而不是先排空現有叢集。將新叢集新增至 CI/CD 管道，然後在監控服務 SLO 時，緩慢地將流量溢出。當新叢集完全接管流量時，您會排空並刪除舊版叢集。
叢集升級的藍綠策略與一般用於服務的藍綠策略類似。一次建立多個新叢集會增加整體費用，但可加快機群升級時間。只有在升級期間使用額外叢集時，才會產生額外費用。先建立新叢集的好處是，如果發生失敗情況，您可以回溯。您也可以先測試新叢集，再將正式環境流量傳送至該叢集。由於這些叢集與舊版叢集並存的時間很短，因此額外費用極低。
如果您重視簡易性和彈性，而非成本，請使用藍綠升級策略。系統會先新增額外叢集，並在升級期間超過 GKE 機群所需的容量。
在上圖中，新增叢集會暫時增加可用容量，超過所需容量，而機群中的另一個叢集則會排空並從機群中移除。不過，移除其中一個舊叢集 (完全耗盡) 後，容量就會恢復到所需大小。系統會醒目顯示這項容量變更，因為視機群中的叢集數量和大小而定，這個模型可能會增加費用。
初期測試版本叢集升級
在本文討論的策略中，初期測試叢集升級是最具彈性且最複雜的策略。這項策略會完全從服務生命週期管理中抽象化叢集生命週期管理，因此可為服務提供最低風險和最高復原能力。在先前的輪流和藍綠升級策略中，您會將整個 GKE 機群維持在單一版本。在這個策略中，您會維護兩到三個 GKE 叢集機群，這些叢集執行不同版本。您不必升級叢集，而是隨著時間將服務從一個叢集機群遷移至另一個機群。當最舊的 GKE 機群耗盡 (也就是所有服務都已遷移至下一個版本的 GKE 機群) 時，您就可以刪除該機群。
這項策略規定您至少要維護兩個 GKE 叢集，一個用於目前的正式版，另一個用於下一個正式版候選版本。您也可以維護兩個以上的 GKE 艦隊。額外車隊可提供更多彈性，但成本和營運負擔也會增加。這些額外機群與不同環境 (例如開發、測試和正式環境) 中的叢集不同。非正式環境非常適合使用非正式流量測試 Kubernetes 功能和服務。
使用 Canary 叢集升級策略時，您必須在正式環境中維護多個 GKE 機群版本。這與服務常用的初期測試版策略類似。透過 Canary 服務部署作業，服務擁有者一律可以找出特定服務版本的問題。使用初期測試叢集時，服務擁有者也必須考量服務執行的 GKE 機群版本。單一分散式 Service 版本可能在多個 GKE 機群版本上執行。您可以逐步遷移服務，先將服務流量傳送至新版叢集，再將所有流量傳送至新版叢集，藉此觀察服務對新機群的影響。
下圖顯示，管理不同的 GKE 叢集機群，可完全將叢集生命週期與服務生命週期抽象化。
上圖顯示分散式服務 frontend 正在從一個 GKE 叢集機群緩慢遷移至下一個執行新版本的機群，直到舊機群的資源用盡為止。排空後，即可移除機群並建立新機群。所有服務都會遷移至下一個車隊，並在舊車隊耗盡資源後移除。
如果最重視復原能力，請使用 Canary 叢集升級策略。
選擇升級策略
您可以參考下圖，根據服務和業務需求，判斷哪種策略最適合您。
上圖為決策樹，可協助您選擇適合的升級策略：
- 如果您不需要完全掌控升級的確切版本和時間，可以選擇 GKE 提供的自動升級功能。
- 如果降低成本是首要目標，您可以選擇滾動升級策略。
- 如果首要考量是平衡成本和韌性，可以選擇藍綠策略。
- 如果優先考量的是復原能力而非成本，可以選擇初期測試叢集升級策略。
管理 GKE 叢集生命週期中的多叢集流量
如要在多叢集升級期間維持服務可用性，您必須在叢集之間排空及重新轉送流量。您可以使用多叢集閘道 (建議) 或多叢集 Ingress 管理這類流量。多叢集閘道是多叢集 Ingress 的後續版本，提供更具表現力且以角色為導向的服務網路方法。
使用多叢集閘道管理叢集生命週期
多叢集閘道 (MCG) 會使用 Gateway API，管理部署在機群內多個 GKE 叢集的服務流量。
GKE Gateway 控制器是 Google 託管的服務，可監控指定設定叢集中的 Gateway 和 HTTPRoute 資源。控制器會自動佈建及維護負載平衡基礎架構，為機群中各叢集的應用程式提供單一整合進入點。這種架構可讓您將負載平衡器的生命週期，與工作負載所在的個別 GKE 叢集分離。
在 GKE 叢集生命週期管理方面，多叢集閘道可啟用進階流量控管策略：
- 藍綠升級：部署新的「綠色」叢集，並修改 HTTPRoute 資源中的權重，逐步轉移「藍色」叢集的流量。
- 以容量為準的負載平衡：當某個叢集中的服務達到定義的容量上限時，系統會自動重新導向流量，有助於在輪流升級期間避免服務過載。
- 健康狀態型容錯移轉：監控所有叢集的後端健康狀態，並自動將流量從正在排空或發生問題的叢集重新導向。
詳情請參閱教學課程，瞭解如何部署多叢集閘道，以便依權重分配流量。
使用多叢集 Ingress 管理叢集生命週期
另一個多叢集流量管理解決方案是多叢集 Ingress。多叢集 Ingress 是 Google Cloud代管的多叢集 Ingress 控制器，適用於 GKE 叢集，支援在不同叢集和區域部署共用的負載平衡資源。多叢集 Ingress 解決方案可將用戶端流量導向分散式服務，該服務在多個區域的多個叢集中執行。與 GKE 的 Ingress 類似，它會使用 Cloud Load Balancing 將流量傳送至後端服務。後端服務是分散式服務。後端服務會將流量傳送至多個後端，也就是在多個 GKE 叢集上執行的 Kubernetes 服務。如要跨叢集傳送服務對服務流量，可以使用服務網格技術，例如 Cloud Service Mesh 或 Istio，這些技術可在分散式服務中提供類似功能。
詳情請參閱教學課程，瞭解如何使用多叢集 Ingress 升級多叢集 GKE 環境。
後續步驟
- 進一步瞭解多叢集閘道。
- 進一步瞭解多叢集 Ingress。