🧱 容器很爽，但 VM 还活着

——聊聊 K8s 上的混合工作负载：KubeVirt 到底是不是救命稻草？

先说一句可能不太“先进”的大实话：

不是所有业务，都配得上被“容器化”。

这话我不是反容器，相反，我是 Kubernetes 的坚定支持者。但这些年在一线折腾下来，我越来越清楚一件事：

• 新业务：容器是真香
• 老系统：能跑就不错了
• 全量容器化：很多时候是 KPI 驱动的“技术浪漫主义”

于是问题来了👇
能不能让 VM 和容器，在一个 K8s 体系里“和平共处”？

答案就是今天的主角：KubeVirt。

一、为什么“纯容器化”在现实里经常翻车？

先别急着谈方案，咱得先把问题讲清楚。

1️⃣ 你身边一定有这种系统

• Oracle / DB2 / 商业中间件
• Windows Server + .NET 老服务
• 启动 5 分钟、停机 10 分钟的“祖宗级应用”
• 强依赖内核参数、设备、license 的玩意儿

你跟它说：“来，做个 Dockerfile。”

它回你一句：

“你礼貌吗？”

2️⃣ 运维的真实困境

• 云平台：VM 是一等公民
• K8s：容器是唯一真理
• 结果：两套体系、两拨人、两种运维模型

久而久之就变成了：

• 资源调度割裂
• 监控告警割裂
• 发布流程割裂
• 运维心智直接裂开

所以很多团队会问一句很朴素的话：

能不能 VM 也当成 K8s 的一个“工作负载”？

这不是偷懒，这是工程现实。

二、KubeVirt 是啥？一句话讲明白

不绕弯子，直接人话版定义：

KubeVirt = 在 Kubernetes 里，把虚拟机当成 Pod 来管。

注意，是**“管”**，不是把 VM 变成容器。

• VM 还是 VM
• QEMU / KVM 还是那套
• 只是生命周期、调度、网络、存储，统一交给 K8s

你可以理解为：

K8s 负责调度，KubeVirt 负责“在节点上起 VM”。

三、KubeVirt 的核心价值，不是“炫技”

我一直觉得，KubeVirt 吸引人的点不是“技术很酷”，而是它解决了三个特别现实的问题。

1️⃣ 统一调度：资源终于不打架了

以前是：

• 容器用 K8s 调度
• VM 用 OpenStack / 云平台调度

现在是：

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: legacy-vm
spec:
  running: true
  template:
    spec:
      domain:
        resources:
          requests:
            memory: 8Gi
            cpu: 4

VM 和 Pod 进了同一个调度池。

• 谁占多少 CPU
• 谁抢内存
• 谁该被驱逐

全部一套规则。

📌 我个人非常看重这一点：
资源统一调度 = 成本终于算得清了。

2️⃣ 生命周期统一：VM 也能 GitOps 了

以前 VM 的生命周期是啥？

• 手工点控制台
• 运维脚本
• 文档 + 口口相传

现在你可以：

• VM 定义即 YAML
• 纳入 Git 管理
• 用 Argo CD / Flux 去发布

spec:
  running: false

一行 YAML = 关机。

这对运维意味着什么？

“不可控的资产”终于变成了“可声明的资源”。

3️⃣ 渐进式现代化，而不是一刀切

这是我最认可 KubeVirt 的地方。

现实里，真正可行的路径往往是：

1. 老系统先 VM 化
2. 跑在 KubeVirt 上
3. 新模块容器化
4. 逐步拆、慢慢换

而不是：

“Q3 全部容器化，Q4 不成功就加班。”

KubeVirt 给的是缓冲区，而不是压力锅。

四、一个典型的混合工作负载架构长啥样？

我画个“脑补版”的结构（你肯定见过）：

• 同一个 K8s 集群里

  • Deployment（新服务）
  • StatefulSet（数据库）
  • VirtualMachine（老系统）

网络：

• Pod 用 CNI
• VM 通过 Multus 接同一张二层网

存储：

• PVC 给容器
• 同一个 StorageClass 给 VM 磁盘

监控：

• Prometheus 统一抓
• VM 通过 exporter 暴露指标

一句话总结：

对运维来说：一套平台
对业务来说：没感觉

这就是好方案。

五、但我得泼点冷水：KubeVirt 不是银弹

说点很多布道文章不爱说的。

1️⃣ 性能 ≠ 裸 VM

• 多了一层抽象
• I/O 敏感场景要谨慎
• NUMA、HugePage 要认真调

👉 适合“能跑就行”的老系统，不适合极致性能场景。

2️⃣ 运维复杂度是“转移”，不是“消失”

你以前要懂：

• KVM / libvirt

现在你要懂：

• K8s + KubeVirt + CNI + 存储

如果团队 Kubernetes 还没玩明白，
直接上 KubeVirt 是给自己上难度。

3️⃣ 不是所有人都该用

我给一个非常个人的判断标准：

👉 当你的“容器化焦虑”大于“VM 运维痛苦”时，再考虑 KubeVirt。

否则，大概率会变成：

• 技术很先进
• 团队很疲惫
• 效果很一般

六、我的真实态度：KubeVirt 是“成熟团队的工具”

说句掏心窝子的总结：

• KubeVirt 不适合“想省事”的团队

• 它适合：

  • 已经全面 K8s 化
  • 但被历史系统拖住脚
  • 又不想维护两套体系的团队

它的价值不在于“替代 VM”，
而在于：

让你有尊严地对待遗留系统。

系统可以老，但运维体系不该老。

七、写在最后

如果你现在：

• 一边高喊 All in K8s
• 一边偷偷养着一堆 VM
• 运维天天在两套系统间横跳

那 KubeVirt 值得你认真看一眼。

不是为了炫技术，
是为了让 系统演进这件事，别总靠“硬上”。

技术最终服务的不是架构图，
是活生生的团队和业务。