規劃機群資源

如機群管理總覽所述，機群是一種分組機制，可大規模管理、設定及保護 Kubernetes 叢集。機群是強大的工具，可讓您不必在多叢集環境中重複執行作業，並針對大型叢集群組提供一致性及全面觀測能力。許多 GKE 功能只能透過機群使用。

建立車隊時使用的分組策略，取決於貴機構的技術和業務需求。舉例來說，某個機構可能會根據叢集中執行的應用程式類型將叢集分組，而另一個機構則可能會依據區域、環境或其他相關因素分組。在其他條件相同的情況下，盡可能減少機構內的車隊數量，可帶來便利性。

這份指南適用於想在機構中開始使用車隊的雲端架構師。這份指南提供一些實用指引，說明如何將叢集整理成機群，包括：

  • 想建立全新叢集時。
  • 想使用現有叢集建立車隊時。

這裡說明的模式適用於許多機構，但並非規劃車隊的唯一方式。機群具有彈性，您可能會決定為叢集使用不同的分組模式。

閱讀本頁面之前，請先熟悉下列概念：

車隊和資源限制

建立車隊時，請遵守下列一般限制：

  • 特定 Google Cloud 專案只能有一個相關聯的機群 (或沒有機群)，但該機群可以包含多個專案的叢集。與機群相關聯的專案稱為機群的機群主專案。
  • 叢集一次只能是單一機群的成員。
  • 特定專案中的所有叢集都必須位於同一個機群，或是完全不屬於任何機群。如果專案已包含機群成員，您就無法將該專案的叢集註冊至其他機群。
  • 機群中的叢集數量預設上限為 250 個，但您可以視需要申請提高上限。

將多個叢集放在同一個專案中，有很多便利之處。不過，規劃要在專案中組合哪些叢集時，請注意下列限制：

一般原則

決定是否要將叢集分組到機群時，請先問自己以下一般問題。我們會在後續章節中詳細說明這些概念的應用方式。

  • 資源是否彼此相關？
    • 資源之間有大量跨服務通訊，最適合在機群中一起管理。
    • 相同部署環境 (例如正式環境) 中的資源應在機群中一起管理。
  • 誰管理資源？
    • 統一控管資源 (或至少彼此信任) 對於確保車隊完整性至關重要。

為新叢集規劃機群

本節說明如何規劃車隊，前提是您已有一組已知的應用程式，但可彈性選擇部署這些應用程式的位置。這可能是因為您尚未開發這些應用程式，或是要從其他容器平台遷移應用程式。或者，您可能已在現有叢集中執行應用程式，但願意將應用程式移至新叢集，以實現偏好的架構。

識別機群後，您可以為每個機群建立新專案，在每個專案中建立機群，然後建立叢集並註冊至預期機群。

稽核工作負載

首先，請列出要部署的所有 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 需求，例如必須讓使用這些功能的所有叢集位於同一虛擬私有雲網路中。

後續步驟