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

一、Project Pacific是做什么的?

    在回答这个问题之前,我们先看下常见的企业IT架构(如下图所示),一些新型的业务跑在容器上,一些有状态的、追求稳定的应用更适合跑在虚拟机、物理机上,比如数据库。这就造成了多种架构的并存,也就是我们经常听到的双态模式,即“稳态”和“敏态”共存。

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

     按照我的经验,在企业里一般是开发部门先尝试容器化,微服务架构等等这些比较时髦的概念,规模一旦达到一定程度后,容器的编排也就无法避免,而K8S已经成为容器编排的标准。因此现在很多企业会在开发环境中部署一套K8S来跑一些边缘应用,经过一段时间试运行后,发现这玩意儿确实很方便,就不断放更多的应用,最后开发测试环境中的K8S规模越搞越大。但是毕竟是测试环境,要真正上生产环境,很多企业内部的开发测试是不太懂数据中心的那一套的(计算、存储、网络、安全、监控等),因此想把K8S丢给运维部门去接手。因此运维部门也需要去维护K8S集群了。对于运维部门来说,他们的关注点有:

  • 安全合规(租户隔离、权限设置、备份是否符合企业内部的安全规范)
  • 高可用(不能动不动服务就挂了)
  • 性能
  • 监控管理

    而开发人员的关注点则比较简单,我需要资源的时候能快速获取,甚至于我不需要关注底层资源,只要我直接调用API就能创建资源,这也是这几年serverless 非常火的原因,这种模式对于开发人员来说真的是太爽了。

    我们知道,企业内部IT运维管理员之前都使用vCenter来管理vSphere,这套软件运维人员已经非常熟悉了,但是这套软件并不是面向开发人员的,开发人员更习惯的是通过命令行或者API的方式来实现对资源的管理。在K8S里开发人员可以通过自己编写yaml文件实现pod的管理,他们不习惯通过Web界面去操作。为了解决开发人员的痛点,在Project Pacific里开发人员同样也可以编写 yaml 来描述k8s 集群 、Pod、虚机等,然后使用kubectl 来部署,这和你使用原生K8S的完全一样。如下图所示,通过定义kind类型描述你需要运行的资源类型,在spec里定义其他一些参数,几秒钟内就创建好你所需要的资源了。

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

     而对于IT运维人员来说,他们能够通过vSphere client来管理K8S,不像以前是管理单个VM或者单个pods,Project Pacific允许你基于应用(或者叫namespace)层面来进行控制,比如为每个应用(namespace)设置配额,权限。每个namespace就是一个独立的租户,租户之间相互隔离。如下图所示。

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

      而每个应用(namespace)是可以包含若干个vm和pod的组合的,这个可以由开发人员自己写yaml文件的时候任意指定。

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

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

应用(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通向容器世界的船票_Project Pacific_06

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

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

      关于supervisor kubernetes cluster可以参考这张图,VMware修改了ESXi,在里面添加了spherelet,你可以把它理解为类似kubelet的agent, agent接收master下发的命令并管理本地的Pods。

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

三、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

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