vSphere 7融合Kubernetes，構建現代化應用的平臺

   題圖攝於加州Monterey：太平洋的清晨

VMware 最新產品 vSphere 7 正式釋出，致力於打造現代化應用平臺，備受使用者矚目和期待。本文帶你深入瞭解 vSphere 7 的原生 Kubernetes 功能，歡迎閱讀。（本文僅代表作者個人觀點。）

VMware 在去年 VMWorld 介紹了雲原生組合 Tanzu 和太平洋專案（Project Pacific）。3月11日，VMware 釋出了近10年來最重要的一個版本：vSphere 7，包含眾多的新功能。其中最引人注目的更新當屬在 vSphere with Kubernetes (VwK) 功能，原生支援 Kubernetes 平臺，實現了虛機和容器混合管理的能力，使 vSphere 成為全新的現代化應用開發運維平臺。

vSphere with Kubernetes, 即之前的太平洋專案，對 vSphere 進行了多項的重構，引入了 Kubernetes 的概念和架構，以應用為中心，讓開發人員和運維人員從不同的檢視使用系統，帶來里程碑式的革新。

VwK 在 VMware 公司內部已孕育了3年有多，目標深遠、工程浩大，Kubernetes 聯合創始人 Joe Beda 直接指導，上百名精英工程師投入研發，現在終於如約而至，重磅推出。

我們一起來看看 vSphere with Kubernetes 的細節吧。

vSphere 叢集轉變成 Kubernetes 叢集

vSphere with Kubernetes 是 vSphere 7 裡面一個功能選項，管理員可在 vCenter 裡啟用這個選項，然後可選擇 vSphere 叢集啟用 VwK 功能。

在啟用 VwK 後，vSphere 叢集中會部署 3 臺虛擬機器，每臺虛擬機器部署 Kubernetes 的 Master 節點，組成高可用的本地控制平面 （Local Control Plane) ；接著在每個 ESXi 節點的核心執行一個 Kubelet 程式（稱作 Spherelet ），使 ESXi 成為 Kubernetes 的 Worker 節點。這樣改造之後，vSphere 叢集華麗轉身成為支援現代應用 Kubernetes 叢集。這個 vSphere 叢集稱為 “Supervisor Cluster”（主管叢集）。

把 vSphere 叢集轉變成 Kubernetes 叢集

把 vSphere 叢集轉換為 Kubernetes 叢集的好處之一，就是系統服務可以跑在這個主管叢集之上，使得系統服務的升級、重啟等生命週期管理可以依照 Kubernetes 的 Pod 方式進行，更加靈活；同時具備隔離性好，安全性高、HA保護等特性。

vSphere 7 提供的系統服務統稱為 VMware Cloud Foundation （VCF）服務。分為3類。

主管叢集的服務（*為實驗性功能，**為 roadmap 功能）

第一類是 Tanzu 執行時服務，主要包含 Tanzu Kubernetes Grid (TKG) 服務。TKG 服務用來管理使用者態的 Kubernetes 叢集，稱作 Tanzu Kubernetes Cluster （TKC），可用於執行使用者的應用。TKG 在部署 TKC 叢集之前，首先建立組成 TKC 叢集的虛擬機器，虛擬機器啟動後，由預置在虛機模板裡的 Kubeadm 程式部署 Kubernetes 節點。當所有虛擬機器都成為 Kubernetes 節點時，叢集部署完成。

第二類是混合基礎架構服務，提供 Kubernetes 所需要的基礎設施，如虛擬機器、儲存、網路、映象倉庫和 vSphere Pod 等。這些服務使 TKC 可以透過標準介面（如CNI， CSI等）訪問基礎設施資源。

第三類是定製服務，有合作伙伴或者使用者自行開發部署，其原理和前兩種相同。此次釋出的 vSphere 版本暫時不支援這類服務，將在後續版本中提供。

VCF服務簡介（59秒 ）

vCenter API 轉為 Kubernetes API

經上述重構之後的主管叢集和 Kubernetes 叢集已經有幾分形似了。要做到十全十美的神似，還有關鍵一步：支援 Kubernetes 的 API 。為此，VwK 對 vSphere API 進行了封裝和改進，向開發者呈現出 Kubernetes API 。

這個 vSphere 版的 Kubernetes API 可謂青出於藍，除了能管理 Pod 之外，還能夠管理 vSphere 的所有基礎設施資源，例如虛擬機器、儲存、網路、容器映象等。

