本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 的三種租戶模型
Kubernetes 叢集通常由組織內的多個團隊使用。在其他情況下，Kubernetes 可能用於向終端使用者交付應用程式，需要對來自不同組織的使用者資源進行分段和隔離。安全共享 Kubernetes 控制平面和工作節點資源在這兩種情況下都可以最大限度地提高生產力並節省成本。
Kubernetes 多租戶工作組負責定義 Kubernetes 的租戶模型，並使其更容易操作與租戶相關的用例。這篇來自工作組成員的博文描述了三種常見的租戶模型，並介紹了相關的工作組專案。
我們還將在 Kubecon EU 2021 小組會議上介紹此內容並討論不同的用例，會議主題是 多租戶與多叢集：何時使用哪種？。
名稱空間即服務
使用 *名稱空間即服務* 模型，租戶共享一個叢集，租戶工作負載被限制在分配給租戶的一組名稱空間中。叢集控制平面資源（如 API 伺服器和排程器）以及工作節點資源（如 CPU、記憶體等）可供所有租戶使用。
為了隔離租戶工作負載，每個名稱空間還必須包含
使用此模型，租戶共享叢集範圍的資源，例如 ClusterRole 和 CustomResourceDefinition (CRD)，因此無法建立或更新這些叢集範圍的資源。
分層名稱空間控制器 (HNC) 專案透過允許使用者在名稱空間下建立額外的名稱空間，並在名稱空間層次結構中傳播資源，從而更容易管理基於名稱空間的租戶。這允許租戶進行自助名稱空間，而無需叢集範圍的許可權。
多租戶基準 (MTB) 專案提供基準和命令列工具，該工具執行多項配置和執行時檢查，以報告租戶名稱空間是否正確隔離以及是否實施了必要的安全控制。
叢集即服務
使用 *叢集即服務* 用例模型，每個租戶都有自己的叢集。此模型允許租戶擁有不同版本的叢集範圍資源（如 CRD），並提供 Kubernetes 控制平面的完全隔離。
租戶叢集可以使用 Cluster API (CAPI) 等專案進行預置，其中管理叢集用於預置多個工作負載叢集。一個工作負載叢集分配給一個租戶，租戶對叢集資源擁有完全控制權。請注意，在大多數企業中，中央平臺團隊可能負責管理所需附加服務（如安全和監控服務），並提供叢集生命週期管理服務（如修補和升級）。租戶管理員可能被限制修改中央管理的服務和其他關鍵叢集資訊。
控制平面即服務
在 *叢集即服務* 模型的一個變體中，租戶叢集可能是虛擬叢集，其中每個租戶都有自己專用的 Kubernetes 控制平面，但共享工作節點資源。與其他形式的虛擬化一樣，虛擬叢集的使用者在虛擬叢集和其他 Kubernetes 叢集之間看不到顯著差異。這有時被稱為 控制平面即服務 (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 頻道 聯絡我們。