Kubernetes 缺少的多租戶功能,你可以通過(guò)這些方式實(shí)現(xiàn)

作者 | 葉豐??使用 Kubernetes 時(shí)，用戶往往需要共享使用 Kubernetes 集群（多租戶），以在滿足多團(tuán)隊(duì)、多客戶需求的同時(shí)簡(jiǎn)化運(yùn)維、降低成本。雖然 Kubernetes 本身不直接提供多租戶功能，但它提供了一系列可被用于支持實(shí)現(xiàn)多租戶的功能?；谶@些功能，Kubernetes 社區(qū)涌現(xiàn)了一些實(shí)現(xiàn)多租戶的項(xiàng)目。本文將粗淺談?wù)?Kubernetes 多租戶的現(xiàn)有實(shí)現(xiàn)機(jī)制及優(yōu)化方案，以及針對(duì)多租戶（共享集群）和多集群方案，企業(yè)該如何選擇。Kubernetes 隔離技術(shù) 控制平面隔離 Kubernetes 提供了三個(gè)機(jī)制來(lái)實(shí)現(xiàn)控制平面的隔離：namespace、RBAC 和 quota。Namespace 應(yīng)該是每個(gè) Kubernetes 用戶都接觸過(guò)的概念，它用來(lái)提供獨(dú)立的命名空間。不同命名空間內(nèi)的對(duì)象可以重名。此外，namespace 也限定 RBAC 以及 quota 的作用范圍。RBAC 被用來(lái)限定用戶或者負(fù)載對(duì) API 的訪問(wèn)權(quán)限。通過(guò)設(shè)定合適的 RBAC 規(guī)則，可以實(shí)現(xiàn)對(duì) API 資源的隔離訪問(wèn)。ResourceQuota 可以被用來(lái)限制 namespace 下各類資源的使用上限，以防止某個(gè) namespace 占據(jù)過(guò)多的集群資源而影響其他 namespace 下的應(yīng)用。不過(guò)使用 ResourceQuota 有一個(gè)限制條件，即要求 namespace 下的每個(gè)容器都指定 resource request 和 limit。盡管這三個(gè)機(jī)制能一定程度上提供控制平面的隔離，但無(wú)法徹底解決問(wèn)題。例如 CRD 這類集群范圍的資源，就無(wú)法做到很好的隔離。數(shù)據(jù)平面隔離 數(shù)據(jù)平面的隔離主要分為三個(gè)方面：容器運(yùn)行時(shí)、存儲(chǔ)和網(wǎng)絡(luò)。容器和主機(jī)共享 kernel，應(yīng)用程序或者主機(jī)系統(tǒng)上的漏洞可能被攻擊者所利用，從而突破容器的邊界而攻擊到主機(jī)或者其他容器。解決方法通常是將容器放到一個(gè)隔離的環(huán)境中運(yùn)行，例如虛擬機(jī)或者是用戶態(tài) kernel。前者以 Kata Containers 為代表，后者的代表則是 gVisor。存儲(chǔ)的隔離應(yīng)保證 volume 不會(huì)跨租戶訪問(wèn)。由于 StorageClass 是集群范圍的資源，為防止 PV 被跨租戶訪問(wèn)，應(yīng)指定其 reclaimPolicy 為 Delete。此外，也應(yīng)禁止使用例如 hostPath 這樣的 volume，以避免節(jié)點(diǎn)的本地存儲(chǔ)被濫用。網(wǎng)絡(luò)的隔離通常由 NetworkPolicy 保證。默認(rèn)地，Kubernetes 內(nèi)所有的 pod 相互之間是可以通信的。利用 NetworkPolicy 則可以限定 pod 能夠通信的 pod 范圍，以防止意外的網(wǎng)絡(luò)訪問(wèn)。此外，service mesh 通常能提供更高級(jí)的網(wǎng)絡(luò)隔離功能。多租戶方案選擇 上面提到的控制平面和數(shù)據(jù)平面的隔離功能，都是 Kubernetes 內(nèi)較為獨(dú)立零散的功能，與完整的多租戶方案還有很大差距，想要把它們組織起來(lái)也需要相當(dāng)大的工作量。不過(guò)，Kubernetes 社區(qū)有許多開源項(xiàng)目專門解決多租戶問(wèn)題。從大方向上，它們分為兩類。一類是以 namespace 為邊界劃分租戶，另一類則為租戶提供虛擬控制平面。按 namespace 劃分租戶 Kubernetes 的控制平面隔離中的 RBAC 和 ResourceQuota 均以 namespace 為邊界，因此以 namespace 來(lái)劃分租戶是比較自然的想法。不過(guò)，在現(xiàn)實(shí)中，限定一個(gè)租戶只能使用一個(gè)命名空間存在較大局限性。例如無(wú)法進(jìn)一步以團(tuán)隊(duì)，或者以應(yīng)用為粒度進(jìn)行細(xì)分，造成一定的管理難度。因此 Kubernetes 官方提供了支持層級(jí)化 namespace 的 controller。此外，第三方開源項(xiàng)目例如 Capsule 和 kiosk 提供了更為豐富的多租戶支持。虛擬控制平面 另一種多租戶的實(shí)現(xiàn)方案是為每個(gè)租戶提供一個(gè)獨(dú)立的虛擬控制平面，以徹底隔離租戶的資源。虛擬控制平面的實(shí)現(xiàn)方式通常是為每個(gè)租戶運(yùn)行一套獨(dú)立的 apiserver，同時(shí)利用 controller 將租戶 apiserver 中的資源同步到原 Kubernetes 集群中。每個(gè)租戶只能訪問(wèn)自己對(duì)應(yīng)的 apiserver，而原 Kubernetes 集群的 apiserver 則通常不對(duì)外訪問(wèn)。這類方案的代價(jià)是額外的 apiserver 的開銷，但能夠獲得更為徹底的控制平面隔離。結(jié)合數(shù)據(jù)平面的隔離技術(shù)，虛擬控制平面可以實(shí)現(xiàn)更為徹底和安全的多租戶方案。此類方案以 vcluster 項(xiàng)目為代表。如何選擇？ 選擇按 namespace 劃分租戶還是使用虛擬控制平面應(yīng)取決于多租戶的使用場(chǎng)景。通常來(lái)說(shuō)，按 namespace 劃分租戶的隔離性和自由度會(huì)略有欠缺，但優(yōu)勢(shì)在于輕量。對(duì)于多團(tuán)隊(duì)共享使用的場(chǎng)景，按 namespace 劃分租戶較為合適。而對(duì)于多客戶共享使用的場(chǎng)景，選擇虛擬控制平面通常能夠提供更好的隔離保障。多集群方案 從上文可以看出，共享使用 Kubernetes 集群并非易事；Kubernetes 集群并非天然地支持多租戶，僅僅是提供了一些細(xì)粒度上的功能支持。要想讓 Kubernetes 支持多租戶場(chǎng)景需要其他項(xiàng)目的支持，以同時(shí)在控制平面和數(shù)據(jù)平面上實(shí)現(xiàn)租戶之間的隔離。這使得整個(gè)方案存在不小的學(xué)習(xí)和適應(yīng)成本。因此，目前有許多用戶采用的不是共享集群，而是多集群的方案。相比共享集群，多集群方案有利有弊：優(yōu)勢(shì)是隔離性強(qiáng)、邊界清晰，劣勢(shì)是資源開銷以及運(yùn)維成本較高。由于每個(gè)集群需要獨(dú)立的控制平面和工作節(jié)點(diǎn)，為了提高物理集群的利用率，通常會(huì)選擇在虛擬機(jī)上搭建 Kubernetes 集群。然而傳統(tǒng)的虛擬化產(chǎn)品因?yàn)樾枰櫦案鼮閺V泛的場(chǎng)景，所以功能上往往大而全，并且售價(jià)高昂，并非支撐虛擬化 Kubernetes 集群的最佳選擇。基于此，可以認(rèn)為，支撐虛擬化 Kubernetes 集群理想的虛擬化平臺(tái)應(yīng)該具備以下特點(diǎn)：

