天啦撸，你的虚拟机还没放进容器？

【编者的话】本文旨在探索KubeVirt和Kata Containers，这两个相当新的项目如何将Kubernetes与虚拟化结合起来。

容器和Kubernetes在业界被公认为“颠覆性”技术的代表，它们将取代之前的所有技术，特别是vSphere和OpenStack等虚拟机（VM）管理平台（被取代是早晚的事）。相反，与大多数平台的创新过程一样，Kubernetes更多地被用于添加一个图层到虚拟机（或组件）。在本文以及SCALE16x的演讲中，我们将探索两个相对较新的项目，旨在帮助用户将Kubernetes与虚拟化相结合，它们就是：KubeVirt和Kata Containers。

大多数组织仍然会在虚拟主机上运行他们的应用程序，而且会持续不断的投资更多money来运行它们的基础架构以及管理它们的工具。我们可以预见这种情况在未来很长一段时间内是客观存在的，就像前几代技术的残余物现在仍然存在一样。此外，虚拟机技术仍然提供一定程度的隔离，使得容器启用功能（如用户命名空间）尚未达到要求。但是，目前很多组织都想要Kubernetes的易用性，可扩展性和开发人员对Kubernetes的吸引力，以及逐渐从虚拟化工作负载转换到容器工作负载的方式。

Kubernetes最近添加的服务目录功能在一定程度上解决了集成问题。此功能允许Kubernetes创建“端点”，因此容器化的应用程序可以将请求路由到其他地方来运行应用程序，例如在OpenStack集群上。但是，这种方法不能提供统一管理虚拟化和容器化应用程序的方法，也不能提供任何方式让Kubernetes应用程序成为VM平台环境和命名空间的一部分。

开发人员在去年启动了多个项目来满足这些集成要求。虽然技术细节存在很多差异，但在较高层次上，这些项目可以分为两个对比的使用目标：

• 作为复杂应用程序的一部分，将传统VM工作负载与应用程序容器一起运行
• 使用硬件辅助的VM级别隔离来运行应用程序容器工作负载，以实现安全性和资源管理

这些用例意味着不同类型的源图像和用户期望的工作流程、启动速度和内存开销。

在传统的虚拟机工作负载中，用户期望能够运行现有的虚拟机镜像或者至少轻松地转换一个（ 包含完整的操作系统和应用程序，并且具有启动时间和内存开销）。这甚至可能是与主机不同的操作系统，并且它可能对使用容器无法实现的虚拟设备和内存地址有特定的要求。

在应用程序容器工作负载情况下，用户希望能够将符合Open Container Initiative标准的容器镜像作为VM运行。他们还希望像任何其他应用程序容器一样快速启动，并且可以更直接映射到应用程序，而且将使用的内存开销更低。他们使用VM的原因是他们希望硬件强制隔离工作负载，无论是安全还是性能。

现在，我们来比较一下两个这样的项目：用于传统VM用例的KubeVirt和用于隔离用例的Kata Containers。

用于传统虚拟机的KubeVirt

KubeVirt项目是由三个红帽工程师在2016年年底推出。该项目的目标是通过一个应用程序，来帮助企业从基于虚拟机的基础设施一次迁移到以容器为主的Kubernetes圈。这就为用户提供了一种来方便处理由本地Kubernetes应用程序（包括管理和路由）在内的现有VM开发工作流程构建的应用程序。同时，这些应用程序中的许多应用程序都需要大量的VM本机配置才能运行。

Kubernetes 1.7于2017年6月发布，其中包括最强大的扩展API Custom Resource Definitions（CRD）。CRD基本上可以让开发人员为Kubernetes系统创建一个全新类型的对象，并定义该对象的特征和功能，然后将其加载到正在运行的集群中。对于那些希望虚拟机像虚拟机一样运行的KubeVirt贡献者来说，CRD是一个完美的界面，并且该项目已被重构。

拥有现有基于KVM的VM工作流程的用户需要添加一个自动步骤，这会对KubeVirt环境的镜像进行一些更改。完成后，可以像使用其他Kubernetes对象一样，使用YAML清单将镜像部署到Kubernetes集群。KubeVirt将每个已部署的虚拟机“包装”在一个容器中，即在Kubernetes中部署的基本单元，通常包含一到几个容器而不是虚拟机。这允许与正常的基于容器的Pod一起部署的其他服务几乎无缝集成。分配的虚拟磁盘将成为Kubernetes持久性卷，并且可以利用集群已有的任何存储空间。

CRD机制还意味着KubeVirt项目可以定义额外的“按钮（knobs）”来调整常规容器中不可用的行为，例如虚拟设备和CPU特性。虽然并非所有功能都已完成，但现有功能包括：

• 使用不同的操作系统创建VM，包括Windows
• 为每个VM配置CPU，RAM和虚拟磁盘
• 将VM直接连接到串行或网络控制台
• 使用cloud-init进行VM启动时配置

更重要的是，可以使用Kubernetes的标准命令行界面kubectl来检查和控制KubeVirt虚拟机，就好像它们是常规的容器一样。由于管理员有时需要连接到虚拟机的“控制台”，KubeVirt附带了一个额外的CLI工具virtctl，就像这样：

