Project Pacific—VMware通向容器世界的船票

   VMware在VMworld 2019正式发布了Project Pacific，在业内引起了广泛的热议。本篇来聊聊我个人对Project Pacific的一些理解。

一、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是做什么的了。

二、那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。

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

-----------------------------------------------------------------------------

如果您有关于IT技术、产品、销售的交流，可以加微信一起探讨