如機群管理總覽所述，機群是一種分組機制，可大規模管理、設定及保護 Kubernetes 叢集。機群是強大的工具，可讓您不必在多叢集環境中重複執行作業，並針對大型叢集群組提供一致性及全面監控功能。許多 GKE Enterprise 功能只能透過機群使用。
建立車隊時使用的分組策略，取決於貴機構的技術和業務需求。舉例來說，某個機構可能會根據叢集中執行的應用程式類型將叢集分組，而另一個機構則可能會依據區域、環境或其他相關因素分組。在其他條件相同的情況下，機構內車隊數量越少越方便。
這份指南適用於想在機構中開始使用車隊的雲端架構師。這份指南提供實用指引，說明如何將叢集整理成機群，包括：
- 想建立全新的叢集時。
- 想使用現有叢集建立機群時。
這裡說明的模式適用於許多機構，但並非規劃車隊的唯一方式。機群具有彈性，您可能會決定為叢集使用不同的分組模式。
閱讀本頁面之前，請先熟悉下列概念：
車隊和資源限制
建立車隊時，請遵守下列一般限制：
- 特定 Google Cloud 專案只能有一個相關聯的機群 (或沒有機群)，但該機群可以包含多個專案的叢集。與機群相關聯的專案稱為機群的機群主專案。
- 叢集一次只能是單一車隊的成員。
- 特定專案中的所有叢集必須位於同一個機群，或是完全不屬於任何機群。如果專案已包含機群成員，您就無法將該專案的叢集註冊至其他機群。
- 機群中的叢集數量預設上限為 250 個，但您可以視需要申請提高上限。
將多個叢集放在同一個專案中，有很多便利之處。不過，規劃要在專案中組合哪些叢集時，請考量下列限制：
- 單一專案最多只能有 32,000 個 VM。如果預計需要的 VM 數量超過此上限，請考慮使用更多專案。
- 一個虛擬私有雲 (VPC) 網路最多只能有 75 個私有叢集。
- 如果您打算使用多叢集 Ingress 或多叢集 Gateway，請考量專案中
MultiClusterIngress和MultiClusterService資源的限制。
一般原則
決定是否要將叢集分組到車隊時，請先問自己以下一般問題。我們會在後續章節中詳細說明這些概念的應用方式。
- 資源是否彼此相關？
- 如果資源需要大量跨服務通訊，最適合在機群中一起管理。
- 相同部署環境 (例如實際工作環境) 中的資源應在機群中一起管理。
- 誰負責管理資源？
- 統一控管 (或至少相互信任) 資源，是確保車隊完整性的關鍵。
為新叢集規劃機群
本節說明如何規劃車隊，前提是您已有一組已知的應用程式，但可彈性選擇部署這些應用程式的位置。這可能是因為您尚未開發這些應用程式，或是要從其他容器平台遷移這些應用程式。或者，您可能已在現有叢集中執行應用程式，但願意將應用程式移至新叢集，以實現偏好的架構。
找出機群後，您可以為每個機群建立新專案，在每個專案中建立機群，然後建立叢集並註冊至所需機群。
稽核工作負載
首先，請列出要部署的所有 Kubernetes 工作負載 (例如 Deployment)。這不一定要是實際清單，只要瞭解您需要哪些工作負載即可。接著，按照本節其餘步驟的指示，逐步將該組應用程式劃分為子集，直到您擁有所需的最少分組為止。這會定義您需要的車隊和叢集。
考慮業務單位
貴機構可能採用聯合 IT 結構，也就是設有一個機構中央 IT 團隊，以及各業務單位專屬的 IT 團隊。在這種情況下，每個聯盟 IT 團隊可能都想管理自己的車隊。如果兩個業務單位的負載 (例如銀行中的稽核和交易) 由於法規因素完全無法彼此通訊，請使用不同的車隊。
依環境區分工作負載
許多機構會依環境將叢集分組，這是常見的做法。一般來說，設定會包含三個主要環境：開發、非實際工作環境 (或測試環境) 和實際工作環境。應用程式變更通常會逐步部署 (或升級) 至清單中的每個環境。因此，您在每個環境中都有相同的基礎應用程式 (例如相同的基本容器映像檔名稱)，但部署作業是分開進行。如要瞭解如何在貴機構中建立環境，請參閱企業基礎藍圖。
機群只能包含來自一個環境的叢集。對許多機構而言，三個環境 (每個環境各有一個車隊) 可能就已足夠。如需每個環境都有一個車隊的範例，以及如何逐步部署應用程式，請參閱企業應用程式藍圖。
合併多餘的工作負載執行個體
如果應用程式需要高可用性，其中一種模式是在兩個以上的區域中執行。這包括執行設定非常相似的部署作業，並以單一單位管理兩個以上的叢集。通常會使用負載平衡器，涵蓋所有叢集中的應用程式執行個體，或使用 DNS 負載平衡。
在這些情境中，請將所有叢集放在同一個機群中。一般來說，不同區域的叢集不需要位於不同的車隊，除非是法規或其他原因要求。
使用現有叢集規劃機群
本節說明在現有叢集上執行工作負載時，如何規劃車隊，以及您不打算遷移工作負載時的規劃方式。這些叢集可能位於或不位於 Google Cloud。在本情境中，目標是在貴機構中建立一組機群，並將現有叢集指派給這些機群。
識別機群後，您可以為每個機群建立新專案，在每個專案中建立機群，然後將叢集註冊至所需機群。
稽核叢集
請先列出貴機構的所有 Kubernetes 叢集。Cloud Asset Inventory 是在機構中搜尋 Kubernetes 叢集資源的方法之一。
然後按照本節其餘步驟操作，逐步將該組應用程式劃分為子集，直到您擁有所需的最小分組集為止。這會定義您需要的車隊。
考慮業務單位
貴機構可能採用聯合 IT 結構，也就是設有一個機構中央 IT 團隊，以及各業務單位專屬的 IT 團隊。這些 IT 團隊可能已建立現有叢集。通常在這種情況下，您會依業務單位分割叢集集。舉例來說，基於法規因素，銀行中特定業務單位的工作負載 (例如稽核和交易) 完全無法彼此通訊。
如果業務部門僅用於成本會計，但使用共同的 IT 團隊，請考慮將叢集合併至單一機群，尤其是當業務部門之間存在顯著的服務間依附元件時。
依環境將叢集分組
找出貴機構使用的環境。常見的環境名稱包括開發、非正式 (或測試) 和正式。
如果每個叢集都只屬於一個環境，請依環境分隔叢集清單。不過，如果某些叢集包含邏輯上屬於不同環境的工作負載，建議您將應用程式重新部署到只包含屬於單一邏輯環境的應用程式的叢集。
盡量減少叢集擁有者人數
將現有專案併入機群時，授權可擔任這些叢集管理員的使用者組合可能不同，因為 IAM 政策 (container.admin) 和 RBAC (管理員 ClusterRoleBinding) 都會影響授權。如果您打算使用需要相同性的功能，目標應是讓所有叢集擁有相同的管理員組合，且機群的管理員組合較小。如果叢集必須有不同的管理員，且目標是使用需要相同管理員的功能，則這些叢集可能不屬於同一個車隊。
舉例來說，如果叢集 C1 和 C2 的管理員不同，且互不信任，也不願將管理員權限授予管理車隊的中央平台團隊，則不應將這兩個叢集歸入同一個車隊。
如要進一步瞭解相同性，以及哪些功能需要相同性，請參閱「機群運作方式」。
考慮機群功能
無論是使用新叢集還是現有叢集，您選擇的車隊功能也可能會影響最佳車隊組織。舉例來說，如果您選擇使用機群範圍的 Workload Identity Federation，在設定機群範圍的工作負載驗證時，您可能會想以盡量降低風險的方式來整理機群；或者，如果您想使用 Cloud Service Mesh，可能需要將特定叢集放在同一個機群中。如果您使用虛擬私有雲 (VPC)，部分功能需要每個機群使用單一 VPC。
如要進一步瞭解如何採用車隊功能，以及相關規定和限制，請參閱本系列下一篇指南「規劃車隊功能」。
考量虛擬私有雲範圍
無論是新叢集還是現有叢集，您都必須考慮是否已選擇或想要在 Google Cloud 使用虛擬私有雲 (VPC) 建立自己的私人網路。VPC 範圍內的叢集 (例如具有 VPC Service Controls 的 Shared VPC) 可以一起加入機群。如果您同時有受限和非受限的 Shared VPC，建議將這些 VPC 分別放入不同的車隊。
如果打算使用 VPC Service Controls 範圍，通常部分工作負載會位於範圍內，部分則位於範圍外。您應規劃在每個環境中，為每個機群提供 VPC Service Controls 和非 VPC Service Controls 版本 (或至少是正式版和緊接在正式版之前的環境)。
規劃使用 VPC 的車隊時，請注意部分車隊功能有特定 VPC 需求，例如要求使用這些功能的所有叢集都必須位於同一個 VPC 網路中。