規劃機群功能

規劃車隊時,決定要使用的車隊功能非常重要。特別是使用現有叢集和正式版工作負載時,您可能會想找出可立即採用、對現有應用程式的摩擦或風險極小的車隊功能,同時規劃其他可能需要更漸進或謹慎採用的功能。本指南說明使用車隊可啟用的不同類型功能及其相關規定,並提供採用功能的實用指引。

本指南所述的許多功能僅適用於 GKE Enterprise。詳情請參閱「GKE Enterprise 部署選項」。

這份指南適用於想在機構中開始使用車隊的雲端架構師。閱讀本指南前,請先熟悉機群管理總覽規劃機群資源,瞭解如何將新叢集或現有叢集納入機群。

採用功能的最佳做法

所有車隊功能 (基本車隊可觀測性除外) 都是選擇性啟用,也就是說,您必須指定要使用這些功能。將現有叢集新增至機群時,叢集設定不會變更。決定使用車隊功能後,部分功能可立即啟用,風險極低,但有些功能可能需要更謹慎地處理。本節提供一些功能採用指南。

特別是現有叢集和工作負載,您需要特別注意功能使用相同性的位置。這是機群概念,指功能會假設不同叢集中名稱相同的命名空間、服務或身分是相同的。如要進一步瞭解相同性原則和使用該原則的功能,請參閱「車隊運作方式」。

開始使用低風險功能

下列「環境」功能不會假設任何類型的相同性,也不會以任何方式影響叢集。即使有現有工作負載和叢集,您也能安全地使用這些功能,立即享有機群的強化可觀測性和安全性洞察,以及根據機群成員資格管理叢集升級順序的功能。

下列功能會安裝在個別叢集上。可以假設相同,但僅限於跨多個叢集設定或指定資源時。也就是說,您可以在叢集上安全地啟用這些功能,並使用現有的工作負載,而且只有在建立或使用這些選用選取器的設定時,才需要考慮是否相同。

啟用進階多叢集功能

下列強大功能可減少管理多個叢集的作業支出。不過,使用這些功能時必須更加謹慎,因為這些功能都需要假設一或多種同質性才能運作,啟用或停用這些功能可能會影響多個叢集及其工作負載。

舉例來說,如果您在不同叢集和應用程式 (包括預設命名空間) 中有名稱相同的現有 Kubernetes 命名空間,請先確認您要將這些命名空間視為相同命名空間,再啟用任何會做出這項假設的功能。同樣地,如要使用 Cloud Service Mesh,請務必瞭解哪些服務端點會跨叢集合併,並確認這是您想要的行為。

稽核命名空間是否相同

如果您對應用程式瞭若指掌,只要確認沒有兩個「不同」的應用程式使用相同的命名空間,即可稽核命名空間。特別要注意預設命名空間是否用於臨時用途。舉例來說,如果您在一個叢集中有名為 default 的命名空間,在另一個叢集中也有名為 default 的命名空間,但用途不同,則應重新命名其中一個命名空間。

如要採取更嚴謹的做法,請嘗試下列步驟。針對機群中不同叢集內名稱相同的每個命名空間組合,請確認:

  • 在每個叢集中,叢集內都有相同的 RBAC 規則,且主體的命名空間可存取該命名空間。
  • Pod 使用的圖片集 (減去雜湊/標記) 相同。
  • Pod 使用的 Secret 集完全相同。

如果這些條件都成立,則命名空間就足夠相似,可視為「相同」。

如果命名空間不夠相似,您可以將應用程式遷移至新的命名空間。確認命名空間相同後,即可啟用使用該命名空間的功能。

稽核服務相同性

如要採用 Cloud Service Mesh 管理微服務型應用程式,另一個需要考慮的問題是服務同質性。也就是說,就下列項目而言,對於任何命名空間和服務名稱組合,Cloud Service Mesh 都會將其視為相同的邏輯服務:

  • 身分 (專為 Cloud Service Mesh 安全性而設):如果 namespace1/service1 獲得授權可執行某項操作,則任何叢集中具有該身分的工作負載都會獲得授權。
  • 流量管理:根據預設,流量會在任何叢集中的 namespace1/service1 服務之間進行負載平衡。
  • 可觀測性:所有叢集中的 namespace1/service1 指標都會匯總在一起。

如果您要為新的叢集和應用程式啟用 Cloud Service Mesh,建議您在整個網格中保留不重複的命名空間/服務名稱組合。如果是現有應用程式,請稽核服務,確保叢集中命名空間和名稱相同的服務,在身分、流量管理和可觀測性方面,都是您希望視為相同服務的服務。

特別是,請確保邏輯上不同的服務 (例如付款會計 API 和付款交易 API) 不會使用相同的 [命名空間、名稱] 配對 (例如 payments/api),因為一旦進入服務網格,系統就會將這些服務視為同一項服務。即使跨越區域界線,概念上的聯結也會發生。此外,服務功能也可能受到影響。

將流量導向多個叢集中的服務時,多叢集 Ingress 和多叢集閘道也會假設服務命名空間/名稱相同,但僅適用於叢集外部公開的服務。

考量 Workload Identity

