KubeZoo：字節(jié)跳動輕量級多租戶開源解決方案

　　KubeZoo是由字節(jié)跳動自研的Kubernetes輕量級多租戶項目，它基于協(xié)議轉(zhuǎn)換的核心理念，在一個物理的Kubernetes Master上虛擬多個租戶，具備輕量級、兼容原生API、無侵入等特點，是一種打造Serverless Kubernetes底座的優(yōu)良方案。

　　從 2014 年開源至今，Kubernetes 已經(jīng)成為容器編排領域的事實標準，為開發(fā)者進行應用編排、提高資源利用率提供了極大便利。但面對集群管理，如何提升多租戶集群管理能力仍是困擾開發(fā)者和企業(yè)的一個關鍵問題。

　　以私有云為例。在這類環(huán)境中，企業(yè)的云原生基礎設施大多被微服務平臺、大數(shù)據(jù)、機器學習和存儲云原生等平臺占據(jù)，它們對上層用戶屏蔽 Kubernetes 的細節(jié)，呈現(xiàn)的是各自的接口和體驗。

　　雖然屏蔽底層有助于開發(fā)人員更專注于業(yè)務本身，但現(xiàn)實中仍有不少業(yè)務需要獨立的 Kubernetes 構建其系統(tǒng)所運行的環(huán)境設施，這些業(yè)務通常形態(tài)各異，資源體量小，但是卻要求獨占和完整的 Kubernetes。如何提供和管理這些小 Kubernetes 集群成為一個痛點，Cluster API 提供了集群自動化管理的能力，但是對基礎設施成熟度有較高的要求。

　　無獨有偶，在公有云上，各大云供應商托管著客戶成千上萬的集群，但是超過 100 個 ECS 節(jié)點的集群寥寥無幾。事實上，絕大部分 Kubernetes 集群的規(guī)格都非常之小，幾十核、上百核是常態(tài)。相比計算資源，托管版的 Kubernetes 的控制面占據(jù)了一定的資源，如高可靠的 Master 和 etcd 等等，這些免費的組件占據(jù)了相當比例的成本。

　　因此，增強 K8s 集群控制面的多租戶能力已經(jīng)成了一個現(xiàn)實問題：

　　從運維視角來看，即使 Kubernetes 具備自動化的集群生命周期管理，但是各項控制面組件的維護、升級，和周邊龐雜設施的交互，對開發(fā)人員來說仍是棘手的問題;

　　隨著機器學習任務、大數(shù)據(jù)平臺接入云原生基礎設施，基于 Kubernetes 打造的系統(tǒng)底座需要提供更快速、更低成本、更高效的管理 Kubernetes 集群的能力。

　　Kubernetes 多租戶模型簡介

　　伴隨云原生技術的發(fā)展和推廣，社區(qū)內(nèi)已經(jīng)先后涌現(xiàn)出多種方案，提供了不同層次的多租戶能力，并在特定場景下具備一定優(yōu)勢。此前社區(qū) Kubernetes Multi-Tenancy Working Group 曾進行了梳理歸納，定義了如下 3 種 Kubernetes 多租戶模型。

　　Namespace as a Service(NaaS)

　　Namespace 是 Kubernetes 原生的資源，提供了原生的基于命名空間的多租戶能力。眾所周知，Kubernetes 的對象分為兩種類型：

　　第一種是 namespace scope，比如常見的 deployment、pod 和 pvc 等，這類資源通常比較常用，為一般的用戶所使用;

　　第二種是 cluster scope，比如 pv、clusterrole 等，這類資源通常需要更高的權限，一般由管理員管理。

　　由于這些比較通用的資源可以劃分到某個 namespace 下，而 namespace 具備一定的權限和視圖隔離能力，管理員可以通過為不同的租戶分配不同的 namespace，并合理的設定租戶的 RBAC、Network Policy 和 Quota，實現(xiàn)租戶之間資源和視圖一定程度的隔離。

　　這種方案的優(yōu)點是不同租戶共享相同的控制面和計算資源池，運維成本低、管理高效，比較適合僅依賴 namespace scope API 的私有云場景;缺點則是多個租戶共享一個 K8s 集群，每個租戶被限定在自己的 namespace，租戶一般只能訪問 namespace scope 的資源，通常不具備 cluster scope 的權限，故 API 訪問很受限。

　　Cluster as a Service(CaaS)

　　顧名思義，Cluster as a Service 則是為每個租戶分配一個完整的集群，包括獨占的控制面和數(shù)據(jù)面。如此每個租戶都有獨立的 Master 和計算節(jié)點，該 Master 可以通過 Cluster API 等方式完成租戶 Master 的生命周期管理。

