題圖攝于加州蒙特雷：黎明中的太平洋
本文首發于公衆号 亨利筆記（ id：henglibiji )。
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等産品。
要想了解更多雲原生和人工智能等技術原理，請立即長按以下二維碼，關注本公衆号亨利筆記（ id：henglibiji )，以免錯過更新。
亨利筆記