本文已超過一年。較舊的文章可能包含過時的內容。檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 的三種租戶模型

作者：Ryan Bezdicek (Medtronic), Jim Bugwadia (Nirmata), Tasha Drew (VMware), Fei Guo (Alibaba), Adrian Ludwin (Google) |

Kubernetes 叢集通常由組織中的多個團隊使用。在其他情況下，Kubernetes 可用於向終端使用者交付應用程式，需要跨不同組織的使用者對資源進行分段和隔離。安全地共享 Kubernetes 控制平面和工作節點資源可以在這兩種情況下最大限度地提高生產力並節省成本。

Kubernetes 多租戶工作組的章程是定義 Kubernetes 的租戶模型，並使其更容易實現與租戶相關的使用案例。這篇來自工作組成員的部落格文章描述了三種常見的租戶模型，並介紹了相關的工作組專案。

我們也將在我們的 Kubecon EU 2021 小組會議 多租戶 vs. 多叢集：何時應該使用哪個？ 上介紹此內容並討論不同的使用案例。

命名空間即服務

使用命名空間即服務模型，租戶共享一個叢集，並且租戶工作負載僅限於分配給租戶的一組命名空間。叢集控制平面資源（如 API 伺服器和排程器）以及工作節點資源（如 CPU、記憶體等）可供所有租戶使用。

為了隔離租戶工作負載，每個命名空間還必須包含

使用此模型，租戶共享叢集範圍的資源，如 ClusterRoles 和 CustomResourceDefinitions (CRD)，因此無法建立或更新這些叢集範圍的資源。

階層式命名空間控制器 (HNC) 專案透過允許使用者在命名空間下建立其他命名空間，並在命名空間階層中傳播資源，從而更輕鬆地管理基於命名空間的租戶。這允許租戶自助服務命名空間，而無需叢集範圍的權限。

多租戶基準測試 (MTB) 專案提供基準測試和命令列工具，執行多項組態和執行階段檢查，以報告租戶命名空間是否已正確隔離，以及是否已實作必要的安全控制。

叢集即服務

使用叢集即服務使用模型，每個租戶都獲得自己的叢集。此模型允許租戶擁有不同版本的叢集範圍資源，如 CRD，並提供 Kubernetes 控制平面的完全隔離。

租戶叢集可以使用 Cluster API (CAPI) 等專案進行佈建，其中管理叢集用於佈建多個工作負載叢集。工作負載叢集分配給租戶，租戶可以完全控制叢集資源。請注意，在大多數企業中，中央平台團隊可能負責管理必要的附加服務（如安全和監控服務），以及提供叢集生命週期管理服務（如修補和升級）。租戶管理員可能被限制修改集中管理的服務和其他關鍵叢集資訊。

控制平面即服務

在叢集即服務模型的變體中，租戶叢集可能是虛擬叢集，其中每個租戶都獲得自己的專用 Kubernetes 控制平面，但共享工作節點資源。與其他形式的虛擬化一樣，虛擬叢集的使用者看不到虛擬叢集與其他 Kubernetes 叢集之間有任何顯著差異。這有時稱為 Control Planes as a Service (CPaaS)。

此類型的虛擬叢集共享工作節點資源和獨立於工作負載狀態的控制平面組件，如排程器。其他工作負載感知控制平面組件（如 API 伺服器）是按租戶建立的，以允許重疊，並且使用其他組件來同步和管理跨租戶控制平面和底層共享叢集資源的狀態。使用此模型，使用者可以管理自己的叢集範圍資源。

虛擬叢集 專案實作此模型，其中 超級叢集 由多個 虛擬叢集 共享。Cluster API Nested 專案正在擴展這項工作以符合 CAPI 模型，允許使用熟悉的 API 資源來佈建和管理虛擬叢集。

安全性考量

雲原生安全性涉及不同的系統層和生命週期階段，如 CNCF SIG Security 的 雲原生安全性白皮書 中所述。如果未在所有層和階段實作適當的安全措施，Kubernetes 租戶隔離可能會受到損害，並且一個租戶的安全漏洞可能會威脅到其他租戶。

任何 Kubernetes 新使用者都必須意識到，新的上游 Kubernetes 叢集的預設安裝是不安全的，您需要投入精力來強化它，以避免安全問題。

至少需要以下安全措施

  • 映像掃描：容器映像漏洞可能被利用來執行命令和存取其他資源。
  • RBAC：對於命名空間即服務，使用者角色和權限必須在每個命名空間層級正確配置；對於其他模型，可能需要限制租戶存取集中管理的附加服務和其他叢集範圍的資源。
  • 網路政策：對於命名空間即服務，建議使用拒絕所有輸入和輸出流量的預設網路政策，以防止跨租戶網路流量，並且也可以作為其他租戶模型的最佳實踐。
  • Kubernetes Pod 安全標準：為了強制執行 Pod 強化最佳實踐，建議將 Restricted 政策作為租戶工作負載的預設政策，僅在需要時配置排除項。
  • Kubernetes 的 CIS 基準：應使用 Kubernetes 的 CIS 基準指南來正確配置 Kubernetes 控制平面和工作節點組件。

其他建議包括使用

  • 政策引擎：用於組態安全最佳實踐，例如僅允許受信任的登錄檔。
  • 執行階段掃描器：偵測和報告執行階段安全事件。
  • 基於 VM 的容器沙箱：用於更強大的資料平面隔離。

雖然無論租戶模型如何都需要適當的安全性，但在共享叢集中沒有基本的安全控制（如 Pod 安全性）會為攻擊者提供損害租戶模型的方法，並可能存取跨租戶的敏感資訊，從而增加整體風險概況。

摘要

2020 年 CNCF 調查顯示，自 2016 年以來，生產環境 Kubernetes 的使用量增加了 300% 以上。隨著越來越多的 Kubernetes 工作負載轉移到生產環境，組織正在尋找跨團隊共享 Kubernetes 資源的方法，以提高敏捷性和節省成本。

命名空間即服務租戶模型允許共享叢集，因此可以提高資源效率。但是，它需要適當的安全配置，並且由於所有租戶共享相同的叢集範圍資源，因此存在限制。

叢集即服務租戶模型解決了這些限制，但具有更高的管理和資源開銷。

控制平面即服務模型提供了一種共享單個 Kubernetes 叢集資源的方法，也讓租戶可以管理自己的叢集範圍資源。共享工作節點資源提高了資源效率，但也暴露了共享叢集存在的跨租戶安全性和隔離問題。

在許多情況下，組織將使用多個租戶模型來解決不同的使用案例，因為不同的產品和開發團隊將有不同的需求。遵循安全和管理最佳實踐，例如應用 Pod 安全標準 並且不使用 default 命名空間，可以更輕鬆地從一個模型切換到另一個模型。

Kubernetes 多租戶工作組 創建了多個專案，如 階層式命名空間控制器、虛擬叢集 / CAPI Nested 和 多租戶基準測試，以更輕鬆地佈建和管理多租戶模型。

如果您對多租戶主題感興趣，或想分享您的使用案例，請加入我們即將舉行的 社群會議 或在 Kubernetes slack 上的 wg-multitenancy 頻道上聯繫我們。