容器与虚拟化的完美融合 - VMware Project Pac

介绍

今天VMware发布了技术预览版的Project Pacific，这项技术将为广大的企业私有云建设者提供新的思路。

Project Pacific给vSphere增加了一个新的控制平面，使用户可以用Kubernetes管理vSphere。 对于开发人员来说，Project Pacific就像是一个增强的Kubernetes集群，可以使用Kubernetes声明式语法来管理虚拟机、磁盘和网络等资源。 对于IT管理员来说，Project Pacific仍旧是vSphere，但是添加了以应用为边界的整体管理的能力，而不是单独管理许多个独立的组成应用的虚拟机或者容器。

Project Pacific可以利用企业现有的SDDC投资、人员技能和工具，加速vSphere平台上现代化应用的开发和运营。 通过利用Kubernetes作为vSphere的控制平面，Project Pacific允许企业利用一个融合的平台同时运行传统应用和现代化应用。

现代化应用的挑战

在企业环境中，现代化应用通常是由很多种不同的技术组件组成的，有些组件运行在容器中，有些组件运行在虚拟机中（如数据库），有时需要访问遗留系统，甚至有些需要访问FaaS。这些组件分布式的部署在不同的运行环境中，通常由不同的团队开发和维护。

企业环境现代化应用

这样的应用架构给开发人员带来了困扰，你不能只关注Kubernetes，因为很多组件并没有运行在容器中。一旦部署了这样的应用程序，如何维护并更新它？可以使用哪些工具来监控、诊断和调试部署？

同样，基础设施部门也面临了新的问题。为了支持容器和虚拟机共存的应用，有些企业不得不在vSphere集群外搭建一套新的容器集群，这种做法引入了新的孤岛，并且多个集群的运维管理工具和方法是完全不同的，应用治理的策略也无法同步到两种类型的集群中。

Kubernetes作为平台的平台

Kubernetes的联合创始人Joe Beda说过，“Kubernetes是一个平台的平台，可以用来构建新的平台”。是的，Kubernetes是一个容器编排平台，但是依赖Kubernetes的核心原则我们能够编排任何东西！如果我们用Kubernetes的方式重新架构vSphere，让vSphere运行在Kubernetes之上会是什么效果呢？那么，开发人员想要创建虚拟机、容器或Kubernetes集群，他们只需要编写一个Kubernetes YAML文件并使用kubectl部署它，就像使用任何其他Kubernetes对象（Pod，service，ingress）一样。

使用Kubernetes作为vSphere API

通过这个理念，开发人员可以将Kubernetes良好的使用感受从云原生应用扩展到数据中心中的任何类型的应用。使他们可以轻松地部署和管理跨多个技术堆栈的现代化应用。

以应用为中心的管理

vSphere提供了很多针对虚拟机的管理功能，vMotion、HA、snapshot、加密、配额管理、存储策略等。但现代化应用一般来说不是一个虚拟机，它可能是几十个虚拟机加上更多的容器。 对于现代化应用来说，从整个应用层面实现以上的功能就比较困难了。

幸运的是，Kubernetes带来了另一个可以解决这个问题的概念：Namespace。 Kubernetes中的Namespace是资源对象（容器、VM、磁盘等）的集合。 如果我们使用Kubernetes Namespace来模拟现代应用，然后将针对虚拟机的管理功能在Namespace上实现，那么就可以一次控制整个应用的资源分配、vMotion、加密、HA和快照，而不必单独配置每个虚拟机或者容器。

Namespace作为管理单元

这对IT管理员有两个真正的变革性影响。

首先，我们认为这为IT管理员提供了巨大的生产力提升。 过去，您可能在vCenter清单中有数千个虚拟机需要处理。 但是，一旦将这些虚拟机分组到其逻辑所属的应用中，您可能只需要处理几十个Namespace。 过去，如果您想加密应用程序，则必须先找到属于该应用程序的所有虚拟机，然后在每个虚拟机上启用加密。 现在，您只需单击vCenter中Namespace上的按钮即可完成所有操作。 您可以获得巨大的生产力提升，因为您可以处理应用而不是单个虚拟机。