機群 Workload Identity 聯盟是強大的機群功能,這項功能擴充了 Workload Identity Federation for GKE 提供的功能,可讓叢集中的工作負載向 Google 進行驗證,而不需下載、手動輪替及一般管理 Google Cloud 服務帳戶金鑰。工作負載會改用叢集產生的短期權杖進行驗證,且每個叢集都會做為身分識別提供者新增至特殊的工作負載身分識別集區。在特定命名空間中執行的工作負載,可以在叢集間共用相同的 Identity and Access Management 身分。

GKE 適用的標準 Workload Identity Federation 使用專案範圍的身分集區,而機群範圍的 Workload Identity Federation 則使用整個機群的工作負載身分集區,即使叢集位於不同專案中,機群中的身分、命名空間和服務也會隱含相同。這樣一來,您就能更輕鬆地為跨專案的應用程式設定驗證,但如果您選擇在多專案機群中使用,則可能需要考慮存取控制,這與 GKE 的一般工作負載身分聯盟不同,特別是當機群主專案同時有機群和非機群叢集時。

如要進一步瞭解機群 Workload Identity 聯盟,以及如何使用這項功能存取 Google Cloud 服務,請參閱「使用機群 Workload Identity」。如需如何透過機群 Workload Identity 聯盟將風險降至最低的指引和範例,請參閱「使用機群 Workload Identity 的最佳做法」。

車隊層級預設值

GKE Enterprise 可為特定企業功能設定機群層級預設值,包括 Cloud Service Mesh、Config Sync 和 Policy Controller。這樣一來,您就能設定叢集使用這些功能,不必個別設定每個叢集。舉例來說,管理員可以為機群啟用 Policy Controller,並在機群層級設定預設政策。這會在新的機群成員叢集中安裝必要代理程式,並套用預設政策。

不過,這些預設值只會自動套用至您在建立叢集時新增至機群的新叢集。即使您已將現有叢集及其工作負載新增至機群,或是在設定功能預設值後新增叢集,這些叢集和工作負載也不會受到影響。也就是說,您可以安全地設定機群層級預設值,不必擔心在尚未準備好的叢集上啟用或設定功能。您隨時可以選擇將預設設定套用至現有叢集。

功能需求

根據貴機構想使用的車隊功能導入車隊時,請注意以下限制。舉例來說,部分功能不支援使用不在機群主專案中的叢集,而其他功能則不支援外部叢集 Google Cloud。

下表列出各元件目前的規定和限制,後續章節也會提供一些具體指引。

功能
叢集類型
專案規定
虛擬私有雲需求
Config Sync 所有支援的 GKE Enterprise 叢集
Policy Controller 所有支援的 GKE Enterprise 叢集
Cloud Service Mesh 請參閱限制 使用 Cloud Service Mesh 的所有叢集 (位於同一專案中) 都必須註冊至同一個機群。詳情請參閱 Cloud Service Mesh 叢集需求條件 GKE 叢集必須位於相同的虛擬私有雲網路。
多叢集服務 (MCS) GKE on Google Cloud 請參閱「共用虛擬私有雲上的 MCS」。
多叢集 Ingress 和多叢集閘道 GKE on Google Cloud Ingress/Gateway 資源、GKE 叢集和機群必須位於同一個專案中。 Ingress/Gateway 資源和 GKE 叢集必須位於相同的 VPC 網路。
Workload Identity 集區 已針對 GKE on Google Cloud 和 Google Distributed Cloud on VMware 完成最佳化調整。系統也支援其他 Kubernetes 叢集,但需要額外設定。
二進位授權 GKE on Google Cloud、Google Distributed Cloud on VMware、 Google Distributed Cloud on Bare Metal
進階安全漏洞分析 GKE on Google Cloud
安全防護機制 GKE on Google Cloud
法規遵循情形 GKE on Google Cloud
機群資源使用率指標 GKE on Google Cloud
機群記錄 全部
連結閘道 全部
機群團隊管理 全部
Pod FQDN 網路政策 GKE on Google Cloud
節點間透明加密功能 GKE on Google Cloud
Config Controller 不適用
推出作業排序 GKE on Google Cloud

考量虛擬私有雲需求

如果您打算使用 Cloud Service Mesh 等功能,這類功能要求叢集必須位於單一虛擬私有雲 (VPC) 網路中 (如上表所示),則應為每個 VPC 建立車隊。如果沒有使用這些功能的打算,則可將多個 VPC 放入一個機群。

舉例來說,常見的模式是機構有多個專案,每個專案都有自己的預設虛擬私有雲。這些網路之間可能已有對等互連連線。如果您未使用需要單一 VPC 的功能,這些都可以放入單一機群。另一個常見模式是採用「軸輻式」拓撲,也就是使用多個虛擬私有雲。如果您使用的功能沒有單一 VPC 需求,則可將所有這些 VPC 的叢集放在一個機群中。請注意,在某些情況下,遵循這些規範可能會導致您只有一個叢集的車隊!在這種情況下,您可能需要放棄使用受虛擬私有雲限制的功能,並建立多專案車隊,或視情況重新考量架構並移動工作負載。

多叢集網路需求

如要使用多叢集 Ingress 或多叢集閘道管理流量,請注意,在這兩種情況下,閘道控制器都無法跨專案。也就是說,如要使用這些功能,所有叢集都必須位於同一個專案和同一個車隊。如要建立包含多個專案叢集的機群,可以改用單一叢集閘道,並以其他方式 (例如使用 DNS) 將流量導向正確的閘道。使用這些功能的叢集也必須位於同一個虛擬私有雲網路。

後續步驟