一个让技术管理者睡不着觉的问题#

我这两年听到最多的一句话来自各个企业的技术负责人，他们说：“我们的核心系统跑在几十台 VMware 虚拟机上，已经稳定运行了很多年。我们很想推进容器化，但那些老应用都是十年前甚至更久以前写的，代码库庞大且文档缺失，没人敢动。迁移意味着巨大的风险和成本，不迁移又感觉在技术路线上掉队了。”

这个困境在 2026 年的今天依然普遍存在。虽然容器化和微服务架构已经成为行业的主流叙事，但一个残酷的现实是：全球仍然有超过百分之七十的企业级应用运行在传统的虚拟机环境中。这些应用可能是银行的核心账务系统、制造企业的企业资源计划系统、医疗机构的病人管理系统，或者是航空公司的票务系统。它们太重要了，承载着企业最核心的业务逻辑，但同时又太老了，代码的每一行都可能隐藏着无人知晓的业务规则。

多年来，企业面临的是一个二元选择：要么维持现状继续用虚拟机，但这意味着无法享受到 Kubernetes 带来的自动化运维能力和弹性伸缩优势；要么投入巨大的成本将这些老应用重写为微服务架构，但这需要大量的时间、资金和人力，而且伴随着极高的风险。KubeVirt 的出现提供了第三个选择，一个中间道路——不需要重写代码，不需要改造架构，只需要把现有的虚拟机直接迁移到 Kubernetes 上运行。

KubeVirt 到底是什么？#

KubeVirt 是云原生计算基金会旗下的一个开源项目，它的核心目标非常直接：扩展 Kubernetes API，让 Kubernetes 能够原生地管理虚拟机。以前你执行 kubectl run 命令启动的是一个容器，现在你执行 kubectl apply 命令加一个 YAML 文件就能启动一台完整的虚拟机。这听起来可能有点奇怪——明明是 Kubernetes 的忠实用户，为什么要往里面加入虚拟机的支持？但实际上，这个思路非常务实。

在任何一个中等规模以上的企业里，技术栈都很少是纯容器的。往往是新开发的业务跑在容器里，而一些历史遗留系统或者第三方提供的闭源软件仍然需要运行在虚拟机上。如果容器和虚拟机使用两套不同的管理系统，运维团队就需要掌握两套完全不同的技能栈，在两个管理面板之间来回切换，效率和体验都很差。KubeVirt 解决了这个问题，它让虚拟机成为了 Kubernetes 的一等公民，可以和容器在同一个集群中统一管理。

1
# 在 K8s 上运行一个完整的虚拟机
2
apiVersion: kubevirt.io/v1
3
kind: VirtualMachine
4
metadata:
5
  name: legacy-app-vm
6
spec:
7
  running: true
8
  template:
9
    spec:
10
      domain:
11
        cpu:
12
          cores: 4
13
          threads: 1
14
          sockets: 1
15
        memory:
16
          guest: 8Gi
17
        devices:
18
          disks:
19
            - name: rootdisk
20
              disk:
21
                bus: virtio
22
            - name: cloudinitdisk
23
              disk:
24
                bus: virtio
25
          interfaces:
26
            - name: default
27
              bridge: {}
28
      networks:
29
        - name: default
30
          pod: {}
31
      volumes:
32
        - name: rootdisk
33
          containerDisk:
34
            image: quay.io/kubevirt/cirros-container-disk-demo:latest
35
        - name: cloudinitdisk
36
          cloudInitNoCloud:
37
            userData: |
38
              #cloud-config
39
              password: password
40
              chpasswd: { expire: False }

KubeVirt 的核心优势#

1
# 查看所有虚拟机
2
kubectl get vms -n production
3

4
NAME              AGE   STATUS    NODE
5
legacy-app-vm     87d   Running   node-01
6
db-server-vm      231d  Running   node-02
7
monitoring-vm     45d   Stopped   node-03
8

9
# 查看 VM 运行时对应的 Pod
10
kubectl get pods -n production | grep virt-launcher
11

