vSphere 7融合Kubernetes，构建现代化应用的平台

   题图摄于加州Monterey：太平洋的清晨

VMware 最新产品 vSphere 7 正式发布，致力于打造现代化应用平台，备受用户瞩目和期待。本文带你深入了解 vSphere 7 的原生 Kubernetes 功能，欢迎阅读。（本文仅代表作者个人观点。）

VMware 在去年 VMWorld 介绍了云原生组合 Tanzu 和太平洋项目（Project Pacific）。3月11日，VMware 发布了近10年来最重要的一个版本：vSphere 7，包含众多的新功能。其中最引人注目的更新当属在 vSphere with Kubernetes (VwK) 功能，原生支持 Kubernetes 平台，实现了虚机和容器混合管理的能力，使 vSphere 成为全新的现代化应用开发运维平台。

vSphere with Kubernetes, 即之前的太平洋项目，对 vSphere 进行了多项的重构，引入了 Kubernetes 的概念和架构，以应用为中心，让开发人员和运维人员从不同的视图使用系统，带来里程碑式的革新。

VwK 在 VMware 公司内部已孕育了3年有多，目标深远、工程浩大，Kubernetes 联合创始人 Joe Beda 直接指导，上百名精英工程师投入研发，现在终于如约而至，重磅推出。

我们一起来看看 vSphere with Kubernetes 的细节吧。

vSphere 集群转变成 Kubernetes 集群

vSphere with Kubernetes 是 vSphere 7 里面一个功能选项，管理员可在 vCenter 里启用这个选项，然后可选择 vSphere 集群激活 VwK 功能。

在启用 VwK 后，vSphere 集群中会部署 3 台虚拟机，每台虚拟机部署 Kubernetes 的 Master 节点，组成高可用的本地控制平面 （Local Control Plane) ；接着在每个 ESXi 节点的内核运行一个 Kubelet 进程（称作 Spherelet ），使 ESXi 成为 Kubernetes 的 Worker 节点。这样改造之后，vSphere 集群华丽转身成为支持现代应用 Kubernetes 集群。这个 vSphere 集群称为 “Supervisor Cluster”（主管集群）。

把 vSphere 集群转变成 Kubernetes 集群

把 vSphere 集群转换为 Kubernetes 集群的好处之一，就是系统服务可以跑在这个主管集群之上，使得系统服务的升级、重启等生命周期管理可以依照 Kubernetes 的 Pod 方式进行，更加灵活；同时具备隔离性好，安全性高、HA保护等特性。

vSphere 7 提供的系统服务统称为 VMware Cloud Foundation （VCF）服务。分为3类。

主管集群的服务（*为实验性功能，**为 roadmap 功能）

第一类是 Tanzu 运行时服务，主要包含 Tanzu Kubernetes Grid (TKG) 服务。TKG 服务用来管理用户态的 Kubernetes 集群，称作 Tanzu Kubernetes Cluster （TKC），可用于运行用户的应用。TKG 在部署 TKC 集群之前，首先创建组成 TKC 集群的虚拟机，虚拟机启动后，由预置在虚机模板里的 Kubeadm 程序部署 Kubernetes 节点。当所有虚拟机都成为 Kubernetes 节点时，集群部署完成。

第二类是混合基础架构服务，提供 Kubernetes 所需要的基础设施，如虚拟机、存储、网络、镜像仓库和 vSphere Pod 等。这些服务使 TKC 可以通过标准接口（如CNI， CSI等）访问基础设施资源。

第三类是定制服务，有合作伙伴或者用户自行开发部署，其原理和前两种相同。此次发布的 vSphere 版本暂时不支持这类服务，将在后续版本中提供。

VCF服务简介（59秒 ）

vCenter API 转为 Kubernetes API

经上述重构之后的主管集群和 Kubernetes 集群已经有几分形似了。要做到十全十美的神似，还有关键一步：支持 Kubernetes 的 API 。为此，VwK 对 vSphere API 进行了封装和改进，向开发者呈现出 Kubernetes API 。

这个 vSphere 版的 Kubernetes API 可谓青出于蓝，除了能管理 Pod 之外，还能够管理 vSphere 的所有基础设施资源，例如虚拟机、存储、网络、容器镜像等。

