一般而言，最佳做法是盡可能減少叢集數量，但機構組織會基於各種原因，選擇部署多個叢集，以達成技術和業務目標。大多數機構至少會將非正式環境與正式環境服務分開，並放在不同的叢集中。在較複雜的情境中，機構可能會選擇多個叢集，藉此區隔不同層級、位置、團隊或基礎架構供應商的服務。
採用多個叢集的大多數原因，都屬於以下三類需求：
- 隔離：將服務的控制層和資料層分開，主要目的是提升可靠性或滿足安全性需求
- 位置：將服務放在特定位置，以滿足可用性、延遲和地域需求
- 擴展：特別是在 Kubernetes 叢集的脈絡中，將服務擴展到超出單一叢集所設的實際限制
我們會在後續章節中進一步說明。
在許多情況下，機構必須同時兼顧多項需求。考量貴機構時，請記住我們的基本建議是盡可能減少叢集數量。判斷貴機構最優先的多叢集需求 (不得妥協)，然後做出適當的取捨，建立多叢集架構。
如果貴機構考慮採用「每個服務模型一個叢集」或「每個團隊一個叢集」模式，您可能需要考慮這類系統對營運人員造成的管理負擔。機群和 Google Cloud 支援機群的元件與功能 會盡可能簡化管理多個叢集的作業，但叢集越多，管理作業的複雜度就越高。
隔離
在此情況下，「隔離」是指控制層和/或資料層的分離，這兩者都可以透過執行多個叢集來達成。不過，視實作方式而定，這種分隔可能也會擴及資料平面隔離。通常在考慮下列事項時，就會出現隔離需求：
環境
通常機構會在不同叢集上執行開發、暫存/測試和生產服務，這些服務通常會在不同網路和雲端專案上執行。這樣做是為了避免生產服務意外中斷，並防止在開發或測試期間存取私密資料。工作負載分層
如果機構有許多複雜的應用程式，通常會將服務分層，選擇在與重要性較低的服務不同的叢集上執行重要性較高的服務。在這種環境中，我們會特別考量存取權、安全性、升級和政策等因素，為這些更重要的服務及其叢集提供特殊待遇。舉例來說，您可以將無狀態和有狀態服務放在不同的叢集，藉此分層。降低故障造成的影響
如果機構想限制運算子錯誤、叢集故障或相關基礎架構故障造成的影響，可以將服務分散到多個叢集。升級
如果機構擔心就地升級 (也就是升級自動化失敗、應用程式不穩定或無法回溯) 可能會造成問題，可以選擇在新叢集中部署服務副本。以這種方式升級需要規劃或自動化，才能順利完成，請務必在升級過程中處理流量管理和狀態複製作業。安全/法規分隔
機構可以選擇隔離服務，原因有很多，包括將受法規要求的工作負載與較不敏感的工作負載分開，或是在與第一方 (信任) 服務 (叢集) 不同的基礎架構上執行第三方 (較不信任) 服務。用戶群分離
將用戶群分離到多個叢集通常是基於各種原因，包括安全隔離、效能隔離、成本會計，甚至是擁有權。
位置
延遲
部分服務有延遲規定，必須將工作負載放在特定位置 (或地理位置)，才能符合規定。如果上游服務或使用者對延遲時間很敏感，就可能需要這麼做；如果工作負載本身對下游服務延遲時間很敏感，也很容易發生這種情況。可用性
在單一雲端服務供應商 (或多個供應商) 的多個可用區中執行相同服務，可提高整體可用性。管轄區
資料落地和其他管轄區處理規定可能要求運算和儲存作業必須在特定區域內進行，因此基礎架構必須部署在多個資料中心或雲端服務供應商。資料重力
大量資料或特定資料庫執行個體可能難以整合至單一雲端供應商或區域，甚至無法整合或不建議整合。視處理和放送需求而定，應用程式可能需要部署在資料附近。舊版基礎架構/服務
資料難以遷移至雲端，某些舊版基礎架構也同樣難以遷移。雖然這些舊版服務無法移動，但機構可以部署額外的叢集來開發新服務，進而加快開發速度。開發人員選擇
機構通常會受益於能夠為開發人員提供所用雲端管理服務的選擇。一般來說，團隊可選擇最符合需求的工具，加快工作速度，但代價是必須管理各供應商分配的額外資源。本機/邊緣運算需求
最後，隨著機構想在更多傳統工作環境 (例如倉庫、工廠、零售商店等) 中採用應用程式現代化做法，這也代表需要在更多基礎架構上管理更多工作負載。
規模
由於 GKE 可將叢集擴充至超過 5000 個節點，因此這些限制很少會成為運作多個叢集的原因。在叢集達到擴充性限制前，機構通常會決定將服務分散到多個叢集。如果叢集達到擴充性上限，在多個叢集中執行應用程式可以解決部分問題，但管理多個叢集會增加複雜度。