企業多用戶群的最佳做法

Google Kubernetes Engine (GKE) 的多租戶架構是指在租戶之間共用一或多個叢集。在 Kubernetes 中，租戶可定義為下列任一項目：

  • 負責開發及執行一或多個工作負載的團隊。
  • 一組相關工作負載，無論是由一或多個團隊運作。
  • 單一工作負載，例如 Deployment。

叢集多重租戶通常用於降低成本，或在租戶之間一致套用管理政策。不過，如果 GKE 叢集或相關聯的 GKE 資源設定有誤，可能無法節省成本、政策套用不正確，或不同租戶的工作負載之間發生破壞性互動。

本指南提供最佳做法，協助企業機構安全且有效率地設定多個多租戶叢集。如要查看所有 GKE 最佳做法的整合總覽，請參閱「GKE 最佳做法」。

假設和需求

本指南的最佳做法是以企業環境的多用戶群用途為基礎，並假設及要求下列事項：

  • 這個機構是單一公司，有多個租戶 (兩個以上的應用程式/服務團隊) 使用 Kubernetes，並希望共用運算和管理資源。
  • 每個房客都是開發單一工作負載的單一團隊。
  • 除了應用程式/服務團隊，還有其他團隊也會使用及管理叢集，包括平台團隊成員、叢集管理員、稽核人員等。
  • 平台團隊擁有叢集，並定義每個租戶團隊可使用的資源量；每個租戶都可以要求更多資源。
  • 每個租戶團隊都應能透過 Kubernetes API 部署應用程式，而不必與平台團隊溝通。
  • 除了透過 API 呼叫、共用資料來源等明確的設計決策外，每個租戶都不應影響共用叢集中的其他租戶。

這個設定將做為示範多租戶最佳做法的模型。雖然這種設定可能無法完美描述所有企業機構，但可以輕鬆擴充，涵蓋類似情境。

設定資料夾、專案和叢集

最佳做法：

建立資料夾和專案階層結構。
使用 IAM 指派角色。
透過 Shared VPC 集中控管網路。
為每個叢集建立一個叢集管理員專案。
將叢集設為私人。
確認叢集的控制層為區域性。
確保叢集中的節點至少涵蓋三個區域。
自動調度叢集節點和資源。
安排在離峰時段進行維護作業。
使用 Ingress 設定外部應用程式負載平衡器。

對於在 GKE 中部署多租戶叢集的企業機構，您需要在其他Google Cloud 系統中進行額外設定，才能管理複雜性，這在較簡單的單一應用程式和單一團隊 Kubernetes 部署作業中並不存在。這包括用於隔離管理問題的專案設定，以及將組織結構對應至 Cloud Identity 和帳戶，並管理其他 Google Cloud 資源，例如資料庫、記錄和監控、儲存空間和網路。

建立資料夾和專案階層

如要反映貴組織管理 Google Cloud 資源的方式，並將不同的關注範圍區隔開來，請使用資料夾和專案。不同團隊可透過資料夾設定政策，並將政策套用至多個專案；專案則可用於區隔環境 (例如正式環境與測試環境)，以及區隔不同團隊。舉例來說，大多數組織都有一個團隊負責管理網路基礎架構，另一個團隊負責管理叢集。每項技術都視為堆疊的獨立部分，需要各自的專業知識、疑難排解和存取權。

上層資料夾最多可包含 300 個資料夾，巢狀資料夾最多可達 10 層。如果租戶數量超過 300 個，可以將租戶安排在巢狀階層中，以免超出限制。如要進一步瞭解資料夾，請參閱「建立及管理資料夾」。

使用 IAM 指派角色

您可以透過 IAM 政策控管資源存取權。 Google Cloud 首先，請找出機構所需的群組及其作業範圍，然後將適當的 IAM 角色指派給群組。

使用 Google 網路論壇，有效率地為使用者指派及管理 IAM。

集中控制網路

如要集中控管網路資源 (例如子網路、路徑和防火牆)，請使用共用虛擬私有雲網路。Shared VPC 中的資源可以跨越專案界線，使用內部 IP 安全有效率地相互通訊。每個 Shared VPC 網路都是由集中式主專案定義及擁有，且可供一或多個服務專案使用。

