Steve Gordon 共同撰写了本文。
容器和 Kubernetes 长期以来被广泛宣传为“颠覆性”技术，将取代之前的一切，最显著的是虚拟机 (VM) 管理平台，如 vSphere 和 OpenStack。然而，与大多数平台创新一样，Kubernetes 更常用于为虚拟机添加一层（或作为补充）。在本文以及 SCALE16x 的演讲 中，我们将探讨两个相对较新的项目，旨在帮助用户将 Kubernetes 与虚拟化相结合：KubeVirt 和 Kata Containers。
大多数组织仍然在运行于虚拟化主机上的应用程序、运行它们的基础设施以及管理它们的工具方面拥有大量现有投资。我们可以预见这种情况在未来很长一段时间内都将如此，就像现在仍然存在着前几代技术的遗留物一样。此外，虚拟机技术仍然提供容器化功能（如用户命名空间）尚未达到的隔离级别。然而，这些组织也希望获得 Kubernetes 的易用性、可扩展性和开发者吸引力，以及一种从虚拟化工作负载逐步过渡到容器化工作负载的方法。
Kubernetes 最近添加的 Service Catalog 功能在一定程度上解决了集成问题。此功能允许 Kubernetes 创建“端点”，以便容器化应用程序可以将请求路由到在其他地方运行的应用程序，例如在 OpenStack 集群上。然而，这种方法无法统一管理虚拟化和容器化应用程序，也无法让 Kubernetes 应用程序成为虚拟机平台环境和命名空间的一部分。
开发人员在过去一年中启动了多个项目，以满足这些集成需求。虽然技术细节上存在许多差异，但在较高层面上，这些项目可以分为两个对比鲜明的使用目标：
- 将传统虚拟机工作负载与应用程序容器一起运行，作为复杂应用程序的一部分
- 运行应用程序容器工作负载，利用硬件辅助的虚拟机级隔离来实现安全性和/或资源管理
这些用例意味着不同类型的源镜像以及用户在工作流程、启动速度和内存开销方面的期望。
在传统的虚拟机工作负载中，用户希望能够运行现有的虚拟机镜像——或者至少可以轻松转换一个——其中包含完整的操作系统和应用程序，并具有相应的启动时间和内存开销。这甚至可能是一个与主机不同的操作系统，并且它可能对虚拟设备和内存地址有特定的要求，而这些要求无法使用容器来实现。
在应用程序容器工作负载的情况下，用户希望能够将 符合开放容器规范的容器镜像 作为虚拟机运行。他们还期望像任何其他应用程序容器一样快速启动，以及更直接地映射到应用程序将使用的内存开销。他们使用虚拟机的原因是他们希望对工作负载进行硬件强制隔离，无论是为了安全还是性能。
让我们比较两个这样的项目：用于传统虚拟机用例的 KubeVirt 和用于隔离用例的 Kata Containers。
用于传统虚拟机的 KubeVirt
KubeVirt 项目 由三位红帽工程师于 2016 年底启动。该项目的目标是帮助企业从基于虚拟机的基础设施迁移到基于 Kubernetes 和容器的堆栈，一次迁移一个应用程序。这意味着提供一种机制，将通过现有虚拟机开发工作流程构建的应用程序视为原生 Kubernetes 应用程序，包括管理和路由。与此同时，这些应用程序中的许多应用程序需要大量的虚拟机原生配置才能运行。
Kubernetes 1.7 于 2017 年 6 月发布，其中包括 自定义资源定义 (CRD)，这是该项目最强大的扩展 API。CRD 基本上允许开发人员为 Kubernetes 系统创建一种全新的对象类型，并定义该对象的特性和功能，然后将其加载到正在运行的集群中。对于希望其虚拟机像虚拟机一样运行的 KubeVirt 贡献者来说，CRD 是完美的接口，并且该项目围绕它进行了重构。
拥有现有基于 KVM 的虚拟机工作流程的用户需要添加一个自动化步骤，该步骤会对 KubeVirt 环境的镜像进行一些更改。完成此操作后，就可以像其他 Kubernetes 对象一样，使用 YAML 清单 将镜像部署到 Kubernetes 集群。KubeVirt 将每个已部署的虚拟机“包装”在一个 pod 中，pod 是 Kubernetes 中最基本的部署单元，通常包含一个或多个容器，而不是虚拟机。这允许与部署为普通基于容器的 pod 的其他服务几乎无缝集成。分配的虚拟磁盘成为 Kubernetes 持久卷，并且可以利用集群中已有的任何存储。
CRD 机制还意味着 KubeVirt 项目可以定义额外的“旋钮”来调整常规容器中不可用的行为，例如虚拟设备和 CPU 特性。虽然并非所有功能都已完成，但现有功能包括：
- 使用不同的操作系统（包括 Windows）创建虚拟机
- 配置每个虚拟机的 CPU、RAM 和虚拟磁盘
- 将虚拟机直接连接到串行或网络控制台
- 使用 cloud-init 进行虚拟机启动时配置
更重要的是，可以使用 Kubernetes 的标准命令行界面 kubectl 来检查和控制 KubeVirt 虚拟机，就好像它们是普通的 pod 一样。由于管理员有时也需要连接到虚拟机的“控制台”，因此 KubeVirt 附带了一个额外的 CLI 工具 virtctl，它支持此功能。
virtctl console --kubeconfig=$KUBECONFIG testvmKubeVirt 项目正在快速开发中，并正在寻找更多贡献者。您可以通过 其 GitHub 仓库 和那里提到的论坛，或者在 Kubernetes Slack 的 #virtualization 频道中与团队联系。
Kata Containers：用于隔离的虚拟机
与虚拟机一样，容器也用于运行应用程序云。容器云之所以受欢迎，是因为容器部署和启动速度非常快、自动化程度高，以及 CPU 和内存使用率较低。这些使得在虚拟机环境中无法实现的开发和管理模型成为可能。然而，工作负载的安全隔离也是许多云所有者的目标，但在容器堆栈中更难实现。Kata Containers 项目 旨在提供虚拟机的安全隔离和容器的速度。
主机上的 Linux 内核使用 内核命名空间 以及各种内核进程限制技术（如 SELinux 和 SECCOMP）将运行在各种应用程序容器中的工作负载彼此隔离。虽然内核中的命名空间隔离仍在不断改进，但它仍然不能——并且可以说永远不会——提供与在现代 CPU 上运行的硬件辅助虚拟化相同的隔离级别。容器环境中的恶意脚本和应用程序错误仍然可以访问任何未修补的内核漏洞，即使没有其他问题。
类似 KubeVirt 的方法提供了虚拟机级的安全隔离，但也给管理员带来了额外的管理负担、较慢的部署速度和虚拟机 pod 的较慢启动时间。对于想要快速、基于容器的开发工作流程并且不关心与旧平台兼容性的开发人员来说，这是一个糟糕的权衡。Kata Containers 采用不同的方法来获得类似容器的速度，使用精简的虚拟机平台和不同的 Kubernetes API。
英特尔于 2015 年启动了一个名为 Clear Containers 的容器项目。作为英特尔 Clear Linux 计划的一部分，Clear Containers 实施了一种安全容器方法，该方法利用了英特尔 CPU 虚拟化硬件。与此同时，一家总部位于北京的初创公司 HyperHQ 推出了 Hyper，它采用了类似的方法来解决容器隔离问题。在 2017 年 12 月的 KubeCon 上，这两个项目宣布他们将合并为 Kata Containers 项目，由 OpenStack 基金会托管。
由于 Kata Containers 项目仍处于早期开发阶段，我们将解释 Clear Containers 3.0 的工作流程和架构，并相信 Kata Containers 的最终发布版本将非常相似。
Clear Containers 3.0 没有像 KubeVirt 那样通过 CRD 提供顶层 API 对象，而是提供了一个名为 cc-runtime 的开放容器规范 (OCI) 兼容运行时实现。然后，它使用不同的扩展 API，即 容器运行时接口 (CRI) 插入 Kubernetes，CRI 使 Kubernetes 能够在不同的容器平台上运行，包括 Docker、containerd、rkt 和 CRI-O。实际上，Clear Containers 虚拟机被 Kubernetes 视为只是容器的不同“变体”。实际上，这确实需要对每个 Kubernetes 节点进行一些额外的配置。
cc-runtime “容器”运行一个 “迷你操作系统”镜像，该镜像虽然在技术上是一个完整的虚拟机，但仅包含精简的 Linux 内核和很少的其他操作系统机制。结合添加到英特尔虚拟化硬件的优化，这使得容器虚拟机比传统虚拟机启动速度快得多，同时使用的系统资源也更少。虽然它们比常规 Linux 容器慢，但它们足够快，可以集成到基于容器的开发工作流程中。
在 Kubernetes-Clear Containers 集群中，可以将 pod 指定为受信任或不受信任。受信任的 pod 使用常规的基于 runc 的容器运行时。对于不受信任的 pod，运行时会创建一个轻量级虚拟机，然后在该虚拟机内部生成 pod 中的所有容器。由于 Kubernetes 集群可以默认配置为受信任或不受信任，这意味着管理员可以添加硬件辅助虚拟化的额外隔离，而无需更改任何工作负载定义。
在接下来的几个月中，英特尔、HyperHQ 和越来越多的支持公司将致力于将 Clear Containers 和 Hyper 实现合并到新的 Kata Containers 项目 中。
虚拟机-容器融合与未来
虽然 KubeVirt 和 Kata Containers 都分享了一些想法、一些支持公司以及集成虚拟机和容器的愿望，但似乎这两种根本不同的方法永远不可能调和。KubeVirt 旨在提供尽可能多的虚拟机功能，而 Kata Containers 尝试为虚拟机提供类似容器的体验。与其他无法调和的架构权衡一样，我们可以预期看到一些用户同时为不同的工作负载采用这两种方法。
当然，还有其他旨在融合虚拟机和容器的工具和实现，例如 Virtlet 和 RancherVM。一般来说，这些项目采用上述两种方法之一，尽管它们可能具有与 KubeVirt 和 Kata Containers 不同的具体细节。无论使用何种工具，希望迁移到 Kubernetes 的虚拟机管理员和希望获得更好隔离的容器开发人员都可以期待一个更易于管理和更统一的未来。
您可以在 You Got Your VM In My Container 演示文稿中了解更多关于 Kubernetes 和虚拟机的信息，该演示文稿由 Josh Berkus 和 Jason Brooks 在 南加州 Linux 展会 上展示，包括演示和示例代码。此外，KubeVirt 和 Kata Containers 都在寻找贡献者。在他们的 GitHub 页面或 Kubernetes Slack 上的 #virtualization 频道中找到他们。
要参加 SCALE16x 并获得 50% 的门票折扣，请使用促销代码 OSDC 注册。
评论已关闭。