• 輕量。不需要顧及到桌面虛擬化等場(chǎng)景，只需專注于服務(wù)器虛擬化，減去一切不必要的功能和開銷。

• 高效。全面使用 virtio 這樣的半虛擬化 I/O 技術(shù)，提高效率。

• 安全。最大程度減少主機(jī)受到攻擊的可能。

• Kubernetes 原生。虛擬化平臺(tái)本身最好是 Kubernetes 集群，以降低學(xué)習(xí)和運(yùn)維成本。

而這些特點(diǎn)，恰恰是 SmartX 前段時(shí)間發(fā)布的 Virtink 虛擬化引擎所具備的。Virtink 基于 Cloud Hypervisor 項(xiàng)目，提供在 Kubernetes 上編排輕量化、現(xiàn)代化虛擬機(jī)的能力。相比基于 QEMU 和 libvirt 的 KubeVirt 項(xiàng)目，Virtink 能為每個(gè) VM 降低至少 100MB 的額外開銷。此外，Virtink 全面使用 virtio，提高 I/O 效率。最后，在安全性方面，Cloud Hypervisor 由 Rust 語(yǔ)言編寫，具備更為安全的內(nèi)存管理。并且通過(guò)減少過(guò)時(shí)和不必要的外設(shè)支持，盡可能地減小暴露給 VM 的可攻擊面，以提高主機(jī)的安全性。更輕量、更高效、更安全的 Virtink 為 Kubernetes in Kubernetes 提供了更為理想和經(jīng)濟(jì)的虛擬化支持，盡最大可能降低虛擬化層的開銷。
此外，針對(duì)在 Virtink 上創(chuàng)建和運(yùn)維虛擬化 Kubernetes 集群的需要，SmartX 開發(fā)了 knest 命令行工具來(lái)幫助用戶一鍵式創(chuàng)建集群以及對(duì)集群進(jìn)行擴(kuò)縮容管理。在 Virtink 集群上創(chuàng)建一個(gè)虛擬化 Kubernetes 集群僅需執(zhí)行“knest create”命令即可實(shí)現(xiàn)。對(duì)集群進(jìn)行后續(xù)的擴(kuò)縮容也可以通過(guò) knest 工具進(jìn)行一鍵式操作。總? ?結(jié) Kubernetes 并未內(nèi)建多租戶功能，但提供了一些細(xì)粒度的功能支持。利用這些功能，結(jié)合一些第三方工具，能夠?qū)崿F(xiàn)多租戶共享使用集群。但同時(shí)這些工具也帶來(lái)了額外的學(xué)習(xí)和運(yùn)維成本。在這個(gè)情況下，多個(gè)虛擬化集群依然是很多用戶選擇的方案。然而傳統(tǒng)的虛擬化平臺(tái)在效率和成本上并非此場(chǎng)景的最佳選擇。SmartX Virtink 開源虛擬化引擎基于高效、安全的 Cloud Hypervisor，提供 Kubernetes 上編排輕量虛擬機(jī)的能力，最大程度降低虛擬化 Kubernetes 集群的資源開銷。配套提供的 knest 命令行工具則支持集群一鍵式創(chuàng)建和運(yùn)維，有效降低多個(gè)集群的運(yùn)維成本 相關(guān)鏈接：