使用 Shared VPC 和 IAM，即可區隔網路管理和專案管理。這種劃分方式有助於您實作最小權限原則。例如，中央網路團隊不需具備參與專案的任何權限即可管理網路。同樣地，專案管理員不需具備任何能夠操控共用網路的權限即可管理其專案資源。

設定 Shared VPC 時，您必須在 VPC 中設定子網路及其次要 IP 範圍。如要判斷子網路大小，您必須瞭解預期的租戶數量、預期執行的 Pod 和 Service 數量，以及 Pod 大小的上限和平均值。計算所需的叢集總容量，有助於瞭解所需的執行個體大小，並提供節點總數。有了節點總數，就能計算耗用的 IP 空間總量，進而提供所需的子網路大小。

設定網路時，也請考慮下列因素：

  • 可附加至主專案的服務專案數量上限為 1,000 個，單一組織中的 Shared VPC 主專案數量上限為 100 個。
  • 節點、Pod 和服務的 IP 範圍不得重複。您無法建立主要和次要 IP 位址範圍重疊的子網路。
  • 特定 GKE 叢集的 Pod 和 Service 數量上限，取決於叢集次要範圍的大小。
  • 叢集的節點數上限受限於叢集子網路的主要 IP 位址範圍大小，以及叢集的 Pod 位址範圍。
  • 如要更靈活、更全面地控管 IP 位址管理作業，您可以設定節點可執行的 Pod 數量上限。減少每個節點的 Pod 數量，也能減少每個節點分配到的 CIDR 範圍，因此需要的 IP 位址較少。

如要瞭解虛擬私有雲叢集中的網路範圍，請參閱「建立 VPC 原生叢集」。

如果租戶需要進一步隔離在共用叢集外部執行的資源 (例如專用 Compute Engine VM)，可以使用自己的 VPC，並與網路團隊執行的 Shared VPC 對等互連。這項做法可提供額外安全性，但會增加複雜度，並造成許多其他限制。如要進一步瞭解對等互連，請參閱「使用虛擬私有雲網路對等互連」。在下方範例中，所有租戶都選擇共用單一 (每個環境) 租戶虛擬私有雲。

建立可靠且高可用性的叢集

請按照下列建議設計叢集架構，確保高可用性和可靠性：

  • 為每個叢集建立一個叢集管理員專案，以降低專案層級設定 (例如 IAM 繫結) 對多個叢集造成負面影響的風險，並協助區隔配額和帳單。叢集管理員專案與租戶專案不同，後者由個別租戶用於管理資源等項目。 Google Cloud
  • 設定網路隔離措施，停用節點存取權並管理控制層存取權。我們也建議您為開發和測試環境設定網路隔離。
  • 請確保叢集的控制層為區域性，為多用戶群架構提供高可用性；控制層發生任何中斷都會影響用戶群。請注意，執行區域叢集會產生費用。Autopilot 叢集預先設定為區域叢集。
  • 請確保叢集中的節點至少涵蓋三個可用區，以達到區域可靠性。如要瞭解同一區域內不同可用區之間的輸出費用，請參閱網路定價說明文件。
私人區域叢集，控制層在三個可用區中執行
圖 3： 私人區域叢集，其區域控制層在三個可用區中運作。

自動調度叢集節點和資源

如要滿足租戶需求，請啟用自動調度資源，自動調整叢集中的節點數量。

當各種租戶在命名空間中部署大量工作負載，或發生區域性中斷時，自動調度資源可協助系統保持回應能力和運作狀態。

使用 Autopilot 叢集時，節點集區會自動調度資源，以符合工作負載需求。

啟用自動調度資源功能時，您需要根據預期的工作負載大小，指定叢集中的節點數量下限和上限。指定節點數量上限，即可確保叢集有足夠空間容納所有 Pod，無論 Pod 在哪個命名空間中執行都一樣。叢集自動調整資源配置會根據最小/最大界線重新調整節點集區，在系統負載降低時協助減少營運成本，並避免 Pod 在可用叢集資源不足時進入待處理狀態。如要判斷節點數上限，請找出每個租戶需要的 CPU 和記憶體上限，然後將這些上限加總，即可得出叢集應能處理的總容量 (假設所有租戶都達到上限)。接著，您可以根據節點數量上限，選擇執行個體大小和數量，並考量叢集可用的 IP 子網路空間。

