Kubernetes 缺少的多租戶功能,你可以通過這些方式實現

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

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

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

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

• Kubernetes 原生。虛擬化平臺本身最好是 Kubernetes 集群，以降低學習和運維成本。

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

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

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

推薦閱讀

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

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

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

點擊 領取2022最新10000T學習資料