這裡的秘訣要歸功於 Kubernetes 的宣告式介面和 CRD （Custom Resource Definition）的擴充套件形式。基礎設施的資源可以用 CRD 表示，如上文中的網路、儲存、TKC 等都有相應的 CRD。 

使用者只需要編寫 yaml 格式的檔案（一種簡潔的文字檔案），宣告所需要的 CRD 資源，透過 kubectl 命令即可建立和維護 vSphere 的資源了。

用於建立虛擬機器的yaml檔案例子

熟悉 Kubernetes 的同學都知道，管理 CRD 資源一種較好的方法是透過 Operator 模式。Operator 實際上是執行在 Kubernetes 上的程式，負責管理特定 CRD 資源的生命週期。在 vSphere 的主管叢集裡面，執行著不少各施其職的 Operator，分別擔負起叢集、虛機、網路、儲存等資源的管理任務。

因為 Operator 是開源和開放的架構，合作伙伴還可以開發定製化的 Operator，實現更豐富的功能。後面還會提到。

增加 CRX 執行 vSphere Pod 

既然 vSphere 提供了 Kubernetes API，那麼問題來了：vSphere能直接執行 Pod 嗎？答案是肯定的。（注：Pod 是 Kubernetes 特有的執行應用的最小單元，由一個或數個容器組成。）

在 vSphere 7中，ESXi 內建了一個容器執行時（runtime），稱作 CRX：Container Runtime for ESXi。CRX 執行 Pod 的時候，先建立一個虛機，然後在虛機內啟動一個微小的 Linux 核心，大約 20-30MB 的樣子。接著把容器映象的檔案系統掛載到虛擬機器之中，最後執行映象裡面的應用。這樣就啟動了一個Pod 的應用。

用 CRX 執行的 Pod 是跑在一個輕量級虛擬機器裡面的，這個虛機稱作 vSphere Pod （之前稱為 PodVM）。vSphere Pod 是以虛擬機器的方式產生，比基於 Linux  Container 的 Pod 隔離度更高，安全性更好。另一個好處是可以同時支援 Windows 容器，這點 Linux Container 無法實現。

ESXi 原生 Pod 的架構

上圖黃色部分就是基於 CRX 的 vSphere Pod。在建立的時候， NSX 的 Kube Proxy 同步更新網路，儲存 CNS 同步建立 VMDK 來繫結 vSphere Pod 需要的PV （Persistent Volume）。

大家對 vSphere Pod 是否有種似曾相識的感覺？沒錯，VMware 之前的產品VIC 和開源專案 Kata Containers 都採用過類似輕量級虛擬機器載入容器的技術。經過幾年的積澱，已發展成為比較成熟的技術了。

參加過 VIC 專案的核心工程師，大都在 vSphere 7 裡面繼續奮戰。VIC 支援的是Docker API 和單容器，相比之下，vSphere with Kubernetes 支援 Kubernetes API 和 Pod （可多容器）。

TKC 叢集 （應用叢集）

前面介紹的主管叢集（supervisor cluster）可直接用 Kubernetes API管理 vSphere 的資源，可以執行 Pod。但是需要指出的是，主管叢集的並不是完全相容 Kubernetes API 的，例如 privilege（特權） pod 在主管叢集裡面就不能使用。其次，主管叢集的 Kubernetes 版本是相對固定的，不太可能頻繁升級。還有一點，主管叢集在每個 vSphere 叢集裡只有一個，多租戶的場景中無法使用不同版本的 Kubernetes。

TKC叢集

為此，VwK 提供了 Tanzu Kubernetes Cluster (TKC) 叢集，由前文所述的 TKG 服務管理。簡單的說，就是部署在虛機裡的 Kubernetes 叢集，並且符合 CNCF的一致性 （Conformance）認證標準，可以相容執行在 Kubernetes上的應用。TKC 叢集可直接使用內建於主管叢集中的 VCF 服務，可以很便捷地獲取 Load balancer，PV 等資源。