1. Kubernetes-sigs / hierarchical-namespaces https://github.com/kubernetes-sigs/hierarchical-namespaces

2. clastix / capsule https://github.com/clastix/capsule

3. loft-sh / kiosk https://github.com/loft-sh/kiosk

4. loft-sh / vcluster https://github.com/loft-sh/vcluster

5. smartxworks / virtink https://github.com/smartxworks/virtink

6. smartxworks / knest https://github.com/smartxworks/knest

?作者簡(jiǎn)介葉豐，SmartX 研發(fā)經(jīng)理、Virtink 開源項(xiàng)目維護(hù)者
------ 我們創(chuàng)建了一個(gè)高質(zhì)量的技術(shù)交流群，與優(yōu)秀的人在一起，自己也會(huì)優(yōu)秀起來(lái)，趕緊點(diǎn)擊加群，享受一起成長(zhǎng)的快樂。另外，如果你最近想跳槽的話，年前我花了2周時(shí)間收集了一波大廠面經(jīng)，節(jié)后準(zhǔn)備跳槽的可以點(diǎn)擊這里領(lǐng)取！

推薦閱讀

• 比996還狠！為了不被裁員，Twitter員工每天狂干12小時(shí)！
  
• 別再自己瞎寫工具類了，Spring Boot 內(nèi)置工具類應(yīng)有盡有！
  
• 關(guān)于 “ React 和 Vue 該用哪個(gè)” 我真的栓 Q
  

··································

你好，我是程序猿DD，10年開發(fā)老司機(jī)、阿里云MVP、騰訊云TVP、出過(guò)書創(chuàng)過(guò)業(yè)、國(guó)企4年互聯(lián)網(wǎng)6年 。 從普通開發(fā)到架構(gòu)師、再到合伙人。一路過(guò)來(lái)，給我最深的感受就是一定要不斷學(xué)習(xí)并關(guān)注前沿。只要你能堅(jiān)持下來(lái)，多思考、少抱怨、勤動(dòng)手，就很容易實(shí)現(xiàn)彎道超車！ 所以，不要問(wèn)我現(xiàn)在干什么是否來(lái)得及。如果你看好一個(gè)事情，一定是堅(jiān)持了才能看到希望，而不是看到希望才去堅(jiān)持。相信我，只要堅(jiān)持下來(lái)，你一定比現(xiàn)在更好！ 如果你還沒什么方向，可以先關(guān)注我， 這里會(huì)經(jīng)常分享一些前沿資訊，幫你積累彎道超車的資本。

點(diǎn)擊 領(lǐng)取2022最新10000T學(xué)習(xí)資料