KubeVirt在混合工作负载中的位置

KubeVirt 在混合工作负载中的位置，可以先用一句话概括：它把难以容器化的现有虚拟机接入 Kubernetes 的资源和运维模型，让 VM 与容器在同一平台上协作，但不要求所有 VM 都改造成容器，也不承诺替代所有传统虚拟化平台。

官方地址：https://kubevirt.io/

先把 KubeVirt 放回真实的混合平台

我在评估混合平台时，最容易犯的错误是把“虚拟机也能被 Kubernetes 管理”理解成“以后所有业务都应该跑成 VM”。KubeVirt 官方定位更克制：开发团队已经采用 Kubernetes，但手上的某些 VM 工作负载不容易容器化，因此需要在同一共享环境里管理容器和 VM。

这意味着 KubeVirt 主要解决的是管理面统一和迁移节奏可控。例如，旧版商业系统、依赖特定内核或安装方式的中间件可以继续作为 VM 运行；新建的 API、任务服务和周边组件仍然使用容器。两类工作负载可以共享 Namespace、资源策略、网络治理和观测入口，但它们的启动、存储、内核依赖和故障处理并不相同。

这也是 CNCF 在 2026 年 11 月公告中把 KubeVirt 列入毕业项目里程碑后，平台团队更应该关注的判断题：它成熟的是 Kubernetes 上的虚拟机管理路径，不是“所有应用统一成一种运行形态”的口号。

用 VirtualMachine 资源表达虚拟机生命周期

KubeVirt 的关键变化是把虚拟机变成 Kubernetes 可声明的对象。团队可以围绕 VirtualMachine 管理期望状态，围绕 VirtualMachineInstance 观察正在运行的实例，再用 PVC 或 DataVolume 承载磁盘。这样做的重点不是把 VM 的每个内部动作都变成 Pod 操作，而是让创建、启动、停止、调度和资源依赖进入集群的协作模型。

下面的示例只表达“一个 VM 需要多少资源、使用哪块 PVC、接入哪个网络”的边界。它不是某个真实集群的运行结果，存储类、镜像和网络定义要按环境替换：

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: legacy-order
  namespace: workloads
spec:
  running: false # 先以停止状态提交，发布窗口再显式启动。
  template:
    metadata:
      labels:
        kubevirt.io/domain: legacy-order
    spec:
      domain:
        resources:
          requests:
            memory: 4Gi # 给调度器一个明确的内存请求，避免与容器争抢。
        cpu:
          cores: 2 # 资源规格是平台配额和发布检查的输入。
      networks:
        - name: default
          pod: {} # 示例使用默认 Pod 网络，生产环境按隔离策略替换。
      volumes:
        - name: rootdisk
          persistentVolumeClaim:
            claimName: legacy-order-root # 磁盘依赖由 PVC 显式表达。

在混合平台里，最重要的不是 YAML 看起来像不像 Pod，而是每个外部依赖都能被平台团队找到：PVC 属于哪个 Namespace，网络是否允许访问容器服务，Secret 是否会随迁移准备到目标位置，资源请求是否会被配额接受。

把权限、网络和资源配额设成生产边界

KubeVirt 使用 Kubernetes RBAC 做授权。默认的查看角色只允许读取资源，不包含创建、删除、修改或访问全部虚拟机能力。企业环境应该从最小权限开始，而不是把集群管理员角色交给需要启动 VM 的业务账号。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: order-vm-operator
  namespace: workloads
subjects:
  - kind: Group
    name: order-platform # 只绑定负责该业务 Namespace 的团队组。
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubevirt.io:view # 先从只读观察开始，写权限按任务单独授予。

真正需要启动或变更 VM 的团队，可以在经过审批后绑定更窄的角色，并把范围限制在目标 Namespace。网络上也不要把“同一集群”当成“天然互通”：需要额外网段或东西向隔离时，应通过 NetworkAttachmentDefinition、网络策略和平台约定明确 VM 与容器的访问范围。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: workloads-vm-quota
  namespace: workloads
spec:
  hard:
    requests.cpu: "16" # 限制该 Namespace 可申请的总 CPU。
    requests.memory: 32Gi # VM 与容器共用资源池时，给总量设上限。
    persistentvolumeclaims: "20" # 防止磁盘对象无上限增长。

这一步的目的不是把 VM “锁死”，而是让 VM 和容器在同一个平台上有可预测的资源边界：当请求超过配额时，发布在入口处失败，比运行后才发现节点被挤占更容易处理。

存储和在线迁移要先检查依赖