这里的秘诀要归功于 Kubernetes 的声明式接口和 CRD （Custom Resource Definition）的扩展形式。基础设施的资源可以用 CRD 表示，如上文中的网络、存储、TKC 等都有相应的 CRD。 

用户只需要编写 yaml 格式的文件（一种简洁的文本文件），声明所需要的 CRD 资源，通过 kubectl 命令即可创建和维护 vSphere 的资源了。

用于创建虚拟机的yaml文件例子

熟悉 Kubernetes 的同学都知道，管理 CRD 资源一种较好的方法是通过 Operator 模式。Operator 实际上是运行在 Kubernetes 上的程序，负责管理特定 CRD 资源的生命周期。在 vSphere 的主管集群里面，运行着不少各施其职的 Operator，分别担负起集群、虚机、网络、存储等资源的管理任务。

因为 Operator 是开源和开放的架构，合作伙伴还可以开发定制化的 Operator，实现更丰富的功能。后面还会提到。

增加 CRX 运行 vSphere Pod 

既然 vSphere 提供了 Kubernetes API，那么问题来了：vSphere能直接运行 Pod 吗？答案是肯定的。（注：Pod 是 Kubernetes 特有的运行应用的最小单元，由一个或数个容器组成。）

在 vSphere 7中，ESXi 内置了一个容器运行时（runtime），称作 CRX：Container Runtime for ESXi。CRX 运行 Pod 的时候，先创建一个虚机，然后在虚机内启动一个微小的 Linux 内核，大约 20-30MB 的样子。接着把容器镜像的文件系统挂载到虚拟机之中，最后执行镜像里面的应用。这样就启动了一个Pod 的应用。

用 CRX 运行的 Pod 是跑在一个轻量级虚拟机里面的，这个虚机称作 vSphere Pod （之前称为 PodVM）。vSphere Pod 是以虚拟机的方式产生，比基于 Linux  Container 的 Pod 隔离度更高，安全性更好。另一个好处是可以同时支持 Windows 容器，这点 Linux Container 无法实现。

ESXi 原生 Pod 的架构

上图黄色部分就是基于 CRX 的 vSphere Pod。在创建的时候， NSX 的 Kube Proxy 同步更新网络，存储 CNS 同步创建 VMDK 来绑定 vSphere Pod 需要的PV （Persistent Volume）。

大家对 vSphere Pod 是否有种似曾相识的感觉？没错，VMware 之前的产品VIC 和开源项目 Kata Containers 都采用过类似轻量级虚拟机加载容器的技术。经过几年的积淀，已发展成为比较成熟的技术了。

参加过 VIC 项目的核心工程师，大都在 vSphere 7 里面继续奋战。VIC 支持的是Docker API 和单容器，相比之下，vSphere with Kubernetes 支持 Kubernetes API 和 Pod （可多容器）。

TKC 集群 （应用集群）

前面介绍的主管集群（supervisor cluster）可直接用 Kubernetes API管理 vSphere 的资源，可以运行 Pod。但是需要指出的是，主管集群的并不是完全兼容 Kubernetes API 的，例如 privilege（特权） pod 在主管集群里面就不能使用。其次，主管集群的 Kubernetes 版本是相对固定的，不太可能频繁升级。还有一点，主管集群在每个 vSphere 集群里只有一个，多租户的场景中无法使用不同版本的 Kubernetes。

TKC集群

为此，VwK 提供了 Tanzu Kubernetes Cluster (TKC) 集群，由前文所述的 TKG 服务管理。简单的说，就是部署在虚机里的 Kubernetes 集群，并且符合 CNCF的一致性 （Conformance）认证标准，可以兼容运行在 Kubernetes上的应用。TKC 集群可直接使用内置于主管集群中的 VCF 服务，可以很便捷地获取 Load balancer，PV 等资源。

TKG 服务采用了 Kubernetes 社区的 Cluster API 开源项目。Cluster API 体现了“用 Kubernetes 管理 Kubernetes ” 的思想，即用户把需要创建的集群规范以 CRD 的形式提交给一个 Kubernetes 管理集群，该管理集群根据 CRD 去维护目标集群的生命周期。Cluster API 以 provider 的方式支持多种云服务商。在 vSphere 7 中，主管集群（Supervisor Cluster）就是管理集群，而且只有 vSphere provider。 

