企業多用戶群的最佳做法

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

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

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

本指南提供最佳做法，協助企業機構安全且有效率地設定多個多租戶叢集。

假設和需求

本指南中的最佳做法是以企業環境的多租戶應用情境為基礎，並有下列假設和需求：

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

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

設定資料夾、專案和叢集

最佳做法：

建立資料夾和專案階層結構。
使用 IAM 指派角色。
使用共用虛擬私有雲集中控制網路。
為每個叢集建立一個叢集管理員專案。
將叢集設為私有。
確認叢集的控制層為區域層級。
確保叢集中的節點涵蓋至少三個區域。
自動調度叢集節點和資源。
將維護期間排定在離峰時段。
使用 Ingress 設定外部應用程式負載平衡器。

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

建立資料夾和專案階層結構

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

上層資料夾最多可包含 300 個資料夾，巢狀結構最多可達 10 層。如果房客超過 300 人，可以將房客安排到巢狀階層中，以符合限制。如要進一步瞭解資料夾，請參閱「建立及管理資料夾」。

使用 IAM 指派角色

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

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

集中控制網路

如要集中控管子網路、路徑和防火牆等網路資源，請使用共用虛擬私有雲網路。共用虛擬私有雲中的資源可以透過內部 IP 安全又有效率地彼此通訊，不受限於專案界線。每個共用虛擬私有雲網路都由集中式主專案定義及擁有，且可供一或多個服務專案使用。

共用虛擬私有雲和 IAM 可讓您將網路管理作業與專案管理作業分開。這種方式有助於落實最低權限原則。例如，中央網路團隊不需具備參與專案的任何權限即可管理網路。同樣地，專案管理員不需具備任何能夠操控共用網路的權限即可管理其專案資源。

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

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

  • 單一主專案最多可附加 1,000 個服務專案，單一機構最多可有 100 個共用 VPC 主專案。
  • 節點、Pod 和服務的 IP 範圍不得重複。您無法建立主要和次要 IP 位址範圍重疊的子網路。
  • 指定 GKE 叢集的 Pod 和 Service 數量上限取決於叢集的次要範圍大小。
  • 叢集的節點數量上限受限於叢集子網路的主要 IP 位址範圍大小，以及叢集的 Pod 位址範圍。
  • 如要彈性管理 IP 位址，並取得更多控制權，您可以設定可在節點上執行的最大 Pod 數。減少每個節點的 Pod 數，也會減少每個節點分配到的 CIDR 範圍，因此需要的 IP 位址較少。

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

如要進一步隔離在共用叢集外部執行的資源 (例如專用 Compute Engine VM)，租戶可以使用自己的虛擬私有雲，並與網路團隊執行的共用虛擬私有雲對等互連。這項做法雖然能提高安全性，但會增加複雜度，並導致許多其他限制。如要進一步瞭解對等互連，請參閱「使用虛擬私有雲網路對等互連」。在下方範例中，所有房客都選擇共用單一 (每個環境) 房客 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 個地區叢集。

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

    • 每個節點集區 1,000 個節點
    • 每個叢集 1,000 個節點 (如果您使用 GKE 輸入控制器)
    • 預設為每個叢集 5,000 個節點。您可以將這個限制提高至 15,000 個或 65,000 個節點。詳情請參閱節點超過 5,000 個的叢集。
    • 每個節點 256 個 Pod
    • 每個叢集 150,000 個 Pod，每個叢集 300,000 個容器

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

排定維護期間

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

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

為協助管理租戶發布的服務，以及管理這些服務的連入流量，請建立 HTTP(S) 負載平衡器，允許每個叢集使用單一 Ingress，其中每個租戶的服務都會向叢集的 Ingress 資源註冊。您可以建立 Kubernetes Ingress 資源，藉此建立及設定 HTTP(S) 負載平衡器。Ingress 資源會定義流量如何到達您的 Service，以及流量如何轉送至您租戶的應用程式。向 Ingress 資源註冊服務後，服務的命名慣例會保持一致，顯示單一 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。GKE 適用的工作負載身分聯盟可協助管理員管理 Kubernetes 服務帳戶，Kubernetes 工作負載會使用這些帳戶存取 Google Cloud 服務。建立叢集時，如果啟用 GKE 適用的工作負載身分聯盟，系統會為叢集所在的專案建立身分命名空間。身分識別命名空間可讓叢集將 Kubernetes 服務帳戶名稱對應至虛擬 Google 服務帳戶控制代碼，藉此自動驗證 GKE 應用程式的服務帳戶，而虛擬 Google 服務帳戶控制代碼則用於租戶 Kubernetes 服務帳戶的 IAM 繫結。

限制控制層的網路存取權

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

佈建租戶

最佳做法：

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

建立用戶群專案

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

使用 RBAC 調整房客存取權

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

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

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

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

授予在租戶群組中新增及移除使用者的權限。
租戶開發人員 命名空間編輯器、
命名空間檢視器		 可授予在命名空間中建立/編輯/刪除 Pod、部署項目、服務和 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 個) 數量上限；其他因素 (例如密鑰數量) 也可能進一步降低有效限制。因此，一開始的經驗法則是，一次只嘗試接近一個限制的理論上限，並與其他限制保持約一個數量級的差距，除非實驗顯示您的用途運作良好。如果需要的資源超出單一叢集可支援的範圍，請建立更多叢集。如要瞭解 Kubernetes 可擴充性，請參閱「Kubernetes 可擴充性門檻」一文。

命名空間命名標準化

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

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

在租戶命名空間中，為每個不同的工作負載建立租戶專屬的 Google 服務帳戶。這項功能可確保租戶能管理各自命名空間中擁有/部署的工作負載服務帳戶，提供某種程度的安全性。每個命名空間的 Kubernetes 服務帳戶，都會透過 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專案中建立的記錄檔值區。

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

檢查清單摘要

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

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

後續步驟