在這篇文章中，CNCF 官方博客報道了阿里雲Kubernetes團隊如何利用一組名爲“Virtual Cluster”的插件對社區中的租戶設計進行擴展，並分享了他們如何以此來基於上游 Kubernetes 代碼構建“強多租戶“能力。目前，阿里雲 Kubernetes 團隊正在開源這些K8s插件，並在即將到來的KuberCon大會上將其貢獻給Kubernetes社區。
內容簡介
在阿里雲，他們的 Kubernetes 團隊正利用一套互聯網級規模的集羣向作爲最終用戶（阿里巴巴的衆多業務部門）提供服務。在這種情況下，每個部門（最終用戶），實際上都成爲該K8s集羣的“租戶”，而巨大的需求量也使 K8s 原本的弱租戶機制難以應對。
所以，阿里雲的 Kubernetes 團隊給自己提出了一項挑戰：要試圖在不修改任何Kubernetes代碼的前提下構建“Virtual Cluster”多租戶試圖，並且緩解Kubernetes APIServer與資源模型的工作壓力。利用這套架構，每個租戶都將分配一個專用的K8s控制平面（kube-apiserver + kube-controller-manager）外加幾個“Virtual Node”（純節點API對象，但沒有相應的kubelet）。通過這種方式， Kubernetes 集羣管理員不僅不需要擔心命名或者節點衝突，同時也能保證來自不同租戶的工作負載仍然運行在同一個底層“Super Cluster”當中，從而實現理想的資源利用率。這種設計在阿里雲 Kubernetes 團隊幾個月前向社區提交的《Virtual Cluster 提案（virtual cluster proposal）》中已有詳盡介紹，並收到了大量反饋。
需要指出的是，雖然該設計中引入的“租戶 Master 節點（tenant master）”是一個新概念，但虛擬集羣（Virtual Cluster）本身實際上是對K8s社區中現有的、基於命名空間（Namespace） 機制的多租戶設計的一種架構擴展，在下文中我們將稱後者爲“命名空間組（namespace group）設計”。 此外，虛擬集羣的完全實現，同樣依賴於命名空間組下層的資源隔離機制（比如網絡和資源隔離能力），我們期待着這一問題能夠在 Kubernetes WG-multitenancy 中得到進一步解決。
如果大家希望瞭解關於Virtual Cluster設計的更多細節信息，請參閱之前的《Virtual Cluster 提案》。而在本文，我們將重點關注虛擬集羣背後的更高層次設計理念，並詳盡說明如何利用“租戶集羣”視圖來對命名空間組進行擴展，以及爲何這一擴展將對Kubernetes多租戶場景產生重要價值。
背景介紹
本節將簡要回顧命名空間組多租戶提案的基本架構。
下圖摘自 Kubernetes 社區早期的《K8s 多租戶興趣小組的工作介紹（K8s Multi-tenancy WG Deep Dive）》，如圖一所示，其解釋瞭如何利用命名空間（Namespace）這一概念來組織 K8s 租戶的資源。
圖一：命名空間組多租戶架構
在上述基於命名空間組的多租設計中，所有租戶共享相同的K8s 訪問入口，即K8s apiserver，來使用租戶的資源。他們的賬戶、被分配的命名空間以及資源隔離策略，都在一個稱作 租戶 CRD 的對象中進行指定，而各CRD對象則由租戶管理員負責管理。租戶用戶視圖被限制在各個租戶持有的命名空間之內。租戶資源隔離策略的基本定義爲，禁止租戶之間進行直接通信，並保護租戶Pod免受攻擊影響。這些策略通過Kubernetes的原生資源隔離機制實現，包括RBAC、Pod安全策略、網絡策略、准入控制以及沙箱運行時等。我們可以配置多個安全配置文件以實現不同級別的隔離要求。此外，資源配額、退費以及計費等都在租戶層級上實現。
虛擬集羣如何擴展視圖層
從概念上講，虛擬集羣在命名空間組之上提供了一個重要的視圖層擴展。大家可以參考[virtual cluster]中的技術細節說明。在這個設計中，租戶管理員仍然需要使用命名空間組中的同一租戶CRD 來指定租戶資源供應方（即真實集羣）的賬戶、命名空間以及資源隔離策略。
圖二：由虛擬集羣提供的視圖層擴展
如圖二所示，由於有了新的虛擬集羣視圖層，現在租戶用戶可以擁有不同的訪問點與租戶資源視圖。租戶不再需要直接訪問真實集羣以查看租戶的命名空間，而是同專屬的租戶 Master 節點（tenant master）進行交互以使用租戶的資源，同時持有專屬的、完整的 K8s視圖。所有租戶請求皆由 sync-manager（Syncer） 自動同步至真實集羣，並由後者根據租戶CRD中設置對應的資源隔離策略，根據租戶用戶的行爲創建相應的自定義資源。所以說，虛擬集羣的核心設計，在於它主要將來自分租戶看到的視圖從命名空間變更爲真實的、租戶專屬的APIserver。而從真實集羣的角度來看，租戶控制器在響應租戶CRD時觸發的也是完全相同的工作流程。
虛擬集羣視圖擴展的優勢
在租戶用戶的現有命名空間視圖之上使用虛擬集羣視圖，能夠帶來以下助益：
- 爲租戶用戶提供靈活便捷的租戶資源管理機制。例如，嵌套命名空間層級（如圖三（a）所示）能夠輕鬆解決命名衝突、命名空間可見性、以及命名空間組解決方案[Tenant Concept]中的子分區租戶資源等問題。通常情況下，我們很難在不修改K8s代碼的前提下支持嵌套命名空間。而利用虛擬集羣視圖，我們可以在租戶集羣中創建命名空間，同時在真實集羣中建立對應的命名空間組，從而提供與嵌套命名空間一致的用戶體驗。
如上圖（b）所示，租戶用戶可以在租戶主節點中創建自助命名空間，而無需擔心與其他租戶的命名產生衝突。在將租戶命名空間添加到真實集羣的命名空間組時，sync-manager將負責解決這類衝突。租戶A的用戶永遠無法查看租戶B用戶的命名空間，因爲他們訪問的實際上是不同的主節點。這種方式還能夠爲租戶輕鬆提供不同的用戶定製策略，且此類策略僅在租戶集羣中生效。
-
帶來更強的租戶隔離性與安全性。這是因爲新機制避免了因多租戶用戶共享同一K8s主節點而導致的某些問題。例如DoS攻擊、各租戶間API訪問速率控制、以及租戶控制器隔離等等。
-
允許租戶用戶在租戶主節點當中創建集羣範圍對象，且不會影響到其他租戶。例如，租戶用戶現在可以在租戶主機中自由創建CRD、ClusterRole/ClusterRoleBinding、PersistentVolume、ResourceQuota、ServiceAccount以及NetworkPolicy，而不必擔心與其他租戶發生衝突。
-
減輕了真實集羣主節點（Super Master）的可擴展性壓力。首先，RBAC規則、策略、以及真實集羣所管理的用戶賬戶，都可以被轉移至租戶主節點，進而實現各自獨立擴展。第二，租戶控制器與操作器將訪問多個租戶主節點，而非單一真實集羣，這同樣使得獨立擴展成爲可能。
-
降低爲租戶用戶創建用戶的難度。以往，如果租戶用戶希望將一部分租戶資源公開給其他用戶（例如，團隊負責人希望添加新成員併爲其分配對應團隊資源），那麼租戶管理員必須重新創建所有用戶。一旦租戶管理員面對的是大型組織當中多達數百個類似團隊的同類要求，那麼租戶用戶的創建工作可能成爲沉重的負擔。虛擬集羣將這種負擔從租戶管理員處完全轉移至租戶用戶處。
侷限性
由於虛擬集羣的訴求在於擴展多租戶視圖選項，同時防止因共享服務器而引發的相關問題，因此其也繼承了命名空間組解決方案在租戶Kubernetes節點組件感知方面存在的相同侷限和挑戰。目前需要增強的節點組件包括但不限於：
-
Kubelet與CNI-plugin。二者需要實現租戶感知能力，從而支持與VPC類似的強大網絡隔離能力。
- 例如，如果某個pod在另一VPC中與節點隔離開來，那麼該如何實現 ReadinessProbe 和 LivenessProve？目前，我們已經就這個問題與SIG-Node開展上游合作。
-
Kube-proxy/Kube-dns。二者需要實現租戶感知能力，從而實現租戶服務的集羣-IP類型。
-
工具。例如，監控工具應具備租戶感知能力，從而避免泄露租戶信息。性能調優工具應具備租戶感知能力，以避免在不同租戶之間產生意外的性能干擾。
當然，虛擬集羣還需要額外資源以允許每個租戶運行自己的租戶主節點。目前，某些用例還無法支持這種需求。
總結
虛擬集羣利用一種用戶友好 的”集羣視圖“對命名空間組進行了擴展，並利用 K8s 自身的底層資源隔離機制以及社區中的現有租戶CRD與控制器，希望藉此有針對性地提升多租戶羣體的使用體驗。
總體來講，我們認爲虛擬集羣與基於命名空間的多租戶機制相結合，能夠爲生產集羣中的各類Kubernetes多租戶用例提供全面的解決方案。我們也在積極努力，希望將這款插件貢獻給上游社區。
原文作者：
郭飛，阿里雲容器平臺資深技術專家。
張磊，阿里雲容器平臺高級技術專家