其次，我们认为Namespace为开发人员提供了更好的自助服务模型。 使用Namespace，IT管理员可以在Namespace上设置一次策略，然后将Namespace权限分配给开发人员，Namespace中的每个对象都将继承统一设置的策略。 开发人员可以快速、自助的创建任何他需要的资源，虚拟机、容器、Kubernetes集群等，而IT只需要从应用的整体维度来确保资源的使用符合公司的策略。

Kubernetes原生的vSphere平台

Project Pacific将Kubernetes控制平面直接集成到ESXi和vCenter中 - 使其成为ESXi的控制平面，并通过vCenter提供以应用为中心的管理功能。

Kubernetes原生的vSphere平台

Supervisor clusters

Supervisor cluster是一种特殊的Kubernetes集群，它将ESXi节点变成Kubernetes的worker node。 这是通过将类似kubelet的agent（Spherelet）直接集成到ESXi中实现的。 Spherelet不是虚拟机，它是ESXi上的一个进程。

把vSphere Cluster变成Kubernetes Cluster

ESXi Native Pods

部署在Supervisor上的Pod，每个Pod都在一个隔离的轻量级虚拟机中运行。 这个轻量级的虚拟机就是CRX，包含一个Linux内核和最小容器运行时。

经过测试，ESXi可以在100毫秒内启动native pod，在单个ESXi主机上支持超过1000个pod。 在我们的内部测试中，我们已经证明了ESXi Native Pods在SPECjbb2015基准测试中的吞吐量比虚拟机中的常规Pod高出30％，比裸机Linux上的Pod快8％！

虚拟机

Supervisor cluster提供VM operator，允许用户以Kubernetes的方式管理虚拟机。用户可以在一个yaml文件中描述虚拟机的部署规范和其所需的网络和存储资源。
VM Operator 对于私有云建设有着重大的业务价值，请参考另一篇文章。新一代企业私有云建设的“底座”
VM Operator只是作为vSphere管理虚拟机的补充，这意味着用户可以继续使用vSphere的所有功能，来管理Kubernetes置备出的虚拟机实例。

Guest cluster

虽然Supervisor cluster已经是一个Kubernetes集群，但是它的设计目标是用来管理vSphere，而不是通用的业务部署平台。这样设计的原因有以下几个，

• Kubernetes的最佳实践是多集群，不同的租户使用不同规格（版本、规模）的集群。而一个vSphere的cluster就是一个Supervisor cluster，这种方式不符合最佳实践。当租户需要不同版本的Kubernetes的时候，Supervisor cluster不能够满足要求。
• Supervisor cluster内置在vSphere中，只能随着vSphere版本的升级而升级。一般来讲，用户要求Kubernetes的版本可以随时升级，而不希望频繁的升级底层的vSphere。
• 为了安全原因，Supervisor cluster禁止了privilege等一些特殊模式。而有些时候用户需要这些模式的集群。

Guest Clusters 很好的解决了以上的问题，Guest Clusters可以提供通用的Kubernetes给用户。Guest Cluster是一个Kubernetes集群，它在Supervisor Cluster上的虚拟机内运行。 Guest Cluster是完全符合CNCF认证的Kubernetes，因此可以保证兼容任何运行在Kubernetes上的应用。

vSphere中的Guest Clusters使用开源Cluster API项目来生命周期管理Kubernetes集群。

Guest Cluster

镜像仓库

为了运行容器，用户需要一个镜像仓库。 因此，Project Pacific将Harbor集成到vSphere中，您可以从vCenter直接打开Harbor。 每个Namespace都是Harbor中的一个project。

总结

Project Pacific是VMware在Kubernetes领域一个里程碑的发布。如果您想了解更多细节，敬请关注本周在VMworld上的相关内容。VMWorld

本文翻译补充自 - Project Pacific 技术概览