virtctl console --kubeconfig=$KUBECONFIG testvm

KubeVirt项目正在快速发展中并不断寻找更多的贡献者。你可以通过其GitHub repo和其论坛，或者在Kubernetes’Slack的#virtualization频道中与KubeVirt团队联系。

Kata容器：用于隔离的虚拟机

与虚拟机一样，容器也用于运行云应用程序。由于非常快速的自动化容器部署和启动，以及较低的CPU和内存使用率，容器云受到欢迎。这些支持在VM环境中无法实现的开发和管理模型。然而，工作负载的安全隔离也是许多云所有者的目标，这在容器堆栈中更难实现。该Kata容器项目旨在提供虚拟机的安全隔离与容器的运行速度。

主机上的Linux内核使用内核命名空间将各种应用程序容器中运行的工作负载隔离开来，以及SELinux和SECCOMP等各种内核进程限制技术。虽然内核中的命名空间隔离性不断提高，但它仍然没有（并且可以说永远不会）提供与在现代CPU上运行的硬件辅助虚拟化相同级别的隔离。如果不做点什么的话，容器环境中的木马脚本和应用程序错误仍然可以使“用户”访问任何未修补的内核漏洞。

虽然类似KubeVirt的方法提供了VM级别的安全隔离，但同时也会给管理员带来额外的管理负担，部署速度较慢以及虚拟机pods的启动时间较慢。对于想要快速开发基于容器的开发工作流程而不关心与传统平台的兼容性的开发人员来说，这是一个糟糕的情况。kata容器采用不同的方法来获得容器般的速度，使用精简的VM平台和不同的Kubernetes API。

英特尔在2015年推出了名为Clear Containers的容器项目。作为英特尔Clear Linux计划的一部分，Clear Containers实施了一种保护容器的方法，该方法利用了Intel CPU虚拟化硬件。同时，一家名为HyperHQ的北京创业公司推出了Hyper解决方案，该方案采用了类似的方法来解决容器隔离问题。在KubeCon，2017年12月，这两个项目已宣布他们将合并为Kata Containers项目（由OpenStack基金会主办）。

由于Kata Containers项目仍处于早期开发阶段，因此我们将着重介绍Clear Container 3.0的工作流程和体系结构，我们坚信最终发布的Kata Containers版本将与之非常相似。

Clear Containers 3.0不是通过像KubeVirt这样的CRD提供顶级API对象，而是提供了一个与Open Containers Initiative（OCI）兼容的运行时实现，称为cc-runtime。然后使用不同的扩展API（Container Runtime Interface，CRI）将Kubernetes插入到Kubernetes中，从而使Kubernetes能够在不同的容器平台（包括Docker，containerd，rkt和CRI-O）上运行。实际上，Kubernetes将Clear Container VM视为容器的一种不同“风味”。实际上，这也需要对每个Kubernetes节点进行一些额外的配置。

cc运行时“容器”运行一个“mini O / S”镜像，尽管技术上它是一个完整的虚拟机，但只包含一个精简的Linux内核和其他一些操作系统机器。结合英特尔虚拟化硬件中添加的优化功能，这使得容器虚拟机的启动速度比传统虚拟机快得多，同时还可以使用更少的系统资源。虽然它们比普通的Linux容器慢，但就速度而言足以集成到基于容器的开发工作流程中。

在Kubernetes-Clear Containers集群中，可将pod指定为受信任或不受信任。受信任的容器使用常规的基于runc的容器运行时。对于不受信任的pod，运行时将创建一个轻量级VM，然后生成该VM内的pod中的所有容器。由于默认情况下Kubernetes集群可以配置为可信或不可信，这意味着管理员可以添加额外的硬件辅助虚拟化隔离，而无需改变工作负载定义。

在接下来的几个月中，英特尔，HyperHQ和越来越多的公司将致力于将Clear Container和Hyper实施整合到新生的Kata Containers项目中。

VM容器融合和未来

尽管KubeVirt和Kata Containers都分享了他们的想法、他们的一些支持公司以及整合虚拟机和容器的愿望，但这两种根本不同的方法似乎不可能协调一致。KubeVirt旨在提供尽可能多的虚拟机功能，而Kata容器则试图为虚拟机提供类似容器的体验。与其他不可调和的架构愿景一样，我们希望看到一些用户可以根据自己的情况，同时使用这两种方法来处理不同的工作场景。

当然，还有其他工具和实现旨在融合虚拟机和容器，例如Virtlet和RancherVM。一般来说，这些项目采取上述两种方法之一，尽管它们可能具有与KubeVirt和Kata Containers不同的具体细节（基本都是大同小异）。无论采用何种工具，想要迁移到Kubernetes的VM管理员和希望获得更好隔离的容器开发人员都期待更易于管理和更加统一的未来。

你可以了解更多有关Kubernetes和虚拟机You got your VM in my container，由Josh Berkus和贾森-布鲁克斯在南加州Linux世界博览会的演讲，其中包括演示和示例代码。另外，KubeVirt和Kata Containers都在积极寻找贡献者。如果你感兴趣，你可以在他们的GitHub页面或Kubernetes Slack上的#virtualization频道上找到他们。

原文链接：You got your VM in my container（翻译：dssky2008）