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 允许企业利用一个融合的平台同时运行传统应用和现代化应用。
