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

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

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

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

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

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

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

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

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

　　Kubernetes 多租戶模型簡(jiǎn)介

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

　　Namespace as a Service(NaaS)

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

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

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

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

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

　　Cluster as a Service(CaaS)

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

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

　　Control Planes as a Service(CPaaS)

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

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

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

　　小結(jié)

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

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

　　為了達(dá)成這個(gè)目標(biāo)，基礎(chǔ)架構(gòu)團(tuán)隊(duì)推出了輕量級(jí)多租戶解決方案 KubeZoo，并把它開放給社區(qū)。

　　KubeZoo 簡(jiǎn)介

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

　　理念簡(jiǎn)介

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

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

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

　　架構(gòu)概覽

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

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

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

　　租戶管理

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

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

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

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

　　安全設(shè)計(jì)

　　認(rèn)證

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

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

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

　　流量管理

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

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

　　總結(jié)

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