12
virt-launcher-legacy-app-vm-xxxxx   2/2  Running   node-01
13
virt-launcher-db-server-vm-yyyyy    2/2  Running   node-02

1
# 触发虚拟机热迁移
2
apiVersion: kubevirt.io/v1
3
kind: VirtualMachineInstanceMigration
4
metadata:
5
  name: migrate-legacy-app
6
spec:
7
  vmiName: legacy-app-vm

1
kubectl get vmi legacy-app-vm -w
2

3
NAME            AGE   PHASE     NODE
4
legacy-app-vm   87d   Running   node-01
5
legacy-app-vm   87d   Migrating node-01 → node-03
6
legacy-app-vm   87d   Running   node-03

1
# 给 VM 配置 Cilium 网络策略
2
apiVersion: cilium.io/v2
3
kind: CiliumNetworkPolicy
4
metadata:
5
  name: allow-api-to-vm
6
spec:
7
  endpointSelector:
8
    matchLabels:
9
      kubevirt.io/vm: legacy-app-vm
10
  ingress:
11
    - fromEndpoints:
12
        - matchLabels:
13
            app: api-gateway
14
      toPorts:
15
        - ports:
16
            - port: "8080"
17
              protocol: TCP

2026 年的杀手级特性#

1
# 混合部署：新版容器和旧版 VM 共存
2
apiVersion: apps/v1
3
kind: Deployment
4
metadata:
5
  name: hybrid-deployment
6
spec:
7
  replicas: 5
8
  selector:
9
    matchLabels:
10
      app: my-service
11
  template:
12
    metadata:
13
      labels:
14
        app: my-service
15
    spec:
16
      containers:
17
        - name: new-service
18
          image: my-service:latest
19
  vmTemplate:
20
    spec:
21
      running: true
22
      template:
23
        spec:
24
          domain:
25
            devices:
26
              disks:
27
                - disk: {}
28
                  name: legacy-container

1
apiVersion: kubevirt.io/v1
2
kind: VirtualMachine
3
metadata:
4
  name: gpu-training-vm
5
spec:
6
  template:
7
    spec:
8
      domain:
9
        devices:
10
          gpus:
11
            - deviceName: nvidia.com/Tesla_A100
12
              name: gpu1
13
            - deviceName: nvidia.com/Tesla_A100
14
              name: gpu2

1
kubectl create -f - <<EOF
2
apiVersion: snapshot.kubevirt.io/v1alpha1
3
kind: VirtualMachineSnapshot
4
metadata:
5
  name: pre-upgrade-snapshot
6
spec:
7
  source:
8
    apiGroup: kubevirt.io
9
    kind: VirtualMachine
10
    name: legacy-app-vm
11
EOF

真实案例#

某城市商业银行的核心账务系统多年来一直运行在十二台 VMware 虚拟机上。合规部门要求今年完成基础设施的升级改造，云计算团队评估了将账务系统重写为微服务的方案，结果令人沮丧：预计耗时十八个月，预算五百万元，并且由于核心账务系统的复杂性，项目风险被评为最高等级，任何数据不一致都可能导致严重的业务事故。这个方案在董事会层面被直接否决了。

但在他们尝试了 KubeVirt 之后，情况完全不一样了。整个迁移分为四个阶段：第一阶段，把十二台虚拟机原封不动地迁移到 KubeVirt 上，这个过程只用了两周时间，因为不需要对应用做任何改动。第二阶段，统一使用 Cilium 实现网络策略管理，适配了原有基于 IP 的防火墙规则，花了一周时间。第三阶段，启用虚拟机的热迁移功能，实现了零停机的节点维护，配置了三天。第四阶段，开始逐步将边缘模块容器化并迁移到新的架构中，这是一个可以持续推进的过程。

最终的结果让所有人都非常满意：三周上线，核心账务系统零代码改动，运维效率提升了百分之六十。老的 Java 应用程序现在运行在 Kubernetes 集群中，通过 Prometheus 统一监控，通过 ArgoCD 进行 GitOps 管理。虽然底层仍然是虚拟机在运行，但所有的管理操作都统一到了 Kubernetes 的体系中。