使用 Pod 自動調整資源配置功能，根據資源需求自動調整 Pod。水平 Pod 自動配置器 (HPA) 會根據 CPU/記憶體使用率或自訂指標，調整 Pod 副本數量。垂直自動調度 Pod 資源 (VPA) 可用於自動調度 Pod 資源需求。除非有自訂指標，否則不應與 HPA 搭配使用，因為這兩個自動配置器可能會互相競爭。因此，請先使用 HPA，之後再視需要使用 VPA。

決定叢集大小

決定叢集大小時，請考量下列重要因素：

  • 叢集的大小取決於您打算執行的工作負載類型。工作負載密度越高，成本效益就越高，但資源爭用機率也越高。
  • 叢集的大小下限取決於涵蓋的可用區數量：可用區叢集為一個節點，區域叢集則為三個節點。
  • 每個專案在每個區域最多可有 50 個叢集，加上每個區域 50 個區域叢集。

  • 每個叢集的節點適用下列最大值：

    • 每個節點集區在每個可用區中最多可有 2,000 個節點。
    • 使用 Google Kubernetes Engine Ingress 控制器時，每個叢集每個可用區 1,000 個節點。
    • 每個叢集最多可有 5,000 個、15,000 個或 65,000 個節點。並非所有節點增加作業都是自動進行。視目標節點數量而定，您可能需要滿足特定基礎架構需求，或與 Cloud Customer Care 聯絡。詳情請參閱「叢集大小限制和規定」。
    • Standard 叢集每個節點最多可有 512 個 Pod (Autopilot 叢集則動態設定為最多 256 個)。
    • 每個叢集 200,000 個 Pod 和 400,000 個容器。

    詳情請參閱「配額與限制」頁面。

排定維護期間

如要減少叢集/節點升級和維護期間的停機時間，請將維護期間排定在離峰時段。升級期間，工作負載會移至重新建立的節點，因此可能會暫時中斷。為確保這類中斷情形造成的影響降到最低，請安排在離峰時段升級，並盡可能設計應用程式部署作業，以便順暢處理部分中斷情形。

使用 Ingress 設定外部應用程式負載平衡器

如要管理租戶發布的服務，以及傳入這些服務的流量，請建立 HTTP(S) 負載平衡器，允許每個叢集有一個 ingress，其中每個租戶的服務都會向叢集的 Ingress 資源註冊。您可以建立 Kubernetes Ingress 資源，定義流量如何到達服務，以及如何轉送至租戶的應用程式，藉此建立及設定 HTTP(S) 負載平衡器。向 Ingress 資源註冊 Service 後，Service 的命名慣例會保持一致，顯示單一 Ingress，例如 tenanta.example.com 和 tenantb.example.com。

保護多租戶叢集

最佳做法：

使用網路政策控管 Pod 通訊。
使用 GKE Sandbox 執行工作負載。
設定以政策為準的許可控制。
使用 Workload Identity Federation for GKE 授予 Google Cloud 服務存取權。
限制控制層的網路存取權。

使用網路政策控管 Pod 通訊

如要控管叢集各命名空間中 Pod 之間的網路通訊，請根據租戶需求建立網路政策。建議您先封鎖託管不同租戶應用程式的命名空間之間的流量。叢集管理員可以套用deny-all網路政策，拒絕所有輸入流量，避免一個命名空間的 Pod 意外將流量傳送至其他命名空間的服務或資料庫。

舉例來說，下列網路政策會限制從所有其他命名空間輸入至 tenant-a 命名空間：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:

  ingress:
  - from:
    - podSelector: {}

使用 GKE Sandbox 執行工作負載

與其他叢集相比，執行不受信任工作負載的叢集更容易受到安全漏洞影響。使用 GKE Sandbox，您可以強化多租戶環境中工作負載之間的隔離界線。如要管理安全性，建議先使用 GKE Sandbox，然後使用以政策為準的許可控制項填補任何缺口。

