posted

0 Comments

VMworld 2019 大會上 VMware 發佈了 Project Pacific,這可以說是今年產品發佈的最大亮點。Project Pacific 在 vSphere 平臺上原生集成了 Kubernetes,使得 vSphere 平臺具有了原生支援容器運行的能力。vSphere 原來也支持容器運行 ,通過 vSphere Integrated Container 或是 VMware Enterprise PKS 來實現,這兩種方案都是在虛機環境裡運行容器。Project Pacific 使得 vSphere 具有了在 ESXi hypervisor 作業系統中直接運行容器 Pod 的能力,同時 Project Pacific 也為傳統的 vSphere 環境提供了一個 Kubernetes 介面,使得開發人員在 vSphere 環境中也可以繼續利用熟悉的 Kubernetes 命令和 API 來開發和部署應用。

 

現代應用的挑戰

在實際生產環境中,企業應用是經過很多年的演化和發展而來的,通常是由多種不同的技術元件組成,有些元件用到了最新的容器和 Serverless 技術,有些組件則運行在虛擬機器中(如資料庫),還有的系統需要訪問遺留系統,或者是訪問企業外部的 SaaS 服務。這些元件分佈在不同的運行環境中,通常由不同的團隊開發和維護。

 

這樣的應用架構給開發人員帶來了困擾,你不能只關注 Kubernetes,因為很多組件並沒有運行在容器中。一旦部署了這樣的應用程式,開發人員會產生各種疑慮:

  • 如何保證應用的安全性、可靠性、服務品質等級?
  • 如何維護並更新它?
  • 可以使用哪些工具來監控、診斷和調試部署?

同樣,運維團隊也面臨著新的問題,為了支援容器應用,有些企業不得不在 vSphere 虛擬化環境之外搭建一套新的容器環境,這種做法打破企業原有的標準運維流程,運維團隊也並不熟悉新的 Kubernetes 環境,管理 vSphere 虛擬化環境和 Kubernetes 容器環境用到的工具和方法是完全不同的,應用治理的策略也無法同步到兩種類型的環境中。

 

Project Pacific 的解決之道

Project Pacific 就是為了解決這種現代應用的挑戰而創建的,它為開發人員和 IT 運維人員提供了他們各自所熟悉的介面和工具,來管理現代應用環境。

 

ESXi 原生 Pod

Project Pacific 在 vSphere 環境中增加了一種 ESXi 原生的容器運行時環境 CRX (Container Runtime for ESXi ),CRX 是一種羽量級的虛機,其中僅包含 Linux 內核和必要的容器運行環境,Pod 就運行在 CRX 虛機中。ESXi hypervisor 針對 CRX 虛機做了專門的優化,在 vSphere 環境中運行容器能夠達到跟物理機同樣的性能水準,不用擔心由於多了一層虛擬化而帶來的性能損失,ESXi 啟動一個原生 Pod 只需要花 100 毫秒,在單台服伺服器上能夠支持上千個 Pod。在性能測試中,我們發現 ESXi 原生 Pod 比在虛機中運行容器 Pod 要快 30%,甚至比物理伺服器還要快上 8%,這是由於 ESXi 對於 CRX 的性能優化而實現的 (感興趣的同學可以進一步閱讀博文 How Does Project Pacific Deliver 8% Better Performance Than Bare Metal? 來瞭解 Project Pacific 對於 NUMA 架構的優化)。

下圖展示了 vSphere 群集支援原生 Pod 的架構,每台 ESXi 伺服器上都有兩個服務進程

  • Spherelet:類似於 kubernetes 環境中的 kublet,負責 Kubernetes 資源管理;
  • hostd:傳統的 vSphere 服務進程,負責虛機資源的管理。

 

採用 Kubernetes 的方法來管理工作負載

Project Pacific 為開發人員提供了 YAML 語言來定義所有的資源物件,開發人員可以用 YAML 來描述所有的基礎架構資源,包括 Kubernetes Cluster 、Pod、虛機、資料庫等,然後使用他們熟悉的 kubectl 來部署這些資源物件,就像使用任何其他 Kubernetes 物件 (Pod、service、ingress) 一樣。這種理念將 Kubernetes 的使用體驗從雲原生應用擴展到其他應用,使開發人員可以輕鬆地部署和管理現代應用,即使這些應用橫跨了多個技術堆疊。

 

以應用為中心的管理

現代應用往往是由幾十個甚至更多的虛機和容器所組成的,管理員需要針對每一個虛機來配置運行參數,如是否需要加密、存儲可靠性等級、虛機的保護機制等等,這樣不僅費時費力,並且很難保證一致性。Project Pacific 借用了 Kubernetes 中 Namespace 概念來管理應用,每一個應用都有一個對應的 Namespace,其中包含了組成該應用的所有虛機和容器,可以針對整個 Namespace 來指定該應用的服務品質等級、安全性要求、可用性參數、存取控制許可權等運行參數。Namespace 使得資料中心的管理以基礎架構為中心轉向以應用為中心,更好地滿足了現代應用運維管理的要求。

 

同時滿足開發和運維團隊的需求

vSphere 原有的控制平面是 vCenter,管理員通過 vCenter 來管理 vSphere 集群;Project Pacific 為開發人員提供了一個新的控制平面 Kubernetes, 從而同時滿足開發和運維團隊的需求。

  • 開發人員不僅可以通過 Kubernetes 介面來創建和管理 Kubernetes 物件,還可以使用他們熟悉的 Kubernetes 命令和 API 來部署應用和調配基礎架構資源,Project Pacific 提供的不僅是介面,而且也向開發人員開放了 vSphere 資源管理的許可權。他們不再像以前那樣依賴於運維團隊來為他們創建所需要的基礎架構,可以更加快捷便利地獲得所有的資源,大大提高了對於業務的回應速度。
  • 運維團隊可以在熟悉的平臺上管理新增的容器應用,不需要改動現有的運維流程,也不需要去學習新的管理工具,通過傳統的 vCenter、vRealize Operations 的工具就可以實現對於現代應用的支援,實現服務品質等級、工作負載管理等運維職能。

 

總結

Project Pacific 給 vSphere 增加了一個新的控制平面,使用戶可以用 Kubernetes 來管理 vSphere。 對於開發人員來說,Project Pacific就像是一個增強的 Kubernetes 集群,可以使用 Kubernetes 聲明式語法來管理虛擬機器、磁片和網路等資源。 對於 IT 管理員來說,Project Pacific 仍舊是 vSphere,但是添加了對於應用整體管理的能力,而不是單獨管理許多個獨立的組成應用的虛擬機器或者容器。

Project Pacific 可以利用企業現有的 SDDC 投資、人員技能和工具,加速 vSphere 平臺上現代化應用的開發和運營。 通過利用 Kubernetes 作為vSphere 的控制平面,Project Pacific 允許企業利用一個融合的平臺同時運行傳統應用和現代化應用。

 

延伸閱讀

將 VMware vSphere / vSAN 軟體與 Intel 的最新硬體平臺技術相結合,可以為用戶交付最佳的超融合架構平臺,幫助用戶簡化資料中心管理,降低採購和運維成本,輕鬆應對企業在數位化轉型中面對的各種挑戰。

  • VMware vSAN 是最佳的存儲方案平臺,具有管理簡便、高性能、低成本、易擴展的特點,在 vSAN 平臺上可以支援任何類型的應用。
  • Intel 至強處理器提供最強計算能力,基於傲騰 (Optane) 和 3D NAND 技術的固態盤是理想的快取記憶體,乙太網融合網卡提供穩定的網路頻寬和低網路延遲。