生產環境中運行Kubernetes的人經常吐槽的一點是多租戶有多難。

企業主要使用兩種模型與多個租戶共享Kubernetes集群：基于命名空間的多租戶和基于集群的多租戶。

第一種常見的多租戶模型基于命名空間隔離，其中單個租戶（比如開發微服務的團隊）只能使用集群中的一個或某幾個命名空間。雖然這種模型適用于某些團隊，但也存在缺陷。

首先，限制團隊成員只能訪問命名空間中的資源意味著他們無法管理集群中的全局對象，比如自定義資源定義（CRD）。對于直接或間接處理CRD（比如在Kubeflow或Argo Pipelines上構建）的團隊來說，這是大問題。

其次，一個更大的長期維護問題是需要不斷向命名空間隔離規則添加例外。比如說，使用網絡策略鎖定單個命名空間時，管理員可能發現一些團隊最終需要運行多個相互聯系的微服務。集群管理員需要為這些情況添加異常，跟蹤它們，并管理所有這些特殊情況。而且，隨著時間的推移和更多的團隊開始使用Kubernetes，復雜性也將隨之增大。

另一種標準的多租戶模型是在集群層面使用隔離，問題來得更大。在這種情況下，每個團隊都有自己的集群，甚至可能有多個集群（開發、測試、UAT和登臺等）。

使用集群隔離的直接問題是最終需要管理許多集群，這個問題可能很棘手。所有這些集群都需要昂貴的云計算資源，即使是使用它們的低峰時段，比如在晚上或周末。

正如Holly Cummins在KubeCon 2021主題演講中指出，這種集群激增給環境帶來的影響很危險。

就在不久前，集群管理員還只好在這兩種令人不滿意的模型之間做出選擇，選擇更適合其用例和預算的模型。然而，Kubernetes中有一個比較新的概念：虛擬集群，它更適合許多用例。

虛擬集群簡介

虛擬集群是一個共享的Kubernetes集群，在租戶看來是專用集群。2020年，Loft Labs團隊發布了vcluster，這是虛擬Kubernetes集群的開源實現方法。

有了vcluster，工程師可以在共享的Kubernetes集群上配置虛擬集群。這些虛擬集群在底層集群的常規命名空間內運行。因此，管理員可以啟動虛擬集群并將它們分發給租戶。

如果組織已經在使用基于命名空間的多租戶，但用戶被限制在單個命名空間中，租戶用戶還可以在命名空間內自行啟動這些虛擬集群。

這結合了上述兩種多租戶方法的優點：租戶被限制在單個命名空間中，不需要例外，因為他們在虛擬集群內部擁有完全控制權，但虛擬集群外面的訪問非常有限。

與集群管理員一樣，用戶在虛擬集群內擁有完全控制權。這讓他們可以在虛擬集群內執行任何操作，而不影響底層共享主機集群上的其他租戶。

在幕后，vcluster通過在主機集群上的命名空間內的pod中運行Kubernetes API服務器及其他一些組件來實現這一點。用戶將請求發送到命名空間內的虛擬集群API服務器，而不是底層集群的API服務器。虛擬集群的集群狀態也完全獨立于底層集群。虛擬集群內創建的Deployment或Ingress等資源僅存在于虛擬集群的數據存儲中，并不持久保存在底層集群的etcd中。

與命名空間隔離模型和集群隔離模型相比，這種架構有顯著的優勢：

1. 由于用戶是虛擬集群中的管理員，他們可以管理整個集群的對象（比如CRD），從而克服了命名空間隔離的一大限制。

2. 由于用戶與各自的API服務器進行聯系，其流量比平常的共享集群更孤立。這還提供了聯合機制，有助于在高流量集群中擴展API請求。

3. 虛擬集群配置和拆卸起來很快，因此用戶可以得益于使用真正臨時的環境，并可能在需要時啟動許多臨時環境。

如何使用虛擬集群？

虛擬集群有很多用例，下面介紹大多數vcluster用戶采用的幾個用例。

?開發環境

配置和管理開發環境是目前vcluster最流行的用例。如果開發人員編寫Kubernetes集群中運行的服務，開發過程中需要在某個地方運行應用程序。雖然可以使用Docker Compose等工具為開發環境編排容器，但針對Kubernetes集群編寫代碼的開發人員將獲得更接近其服務在生產環境中運行方式的體驗。

本地開發的另一個選擇是使用Minikube或Docker Desktop之類的工具來配置Kubernetes集群，但有幾個缺點。

開發人員必須擁有并維護這本地集群架構，這并非易事，且耗費時間。

此外，那些本地集群可能需要大量的計算能力，這在本地開發機器上很難做到。我們都知道筆記本電腦在開發過程中會變得多熱，再添加Kubernetes可能不是好主意。

在共享開發集群中將虛擬集群作為開發環境來運行可以解決這些問題。而且，如上所述，vcluster可以快速配置和刪除。

管理員可以使用單個kubetctl命令來刪除底層主機命名空間或運行命令行界面工具提供的vcluster delete命令，從而刪除vcluster。開發工作流程中基礎設施和工具的速度至關重要，因為縮短開發人員的周期時間可以提高其生產力和幸福感。

?CI/CD 管道

持續集成/持續開發（CI/CD）是虛擬集群的另一大用例。管道通常配置受測系統（SUT），從而運行測試套件。團隊常常希望那些是新系統，沒有可能干擾測試的包袱。

如果團隊運行有許多測試的長管道，可能會在測試運行中多次配置和銷毀SUT。如果用戶花費大量時間配置集群，可能已注意到啟動Kubernetes集群常常很耗時。即使在最先進的公共云中，也可能需要20多分鐘。

使用vcluster可以快速輕松地配置虛擬集群。運行vcluster create命令來配置新的虛擬集群時，幕后只需要運行Helm圖表，并安裝幾個pod。這番操作通常只需幾秒鐘。任何運行長時間測試套件的人都知道，縮短流程的時間對QA團隊和工程師收到反饋的速度都會帶來顯著提升。

此外，企業可以利用vcluster的速度來改進配置大量集群的任何其他流程，比如為研討會或客戶培訓創建環境。

?測試不同的Kubernetes版本

如前所述，vcluster在底層主機命名空間中運行Kubernetes API服務器。它默認使用K3s（輕量級Kubernetes）API服務器，但用戶也可以使用k0s、Amazon Elastic Kubernetes Service 或常規的上游Kubernetes API服務器。

配置vcluster 時，用戶可以指定運行它的Kubernetes版本，這帶來了諸多可能性。用戶可以：

?在虛擬集群中運行較新的Kubernetes版本，以查看應用程序面對較新的API服務器將如何運行。

?在開發或端到端測試期間，使用不同版本的Kubernetes運行多個虛擬集群，以便在一組不同的Kubernetes發行版和版本中測試operator。

補充

Kubernetes多租戶可能沒有完美的解決方案，但虛擬集群解決了當前租戶模型的許多問題。如果用戶希望使用共享集群，但又希望為用戶提供管理集群的靈活性，vcluster的速度和易用性使其成為許多場景的理想選擇。除了本文描述的用例外，vcluster還支持許多用例。

想了解更多信息，請訪問vcluster.com，或者如果想深入了解代碼，可從GitHub代碼庫（https://github.com/loft-sh/vcluster）下載。

原文標題：??Virtual Kubernetes clusters: A new model for multitenancy??，作者：Lukas Gentele