多用戶群叢集

本頁面說明 Google Kubernetes Engine (GKE) 上的多用戶群叢集，其中包括單一機構內不同使用者共用的叢集，以及軟體即服務 (SaaS) 應用程式每位客戶專用執行個體共用的叢集。多用戶群叢集是管理多個單一用戶群叢集的替代方案。

本頁面也會概述可用來管理多用戶群叢集的 Kubernetes 和 GKE 功能。

什麼是多用戶群架構？

多用戶群叢集是由多位使用者和/或工作負載共用，而這些使用者和/或工作負載就是「用戶群」。多用戶群叢集的經營者必須將用戶群彼此隔開，藉以降低遭駭用戶群或惡意用戶群對叢集和其他用戶群造成的損害。此外，叢集資源也需平均分配給所有用戶群。

規劃多用戶群架構時，應考量 Kubernetes 中各類資源隔離層，包括：叢集、命名空間、節點、Pod 和容器。此外也應顧及在用戶群之間共用不同資源類型的安全疑慮。舉例來說，在相同節點上排定來自不同用戶群的 Pod 可減少叢集需要的機器數量。另一方面，您可能需要防止系統共置特定的工作負載。例如，您可禁止機構外部不受信任的程式碼與處理機密資訊的容器在同一節點上運作。

雖然 Kubernetes 無法完全保證能安全隔離不同的用戶群，但所提供的功能應足以因應特定用途需求。您可以將每個用戶群及 Kubernetes 資源分到各自的命名空間，接著使用政策來強制隔離用戶群。政策通常會依命名空間劃分，且可用來限制 API 存取權、資源使用量以及容器能執行的動作。

多用戶群叢集的用戶群可以共用下列資源：

與操作多個單一用戶群叢集相比，操作多用戶群叢集具有更多優點：

  • 減輕管理負擔
  • 減少資源分散
  • 新用戶群可以立即建立叢集

多用戶群架構應用實例

本節說明如何針對各種多用戶群用途設定叢集。

企業多用戶群架構

在企業環境中，叢集用戶群是指機構內的不同團隊。每個用戶群通常都有對應的命名空間，這是因為每個用戶群對應一個叢集，或是每個用戶群對應一個Google Cloud 專案的多用戶群替代模型會更難管理。命名空間內的網路流量沒有任何限制，但不同命名空間之間的網路流量必須明確允許。您可以使用 Kubernetes 網路政策強制執行這些政策。

叢集使用者可根據各自的權限分成三個不同角色：

叢集管理員
這個角色的適用對象是在整個叢集中管理所有用戶群的管理員。叢集管理員可以建立、讀取、更新及刪除任何政策物件，且可建立命名空間並將其指派給命名空間管理員。
命名空間管理員
這個角色的適用對象是特定單一用戶群的管理員。命名空間管理員可以管理自己命名空間中的使用者。
開發人員
這個角色的成員可以建立、讀取、更新及刪除命名空間中的非政策物件，例如 Pod、工作和 Ingress。開發人員只有在有權存取的命名空間內才擁有這些權限。

如要瞭解如何為企業機構設定多個多租戶叢集，請參閱「企業多租戶的最佳做法」。

SaaS 供應商多用戶群架構

SaaS 供應商叢集用戶群是指應用程式每位客戶專用的執行個體，以及 SaaS 的控制層。為了充分運用依命名空間劃分的政策，您必須將應用程式執行個體歸納至各自的命名空間，並以同樣方式處理 SaaS 控制層的元件。使用者無法直接與 Kubernetes 控制層互動，但可透過 SaaS 介面與 Kubernetes 控制層互動。

舉例來說，網誌平台可以在多用戶群叢集上運作。在這種情況下，用戶群指的是每位客戶的網誌執行個體和平台控制層。系統會在不同的命名空間中執行平台控制層和每個託管網誌，而客戶可以透過平台介面建立和刪除網誌、更新網誌軟體版本，但無法清楚瞭解叢集的運作方式。

強制執行多用戶群政策

GKE 和 Kubernetes 提供了幾項可用來管理多用戶群叢集的功能。以下各節將概述這些功能。

存取權控管

GKE 有兩個存取權控管系統，一個是 Identity and Access Management (IAM)，另一個是角色型存取權控管 (RBAC)。IAM 是 Google Cloud的存取權控管系統，用於管理 Google Cloud資源的驗證和授權作業。您可以使用 IAM 授予使用者 GKE 和 Kubernetes 資源的存取權。Kubernetes 內建的 RBAC 則可針對叢集內的特定資源和操作授予精細的權限。

如要進一步瞭解上述選項和使用時機，請參閱存取權控管總覽。

如要瞭解如何使用上述存取權控管系統，請參閱 RBAC 使用指南和 IAM 使用指南。

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

網路政策

叢集網路政策可讓您掌控叢集 Pod 之間的通訊。這些政策會指定 Pod 可以進行通訊的命名空間、標籤和 IP 位址範圍。

如需在 GKE 上啟用強制執行網路政策功能的操作說明，請參閱網路政策使用指南。

如要瞭解如何編寫網路政策，請按照網路政策教學課程進行操作。

資源配額

資源配額會管理命名空間中物件使用的資源量。您可以根據 CPU 和記憶體用量或物件數量來設定配額。資源配額可確保用戶群使用的叢集資源不會超過指定的份額。

詳情請參閱資源配額說明文件。

以政策為依據的 Pod 許可控制

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

GKE 支援下列類型的許可控制：

Pod 反相依性

您可以使用 Pod 反相依性規則，防止系統將來自不同用戶群的 Pod 排定在同一節點上。反相依性限制是以 Pod 標籤為依據。舉例來說，下方 Pod 規格所述的 Pod 含有 "team": "billing" 標籤，而規格中的反相依性規則可防止系統將這個 Pod 與沒有標籤的 Pod 排定在一起。

apiVersion: v1
kind: Pod
metadata:
  name: bar
  labels:
    team: "billing"
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: "kubernetes.io/hostname"
        labelSelector:
          matchExpressions:
          - key: "team"
            operator: NotIn
            values: ["billing"]

這種方法的缺點在於惡意使用者可以將 team: billing 標籤套用至任意 Pod，藉此規避這項規則。如果只使用 Pod 反相依性規則，就無法在有不受信任用戶群的叢集上安全地強制執行政策。

詳情請參閱 Pod 反相依性說明文件。

包含 taint 和容許條件的專屬節點

節點 taint 是另一種控管工作負載排程的方法。您可以使用節點 taint 保留專用節點，以供特定用戶群使用。舉例來說，你可以將搭載 GPU 的節點專門留給工作負載需要 GPU 的特定用戶群使用。如果是 Autopilot 叢集，節點容許度僅支援工作負載分離。節點自動佈建功能會視需要自動新增節點汙點。

如要專門保留節點集區給特定用戶群使用，請將具有 effect: "NoSchedule" 標籤的 taint 套用至節點集區。如此一來，只有具備相對應容許條件的 Pod 才能排定在節點集區中的節點上。

這種方法的缺點在於惡意使用者可以在自己的 Pod 中新增容許條件，藉此取得專屬節點集區的存取權。如果只使用節點 taint 和容許條件，就無法在有不受信任用戶群的叢集上安全地強制執行政策。

詳情請參閱 Kubernetes 說明文件中的「Taints and Tolerations」。

後續步驟