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.0探索更多轩辕镜像的使用方法,找到最适合您系统的配置方式
通过 Docker 登录认证访问私有仓库
无需登录使用专属域名
Kubernetes 集群配置 Containerd
K3s 轻量级 Kubernetes 镜像加速
VS Code Dev Containers 配置
Podman 容器引擎配置
HPC 科学计算容器配置
ghcr、Quay、nvcr 等镜像仓库
Harbor Proxy Repository 对接专属域名
Portainer Registries 加速拉取
Nexus3 Docker Proxy 内网缓存
需要其他帮助?请查看我们的 常见问题Docker 镜像访问常见问题解答 或 提交工单
manifest unknown
no matching manifest(架构)
invalid tar header(解压)
TLS 证书失败
DNS 超时
410 Gone 排查
402 与流量用尽
401 认证失败
429 限流
D-Bus 凭证提示
413 与超大单层
来自真实用户的反馈,见证轩辕镜像的优质服务