KubeVirt 文档把迁移描述成有条件的能力。在线迁移依赖节点、网络和存储共同满足要求；忙碌的工作负载可能无法在限定时间内完成迁移，网络配置也可能造成连接中断。跨 Namespace 或集群迁移时，目标位置还要准备好目标 VM、存储、网络以及 SSH Secret、ConfigMap 等辅助资源。

涉及磁盘切换时，声明式配置是优点也是责任。以存储卷更新为例，设置 updateVolumesStrategy: Migration 后，KubeVirt 会尝试把旧卷迁移到新卷；如果迁移失败，系统可能按退避策略继续尝试。要取消更新，应该恢复原来的卷集合，而不是只删除一个旁路对象。

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: legacy-order
  namespace: workloads
spec:
  updateVolumesStrategy: Migration # 允许卷集合变更走迁移策略。
  template:
    spec:
      volumes:
        - name: rootdisk
          dataVolume:
            name: legacy-order-destination # 目标 DataVolume 必须已按环境规划。

发布前我会把检查拆成四类：目标节点是否有 CPU 和内存余量；目标网络是否与源端匹配；目标 PVC 或 DataVolume 是否可用；相关 Secret、ConfigMap 和访问权限是否已经复制。若 VM 被意外关闭或 VMI 在迁移中消失，KubeVirt 可能标记 ManualRecoveryRequired，这时应先恢复原卷定义，再决定是否重试，不要直接强行启动。

# 先查看 VM 的条件和卷迁移状态，再决定回滚或重试。
kubectl get vm legacy-order -n workloads -o yaml > legacy-order.vm.yaml

# 查看运行实例、事件与迁移对象，确认失败来自资源、网络还是存储。
kubectl get vmi,vmim -n workloads
kubectl get events -n workloads --sort-by=.lastTimestamp

用日志审计把两类工作负载放进同一值班流程

混合平台最容易出现“资源统一了，责任没有统一”的问题。容器团队看 Deployment 和 Pod，虚拟化团队看 VM 和 VMI，最后故障却发生在两者的网络、存储或配额交界处。因此发布后至少要把 VM 创建、启动、停止、迁移、卷变更和异常条件纳入同一套审计与告警入口。

日志审计关注“谁在什么时候改变了什么”；运行监控关注“VM 是否仍然有可用资源和健康状态”。KubeVirt 文档中的资源对象、条件和事件足以支持第一层排查，Prometheus 等监控系统则适合把 CPU、内存、迁移状态和容器侧指标放到同一个值班面板，但不要用一条聚合指标掩盖 VM 与容器不同的故障语义。

# 发布前记录声明与关键依赖，便于出现迁移或权限问题时回溯。
kubectl get vm legacy-order -n workloads -o yaml > legacy-order.vm.yaml
kubectl get pvc -n workloads
kubectl get networkattachmentdefinition -n workloads

# 发布后先查条件和事件，再进入更深的组件日志排查。
kubectl get vm legacy-order -n workloads -o jsonpath='{.status.conditions}'
echo # 让输出回到下一行，便于值班记录阅读。
kubectl get events -n workloads --sort-by=.lastTimestamp

发布前用这份清单判断是否适合生产

如果团队只是要运行全新、无特殊内核依赖的微服务，直接使用容器通常更简单；如果平台正在承接一批不能立即改造的 VM，同时又希望统一 Kubernetes 的治理、发布和观测，KubeVirt 才更像合适的桥梁。

常见问题

KubeVirt 会不会让所有虚拟机都变成容器？

不会。VM 仍然以虚拟机方式运行，KubeVirt 做的是把它的声明、调度和运维入口接入 Kubernetes。

有了 KubeVirt 还需要传统虚拟化团队吗？

需要。KubeVirt 改变的是平台协作边界，并不会消除操作系统、存储、网络、备份和迁移方面的专业责任。

在线迁移是不是一定不会中断业务？

不是。迁移受到工作负载忙碌程度、网络配置、磁盘类型和目标节点资源影响，发布前要按实际网络与存储做演练。

混合工作负载最先应该收紧什么？

先收紧 Namespace 级 RBAC、网络访问和 ResourceQuota，再建立 VM/VMI 事件、迁移状态与卷变更的审计记录。

资料依据

• CNCF 公告：https://www.cncf.io/announcements/2026/11/10/cncf-hits-major-milestones-with-global-community-growth-record-industry-investment-and-a-new-generation-of-projects-to-build-ai-systems-in-production/
• KubeVirt 官方定位：https://kubevirt.io/
• KubeVirt 授权与 RBAC：https://kubevirt.io/user-guide/cluster_admin/authorization/
• KubeVirt 在线迁移：https://kubevirt.io/user-guide/operations/live_migration/
• KubeVirt 卷迁移：https://kubevirt.io/user-guide/storage/volume_migration/