TKG 服務採用了 Kubernetes 社群的 Cluster API 開源專案。Cluster API 體現了“用 Kubernetes 管理 Kubernetes ” 的思想，即使用者把需要建立的叢集規範以 CRD 的形式提交給一個 Kubernetes 管理叢集，該管理叢集根據 CRD 去維護目標叢集的生命週期。Cluster API 以 provider 的方式支援多種雲服務商。在 vSphere 7 中，主管叢集（Supervisor Cluster）就是管理叢集，而且只有 vSphere provider。 

Cluster API：用K8s管理K8s

Namespace （名稱空間）應用檢視

名稱空間要點（58秒影片）

之前提到，VwK 為應用提供了單獨的檢視，稱作 Namespace（名稱空間）。Namespace 是電腦科學裡廣泛使用的概念，用來區分不同的邏輯功能或實體，如程式語言裡面的 namespace ，Linux 的 namespace，容器 registry 裡面的 namespace 等等。VwK 在主管叢集中借鑑並擴充套件了 Kubernetes 劃分虛擬叢集的概念 namespace 。

Namespace 和主管叢集、SDDC 的關係

Kubernetes 的 namespace 對應用做了邏輯上的隔離，形成虛擬叢集，優點是每個 namespace 可以單獨設定資源管理策略，如統一控制網路訪問策略。

VwK 在主管叢集中增設了namespace ，可以包括容器、虛擬機器和 vSphere Pod 等資源。應用所需的資源，如 Pod 和虛擬機器等，都收納於一個 namespace 之下。由於 Namespace 是面向應用的邏輯單元，只需要對 namespace 配置 Quota， HA， DRS，網路、儲存、加密和快照等策略，就可以對應用的所有虛擬機器和 Pod 等資源進行管控，大大方便了運維管理。

使用者介面上的 namspace（左側導航欄）

從技術實現的角度看，當管理員建立 namespace 的時候，vSphere 自動在後臺建立一個對應的資源池 （Resource pool），對應著 namespace裡的所有資源。之後對 namespace 的管控實質上都是轉化為資源池的操作。

Namespace由 Resource pool支援

Namespace 是 VwK 的一項創新，定義了管理員和開發人員的邊界，實現面向應用的管理，提高了新應用的開發效率。管理員在 vCenter 建立 namespace 後，可交給開發人員使用。開發人員用 Kubernetes API 在 namespace 中建立應用所需虛擬機器、vSphere Pod，或者 Kubernetes 叢集 （TKC 叢集）等資源，不再需要管理員的介入。管理員只需要管理好 namespace 的資源策略，即使開發團隊在裡面呼風喚雨，翻天覆地，管理員也可高枕無憂了。

內建 Harbor Registry

Harbor Registry 中國使用者一定不會陌生，VwK 的映象倉庫服務由 Harbor 開源鏡專案提供，確保映象安全和提高效能。當建立 namespace 時，會同時建立一個 Harbor 的專案與其對應，提供該 namespace 下的映象服務。這個設計理念我們團隊已經構思很久，現在終於體現在 vSphere 裡面了。

萬事皆服務

Kubernetes 的聯合創始人 Joe Beda 說過一句經典的話：“ Kubernetes 是平臺的平臺，可以用來構建新的平臺”。這句深刻地闡明瞭 Kubernetes 建立者對產品的定位和設計理念。Kubernetes 不僅可管理容器編排服務，還可以透過擴充套件，管理其他服務，如資料庫、函式服務、人工智慧服務等等。

這個理念在 vSphere with Kubernetes 裡面得到了充分體現：vSphere 平臺可以構建各類服務（ XXX as a Service ）。我們只需在主管叢集裡面部署特定服務的 Operator ，就可以用該 Operator 運維相應的服務。

主管叢集成為控制平面，可管理各種服務

上面提到的 TKC 叢集實質上就是 Kubernetes as a Service，它的 Operator 已經內建在主管叢集中。同樣的，我們也可以部署 VM as a Service, MySQL as a Service 等服務的 Operator，達到管理這些服務的目的。

Operator 是開放架構，合作伙伴可以開發出各類功能的服務，並且部署和執行在主管叢集中，這將使得圍繞 vSphere 的生態系統百花齊放，成為名副其實的“平臺的平臺”。

vSphere with Kubernetes 使 vSphere 蛻變成改變遊戲規則的新一代現代化應用平臺，無疑是VMware Tanzu 組合中最閃亮的元件。

VMware 本次新產品釋出還包括 Tanzu 套件，VCF 4等產品。大家可關注官網，或者留意筆者後續的文章介紹。