GKE Sandbox 以開放原始碼容器沙箱專案 gVisor 為基礎，在容器和主機 OS 之間新增一層，為多租戶工作負載提供額外的隔離機制。容器執行階段通常會以節點上的特殊權限使用者身分執行，並可存取主機核心的大部分系統呼叫。在多租戶叢集中，惡意租戶可能會取得主機核心的存取權，以及其他租戶的資料。GKE Sandbox 可減少容器與主機互動的需求，縮小主機的受攻擊面，並限制惡意行為人的活動，進而減輕這些威脅。

GKE Sandbox 在容器和主機 OS 之間提供兩道隔離界線：

  • 以 Go 語言編寫的使用者空間核心，可處理系統呼叫，並限制與主機核心的互動。每個 Pod 都有各自獨立的使用者空間核心。
  • 使用者空間核心也會在命名空間和 seccomp 篩選系統呼叫中執行。

設定以政策為基礎的許可控制項

如要防止違反安全界限的 Pod 在叢集中執行，請使用許可控制器。准入控制器可以根據您定義的政策檢查 Pod 規格，並防止違反這些政策的 Pod 在叢集中執行。

GKE 支援下列類型的准入控制：

使用 Workload Identity Federation for GKE 授予 Google Cloud 服務

如要安全地授予工作負載服務存取權，請在叢集中啟用 Google Cloud Workload Identity Federation for GKE。Workload Identity Federation for GKE 可協助管理員，管理 Kubernetes 工作負載用來存取 Google Cloud 服務的 Kubernetes 服務帳戶。建立叢集並啟用 Workload Identity Federation for GKE 時，系統會為叢集所在的專案建立身分命名空間。叢集可透過身分命名空間，將 Kubernetes 服務帳戶名稱對應至虛擬 Google 服務帳戶控制代碼，自動驗證 GKE 應用程式的服務帳戶，並用於租戶 Kubernetes 服務帳戶的 IAM 繫結。

限制控制層的網路存取權

為保護控制層，請限制授權網路的存取權。在 GKE 中，啟用授權網路後，您最多可以授權 50 個 CIDR 範圍，並僅允許這些範圍內的 IP 位址存取控制層。GKE 已使用傳輸層安全標準 (TLS) 和驗證機制，從公開網際網路安全存取控制層端點。使用已授權網路，可進一步限制對特定 IP 位址集的存取權。

佈建租戶

最佳做法：

建立租戶專案。
使用 RBAC 調整房客存取權。
建立命名空間，區隔不同用戶群。

建立租戶專案

如要代管租戶的非叢集資源，請為每個租戶建立服務專案。這些服務專案包含租戶應用程式專屬的邏輯資源 (例如記錄、監控、儲存空間 bucket、服務帳戶等)。所有租戶服務專案都會連線至租戶主專案中的 Shared VPC。

使用 RBAC 調整租戶存取權

使用 Kubernetes RBAC，為租戶定義更精細的叢集資源存取權。除了最初透過 IAM 授予租戶群組的唯讀存取權外，請為每個租戶群組定義命名空間層級的 Kubernetes RBAC 角色和繫結。

我們稍早識別出兩個租戶群組：租戶管理員和租戶開發人員。 針對這些群組，我們定義了下列 RBAC 角色和存取權：

群組 Kubernetes
RBAC 角色		 說明
租戶管理員 命名空間管理員

可列出及監控命名空間中的部署作業。

授予在租戶群組中新增及移除使用者的權限。
租戶開發人員 命名空間編輯者、
命名空間檢視者		 可建立/編輯/刪除命名空間中的 Pod、Deployment、Service 和 ConfigMap。

除了建立 RBAC 角色和繫結，在命名空間內為 Google Workspace 或 Cloud Identity 群組指派各種權限，租戶管理員通常也需要管理每個群組中的使用者。視貴機構的需求而定，您可以將 Google Workspace 或 Cloud Identity 權限委派給租戶管理員，讓他們管理自己的群組成員資格，也可以由租戶管理員與貴機構中擁有 Google Workspace 或 Cloud Identity 權限的團隊合作，處理這些變更。

您可以搭配使用 IAM 和 RBAC 權限與命名空間，限制使用者在 Google Cloud 控制台與叢集資源的互動。詳情請參閱「 依命名空間啟用存取權及查看叢集資源」。

使用 Google 網路論壇繫結權限