1
kubectl top vm -n core-banking
2

3
NAME              CPU(cores)   MEMORY(bytes)   DISK(GB)   AGE
4
core-account-vm   3200m        12Gi            500         89d
5
settlement-vm     1500m        8Gi             300         89d
6
report-vm         800m         4Gi             100         89d

写在最后#

从 KubeVirt 到全面云原生的路径规划#

很多团队在成功将虚拟机迁移到 KubeVirt 之后，会问一个很实际的问题：接下来呢？这个问题问得很好，因为 KubeVirt 本身只是一个过渡方案，最终目标仍然是全面容器化。但有了 KubeVirt 之后，这个过渡过程可以更加从容和有规划。

一个经过多家企业验证的有效路径是”三阶段迁移法”。第一阶段是”搬进来”，不做任何代码改动，直接把虚拟机从 VMware 或 Proxmox 迁移到 KubeVirt 上。这个阶段的收益是统一了管理平面，让所有工作负载都在同一个 Kubernetes 集群中管理。第二阶段是”拆出来”，分析现有虚拟机中运行的应用程序，识别出那些依赖较少、业务逻辑相对独立、适合优先容器化的模块。这些模块往往是边缘功能或者非核心链路，即使出问题也不会影响主要业务流程。第三阶段是”原生跑”，将识别出的模块逐步改写为容器化部署，利用 Kubernetes 的原生能力实现弹性伸缩和自动化运维。

在实际操作中，有一个非常有效的策略叫做”容器化孵化器”：在同一个命名空间中，让容器版本和 KubeVirt 版本的服务同时运行，通过流量比例控制逐步将流量从虚拟机版本切换到容器版本。一开始百分之十的流量走容器版本，观察一段时间没有问题，再逐步提升到百分之五十、百分之九十，最后百分之百。如果在任何阶段发现问题，可以立即把流量切回虚拟机版本，整个过程对用户完全透明，不会造成任何感知。这种渐进式的迁移策略既保证了业务的稳定性，也给团队留出了充足的学习和适应时间，是目前业内公认的最佳实践。

关于 KubeVirt 的常见误解#

有些开发者对 KubeVirt 存在误解，认为它在”开倒车”——好不容易把应用容器化了，怎么又跑回到虚拟机去了？这个误解需要澄清。KubeVirt 不是为了替代容器技术，恰恰相反，它的价值在于给那些还不能容器化的传统应用提供了一个搭上 Kubernetes 这班快车的路径。对于那些百分之七十依然运行在传统虚拟化平台上的核心业务系统，与其等待一个遥遥无期的”完美容器化方案”，不如先把它们迁移到 Kubernetes 生态中，用统一的平台去管理所有的工作负载。然后再根据业务的实际情况和改造的难易程度，有计划地逐步推进容器化。

另一个常见的误解是认为 KubeVirt 的性能不如裸机虚拟化。实际上，由于 KubeVirt 使用了与标准 KVM 相同的虚拟化技术栈，并且可以充分利用现代 CPU 的硬件虚拟化扩展特性，它的性能损失非常小，在绝大多数场景下的性能差异可以忽略不计。加之 KubeVirt 还支持 NUMA 绑定、CPU 独占和巨页内存等性能优化特性，使得它对性能敏感型的工作负载也能够提供足够的支持。

写在最后#

一步到位的云原生是理想主义者的蓝图，步步为营的演进才是现实世界中可行的道路。KubeVirt 拆掉了虚拟机和容器之间的那堵墙，让企业可以根据自己的节奏，从容不迫地走完云原生转型的每一步。在这个过程中，团队的心态会发生一个有趣的变化：当老应用成功跑在 KubeVirt 上之后，大家发现原来觉得遥不可及的容器化，实际上也没有想象中那么可怕。信心建立起来了，后续的改造工作也会顺利得多。