本頁將深入探討如何透過機群管理多叢集部署作業，包括一些重要的機群術語和概念。「機群」是一個 Google Cloud 概念，可按照邏輯整理叢集和其他資源，方便您使用及管理多叢集功能，並在不同系統中套用一致的政策。機群是 Google Cloud中企業多叢集功能運作方式的重要部分。
本指南適用於技術人員，包括系統架構師、平台營運人員和服務營運人員，他們想運用多個叢集和相關基礎架構。無論貴機構是在Google Cloud、多個雲端服務供應商，還是內部部署環境中執行多個叢集，這些概念都非常實用。
閱讀本頁內容前，請務必熟悉叢集和命名空間等 Kubernetes 基本概念。如不熟悉，請參閱「Kubernetes 基礎知識」、「GKE 說明文件」和「為 Cloud Service Mesh 準備應用程式」。
如要進一步瞭解 GKE Enterprise 平台和使用機群的元件，請參閱 GKE Enterprise 技術總覽和「探索 GKE Enterprise」教學課程。不過，您不需要熟悉 GKE Enterprise 也能按照本指南操作。
術語
以下是我們在討論車隊時會用到的一些重要用語。
可感知機群的資源
機群感知資源是 Google Cloud 專案資源，可邏輯分組並以機群形式管理。目前只有 Kubernetes 叢集可以成為車隊成員。
機群主專案
機群的實作方式與許多其他 Google Cloud 資源相同，都是以 Google Cloud 專案為基礎，也就是機群主專案。每個專案只能有一個 Google Cloud 車隊 (或沒有車隊) 與其建立關聯。這項限制可確保您使用 Google Cloud 專案，在不受共同控管或耗用的資源之間提供更強大的隔離機制。
基礎架構分組
車隊的第一個重要概念是「分組」，也就是選擇哪些「相關」車隊感知資源應成為車隊的一部分。決定要將哪些項目歸為一組時，請先回答下列問題：
- 資源是否彼此相關？
- 如果資源之間有大量跨服務通訊，最適合在機群中一起管理。
- 相同部署環境 (例如實際工作環境) 中的資源應在機群中一起管理。
- 誰負責管理資源？
- 統一 (或至少相互信任) 控制資源，對於確保機群完整性至關重要。
為說明這一點，請參考以下範例：某機構有多個業務線 (LOB)。在這種情況下，服務很少跨 LOB 邊界進行通訊，不同 LOB 中的服務管理方式不同 (例如，LOB 之間的升級週期不同)，甚至每個 LOB 可能都有不同的管理員。在這種情況下，按 LOB 劃分車隊可能較為合理。各個 LOB 也可能採用多個機群，以區隔實際工作環境和非實際工作環境服務。
在接下來的章節中，我們將探討其他車隊概念，您可能會發現其他建立多個車隊的原因，以滿足貴機構的特定需求。
千篇一律
車隊的重要概念是「相同性」。也就是說，當您使用某些支援機群的功能時，系統會將不同叢集中名稱相同的 Kubernetes 物件 (例如命名空間) 視為相同物件。進行這項標準化作業是為了簡化機群資源的管理工作。如果您使用的功能會運用同質性，同質性假設會提供一些強大的指引，說明如何設定命名空間、服務和身分。不過，這也符合我們發現大多數機構已自行採取的做法。
不同類型的相同性可提供不同優勢，如下表所示：
| 相同性屬性 | 你可以... |
|---|---|
| 命名空間在多個叢集中視為相同。 |
|
| 命名空間和服務名稱的組合在多個叢集中視為相同。相同命名空間中名稱相同的服務會使用相同的標籤選取器。 |
|
| 命名空間和服務帳戶 (身分) 的組合在多個叢集中視為相同。 |
|
如上所述，不同的車隊功能會依賴不同類型的相同性。少數功能完全不使用同質性。如要進一步瞭解這項功能，請參閱「哪些功能會使用相同性？」一文，包括哪些功能不需要考慮整個車隊的相同性，以及哪些功能可能需要更仔細的規劃。
命名空間相同
機群中相同性的基本範例是命名空間相同性。許多機群功能會將不同叢集中名稱相同的命名空間視為相同。從另一個角度來看，命名空間是在整個機群中以邏輯方式定義，即使命名空間的例項只存在於部分機群資源中也是如此。
請參考以下 backend 命名空間範例。雖然命名空間只會在叢集 A 和 B 中例項化，但系統會在叢集 C 中隱含保留該命名空間 (允許 backend 命名空間中的服務也排程到叢集 C 中，視需要而定)。也就是說，系統會為整個機群分配命名空間，而非每個叢集。因此，命名空間相同表示機群的命名空間擁有權必須一致。
服務同質性
Cloud Service Mesh 和 Multi Cluster Ingress 會使用命名空間中服務的相同性概念。與命名空間相同性類似，這表示具有相同命名空間和服務名稱的服務會視為相同服務。
如果是 Cloud Service Mesh，服務端點可以跨網格合併。 使用多叢集 Ingress 時，MultiClusterService (MCS) 資源會更明確地合併端點，但我們建議您採用類似的命名做法。因此，請務必確保同一命名空間中名稱相同的服務實際上是同一項服務。
在下列範例中，網際網路流量會在叢集 B 和 C 中 frontend 命名空間內，名稱相同的服務之間進行負載平衡。同樣地，使用機群內的服務網格屬性，frontend 命名空間中的服務可以連線至叢集 A 和 C 中 auth 命名空間內同名的服務。
存取外部資源時的身分一致性
透過機群 Workload Identity Federation，機群中的服務可以利用通用身分，在輸出時存取外部資源，例如 Google Cloud 服務、物件儲存空間等。有了這個通用身分，您就能一次授予艦隊內服務外部資源的存取權，不必逐一授予叢集。
為進一步說明這一點，請參考以下範例。叢集 A、B 和 C 已在機群中註冊通用身分。當 backend 命名空間中的服務存取 Google Cloud 資源時，系統會將其身分對應至名為 back 的通用服務帳戶。 Google Cloud Google Cloud 服務帳戶back可在任意數量的受管理服務上獲得授權，從 Cloud Storage 到 Cloud SQL 皆可。在 backend 命名空間中新增叢集等機群資源時，這些資源會自動繼承工作負載身分相同性屬性。
由於身分相同，因此機群中的所有資源都必須值得信任且受到妥善管理。以前一個範例來說，如果叢集 C 由另一個不受信任的團隊擁有，他們也可以建立 backend 命名空間，並存取代管服務，就像他們是叢集 A 或 B 中的 backend 一樣。
機群內的身分一致性
在機群中，身分相同性與我們先前討論的外部身分相同性類似。就像車隊服務授權外部服務一樣，也可以授權內部服務。
在下列範例中，我們使用 Cloud Service Mesh 建立多叢集服務網格，其中 frontend 可存取 backend。使用 Cloud Service Mesh 和車隊時，我們不需要指定叢集 B 和 C 中的 frontend 可以存取叢集 A 和 B 中的 backend。我們只會指定車隊中的 frontend 可以存取車隊中的 backend。這項屬性不僅簡化授權程序，也讓資源界線更具彈性；現在工作負載可以輕鬆從一個叢集移至另一個叢集，且不會影響授權方式。與工作負載身分相同性一樣，控管車隊資源對於確保服務間通訊的完整性至關重要。
哪些功能會使用相似度？
許多機群功能完全不依賴同質性，因此啟用及使用時，不必考慮是否要在機群中假設任何形式的同質性。其他功能 (包括 Config Sync 和 Policy Controller) 可以使用同質性，舉例來說，如果您想從單一可靠來源，為多個 Fleet 成員叢集選取命名空間進行設定，但並非所有用途都需要同質性。最後，多叢集 Ingress 和機群範圍的工作負載身分聯盟等功能，一律會假設叢集之間存在某種形式的同質性，因此您可能需要根據需求和現有工作負載，謹慎採用這些功能。
部分機群功能 (例如機群 Workload Identity Federation) 需要整個機群都符合其使用的相同假設。其他功能 (例如團隊管理) 則可讓您在命名空間或團隊範圍層級逐步選擇啟用同質性。
下表列出需要本節所述一或多個相同概念的功能。
| 功能 | 支援逐步採用相同性 | 取決於命名空間是否相同 | 視服務是否相同而定 | 取決於身分是否相同 |
|---|---|---|---|---|
| 機群 | 不適用 | 否 | 否 | 否 |
| 二進位授權 | 不適用 | 否 | 否 | 否 |
| 節點間透明加密功能 | 不適用 | 否 | 否 | 否 |
| 以完整網域名稱為依據的網路政策 | 不適用 | 否 | 否 | 否 |
| 連結閘道 | 不適用 | 否 | 否 | 否 |
| Config Sync | 不適用 | 否 | 否 | 否 |
| Policy Controller | 不適用 | 否 | 否 | 否 |
| GKE 安全防護機制 | 不適用 | 否 | 否 | 否 |
| 進階安全漏洞分析 | 不適用 | 否 | 否 | 否 |
| 法規遵循情形 | 不適用 | 否 | 否 | 否 |
| 推出作業排序 | 不適用 | 否 | 否 | 否 |
| 團隊管理 | 是 | 是 | 是 | 否 |
| 多叢集 Ingress | 是 | 是 | 是 | 是 |
| 多叢集服務 | 是 | 是 | 是 | 是 |
| Fleet Workload Identity 聯盟 | 否 | 是 | 是 | 是 |
| Cloud Service Mesh | 否 | 是 | 是 | 是 |
獨占性
機群感知資源在任何時間點都只能是單一機群的成員，這項限制是由 Google Cloud 工具和元件強制執行。這項限制可確保只有一個來源控管叢集。如果沒有專屬性，即使是最簡單的元件也會變得難以使用，貴機構必須考量及設定多個車隊的多個元件如何互動。
高信任度
服務一致性、工作負載身分一致性和網格身分一致性，都是以機群成員之間的高度信任原則為基礎。有了這項信任機制，您就能將這些資源的管理作業提升至車隊層級，而不必逐一管理資源 (也就是逐一管理 Kubernetes 資源的叢集)，最終讓叢集界線變得不那麼重要。
換句話說，在車隊中，叢集可提供保護，避免受到爆炸範圍、可用性 (控制層和基礎基礎架構) 和吵雜鄰居等問題影響。不過，由於機群中任何成員的管理員都可能影響機群其他成員的服務運作，因此這些成員並非政策和控管的強大隔離界線。
因此，建議您將車隊管理員不信任的叢集放在自己的車隊中，以保持隔離狀態。然後視需要跨機群授權個別服務。
團隊範圍
團隊範圍是一種機制，可將機群進一步細分為叢集群組，讓您定義指派給特定應用程式團隊的機群感知資源。視用途而定，個別機群成員叢集可以不與任何團隊建立關聯，也可以與一個或多個團隊建立關聯，讓多個團隊共用叢集。您也可以使用團隊範圍，在機群中依序推出叢集升級，但前提是每個叢集只能與單一團隊建立關聯。
團隊範圍可以有明確定義的相關聯機群命名空間，其中命名空間在範圍內視為相同。 與單獨使用機群提供的預設命名空間相同性相比，這樣可更精細地控管命名空間。
支援機群的元件
下列 GKE Enterprise 和 GKE 元件均採用命名空間和身分相同性等機群概念，讓您輕鬆使用叢集和服務。如要瞭解使用車隊時，各個元件的現行規定或限制，請參閱元件規定。
工作負載身分集區
機群提供通用的工作負載身分集區，可用於在服務網格內和外部服務中，統一驗證及授權工作負載。Cloud Service Mesh
Cloud Service Mesh 是一套工具，可協助您監控及管理服務網格的可靠性，適用於 Google Cloud、地端和其他支援的環境。 您可以跨相同機群中的叢集形成服務網格。Config Sync
Config Sync 可讓您部署及監控系統的宣告式設定套件，這些套件儲存在 Git 存放區等可靠的中央來源，並運用命名空間、標籤和註解等核心 Kubernetes 概念。透過 Config Sync，您可以在整個機群中定義設定，但這些設定會在每個成員資源中套用及強制執行。Policy Controller
您可以透過 Policy Controller，對 Kubernetes 叢集套用並強制執行陳述式政策。這些政策可做為防護機制，協助您管理叢集和機群的最佳做法、安全性與法規遵循事宜。多叢集 Ingress
多叢集 Ingress 會使用機群定義叢集和服務端點的集合，流量可透過這些端點進行負載平衡，進而提供低延遲和高可用性的服務。