本文說明如何在多叢集 Google Kubernetes Engine (GKE) 環境中設計、規劃及實作升級作業。雖然本文使用多叢集 Ingress 進行升級，但這些概念也適用於其他解決方案，例如手動設定外部負載平衡器。本文件附有教學課程，說明如何使用多叢集 Ingress 升級多叢集 GKE 環境。本文適用於負責維護 GKE 叢集車隊的管理員。 Google Cloud
多叢集架構的需求
本節將討論您可能需要多叢集 Kubernetes 架構的各種原因。
Kubernetes 做為基礎架構
本文件將 Kubernetes 叢集視為基礎架構的元件。基礎架構可拋棄。基礎架構元件不需特別處理，因為元件的用途就是提供服務。Kubernetes 的用途是為開發人員和營運人員提供自動化和自動化調度管理功能，以便向消費者提供容器型應用程式和服務。消費者可以是內部團隊、其他服務或外部客戶。
常見多叢集情境
除了 Kubernetes 即基礎架構的論點，還有許多理由可說明為何需要多叢集環境：
- 地理位置。許多服務需要位於多個區域。將服務放置在靠近消費者 (位於消費者所在區域) 的位置，可提供更優質的體驗，因為與從單一區域提供服務相比，這樣做可降低延遲時間。Kubernetes 叢集會在單一地區中執行。如要進行多區域部署，您需要多個區域中的多個 Kubernetes 叢集。多雲或混合雲環境也需要在每個環境中有多個叢集。Kubernetes 叢集通常也會與服務的 (具狀態) 資料來源共置。某些應用程式可能需要與後端 (例如關聯式資料庫管理系統 (RDBMS)) 位於相同位置 (區域和可用區)。
- 租戶和環境。Kubernetes 叢集專為多租戶設計，多個團隊可以共用單一叢集，各自使用自己的服務。Kubernetes 提供標準資源，例如命名空間、角色型存取權控管 (RBAC)、網路政策和驗證，可讓您在多租戶環境中正確設定存取權控管。在某些情況下，由於公司政策、隱私權、安全性或產業法規，某些服務可能無法與其他服務共用叢集。在這種情況下，需要多個叢集，才能將特定房客區隔到自己的叢集。環境 (開發、測試及實際工作環境) 通常也會建立為個別叢集。不同環境中安裝的應用程式類型和存取範圍差異極大，因此應視為個別叢集。
- 組成和功能。有時叢集是為了執行特定功能而建立，舉例來說，機器學習工作流程會使用 Kubeflow，或資料分析工作，這類工作可能需要具備 GPU 或其他硬體需求的節點，才能用於由閒置 VM 組成的執行個體叢集，以執行批次分析工作負載。這些硬體需求可能不適用於其他服務。這些工作流程可能對業務運作並不重要，而且可能需要暫時性叢集 (生命週期短的叢集)。可觀測性 (記錄、指標和追蹤記錄) 和 CI/CD 工具等共用服務，更適合在自己的平台管理員叢集中。對於非業務關鍵工作流程，通常會看到特定功能的叢集。
- 韌性。環境中通常會使用多個叢集來提高彈性。每個叢集都有影響範圍。在此情況下，影響範圍是指因叢集故障、設定錯誤，或因排定或未排定的維護作業而離線，導致服務受到負面影響的數量。如果您有大量小型叢集，就會有大量小型影響區域。如果服務存在於兩個叢集中，叢集會平均分攤負載。如果其中一個叢集離線，50% 的流量會受到影響。如果單一叢集提供相同「服務」，該叢集上的任何事件都會導致該「服務」完全中斷。因此，多個叢集通常也用於災難復原。
本文著重於多叢集部署項目的復原能力。
多叢集和分散式服務
分散式服務是指部署至多個 Kubernetes 叢集的 Kubernetes 服務。分散式服務是無狀態服務，在多個叢集中的運作方式完全相同。也就是說，分散式服務具有相同的 Kubernetes 服務名稱，且在多個叢集中的相同命名空間內實作。Kubernetes 服務會繫結至執行的 Kubernetes 叢集。如果 Kubernetes 叢集離線，Kubernetes 服務也會離線。分散式服務會從個別 Kubernetes 叢集抽象化。如果一或多個 Kubernetes 叢集停止運作，分散式服務可能仍處於上線狀態，且符合服務等級目標 (SLO)。
在下圖中，frontend 是在多個叢集上執行的分散式服務，具有相同的服務名稱和命名空間。
採用這種架構後，frontend 服務就不會與單一叢集綁定，在圖中會以跨越 Kubernetes 叢集基礎架構層的層表示。如果執行 frontend 服務的任何個別叢集發生故障，frontend 仍會保持連線。單一叢集上還會執行其他服務：accounts
服務和 ledger 服務。這些節點的正常運作時間和可用性，取決於所在 Kubernetes 叢集的正常運作時間。
多叢集部署作業的優點之一就是具備復原能力。分散式服務可在多叢集架構中建立彈性服務。無狀態服務是多叢集環境中分散式服務的主要候選項目。使用分散式服務時，請注意下列需求和考量事項：
多叢集網路。您可以透過多叢集 Ingress 等多叢集 Ingress 技術，或使用自己的外部負載平衡器或 Proxy 解決方案，將傳送至分散式服務的流量導向執行該服務的叢集。無論使用哪種選項，都必須能控制流量轉送至分散式服務特定執行個體的時間、地點和流量大小。下圖顯示負載平衡器將流量傳送至分散式服務
frontend，該服務在兩個 GKE 叢集中執行。
可觀測性。使用工具測量分散式服務的服務等級目標 (通常是可用性和延遲時間)。這項設定可提供全域檢視畫面，顯示每個服務在多個叢集中的成效。雖然分散式服務在大多數可觀測性解決方案中並非明確定義的資源，但您可以收集及合併個別 Kubernetes 服務指標。Cloud Monitoring 等解決方案或 Grafana 等開放原始碼工具，都能提供 Kubernetes 服務指標。服務網格解決方案 (例如 Istio 和 Cloud Service Mesh) 也提供服務指標，而且不需要任何檢測。
服務刊登位置。Kubernetes 服務可在單一 Kubernetes 叢集中提供節點層級的容錯能力。也就是說，Kubernetes Service 可以承受節點中斷。節點中斷期間，Kubernetes 控制層節點會自動將 Pod 重新排定至健康狀態良好的節點。分散式服務可提供叢集層級的容錯能力。也就是說，分散式服務可承受叢集故障。為分散式服務規劃容量時，您必須考量這項服務的放置位置。分散式服務不需要在每個叢集上執行。分散式服務在哪些叢集上執行，取決於下列需求：
- 需要服務的地點或區域？
- 分散式服務的必要服務水準目標為何？
- 分散式服務需要哪種容錯能力？叢集、可用區或區域？舉例來說，您是否需要在單一可用區中建立多個叢集，或是在單一區域或多個區域的可用區中建立多個叢集？
在最糟的情況下，分散式服務應能承受多大規模的停機？叢集層級提供下列選項：
- N+1 (其中 N 代表滿足服務容量需求所需的叢集數量)。分散式服務可承受單一叢集故障
- N+2. 分散式服務可承受兩個並行故障。舉例來說，兩個叢集中的 Kubernetes 服務同時發生計畫內和計畫外中斷。
推出及復原。Kubernetes 服務等分散式服務可逐步推出及復原。與 Kubernetes 服務不同，分散式服務可讓叢集成為額外的部署單元，以逐步變更。推出和復原作業也取決於服務需求。在某些情況下，您可能需要同時升級所有叢集上的服務，例如修正錯誤。在其他情況下，您可能需要一次推出 (或交錯) 一個叢集的變更。這項逐步推出作業會逐步將變更導入服務，降低分散式服務的風險。不過，視叢集數量而定，這項作業可能需要較長的時間。 沒有所謂的最佳升級策略。通常會根據分散式服務需求，使用多種推出和復原策略。重點在於分散式服務必須允許環境中的變更逐步進行，且受到控制。
業務持續性和災難復原 (BCDR)。這些字詞通常會一起使用。營運持續性是指在發生重大 (計畫內或計畫外) 事件時，持續提供重要服務；災難復原則是指在發生這類事件後，為使業務運作恢復正常狀態而採取或需要採取的步驟。BCDR 有許多策略，但不在本文的討論範圍內。BCDR 需要系統和服務具備一定程度的備援能力。分散式服務的主要前提是，服務會在多個位置 (叢集、區域和地區) 執行。
BCDR 策略通常取決於先前討論的推出和復原策略。舉例來說，如果以交錯或受控方式推出，就能及早發現錯誤或不良的設定推送，而不影響大量使用者。大規模的快速變更率 (例如在現代 CI/CD 做法中) 搭配使用時，並非所有使用者都會收到相同版本的分散式服務。分散式系統和服務的 BCDR 規劃與策略，與傳統單體式架構不同。在傳統系統中，變更會大規模進行，影響大量 (或所有) 使用者，因此必須備妥備援或備份系統，以防推出後產生不良影響。在分散式系統和服務中，幾乎所有變更都是逐步完成，因此只會影響少數使用者。
叢集生命週期管理。與受控推出和回溯功能類似，分散式服務可讓您控管叢集生命週期管理。分散式服務提供叢集層級的復原能力，因此叢集可以從輪替中移除以進行維護。叢集生命週期管理是分散式服務的原則，不適用於 Kubernetes 服務。
本文的其餘部分將著重於分散式服務的叢集生命週期。
GKE 叢集生命週期管理
叢集生命週期管理可定義為維持 Kubernetes 叢集機群健康狀態和最新狀態所需的策略和規劃，且不得違反服務 SLO。只要有適當的策略和規劃，叢集生命週期管理應該就會是例行、可預期且平淡無奇的作業。
本文著重於 GKE 生命週期管理。不過，您可以將這些概念套用至其他 Kubernetes 發布版本。
GKE 版本管理與升級
討論叢集生命週期管理策略和規劃之前，請務必先瞭解叢集升級的定義。
叢集包含兩個元件：控制層節點和工作站節點。如要升級 Kubernetes 叢集，所有節點都必須升級至相同版本。Kubernetes 遵循語意版本管理結構定義。Kubernetes 版本表示為 X.Y.Z:，其中 X 是主要版本，Y 是次要版本，Z 則是修補程式版本。次要版本約每三個月 (每季) 發布一次，Kubernetes 專案會維護最近三個次要版本的發布分支。也就是說，如果 Kubernetes 次要版本已發布九個月，系統就不會再維護，因此升級至最新版本時，可能需要變更 API。必須定期規劃 Kubernetes 升級作業。建議每季或每兩季進行一次 GKE 升級。
GKE 叢集支援執行任何支援的次要版本 Kubernetes。任何時間至少有兩個次要版本可供使用。
GKE 是受管理服務，可為控制層節點和工作站節點提供自動升級。
GKE 自動升級
GKE 自動升級是常見且經常使用的叢集生命週期策略。GKE 自動升級功能提供全代管方式，可讓 GKE 叢集保持在支援版本。GKE 自動升級功能會分別升級控制層節點和工作站節點：
主機自動升級。根據預設，GKE 控制層節點會自動升級。單一區域和多區域叢集只有一個控制層 (控制層節點)。在控制層節點升級期間，工作負載會繼續執行。不過，升級完成前，您無法部署新工作負載、修改現有工作負載，或對叢集設定進行其他變更。
區域叢集具有多個控制層副本，但一次只會升級一個副本。升級期間，叢集仍維持高可用性，只有在升級時，各個控制層副本才會無法使用。
工作站節點自動升級。節點集區會逐一升級。 在節點集區中，節點會依未定義的順序一次升級一個。 您可以一次變更升級的節點數量，但視節點數量和工作負載設定而定，這個程序可能需要數小時。
GKE 自動升級生命週期策略
建議盡可能使用 GKE 自動升級功能。 GKE 自動升級功能會優先考量便利性，而非控制權。不過，GKE 自動升級功能提供多種方式，讓您在特定參數範圍內，影響叢集的升級時間和方式。您可以影響維護期間和維護排除時段。發布版本會影響版本選取和節點升級策略，進而影響節點升級的順序和時間點。儘管有這些控制項和區域叢集 (具有多個 Kubernetes 控制層)，GKE 自動升級功能仍無法保證服務正常運作時間。如果您需要下列一或多項功能，可以選擇不使用 GKE 自動升級功能：
- 控管 GKE 叢集的確切版本。
- 控管 GKE 升級的確切時間。
- 控管 GKE 裝置的升級策略 (下一節會討論)。
GKE 多叢集生命週期管理
本節說明各種 GKE 多叢集生命週期管理策略，以及如何規劃這些策略。
規劃和設計注意事項
選取叢集生命週期管理策略時，GKE 多叢集架構扮演著重要角色。在討論這些策略之前，請務必先討論某些設計決策，這些決策可能會影響叢集生命週期管理策略，或受到該策略影響。
叢集類型
如果您使用 GKE 自動升級功能做為叢集生命週期管理策略，叢集類型可能很重要。舉例來說，區域叢集有多個控制層節點，控制層節點會一次自動升級一個，而區域叢集只有一個控制層節點。如果您未使用 GKE 自動升級功能，且將所有 Kubernetes 叢集視為可拋棄式基礎架構，那麼在決定叢集生命週期管理策略時，選擇哪種叢集可能就無關緊要。您可以將下一節討論的策略套用至任何類型的叢集。
叢集放置位置和足跡
決定叢集放置位置和足跡時，請考慮下列因素：
- 叢集必須位於的可用區和區域。
- 所需叢集的數量和大小。
第一個因素通常很容易解決，因為區域和地區是由您的業務和為使用者提供服務的地區決定。
解決叢集數量和大小問題通常屬於下列類別，各有優缺點：
- 少量大型叢集。您可以選擇使用地區叢集提供的備援和復原能力，並在每個區域放置一 (或兩) 個大型地區叢集。這種做法的優點是管理多個叢集的作業負擔較低。缺點是影響範圍廣泛，因此可能會一次影響大量服務。
- 大量小型叢集。您可以建立大量小型叢集，將服務分散到多個叢集，藉此縮小叢集影響範圍。這種方法也很適合用於生命週期較短的暫時叢集 (例如執行批次工作負載的叢集)。這種做法的缺點是作業負擔較高，因為需要升級的叢集較多。控制層節點數量越多，相關費用也可能越高。您可以透過自動化、可預測的排程和策略，以及受影響團隊和服務之間的謹慎協調，抵銷成本和高營運費用。
本文不會特別推薦某種做法，而是提供選項。 在某些情況下，您可以為不同類別的服務選擇兩種設計模式。
無論選擇哪種設計，都可以使用下列策略。
處理能力規劃
規劃容量時，請務必考量所選叢集的生命週期策略。容量規劃必須考量下列正常服務負載和維護事件：
- 叢集升級等預定事件
- 叢集服務中斷等非預期事件，例如推送錯誤設定和推出錯誤版本
規劃容量時，請務必考量全面或局部中斷。如果您只針對計畫性維護事件設計，則所有分散式服務都必須比需求多一個叢集，這樣您才能一次從輪替中取出一個叢集進行升級，而不會降低服務品質。這種方法也稱為「N+1 容量規劃」。如果您要為預期和非預期的維護事件設計服務，所有分散式服務都必須有兩個 (或更多) 額外叢集，才能提供預期容量，其中一個用於預期事件，另一個則用於非預期事件 (以防在預期維護期間發生)。這種做法也稱為「N+2 容量規劃」。
在多叢集架構中，經常會使用「排空」和「溢出」這兩個詞。這些術語是指在升級和維護期間，從叢集移除 (或排空) 流量，並將流量重新導向 (或溢出) 至其他叢集的程序。這項程序是透過多叢集 Ingress 等網路解決方案或其他負載平衡方法完成。審慎使用排空和溢出功能，是某些叢集生命週期管理策略的核心。規劃容量時，請務必考量排空和溢出。舉例來說，當單一叢集排空時，您需要考量其他叢集是否有足夠容量來處理額外溢出的流量。其他考量包括可用區或區域是否有足夠容量，或是是否需要將流量傳送至其他區域 (如果每個區域使用單一區域叢集)。下圖顯示流量從一個叢集移除 (有時稱為叢集排空)，並傳送到執行相同分散式服務的另一個叢集。
叢集和分散式服務
以服務為基礎的叢集設計規定，叢集架構 (數量、大小和位置) 是由叢集上執行的服務決定。因此，叢集的位置取決於需要分散式服務的位置。決定分散式服務的放置位置時，請考慮下列事項：
- 地點規定。服務需要從哪些地區提供？
- 重要性。服務可用性對業務有多重要？
- 服務等級目標。服務的服務等級目標為何 (通常以重要性為依據)？
- 應變能力。服務需要多大的復原能力？是否需要抵禦叢集、可用區，甚至是區域故障？
規劃叢集升級時，您必須考量單一叢集在排空時影響的服務數量，並將這些服務溢出至其他適當的叢集。叢集可以是單一租戶或多個租戶。單一租戶叢集只會提供單一服務，或一組服務代表的產品。單一租戶叢集不會與其他服務或產品共用叢集。多租戶叢集可執行許多服務和產品，這些服務和產品通常會劃分為命名空間。
對團隊的影響
叢集事件不僅會影響服務，也可能影響團隊。舉例來說，DevOps 團隊可能需要在叢集升級期間，重新導向或停止 CI/CD 管道。同樣地，支援團隊也能收到預計中斷的警報。您必須使用自動化方式與工具，才能減輕對多個團隊的影響。通知所有團隊後，叢集或叢集機群升級應視為例行作業，不會發生任何問題。
時間、排程和協調
Kubernetes 每季會發行新的次要版本，並維護最近三個版本。您必須仔細規劃叢集升級的時間和排程。 服務擁有者、服務營運商和平台管理員必須就升級時間達成共識。規劃升級時，請考量下列問題：
- 你多久升級一次？您是每季升級，還是按照其他時間表升級？
- 何時升級？您是否會在季初升級，此時業務放緩，或是在產業導致的其他業務停機期間升級？
- 什麼時候不該升級？您是否已明確規劃何時不升級，例如避開黑色星期五、網購星期一等尖峰規模事件，或是在高知名度會議和其他產業特定活動期間。
請務必制定策略，並清楚向服務擁有者以及營運和支援團隊說明。升級叢集時，不應發生任何意外，且所有人都應知道升級時間和方式。這需要與所有相關團隊清楚協調。單一服務有多個團隊與其互動。通常這些團隊可歸類為以下幾種：
- 服務開發人員：負責建立服務，並將業務邏輯編碼至服務中。
- 服務營運商：負責安全可靠地執行服務。營運人員可由多個團隊組成，例如政策或安全管理員、網路管理員和支援團隊。
叢集升級期間，所有人都必須保持通訊，以便在這段時間採取適當行動。其中一種做法是規劃升級，方式與規劃中斷事件相同。您有事件指揮官、聊天室和回顧 (即使沒有使用者受到影響)。詳情請參閱「事件回應」。
GKE 叢集生命週期策略
本節將討論 GKE 多叢集架構中常用的主要叢集生命週期管理策略。請注意，單一策略無法適用於所有情況，您可能會為不同類別的服務和商家需求選擇多種策略。
滾動式升級
下圖顯示輪流升級策略。
使用負載平衡器時，一個 GKE 叢集會排空所有流量並升級。排空的流量負載會溢出至其他 GKE 叢集。
在本文討論的策略中，滾動升級是最簡單且最具成本效益的策略。首先，請找出執行 old_ver (或目前正式版) 的叢集數量。n然後一次排空 m 個叢集，其中 m 小於 n。然後刪除並重新建立新叢集 (使用新版本)，或升級排空的叢集。
決定要刪除還是升級新叢集，取決於叢集大小，以及您是否認為叢集是不可變動的基礎架構。不可變動的基礎架構規定，您應建立新叢集，避免任何無法預料的設定漂移，而不是不斷升級叢集，因為這可能會隨著時間產生非預期的結果。
如果您使用 GKE，可以透過單一指令或 API 呼叫建立 GKE 叢集。新的叢集策略要求您將整個叢集設定 (叢集資訊清單) 儲存在叢集外部，通常是儲存在 Git 中。然後在新叢集上使用相同的設定範本。如果是新叢集，請確保 CI/CD 管道指向正確的叢集。正確設定叢集後，您就可以將流量慢慢推回叢集，同時監控服務的 SLO。
系統會針對所有叢集重複執行這項程序。視容量規劃而定，您可以一次升級多個叢集，而不違反服務服務水準目標。
如果您重視簡便性和成本，而非復原能力，請使用「滾動升級」策略。採用這項策略時，您絕不會超過所有分散式服務的 GKE 叢集必要容量。
下圖比較多叢集架構中，GKE 叢集升級期間的時間軸和服務容量需求。
上圖顯示，在整個 GKE 升級過程中，支援服務的容量絕不會低於必要容量。要升級的 GKE 叢集從輪替中移除後，其他叢集會擴充資源來支援負載。
藍綠升級
下圖顯示藍綠升級策略。
在上圖中，系統新增了執行新版本的 GKE 叢集。接著，系統會使用負載平衡器將流量傳送至新叢集，同時緩慢排空其中一個舊叢集，直到沒有流量傳送至該叢集為止。完全排空後，即可移除舊叢集。其餘叢集也適用相同的程序。
藍綠升級策略可提供額外的復原能力。這項策略與滾動升級類似，但成本較高。唯一不同的是，您會先建立新 m 叢集 (版本為 m，且 m 小於或等於 n)，而不是先排空現有叢集。將新叢集新增至 CI/CD 管道，然後在監控服務 SLO 時，緩慢地將流量溢出。當新叢集完全接管流量後，請排空並刪除舊版叢集。
升級叢集的藍綠策略與一般用於服務的藍綠策略類似。一次建立多個新叢集會增加整體費用，但可加快機群升級時間。只有在升級期間使用額外叢集時，才會產生額外費用。先建立新叢集的好處是，如果發生失敗情況，您可以回溯。您也可以先測試新叢集，再將正式版流量傳送至該叢集。由於這些叢集會與舊版叢集共存一小段時間，因此額外費用極少。
如果您重視簡單性和復原能力，而非成本，請使用藍綠升級策略。系統會先新增額外叢集，在升級期間超出 GKE 艦隊的必要容量。
在上圖中，新增叢集會暫時增加可用容量，超過所需容量，而機群中的另一個叢集則會清空並從機群中移除。不過，移除其中一個舊叢集 (完全耗盡) 後，容量就會恢復到所需大小。我們特別標示這項容量變更，是因為視機群中的叢集數量和大小而定，這個模型可能會導致費用增加。
初期測試叢集升級
在本文討論的策略中，初期測試叢集升級是最具彈性且最複雜的策略。這項策略會完全從服務生命週期管理中，抽象化叢集生命週期管理，因此可為服務提供最低風險和最高復原力。在先前的輪轉式和藍綠升級策略中，您會將整個 GKE 叢集維持在單一版本。採用這項策略時，您會維護兩到三個 GKE 叢集機群，這些叢集執行不同版本。您不必升級叢集，而是隨著時間將服務從一個叢集機群遷移至另一個機群。最舊的 GKE 機群排空後 (也就是所有服務都已遷移至下一個版本的 GKE 機群)，您就可以刪除該機群。
這項策略要求您至少要維護兩個 GKE 艦隊，一個用於目前的正式版，另一個用於下一個正式版候選版本。您也可以維護兩個以上的 GKE 叢集。額外車隊可提供更多彈性，但成本和營運費用也會增加。這些額外機群與不同環境 (例如開發、預備和正式環境) 中的叢集不同。非實際工作環境非常適合使用非實際工作環境流量測試 Kubernetes 功能和服務。
使用 Canary 叢集升級策略時，您必須在正式環境中維護多個 GKE 機群版本。這與服務常用的初期測試版策略類似。透過 Canary 服務部署作業，服務擁有者一律可找出特定服務版本的問題。使用 Canary 叢集時，服務擁有者也必須考量服務執行的 GKE 艦隊版本。單一分散式服務版本可能會在多個 GKE 叢集版本上執行。您可以逐步遷移服務，以便在將服務的所有流量傳送至新版叢集之前，先查看服務對新機群的影響。
下圖顯示，管理不同的 GKE 叢集車隊時，可以完全將叢集生命週期從服務生命週期中抽象化。
上圖顯示分散式服務 frontend 正在從一組 GKE 叢集緩慢遷移至下一組叢集 (執行新版本)，直到舊叢集隨著時間完全耗盡為止。機群排空後，即可移除並建立新機群。所有服務都會遷移至下一個車隊，並在舊車隊耗盡資源時移除。
如果最重視復原能力，請使用 Canary 叢集升級策略。
選擇升級策略
下圖有助於您根據服務和業務需求，決定最適合的策略。
上圖為決策樹，可協助您選擇適合的升級策略：
- 如果您不需要完全掌控升級的確切版本和時間，可以選擇 GKE 提供的自動升級功能。
- 如果您的首要考量是降低成本，可以選擇滾動升級策略。
- 如果您的優先考量是平衡成本和復原能力，可以選擇藍綠策略。
- 如果韌性比成本重要，您可以選擇初期測試版本叢集升級策略。
使用多叢集 Ingress 管理 GKE 叢集生命週期
幾乎所有策略都必須能夠在升級期間排空流量，並將流量重新導向其他叢集。多叢集 Ingress 解決方案可提供這項多叢集 Ingress 功能。多叢集 Ingress 是 Google Cloud代管的多叢集 Ingress 控制器，適用於 GKE 叢集，支援在不同叢集和區域中部署共用的負載平衡資源。多叢集 Ingress 解決方案可將用戶端流量導向多個區域中多個叢集執行的分散式服務。與 GKE 的 Ingress 類似，它會使用 Cloud Load Balancing 將流量傳送至後端服務。後端服務是分散式服務。後端服務會將流量傳送至多個後端，這些後端是在多個 GKE 叢集上執行的 Kubernetes 服務。如要跨叢集傳送服務對服務流量，可以使用服務網格技術，例如 Cloud Service Mesh 或 Istio，這些技術可在分散式服務中提供類似功能。
在 GKE 多叢集環境中，您可以使用多叢集 Ingress，根據先前討論的叢集生命週期管理策略，操控多個叢集的流量。您可以按照教學課程，使用多叢集 Ingress 透過藍綠策略升級 GKE。
後續步驟
- 進一步瞭解多叢集 Ingress。
- 瞭解如何在叢集之間部署多叢集 Ingress。