感觉未来Kubernetes可能更多是跟虚拟机扯上关系，容器反而没那么绝对了

直接整理自网络观点,不对其进行重写或重新排版】

感觉未来Kubernetes可能更多是跟虚拟机扯上关系,容器反而没那么绝对了，这个说法听起来有点反直觉，因为Kubernetes（K8s）最初就是作为容器编排的王者出现的，它的崛起和Docker引领的容器化浪潮密不可分，但现在风向确实在变，很多人开始讨论K8s和虚拟机（VM）更紧密的结合。

为什么会有这种趋势？容器遇到了哪些“麻烦”？

来源中提到,纯粹基于容器的部署方式在一些场景下暴露了局限性，首先就是安全性问题，容器共享主机操作系统内核，这被认为是其轻量、快速的优势，但也成了最大的安全“阿喀琉斯之踵”，如果一个容器被攻破，理论上攻击者有可能利用内核漏洞影响到同一节点上的其他容器，甚至主机本身，对于金融、政府等对安全隔离要求极高的行业，这种“多租户”风险是很难接受的。

遗留应用（Legacy Applications）的迁移是个大难题，不是所有应用都能轻松地拆分成微服务并放进容器的，很多传统企业有大量“巨石应用”，它们可能依赖于特定的操作系统版本、库文件，或者有自己独特的运行方式，把这些应用生搬硬套进容器，不仅工作量巨大，而且可能水土不服，运行不稳定，为了“云原生”而重写所有应用，成本和风险都太高了。

虚拟机如何“卷土重来”？K8s是怎么接纳它的？

这时,虚拟机的价值就重新被看见了，虚拟机通过Hypervisor层实现了强隔离，每个VM都有自己独立的操作系统内核，应用之间互不影响，安全性天然更高，虚拟机非常适合封装那些“原封不动”的遗留应用，直接打包成一个镜像就能运行，省去了复杂的改造过程。

Kubernetes社区很早就意识到了这些问题,并没有固步自封，我们看到了一些关键技术的发展：

1. Kubernetes on VMs：这已经是多年的标准实践了，K8s的节点（Node）本身很多就是运行在虚拟机上的，在公有云上，你创建的Kubernetes集群，其控制平面和工作节点通常都是云厂商提供的虚拟机实例，K8s和VM从来就不是对立关系，而是底层基础。
2. 虚拟机作为K8s的工作负载（Workload）：这是更具革命性的一步，像KubeVirt这样的开源项目，允许用户将虚拟机像容器一样，作为一个Pod里的一个“特殊”容器来管理和调度，你可以在同一个K8s集群里，既有容器化的微服务，也有完整的虚拟机，使用相同的kubectl命令就能管理虚拟机的生命周期（创建、删除、伸缩等），这相当于用K8s统一了容器和虚拟机的编排层。
3. 安全容器（Secure Containers）：这类技术，如Kata Containers，可以看作是容器和虚拟机的“杂交品种”，它用起来像容器（符合OCI标准镜像，可以用Dockerfile构建），但运行时每个Pod都运行在一个轻量级虚拟机里，从而实现了内核级别的强隔离，兼顾了容器的体验和虚拟机的安全。

未来会是什么样子？“没那么绝对”是什么意思？

来源观点认为,未来的趋势是Kubernetes成为一个真正的“通用编排平台”，而不仅仅是“容器编排平台”，它的管理对象会变得多样化：

• 容器：仍然是主角，尤其是为云原生设计的新应用，其敏捷、高效的优势无可替代。
• 虚拟机：通过KubeVirt等技术，成为K8s管理的一等公民，主要用于运行改造困难或安全性要求极高的遗留应用。
• Serverless工作负载：通过Knative等框架，K8s也能管理无服务器函数。

这样一来,对于开发者和管理员来说，他们面对的是一个统一的控制平面（K8s API），而不用关心底层跑的是容器、虚拟机还是其他什么东西，K8s的价值就从“编排容器”上升到了“编排一切计算资源”。

“容器反而没那么绝对了”并不是说容器不重要了，或者会被淘汰，它依然会是新应用开发的首选，这句话的含义是，在Kubernetes的生态里，容器的“唯一性”和“排他性”被打破了，K8s的边界在扩大，它正在包容更多形态的工作负载，其中虚拟机凭借其在安全和兼容性上的固有优势，占据了非常重要的位置，未来的K8s，更像是一个融合了容器敏捷性和虚拟机安全性的超级调度器，为企业提供一种更灵活、更统一的应用部署和管理方式。