　　在實現(xiàn)上，Master 可以容器化部署，也可以部署在虛擬機或者物理機上;而計算節(jié)點通常為虛擬機或者物理機。如此每個租戶擁有一套獨立的控制面組件(apiserver, controller-manager, scheduler, etcd)，租戶間完全隔離，互相不干擾，安全性和隔離性得到絕對的保障;缺點為每個租戶的管理成本和資源成本較高。

　　Control Planes as a Service(CPaaS)

　　不難看出，NaaS 多租戶之間完全共享控制面和數(shù)據(jù)面，而 CaaS 的控制面和數(shù)據(jù)面是完全隔離的。那么有沒有一種介于此的中間形態(tài)，在隔離性和靈活性之間能得到良好的權衡?

　　這就是社區(qū)提出的第三種模式：Control Planes as a Service，在此形態(tài)下每個租戶擁有獨立的 Master(又稱為 virtual cluster)，因而它們在控制面上是獨占和隔離的，也可以擁有靈活的 K8s 版本;但是在數(shù)據(jù)面上，各個租戶共享相同的資源池。

　　這種形態(tài)典型的代表是 Virtual Cluster 項目，它在一個名為 supercluster 的 K8s 集群上容器化部署租戶的控制面，因而各個租戶擁有完整而隔離的 Kubernetes Master，可以自主的管理 namespace scope 和 cluster scope 的各類資源;但是在計算資源上，各個租戶共享 supercluster 的計算資源池，雖然在數(shù)據(jù)面未達到徹底隔離的形態(tài)，但是勝在共享統(tǒng)一的資源池，利于提升資源效率和靈活性。

　　小結

　　綜上深入分析，不難發(fā)現(xiàn)不同多租戶方案各有側(cè)重的場景，都嘗試在成本、效率和安全之間進行權衡。上述方案一定程度提供了路徑手段，但是依舊不夠完美。

　　在字節(jié)跳動業(yè)務發(fā)展過程中，由 K8s 集群控制面的多租戶功能帶來的諸多困擾同樣存在，基礎架構團隊期望近乎零成本、兼容 Kubernetes 原生 API 的多租戶能力：一方面，它要具備極低的資源和運維成本、秒級的生命周期管理、原生的 API 和安全能力，能穩(wěn)定支撐業(yè)務發(fā)展;另一方面，它也能面向團隊技術演進方向 Serverless 展開設計，更好地兼容未來。

　　為了達成這個目標，基礎架構團隊推出了輕量級多租戶解決方案 KubeZoo，并把它開放給社區(qū)。

　　KubeZoo 簡介

　　本章重點介紹 KubeZoo 的架構和核心思想，包括總體架構、租戶管理、控制面多租戶(協(xié)議轉(zhuǎn)換)和數(shù)據(jù)面多租戶等等。

　　理念簡介

　　KubeZoo 基于“協(xié)議轉(zhuǎn)換”核心理念實現(xiàn)控制面多租戶功能，通過在資源的 name/namespace 等字段上增加租戶的唯一標志，從而解決不同租戶的同名資源在同一個上游物理的 K8s 沖突問題。

　　如前文所述，Kubernetes 的資源大致可以分為兩大類型：namespace scope 和 cluster scope。其中，對于 namespace scope 的資源，同一種資源在相同的 namespace 下命名唯一;對于 cluster scope 類型的資源，同一種資源的命名全局唯一，不可重復。

　　在同一個 Kubernetes 下，開發(fā)人員可以在 namespace scope 資源的 namespace 上增加租戶的前綴，在 cluster scope 資源的 name 上增加前綴，通過保證不同租戶的前綴不一樣，最終解決不同租戶在資源命名重復沖突的問題，這種思想和 Linux 內(nèi)存管理有些異曲同工之妙。

　　架構概覽

　　KubeZoo 作為一個獨立的服務部署于 Kubernetes 前端，對用戶提供統(tǒng)一的訪問入口，它接受用戶的請求，并將請求經(jīng)過處理后轉(zhuǎn)發(fā)給后端的 Kubernetes，進而由上游的集群真正完成資源的表達，最終將結果返回給用戶。

　　在具體結構上，KubeZoo 由一個 kubezoo-server 進程和 etcd 組成，其中 KubeZoo 作為無狀態(tài)組件，可以以多主的形式部署，具備良好的橫向擴容能力，etcd 主要提供租戶的元信息的存儲，就數(shù)據(jù)體量上非常輕，同時訪問頻率也較低，理論上不存在性能相關瓶頸。

