如機群管理總覽所述，機群是一種分組機制，可大規模管理、設定及保護 Kubernetes 叢集。機群是強大的工具，可讓您不必在多叢集環境中重複執行作業，並針對大型叢集群組提供一致性及全面監控功能。許多 GKE 功能只能透過機群使用。
建立車隊時使用的分組策略，取決於貴機構的技術和業務需求。舉例來說，某個機構可能會根據叢集中執行的應用程式類型將叢集分組，另一個機構則可能會依據區域、環境或其他相關因素分組。在其他條件相同的情況下，組織內車隊數量越少越方便。
這份指南適用於想在機構中開始使用車隊的雲端架構師。這份指南提供一些實用指引，說明如何將叢集整理成機群，包括：
- 想建立全新叢集時。
- 想使用現有叢集建立車隊時。
這裡說明的模式適用於許多機構，但並非規劃車隊的唯一方式。機群具有彈性，您可以決定為叢集使用不同的分組模式。
閱讀本頁面之前，請先熟悉下列概念：
車隊和資源限制
建立車隊時，請注意下列一般限制：
- 特定 Google Cloud 專案只能有一個相關聯的機群 (或沒有機群)，但該機群可以包含多個專案的叢集。與機群相關聯的專案稱為機群的機群主專案。
- 叢集一次只能是單一車隊的成員。
- 特定專案中的所有叢集必須位於同一個機群，或是完全不屬於任何機群。如果專案已包含機群成員，您就無法將該專案的叢集註冊至其他機群。
- 機群中的叢集數量預設上限為 250 個，但您可以視需要申請提高上限。
將多個叢集放在同一個專案中，有很多便利之處。不過，規劃要在專案中組合哪些叢集時，請注意下列限制：
- 一個虛擬私有雲 (VPC) 網路最多只能有 75 個私有叢集。
- 如果您打算使用多叢集 Ingress 或多叢集 Gateway，請考量專案中
MultiClusterIngress和MultiClusterService資源的限制。 - 查看 Compute Engine 配額和限制。舉例來說，Compute Engine 會對叢集使用的運算資源實施分配配額。
一般原則
決定是否要將叢集分組到車隊時，請先問自己以下一般問題。我們會在後續章節中詳細說明這些概念的應用方式。
- 資源是否彼此相關？
- 如果資源之間有大量跨服務通訊，最適合在機群中一起管理。
- 同一部署環境 (例如正式環境) 中的資源應在機群中一起管理。
- 誰管理資源？
- 統一 (或至少相互信任) 控制資源，是確保機群完整性的關鍵。
為新叢集規劃機群
本節說明如何規劃車隊，前提是您已有一組已知的應用程式，但可彈性選擇部署這些應用程式的位置。這可能是因為您尚未開發這些應用程式，或是要從其他容器平台遷移應用程式。或者，您可能已在現有叢集中執行應用程式，但願意將應用程式移至新叢集，以實現偏好的架構。
識別機群後，您可以為每個機群建立新專案，在每個專案中建立機群，然後建立叢集並註冊至預期機群。
稽核工作負載
首先，請列出要部署的所有 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 的共用 VPC) 可以一起加入機群。如果您同時有受限和非受限的 Shared VPC，建議將這些 VPC 分別放入不同的車隊。
如果打算使用 VPC Service Controls 範圍，通常有些工作負載會位於範圍內，有些則在範圍外。您應規劃在每個環境 (或至少是正式版和緊鄰正式版之前的環境) 中，為每個機群提供 VPC Service Controls 和非 VPC Service Controls 版本。
規劃使用 VPC 的機群時，請注意部分機群功能有特定 VPC 需求，例如要求使用這些功能的所有叢集都必須位於同一個 VPC 網路中。