文章讨论了在 Kubernetes 上融合虚拟机和容器的趋势，以及构建云原生 VM 平台所需的组件、迁移工作负载的挑战、专业知识孤岛问题，并展望了未来，强调了解决关键问题以实现替代虚拟化平台成功的必要性。
译自：KubeCon Is Starting To Sound a Lot Like VMCon
作者：Dan Finneran
在过去的十年里，“云原生”几乎等同于容器的兴起，并因此导致虚拟机作为工作负载主要抽象方式的地位逐渐下降。但在今年于伦敦举行的 KubeCon 欧盟大会上，这种叙事开始发生转变。在走廊交流、项目展区和主旨演讲中，一个反复出现的主题浮出水面：虚拟机不会消失；它们正在与容器融合（或者至少变得与容器相邻），而 Kubernetes 正在成为两者的通用控制平面。
这种日益增长的重叠不仅仅标志着工作负载的共存。它标志着一个重大的平台重构浪潮的开始，Kubernetes 不仅仅是编排 Pod，而且正在成为运行虚拟机、遗留应用程序和面向未来的工作负载的运营模式。正在形成的不仅仅是一次技术迁移，而是对基础设施团队如何看待系统边界、运营责任以及他们用于部署和保护应用程序的抽象方式的重新设计。
在 KubeCon 上展示了一些最具启发性的线索，开源势头、市场压力和新工具已经开始巩固一个曾经边缘化的想法：Kubernetes 作为所有工作负载的基础。随之而来的是一些引人入胜的含义。
迁移到某个地方的迫切需求
一个长期的“稳定”时期预计即将结束，尤其是在我们谈论虚拟化工作负载时。目前虚拟工作负载的现有平台正在给其客户和最终用户造成各种类型的动荡。许可变更预计将大幅增加运营支出，迫使中小型客户迅速寻找替代方案。此外，取消选择实际所需产品的灵活性，并要求客户再次购买整个产品组合，这既增加了成本，又强制使用复杂的平台和更多不必要的资源。
不幸的是，目前，当人们试图确定重新平台化其虚拟工作负载的“某个地方”将是哪里时，未来并不确定。话虽如此，这里是 KubeCon。可以有把握地假设，Kubernetes 将（如果尚未）作为其基础设施中工作负载的平台。这不可避免地会引发一场关于构建潜在的“所有工作负载的单一平台”的对话需要什么！
构建云原生 VM 平台需要哪些组件
下一代 VM 平台的基础必然是 Kubernetes，但不幸的是，Kubernetes 在（我个人看来）启动和运行方面有点声名狼藉，认为它很难。这在 Kubernetes 的早期可能更真实，当时需要各种 OpenSSL 魔法和来回复制证书以及各种 etcd 调整。
不过，好消息是，这些日子已经过去了，Kubernetes 项目拥有像 kubeadm 或 cluster-API 这样的工具，可以自动启动 Kubernetes 节点甚至整个集群。此外，如果你想要一个完整的开箱即用体验，那么有许多经过认证的、供应商支持的 Kubernetes 发行版，它们将提供企业级的安装和支持。
Kubernetes 和云原生周围的生态系统可以说是最繁荣的生态系统之一，因此创建了几个项目来支持与容器化工作负载一起运行虚拟机也就不足为奇了。在 GitHub 上快速搜索一下，就能找到一些超过 9 年历史的项目！然而，很明显，一个项目已经成为在 Kubernetes 上启用虚拟工作负载的事实标准，那就是 kubevirt 项目，这也是大多数企业 Kubernetes 产品的基础！
该项目打包了在 Linux 主机上运行虚拟机所需的所有组件（即 qemu、libvirt 和其他辅助工具），并通过虚拟机等附加对象进一步增强了 Kubernetes。现在，一个控制平面可以通过完全相同的方式使用 kubectl get pods 检索正在运行的 Pod，或者使用 kubectl get virtual machines 检索虚拟机。
迁移工作负载
多年来，已经出现了多种类型的工作负载迁移，我们目前正处于“现代化到云原生”时代。然而，在所有这些工作负载需要迁移到虚拟平台之前，这在很大程度上是通过 P2V 软件完成的，P2V 软件是一种物理到虚拟的转换。此过程通常是在物理机器中安装一个代理，该代理能够读取磁盘的内容，然后此代理将连接到虚拟平台，在该平台上将创建一个目标 VM，其中包含磁盘的复制内容。一个听起来简单的过程，但是，物理机器有各种各样的物理设备，每种设备都需要各种设备驱动程序。通常，在 p2v 之后，你会发现你的虚拟机将不再正确启动，因为这些设备驱动程序找不到硬件，或者设备现在看起来有所不同。
这些担忧今天仍然存在，从一个虚拟机管理程序迁移到另一个虚拟机管理程序被称为 v2v，并且仍然具有相同的注意事项，因为不同的虚拟机管理程序模拟不同的设备。迁移到 kubevirt 通常意味着迁移到 virtio 设备，这再次可能意味着在移动后启动时系统会感到困惑/损坏。
孤岛式专业知识
很多讨论都集中在许多公司已经投入大量时间和精力来雇用和培训团队来管理其当前的虚拟化平台。这就提出了很大的问题，即谁（哪个团队）将构建平台，工作负载如何共享平台，每个工作负载（VM 和容器）应该有一个集群吗？以及最终，谁将从日常角度 运营和拥有集群。
从所需的 开源组件构建一个全新的平台将需要大量的 Kubernetes 经验，并且可以提供运行虚拟工作负载的能力。然而，使用此平台的经验与人们以前习惯的截然不同，这已不是什么秘密。用于创建虚拟机或将 VM 移动到不同网络的清晰用户界面根本不存在。与所有 Kubernetes 一样，它将是 YAML，以及大量的 YAML。
未来可能是什么样子？
幸运的是，这并非都是厄运和悲观！为了改善体验，正在进行大量工作。最初出现了一些处理虚拟机运行的项目；然而，生态系统似乎已经确定 kubevirt 是显而易见的选择。这导致了 kubevirt 项目的提交者涌入，增加了多个新功能和稳定性改进。此外，正在开发端到端解决方案以降低运营复杂性，例如 SUSE 的 Harvester 项目或 Red Hat 的 OpenShift Virtualization。
为了使任何新的虚拟化平台取得成功，肯定需要解决以下几个关键问题：
- 需要实施在其当前现有平台中给定的预期同类功能，考虑动态资源管理与工作负载迁移功能相结合
- 一种将虚拟机从一个平台移动到另一个平台的清晰有效的方法
- 减少运营开销，从而可以轻松管理新的虚拟化平台
替代虚拟化平台（建立在 Kubernetes 之上）的当前状态仍然存在差距，但是，由于这都是 开源的，因此没有任何人可以阻止任何人做出贡献 并帮助推动事情发展！
我们看到的第一波浪潮是将虚拟机置于 Kubernetes 的保护伞之下。但仔细观察，你会发现堆栈中也存在类似的冲突：负载均衡器变成服务网格，防火墙在启用 DPU 的交换机内部运行，并且 可观测性 管道直接馈送到安全引擎。曾经的硬边界正在变成模糊的融合区域。
如果虚拟机和容器不再是对立的，而是同一平台中的对等体，那么接下来会崩溃的其他二分法是什么？
