太平洋项目详解 - VMware Tanzu显露王者风范 (2)
题图摄于越南：太平洋的日出
VMworld 大会上发布了众多的新技术产品，其中以 Tanzu 为主打的云原生产品和服务备受瞩目，业界好评如潮。本文为系列文章第二篇，带你深入了解太平洋项目的技术原理，欢迎阅读。（本文仅代表作者个人意见。）
VMware 新近发布的云原生组合拳 Tanzu 颇引人注目，上期和大家讲述了 Tanzu 的第一式：构建（BUILD）。本期介绍第二式：运行（RUN）。本招式中最耀眼的当数太平洋项目（Project Pacific），在 vSphere 里面内置了 Kubernetes 功能，可以虚机和容器混管。
太平洋项目对 vSphere 进行了多项的重构，引入了 Kubernetes 的概念和架构，让开发人员和运维人员从不同的视图使用系统，带来里程碑式的革新。
太平洋项目在 VMware 公司内部已孕育了3年有多，目标深远、工程浩大，Kubernetes 联合创始人 Joe Beda 直接指导，上百名精英工程人员投身研发，已经到了最后收官时刻，有望不久将来重磅推出。
想了解太平洋项目的读者可能都迫不及待了吧，我们一起来看看个中的细节吧。
重构1: vSphere集群改造成 Kubernetes 集群
在 vSphere集群中部署3台虚拟机，每台虚拟机安装上 Kubernetes 的 Master 节点，作为控制平面；然后在每个 ESXi 节点的内核运行一个 Kubelet 进程（称作Spherelet），使 ESXi 成为 Kubernetes 的 Worker 节点。这样改造之后，vSphere 集群摇身一变成为了 Kubernetes 集群。在太平洋项目里面，这个集群称为 “Supervisor Cluster”（主管集群）。
把vSphere Cluster变成Kubernetes Cluster
Kubernetes 功能内置在主管集群里，包括网络、存储等基础设施，并由 vCenter 负责生命周期管理，像 DRS 或 HA 功能一样，可以按照需要打开或关闭。主管集群可以作为应用和服务的管理平面，也可以运行用户的应用负载。
重构2: vCenter API 转为 Kubernetes API
经上述重构之后的主管集群和 Kubernetes 已经有几分形似了。要做到十全十美的神似，还有关键一步：支持 Kubernetes 的 API 。为此，太平洋项目对vSphere API 进行了封装，向开发者呈现出 Kubernetes API 。
这个 vSphere 版的 Kubernetes API可谓青出于蓝，除了能管理 Pod 之外，还能够管理 vSphere 的所有资源，例如虚拟机、存储、网络等。
这里的秘诀要归功于 Kubernetes 的声明式接口和 CRD （Custom Resource Definition）的扩展形式。vSphere 的资源以 CRD yaml 的形式定义（一种简洁的文本文件），用户通过 kubectl 命令即可创建和维护 vSphere 的所有资源了。
用于创建虚拟机的yaml文件例子
熟悉 Kubernetes 的同学都知道，管理 CRD 资源一种较好的方法是通过 Operator 模式。Operator 实际上是运行在 Kubernetes上的程序，负责管理特定 CRD 资源的生命周期。在 vSphere 的主管集群里面，运行着不少各施其职的 Operator，分别担负起集群、虚机、网络、存储等资源的管理任务。
因为 Operator 是开源和开放的架构，合作伙伴还可以开发定制化的 Operator，实现更丰富的功能。后面还会提到。
重构3: 增加 CRX 运行 Pod
既然 vSphere 提供了 Kubernetes API，那么问题来了：vSphere能直接运行 Pod 吗？答案是肯定的。（注：Pod 是 Kubernetes 特有的运行应用的最小单元，由一个或数个容器组成。）
在太平洋项目中，ESXi 内置了一个容器运行时（runtime），称作 CRX：Container Runtime for ESXi。CRX运行 Pod 的时候，先创建一个虚机，然后在虚机内启动一个微小的 Linux 内核，大约 20-30MB 的样子。接着把容器镜像的文件系统挂载到虚拟机之中，最后执行镜像里面的应用。这样就启动了一个Pod 的应用。
可以看到，用 CRX 运行的 Pod 是跑在一个轻量级虚拟机里面的，这个虚机称作 PodVM。PodVM 隔离了不同的 Pod ，同一个 Pod 里面的多个应用直接跑在操作系统上，不再需要Linux 的容器来隔离了。PodVM 比 Linux的Container 隔离度更高，安全性更好。
ESXi 原生 Pod 的架构
上图黄色部分就是基于 CRX 的 PodVM。在创建 PodVM 的时候， NSX 的 Kube Proxy 同步更新网络，存储 CNS 同步创建 VMDK 来绑定 PodVM 需要的PV （Persistent Volume）。太平洋项目还重新实现了类似 Docker 的镜像服务 （Image Service），可缓存镜像。
大家对 PodVM 是否有种似曾相识的感觉？没错，VMware 之前的产品VIC 和开源项目 Kata Containers 都采用过类似轻量级虚拟机加载容器的技术。经过几年的积淀，已发展成为比较成熟的技术了。
参加过 VIC 项目的核心工程师，大都在太平洋项目里面继续奋战。VIC 支持的是Docker API 和单容器，相比之下，太平洋项目支持 Kubernetes API 和 Pod （可多容器）。
重构4: Guest 集群
前面介绍的主管集群（supervisor cluster）可直接用 Kubernetes API管理 vSphere 的资源，可以运行 Pod。但是需要指出的是，主管集群的并不是完全兼容 Kubernetes API 的，例如 privilege（特权） pod 在主管集群里面就不能使用。其次，主管集群的 Kubernetes 版本是相对固定的，若要升级，必须连同 ESXi 的版本一起升，这样不可能太频繁。还有，主管集群在每个 vSphere 集群里只有一个，多租户的场景中无法使用不同版本的 Kubernetes。
为此，太平洋项目提供了 Guest 集群，有点类似 Guest 操作系统，简单的说，就是部署在虚机里的 Kubernetes 集群，并且符合 CNCF的一致性 （Conformance）认证标准，可以兼容任何运行 Kubernetes上的应用。就是说，用户定制的 Kubernetes ，或者是第三方方案如 OpenShift等，都可以运行在 Guest 集群里。
Guest Cluster
Guest 集群不仅仅是在虚拟机里部署 Kubernetes 那么简单，而且可直接使用内置于主管集群中的服务，如CNI，CSI 等 Kubernetes 插件，这些插件由 vSphere的 NSX 和 CNS 等基础功能提供，可以很便捷地获取 load balancer，PV 等资源。
Guest Kubernetes Cluster 可直接使用 vSphere 基础设施
Guest 集群还有独特的功能，如运行 PodVM 和管理虚拟机等，这点与主管集群一样。
重构5: Namespace应用视图
之前提到，太平洋项目为应用提供了单独的视图，称作 Namespace（命名空间）。Namespace 是计算机科学里广泛使用的概念，用来区分不同的逻辑功能或实体，如编程语言里面的 namespace ，Linux 的 namespace，容器 registry 里面的 namespace 等等。太平洋项目借鉴并扩展了 Kubernetes 划分虚拟集群的概念 namespace 。
Namespace 和主管集群、SDDC 的关系
Kubernetes 的 namespace 对应用做了逻辑上的隔离，形成虚拟集群，优点是每个 namespace 可以单独设置管理策略，如统一控制网络访问策略。
太平洋项目在 vCenter 的集群中增设了namespace ，可以包括容器、虚拟机和 PodVM 等资源。应用所需的资源，如 Pod和虚拟机等，都收纳于一个 namespace之下。由于Namespace是面向应用的逻辑单元，只需要对 namespace 配置 Quota， HA， DRS，网络、存储、加密和快照等策略，就可以对应用的所有虚拟机和Pod 等资源进行管控，大大方便了运维管理。
用户界面上的 namspace（左侧导航栏）
从技术实现的角度看，当管理员创建 namespace 的时候，vSphere 自动在后台创建一个对应的资源池 （Resource pool），对应着 namespace里的所有资源。之后对 namespace 的管控实质上都是转化为资源池的操作。
namespace由 Resource pool支持
Namespace 是太平洋项目的一项创新。管理员在 vCenter 创建 namespace后，可交给开发人员使用。开发人员用 Kubernetes API 在 namespace中创建虚拟机、PodVM，或者 Kubernetes 集群 （Guest集群）等资源，不再需要管理员的介入。管理员只需要管理好 namespace的资源边界，即使开发团队在里面呼风唤雨，翻天覆地，管理员也可高枕无忧了。
重构6: 内置 Harbor Registry
Harbor Registry 中国用户一定不会陌生，太平洋项目在主管集群中集成了 Harbor 开源镜像仓库。当创建 namespace时，会同时建立一个 Harbor 的项目与其对应，提供该 namespace下的镜像服务。这个设计理念我们已经构思很久，现在终于体现在 vSphere 里面了。
万事皆服务
Kubernetes 的联合创始人Joe Beda 说过一句体现身价的话：“ Kubernetes 是平台的平台，可以用来构建新的平台”。这句深刻地阐明了 Kubernetes 创建者对产品的定位和设计理念。 Kubernetes 不仅可管理容器编排服务，还可以通过扩展，管理其他服务，如数据库、函数服务、人工智能服务等等。
这个理念在太平洋项目里面得到了充分体现：vSphere 平台可以构建各类服务（ XXX as a Service ）。我们只需在主管集群里面部署特定服务的 Operator ，就可以用该 Operator 运维相应的服务。
主管集群成为控制平面，可管理各种服务
上面提到的Guest 集群实质上就是 Kubernetes as a Service，它的 Operator 已经内置在主管集群中。同样的，我们也可以部署 VM as a Service, MySQL as a Service 等服务的 Operator，达到管理这些服务的目的。
上文提到，Operator 是开放架构，合作伙伴可以开发出各类功能的服务，并且部署和运行在主管集群中，这将使得围绕 vSphere 的生态系统百花齐放，成为名副其实的“平台的平台”。
经过太平洋项目脱胎换骨式的改进，vSphere 将蜕变成改变游戏规则的新一代现代化应用平台，无疑是 Tanzu 中最闪亮的组件。
下期将介绍 Tanzu 的第三式：管理，主要项目是 Tanzu Mission Control （TMC，Tanzu 任务控制）。TMC 提供跨云和私有云的 Kubernetes 统一管理，帮助用户运筹帷幄。
要想深入了解 TMC 的技术原理和一睹为快用户界面，请立即长按以下二维码，关注本公众号亨利笔记，以免错过更新。
（未完待续）
VMware招聘云原生开发工程师
（北京/上海）
VMware中国研发中心一直致力于前沿领域的创新工作，成功创立并开发了用户普遍使用的 Harbor 容器镜像仓库等开源项目，在国内云原生领域有着深远的影响力。为满足项目发展需要，现招聘 Staff Engineer 一名，需熟悉 Kubernetes平台，开发云原生为主、人工智能为辅的开源项目，涉及多个业界热门和超前的技术领域，和业界大咖合作、待遇优厚、一般不加班，出国学习交流机会，欢迎大家踊跃投递简历或转发给需要的朋友！
职位要求：
计算机科学或相近专业本科以上学历
6年以上应用代码开发经验
熟悉至少一门现代编程语言，如 Go, Python, Java, C++
对云原生技术，如容器，K8s等有较多的项目经验
具有人工智能、机器学习方面经验者优先
熟悉 Kubeflow, Tensorflow, PyTorch 等机器学习框架优先
熟悉开源软件社区运作，参与过开源项目贡献者优先
良好的英语沟通能力，可以和国际团队协作。
请发简历：[email protected]
注明：云原生职位
活动消息：