關於對VMware Project Pacific的理解

   VMware在VMworld 2019正式發佈了Project Pacific，在業內引發了普遍的熱議。本篇來聊聊我我的對Project Pacific的一些理解。

1、Project Pacific是作什麼的？

    在回答這個問題以前，咱們先看下常見的企業IT架構（以下圖所示），一些新型的業務跑在容器上，一些有狀態的、追求穩定的應用更適合跑在虛擬機、物理機上，好比數據庫。這就形成了多種架構的並存，也就是咱們常常聽到的雙態模式，即「穩態」和「敏態」共存。

     按照個人經驗，在企業裏通常是開發部門先嚐試容器化，微服務架構等等這些比較時髦的概念，規模一旦達到必定程度後，容器的編排也就沒法避免，而K8S已經成爲容器編排的標準。所以如今不少企業會在開發環境中部署一套K8S來跑一些邊緣應用，通過一段時間試運行後，發現這玩意兒確實很方便，就不斷放更多的應用，最後開發測試環境中的K8S規模越搞越大。可是畢竟是測試環境，要真正上生產環境，不少企業內部的開發測試是不太懂數據中心的那一套的（計算、存儲、網絡、安全、監控等），所以想把K8S丟給運維部門去接手。所以運維部門也須要去維護K8S集羣了。對於運維部門來講，他們的關注點有：

• 安全合規（租戶隔離、權限設置、備份是否符合企業內部的安全規範）

• 高可用（不能動不動服務就掛了）

• 性能

• 監控管理

    而開發人員的關注點則比較簡單，我須要資源的時候能快速獲取，甚至於我不須要關注底層資源，只要我直接調用API就能建立資源，這也是這幾年serverless 很是火的緣由，這種模式對於開發人員來講真的是太爽了。

    咱們知道，企業內部IT運維管理員以前都使用vCenter來管理vSphere，這套軟件運維人員已經很是熟悉了，可是這套軟件並非面向開發人員的，開發人員更習慣的是經過命令行或者API的方式來實現對資源的管理。在K8S裏開發人員能夠經過本身編寫yaml文件實現pod的管理，他們不習慣經過Web界面去操做。爲了解決開發人員的痛點，在Project Pacific裏開發人員一樣也能夠編寫 yaml 來描述k8s 集羣 、Pod、虛機等，而後使用kubectl 來部署，這和你使用原生K8S的徹底同樣。以下圖所示，經過定義kind類型描述你須要運行的資源類型，在spec裏定義其餘一些參數，幾秒鐘內就建立好你所須要的資源了。

     而對於IT運維人員來講，他們可以經過vSphere client來管理K8S，不像之前是管理單個VM或者單個pods，Project Pacific容許你基於應用(或者叫namespace)層面來進行控制，好比爲每一個應用（namespace）設置配額，權限。每一個namespace就是一個獨立的租戶，租戶之間相互隔離。以下圖所示。

      而每一個應用（namespace）是能夠包含若干個vm和pod的組合的，這個能夠由開發人員本身寫yaml文件的時候任意指定。

應用（namespace）視角下的vm及pod

     所以Project Pacific不只知足了運維人員經過Web UI實現對各類資源的管理，也讓開發人員能夠經過命令行或者API對各類資源的管理。

     最後咱們再來看官方對Project Pacific的描述，Project Pacific is a re-architecture of vSphere with Kubernetes as its control plane. To a developer, Project Pacific looks like a Kubernetes cluster where they can use Kubernetes declarative syntax to manage cloud resources like virtual machines, disks and networks. To the IT admin, Project Pacific looks like vSphere – but with the new ability to manage a whole application instead of always dealing with the individual VMs that make it up.

    經過前文的闡述，再加上下面這張圖，就更容易理解Project Pacific是作什麼的了。

2、那Project Pacific究竟是怎麼作的呢？

       VMware在vSphere7.0中集成了K8S，或者說是用Kubernetes重構vSphere，使用ESXi做爲K8S的worker node，多個ESXi組成了一個大的supervisor kubernetes cluster，在這上面能夠跑K8S集羣(也就是說「子K8S集羣」，咱們也稱爲guest kubernetes cluster)，虛擬機或者pods。這樣就能實現「kubernetes/VM/pods as a service」，用戶能夠隨時建立一個K8S集羣、VM或者pods了。總而言之，這個理念就是雲計算的精髓所在，「Anything as a service」。

      關於supervisor kubernetes cluster能夠參考這張圖，VMware修改了ESXi，在裏面添加了spherelet，你能夠把它理解爲相似kubelet的agent， agent接收master下發的命令並管理本地的Pods。

3、VMware爲何要推出Project Pacific？

     VMware的 Project Pacific應該是過去幾年中VMware發佈的最亮眼的變化，沒有之一。那VMware爲何要作Project Pacific呢？我認爲有兩個方面：

1，首先是容器是將來的趨勢，K8S如今已經成爲容器編排標準，VMware做爲虛擬化的龍頭，從長遠來講，若是VMware不去擁抱K8S，未來極有可能被落下，這就像極了這幾年的雲計算浪潮，短短几年以AWS爲表明的公有云把傳統的硬件廠商打的很是難受。

2，從短時間經濟效益看，VMware感覺到了K8S對其的衝擊，K8S的流行讓企業能夠直接拋開底層的vSphere，而直接運行在物理服務器上。這樣不只省了vSphere昂貴的license成本，性能上還提升了很多（雖然VMware宣稱vSphere7.0中作了相關的優化，Native Pods比物理機直接運行Pods性能提升30%）。

      結語：VMware是我我的很是喜歡的一家公司，大學時期就用他家的Workstation裝虛擬機來學習Linux，畢業後從ESX3.0開始接觸，再到後來作雲管理平臺，算是一直和VMware很有淵源。這麼多年VMware一直在圍繞IaaS這一層，說實話並無什麼大的創新點，直到如今發佈了Project Pacific以及Tanzu系列產品，算是一個革命性的變化，把本身和現代化雲原生應用完全綁在了一塊兒。另外和AWS、阿里雲的戰略合做，也是VMware知道本身沒法阻擋企業上雲的步伐，那就讓客戶在公有云裏繼續使用VMware吧，甚至於VMware還提供了專門的遷移工具HCX (Hybrid Cloud eXtension)來幫助用戶跨雲遷移虛機。既然變化是不能阻擋的趨勢,與其抗拒變化,不如擁抱變化。