如要有效管理叢集中的租戶權限，您可以將 RBAC 權限繫結至 Google 群組。這些群組的成員資格由 Google Workspace 管理員維護，因此叢集管理員不需要使用者的詳細資訊。

舉例來說，假設我們有一個名為 tenant-admins@mydomain.com 的 Google 群組，且名為 admin1@mydomain.com 的使用者是該群組的成員，則下列繫結會提供使用者 tenant-a 命名空間的管理員存取權：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-a
  name: tenant-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "tenant-admins@mydomain.com"

建立命名空間

如要透過邏輯區隔位於同一個叢集的用戶群，請實作命名空間。在 Kubernetes RBAC 程序中，叢集管理員會為每個租戶群組建立命名空間。租戶管理員負責管理各自租戶命名空間中的使用者 (租戶開發人員)。租戶開發人員隨後就能使用叢集和租戶專屬資源部署應用程式。

避免達到命名空間限制

叢集中的命名空間理論上限為 10,000 個，但實際上有很多因素會導致您無法達到這個上限。舉例來說，您可能會在達到命名空間數量上限之前，就先達到叢集層級的 Pod 數量上限 (150,000 個) 和節點數量上限 (5,000 個)；其他因素 (例如 Secret 數量) 可能會進一步降低有效限制。因此，一開始最好只嘗試接近一項限制的理論上限，並與其他限制保持約一個數量級的距離，除非實驗顯示您的用途運作良好。如果需要的資源超出單一叢集可支援的範圍，請建立更多叢集。如要瞭解 Kubernetes 可擴充性，請參閱「Kubernetes 可擴充性門檻」一文。

採用統一的命名空間命名方式

如要簡化在不同叢集代管的多個環境中進行部署作業，請將使用的命名空間命名慣例標準化。舉例來說，請避免將環境名稱 (開發、測試和正式環境) 繫結至命名空間名稱，而是在不同環境中使用相同名稱。使用相同名稱，就不必在不同環境中變更設定檔。

為租戶工作負載建立服務帳戶

為租戶命名空間中的每個不同工作負載，建立租戶專屬的 Google 服務帳戶。這是一種安全措施，可確保租戶能管理各自命名空間中擁有/部署的工作負載服務帳戶。每個命名空間的 Kubernetes 服務帳戶，都會使用 Workload Identity Federation for GKE 對應至一個 Google 服務帳戶。

強制執行資源配額

為確保共用叢集的所有租戶都能存取叢集資源，請強制執行資源配額。根據每個租戶部署的 Pod 數量，以及每個 Pod 需要的記憶體和 CPU 量，為每個命名空間建立資源配額。

以下範例定義的資源配額中，tenant-a命名空間中的 Pod 最多可要求 16 個 CPU 和 64 GB 的記憶體，CPU 上限為 32 個，記憶體上限為 72 GB。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

監控、記錄和用量

最佳做法：

追蹤用量指標。
提供用戶群專屬記錄檔。

追蹤用量指標

如要取得叢集中個別命名空間和標籤的費用明細，可以啟用 GKE 費用分配功能。GKE 成本分配功能會追蹤叢集工作負載的資源要求和資源用量資訊，您還可以依命名空間和標籤細分這些資訊。透過 GKE 費用分配功能，您可以估算共用叢集的部門/團隊費用明細、瞭解個別應用程式 (甚至是單一應用程式的元件) 的使用模式、協助叢集管理員分類使用量尖峰，以及提供更完善的容量規劃和預算。

啟用 GKE 費用分配功能後，GKE 工作負載的叢集名稱和命名空間會顯示在匯出至 BigQuery 的帳單標籤欄位中。

提供用戶群專屬記錄檔

如要為用戶群提供專案工作負載專屬的記錄檔資料，請使用 Cloud Logging 的 Log Router。如要建立租戶專屬記錄，叢集管理員會建立「接收器」，將記錄項目匯出至租戶 Google Cloud專案中建立的「記錄 bucket」。

如要瞭解如何設定這類記錄，請參閱「GKE 的多租戶記錄」。

檢查清單摘要

下表概略列出在企業機構中建立多租戶叢集時，建議執行的工作：

區 Tasks
機構設定
身分與存取權管理
網路
高可用性和可靠性
安全性
記錄和監控

後續步驟