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