生產(chǎn)環(huán)境中運行Kubernetes的人經(jīng)常吐槽的一點是多租戶有多難。

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

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

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

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

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

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

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

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

虛擬集群簡介

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

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

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

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

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

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

與命名空間隔離模型和集群隔離模型相比，這種架構(gòu)有顯著的優(yōu)勢：

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

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

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

如何使用虛擬集群？

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

?開發(fā)環(huán)境

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

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

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

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

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

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

?CI/CD 管道

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

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

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

此外，企業(yè)可以利用vcluster的速度來改進配置大量集群的任何其他流程，比如為研討會或客戶培訓(xùn)創(chuàng)建環(huán)境。

?測試不同的Kubernetes版本

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

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

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

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

補充

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

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

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