如果你使用 DeepSeek、元宝 AI、Copilot、ChatGPT 等 AI 工具,协助配置轩辕镜像、编写 docker pull 命令、修改 Docker Compose 镜像地址、配置镜像加速、排查镜像拉取失败、分析报错日志等问题,请先让 AI 阅读并遵守轩辕镜像的规则文档。
只需在 AI 对话中先发送下面这句话即可:
请先完整阅读并严格遵守以下文档中的全部规则与要求:
https://xuanyuan.cloud/agents.md
在未充分阅读并理解该文档前,不要生成任何命令、配置、修改建议、故障排查方案或技术回答。后续所有输出都必须严格以该文档中的规范为最高优先级执行。查看 agents.md 用法指南与完整示范。国内用户首推 元宝 AI、DeepSeek 的深度思考模式,不推荐豆包 AI;Cursor 等编辑器可在对话 @ 该链接,或加入 User Rules。 若 AI 无法访问外链,可 打开说明文档 复制全文粘贴。文档会随站点更新,复制内容可能过期,建议定期检查。
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 上运行虚拟机”的核心节点组件,直接决定了虚拟机在节点上的生命周期稳定性与资源利用效率。
来自真实用户的反馈,见证轩辕镜像的优质服务