关于对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)来帮助用户跨云迁移虚机。既然变化是不能阻挡的趋势,与其抗拒变化,不如拥抱变化。