Cluster API：用K8s管理K8s

Namespace （命名空间）应用视图

命名空间要点（58秒视频）

之前提到，VwK 为应用提供了单独的视图，称作 Namespace（命名空间）。Namespace 是计算机科学里广泛使用的概念，用来区分不同的逻辑功能或实体，如编程语言里面的 namespace ，Linux 的 namespace，容器 registry 里面的 namespace 等等。VwK 在主管集群中借鉴并扩展了 Kubernetes 划分虚拟集群的概念 namespace 。

Namespace 和主管集群、SDDC 的关系

Kubernetes 的 namespace 对应用做了逻辑上的隔离，形成虚拟集群，优点是每个 namespace 可以单独设置资源管理策略，如统一控制网络访问策略。

VwK 在主管集群中增设了namespace ，可以包括容器、虚拟机和 vSphere Pod 等资源。应用所需的资源，如 Pod 和虚拟机等，都收纳于一个 namespace 之下。由于 Namespace 是面向应用的逻辑单元，只需要对 namespace 配置 Quota， HA， DRS，网络、存储、加密和快照等策略，就可以对应用的所有虚拟机和 Pod 等资源进行管控，大大方便了运维管理。

用户界面上的 namspace（左侧导航栏）

从技术实现的角度看，当管理员创建 namespace 的时候，vSphere 自动在后台创建一个对应的资源池 （Resource pool），对应着 namespace里的所有资源。之后对 namespace 的管控实质上都是转化为资源池的操作。

Namespace由 Resource pool支持

Namespace 是 VwK 的一项创新，定义了管理员和开发人员的边界，实现面向应用的管理，提高了新应用的开发效率。管理员在 vCenter 创建 namespace 后，可交给开发人员使用。开发人员用 Kubernetes API 在 namespace 中创建应用所需虚拟机、vSphere Pod，或者 Kubernetes 集群 （TKC 集群）等资源，不再需要管理员的介入。管理员只需要管理好 namespace 的资源策略，即使开发团队在里面呼风唤雨，翻天覆地，管理员也可高枕无忧了。

内置 Harbor Registry

Harbor Registry 中国用户一定不会陌生，VwK 的镜像仓库服务由 Harbor 开源镜项目提供，确保镜像安全和提高性能。当创建 namespace 时，会同时建立一个 Harbor 的项目与其对应，提供该 namespace 下的镜像服务。这个设计理念我们团队已经构思很久，现在终于体现在 vSphere 里面了。

万事皆服务

Kubernetes 的联合创始人 Joe Beda 说过一句经典的话：“ Kubernetes 是平台的平台，可以用来构建新的平台”。这句深刻地阐明了 Kubernetes 创建者对产品的定位和设计理念。Kubernetes 不仅可管理容器编排服务，还可以通过扩展，管理其他服务，如数据库、函数服务、人工智能服务等等。

这个理念在 vSphere with Kubernetes 里面得到了充分体现：vSphere 平台可以构建各类服务（ XXX as a Service ）。我们只需在主管集群里面部署特定服务的 Operator ，就可以用该 Operator 运维相应的服务。

主管集群成为控制平面，可管理各种服务

上面提到的 TKC 集群实质上就是 Kubernetes as a Service，它的 Operator 已经内置在主管集群中。同样的，我们也可以部署 VM as a Service, MySQL as a Service 等服务的 Operator，达到管理这些服务的目的。

Operator 是开放架构，合作伙伴可以开发出各类功能的服务，并且部署和运行在主管集群中，这将使得围绕 vSphere 的生态系统百花齐放，成为名副其实的“平台的平台”。

vSphere with Kubernetes 使 vSphere 蜕变成改变游戏规则的新一代现代化应用平台，无疑是VMware Tanzu 组合中最闪亮的组件。

VMware 本次新产品发布还包括 Tanzu 套件，VCF 4等产品。大家可关注官网，或者留意笔者后续的文章介绍。