　　KubeZoo 重點提供了控制面的隔離，對數(shù)據(jù)面的實現(xiàn)并沒有相關的約束。如果控制面為常規(guī)的 Kubernetes 節(jié)點池，那么數(shù)據(jù)是共享的，隔離性等同 CPaaS;如果數(shù)據(jù)面采用云上的彈性容器服務，如 AWS Fargate、Aliyun ECI、火山引擎 VCI 等，則可以借用公有云的基礎設施完成計算、存儲和網(wǎng)絡的隔離和表達能力，同時具備良好的彈性能力，這也是本文推薦的后端數(shù)據(jù)面載體。

　　租戶管理

　　KubeZoo 內(nèi)置 Tenant 對象，用于描述租戶的基本信息，相關的結構體如下。其中 name 是必須字段，全局唯一，長度固定 6 位字符串(包括字符或者數(shù)字)，理論上可以管理 2176782336 個租戶(36 ^ 6)，Tenant 對象存儲于 KubeZoo 的 etcd 中：

　　KubeZoo 提供證書簽發(fā)的功能，管理員擁有 Tenant 生命周期管理的能力。每當管理員創(chuàng)建租戶后，即為該租戶簽發(fā)一份 X509 證書，證書中包含了租戶的信息，如名字等等，并寫入 annotations;同時將每個租戶內(nèi)置的 namespace、rbac 等同步到上游的 K8s 中。

　　每當管理員刪除租戶時，會觸發(fā)租戶資源回收，KubeZoo 刪除上游 K8s 該租戶的所有資源，并清理 KubeZoo 側(cè)的元信息。

　　由于租戶的生命周期管理本質(zhì)上是 Tenant 對象元信息的管理、證書簽發(fā)和資源同步，因而過程簡潔，無需創(chuàng)建物理的 Master / etcd 和計算資源池，因而其具備輕量級、秒級的海量租戶生命周期管理能力。

　　安全設計

　　認證

　　KubeZoo 支持證書(X509)和 ServiceAccount 兩種類型的憑據(jù)。這兩種憑據(jù)均屬于 PKI(Public key infra)token，故 KubeZoo 只需要和上游 K8s Master 共用相同的 CA 即可實現(xiàn)憑據(jù)的認證功能，并提取出租戶信息。

　　對于管理員簽發(fā)的 X509 證書，每當創(chuàng)建租戶時，會將 Subject.OrganizationalUnit 字段設置為租戶名稱，進而完成證書的簽發(fā)。每當 KubeZoo 收到租戶的請求時，首先認證證書的有效性，進而解析證書中 OrganizationalUnit 字段，判斷租戶的真實性。

　　對于租戶簽發(fā)的 Service Account(SA) 證書，由于其本質(zhì)上是 jwt token，解析后包含了 namespace 字段，因為上游 K8s 集群中租戶的 namespace 已經(jīng)包含了租戶信息前綴，故租戶簽發(fā)的 SA 同樣包含了租戶信息，KubeZoo 首先認證 jwt token 的有效性，進而從 namespace 中解析出租戶信息，進而判斷租戶的真實性。

　　流量管理

　　KubeZoo 基于令牌桶的原理實現(xiàn)租戶的流控管理，包括租戶流量隔離，即租戶互不干擾，惡意租戶(短時間內(nèi)發(fā)送大量 API 請求)不會影響其他租戶;租戶流量加權，即允許管理員為不同租戶設置不同權重，允許高優(yōu)租戶發(fā)送更多并發(fā)請求。

　　管理員創(chuàng)建租戶時通過在 Tenant annotation 中的 tce.kubezoo/max-requests-inflight 字段設置來自該租戶請求的最大并發(fā)數(shù)。KubeZoo 會統(tǒng)計當前租戶的并發(fā)數(shù)(令牌數(shù))，每當收到來自某個租戶的請求時，KubeZoo 會查看該租戶下的 bucket 是否有令牌，如果有，則拿取一個并處理相關的需求，請求結束后歸還令牌;如果并發(fā)數(shù)超過上限，即令牌為空，則拒絕該請求。

　　總結

　　本文 KubeZoo 基于協(xié)議轉(zhuǎn)換的理念為 Kubernetes 多租戶提供了一種新的思路，相比已有的方案，它具備輕量級、兼容原生 API 、無侵入等特點，或是一種打造 Serverless K8s 底座的優(yōu)良方案。