quay.io/kubevirt/virt-handler 是 Kubevirt 虚拟化平台的核心节点组件,作为守护进程运行在 Kubernetes 集群的每个工作节点上,承担着控制平面与节点虚拟机之间的“桥梁”角色。
在 Kubevirt 架构中,virt-handler 是节点级的“执行者”。它向上对接集群控制平面的 virt-controller 组件,接收虚拟机生命周期管理指令;向下直接与节点上的容器运行时(如 containerd)、网络插件(CNI)、存储插件(CSI)交互,将抽象的虚拟化需求转化为具体的节点操作,最终实现虚拟机在 Kubernetes 环境中的落地运行。
虚拟机生命周期管理
virt-handler 持续监听节点上 VirtualMachineInstance(VMI)对象的状态变化,根据控制平面下发的配置(如 CPU、内存、磁盘、网络规格),通过 CRI(容器运行时接口)调用容器运行时创建承载虚拟机的 Pod,并执行启动、暂停、恢复、重启、迁移等操作。例如,当用户提交 VMI 创建请求后,virt-handler 会解析 VMI 的 Spec 字段,生成对应的虚拟机配置文件(如 libvirt XML),再通过容器化的 libvirt 进程启动虚拟机实例。
节点状态与资源协调
它实时监控节点的 CPU、内存、网络、存储等资源使用情况,将节点状态(如资源余量、虚拟机运行状态)通过 API Server 上报给 virt-controller,辅助控制平面进行调度决策。同时,当节点资源紧张或虚拟机出现异常时,virt-handler 会触发相应的恢复机制,如重启故障虚拟机或释放闲置资源。
网络与存储配置落地
作为节点网络与存储的“配置执行者”,virt-handler 会对接 Kubernetes 的 CNI 插件(如 Calico、Flannel)为虚拟机配置 Pod 网络,包括虚拟网卡、VLAN 划分、端口映射等;同时集成 CSI 插件(如 Ceph CSI、NFS CSI),将持久化存储卷(PVC)挂载到虚拟机,确保虚拟机能够访问集群存储资源。
没有 virt-handler,Kubevirt 控制平面的虚拟化指令无法在节点落地,虚拟机的创建、运行与管理都无从谈起。它通过标准化接口(CRI、CNI、CSI)将 Kubernetes 的容器编排能力与传统虚拟化技术(如 KVM)深度融合,让虚拟机像容器一样被 Kubernetes 原生调度、管理,同时保留虚拟机的隔离性与兼容性。
简言之,virt-handler 是 Kubevirt 实现“在 Kubernetes 上运行虚拟机”的核心节点组件,直接决定了虚拟机在节点上的生命周期稳定性与资源利用效率。
请登录使用轩辕镜像享受快速拉取体验,支持国内访问优化,速度提升
docker pull quay.io/kubevirt/virt-handler:v1.6.0manifest unknown 错误
TLS 证书验证失败
DNS 解析超时
410 错误:版本过低
402 错误:流量耗尽
身份认证失败错误
429 限流错误
凭证保存错误
来自真实用户的反馈,见证轩辕镜像的优质服务