方案解讀 | 如何高效而經濟地實現 Kubernetes 多租戶功能？

一、Kubernetes 隔離技術

Kubernetes 提供了三個機制來實現控制平面的隔離：namespace、RBAC 和 quota。

儘管這三個機制能一定程度上提供控制平面的隔離，但無法徹底解決問題。例如 CRD 這類叢集範圍的資源，就無法做到很好的隔離。

2.資料平面隔離

資料平面的隔離主要分為三個方面：容器執行時、儲存和網路。

容器和主機共享 kernel，應用程式或者主機系統上的漏洞可能被攻擊者所利用，從而突破容器的邊界而攻擊到主機或者其他容器。解決方法通常是將容器放到一個隔離的環境中執行，例如虛擬機器或者是使用者態 kernel。前者以 Kata Containers 為代表，後者的代表則是 gVisor。

儲存的隔離應保證 volume 不會跨租戶訪問。由於 StorageClass 是叢集範圍的資源，為防止 PV 被跨租戶訪問，應指定其 reclaimPolicy 為 Delete。此外，也應禁止使用例如 hostPath 這樣的 volume，以避免節點的本地儲存被濫用。

網路的隔離通常由 NetworkPolicy 保證。預設地，Kubernetes 內所有的 pod 相互之間是可以通訊的。利用 NetworkPolicy 則可以限定 pod 能夠通訊的 pod 範圍，以防止意外的網路訪問。此外，service mesh 通常能提供更高階的網路隔離功能。

二、多租戶方案選擇

上面提到的控制平面和資料平面的隔離功能，都是 Kubernetes 內較為獨立零散的功能，與完整的多租戶方案還有很大差距，想要把它們組織起來也需要相當大的工作量。不過，Kubernetes 社群有許多開源專案專門解決多租戶問題。從大方向上，它們分為兩類。 一類是以 namespace 為邊界劃分租戶，另一類則為租戶提供虛擬控制平面。

1.按 namespace 劃分租戶

Kubernetes 的控制平面隔離中的 RBAC 和 ResourceQuota 均以 namespace 為邊界，因此以 namespace 來劃分租戶是比較自然的想法。不過，在現實中，限定一個租戶只能使用一個名稱空間存在較大侷限性。例如無法進一步以團隊，或者以應用為粒度進行細分，造成一定的管理難度。因此 Kubernetes 官方提供了支援層級化 namespace 的 controller。此外，第三方開源專案例如 Capsule 和 kiosk 提供了更為豐富的多租戶支援。

2.虛擬控制平面

另一種多租戶的實現方案是為每個租戶提供一個獨立的虛擬控制平面，以徹底隔離租戶的資源。虛擬控制平面的實現方式通常是為每個租戶執行一套獨立的 apiserver，同時利用 controller 將租戶 apiserver 中的資源同步到原 Kubernetes 叢集中。每個租戶只能訪問自己對應的 apiserver，而原 Kubernetes 叢集的 apiserver 則通常不對外訪問。

這類方案的代價是額外的 apiserver 的開銷，但能夠獲得更為徹底的控制平面隔離。結合資料平面的隔離技術，虛擬控制平面可以實現更為徹底和安全的多租戶方案。此類方案以 vcluster 專案為代表。

3.如何選擇？

選擇按 namespace 劃分租戶還是使用虛擬控制平面應取決於多租戶的使用場景。通常來說，按 namespace 劃分租戶的隔離性和自由度會略有欠缺，但優勢在於輕量。對於多團隊共享使用的場景，按 namespace 劃分租戶較為合適。而對於多客戶共享使用的場景，選擇虛擬控制平面通常能夠提供更好的隔離保障。

三、多叢集方案

從上文可以看出，共享使用 Kubernetes 叢集並非易事；Kubernetes 叢集並非天然地支援多租戶，僅僅是提供了一些細粒度上的功能支援。要想讓 Kubernetes 支援多租戶場景需要其他專案的支援，以同時在控制平面和資料平面上實現租戶之間的隔離。 這使得整個方案存在不小的學習和適應成本。 因此， 目前有許多使用者採用的不是共享叢集，而是多叢集的方案。

相比共享叢集，多叢集方案有利有弊：優勢是隔離性強、邊界清晰，劣勢是資源開銷以及運維成本較高。由於每個叢集需要獨立的控制平面和工作節點，為了提高物理叢集的利用率，通常會選擇在虛擬機器上搭建 Kubernetes 叢集。 然而傳統的虛擬化產品因為需要顧及更為廣泛的場景，所以功能上往往大而全，並且售價高昂，並非支撐虛擬化 Kubernetes 叢集的最佳選擇。

基於此，可以認為，支撐虛擬化 Kubernetes 叢集理想的虛擬化平臺應該具備以下特點：

而這些特點，恰恰是  SmartX 前段時間釋出的 Virtink 虛擬化引擎所具備的。Virtink 基於 Cloud Hypervisor 專案，提供在 Kubernetes 上編排輕量化、現代化虛擬機器的能力。相比基於 QEMU 和 libvirt 的 KubeVirt 專案，Virtink 能為每個 VM 降低至少 100MB 的額外開銷。此外，Virtink 全面使用 virtio，提高 I/O 效率。最後，在安全性方面，Cloud Hypervisor 由 Rust 語言編寫，具備更為安全的記憶體管理。並且透過減少過時和不必要的外設支援，儘可能地減小暴露給 VM 的可攻擊面，以提高主機的安全性。 更輕量、更高效、更安全的 Virtink 為 Kubernetes in Kubernetes 提供了更為理想和經濟的虛擬化支援，盡最大可能降低虛擬化層的開銷。

此外，針對在 Virtink 上建立和運維虛擬化 Kubernetes 叢集的需要， 我們開發了 knest 命令列工具來幫助使用者一鍵式建立叢集以及對叢集進行擴縮容管理。在 Virtink 叢集上建立一個虛擬化 Kubernetes 叢集僅需執行“knest create”命令即可實現。對叢集進行後續的擴縮容也可以透過 knest 工具進行一鍵式操作。

四、總結

Kubernetes 並未內建多租戶功能，但提供了一些細粒度的功能支援。利用這些功能，結合一些第三方工具，能夠實現多租戶共享使用叢集。但同時這些工具也帶來了額外的學習和運維成本。在這個情況下，多個虛擬化叢集依然是很多使用者選擇的方案。然而傳統的虛擬化平臺在效率和成本上並非此場景的最佳選擇。SmartX Virtink 開源虛擬化引擎基於高效、安全的 Cloud Hypervisor，提供 Kubernetes 上編排輕量虛擬機器的能力，最大程度降低虛擬化 Kubernetes 叢集的資源開銷。配套提供的 knest 命令列工具則支援叢集一鍵式建立和運維，有效降低多個叢集的運維成本。