多用戶群叢集

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

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

什麼是多用戶群架構?

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

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

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

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

與執行多個單一用戶群叢集相比,執行多用戶群叢集具有更多優點:

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

多用戶群架構用途

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

企業多用戶群架構

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

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

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

軟體式服務 (SaaS) 供應商多用戶群架構

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

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

強制執行多用戶群政策

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

存取權控管

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

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

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

網路政策

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

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

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

資源配額

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

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

Pod 安全性政策

PodSecurityPolicies 是一種 Kubernetes API 類型,可用於驗證 Pod 的建立和更新請求。PodSecurityPolicies 會針對 Pod 規格的安全機密欄位定義預設值和需求。您可以建立政策來限制會存取主機檔案系統、網路、PID 命名空間、磁碟區等項目的 Pod 部署作業。

詳情請參閱 PodSecurityPolicies 使用指南

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 的特定用戶群使用。

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

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

如要瞭解如何使用節點 taint 控制排程,請參閱節點 taint 使用指南頁面

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Kubernetes Engine 說明文件