使用Golang操作Kubevirt API实战_在K8s中管理虚拟机

要用 go 直连 kubevirt api 创建虚拟机，必须使用 kubevirt.io/client-go 初始化 clientset 并注册 crd 类型，否则无法识别 virtualmachine；create 成功但 pending 常因 spec.running=false 或控制器未就绪；判断 ssh 可用需轮询 vmi 的 ip 和 ready condition；删除 vm 需显式处理 vmi 和 finalizer。

怎么用 Go 直连 Kubevirt API 创建虚拟机

不能只靠 kubectl 或 YAML 文件，得用 Go client 真正发请求。Kubevirt 没有独立 client-go 分支，它复用 kubernetes 原生 client，但必须手动注册自定义资源（CRD）类型，否则 clientset 根本不认识 VirtualMachine 这类对象。

实操要点：

• 必须引入 kubevirt.io/client-go（不是 client-go 官方库），它封装了 Kubevirt CRD 的 Scheme 注册和 clientset 构建逻辑
• 初始化 clientset 时，不能只传 *rest.Config，还得显式调用 kubecli.NewForConfig，它内部会自动添加 VirtualMachineVirtualMachineInstance 等 GroupVersion
• 如果跳过这一步，直接用标准 clientset.CoreV1() 去 get VirtualMachine，会报错：the server doesn't have a Resource type "virtualmachine"

示例关键行：

client, err := kubecli.NewForConfig(config) if err != nil {     panic(err) } vm, err := client.VirtualMachine(vmNamespace).Create(context.TODO(), vmObj, metav1.CreateOptions{})

为什么 Create() 成功但 VM 一直 Pending

常见现象：Go 代码返回 no Error，kubectl get vm 显示 Phase: Pending，且长时间不变成 Running。这不是代码问题，而是 Kubevirt 控制器没触发或资源不满足调度条件。

立即学习“go语言免费学习笔记（深入）”；

排查重点：

• 检查 VirtualMachine 的 .spec.running 字段是否为 true —— 如果是 false，它只会创建但不启动，状态就是 Pending
• 确认对应命名空间下是否存在 VirtualMachineInstance（VMI）：运行 kubectl get vmi -n <ns></ns>，没有说明控制器压根没响应；有但状态是 Failed 或 Scheduling，说明节点资源或 CNI 插件有问题
• Kubevirt 要求节点有 kubevirt.io/virt-handler DaemonSet 正常运行，且 CPU 支持虚拟化（cat /proc/cpuinfo | grep vmx|svm），缺一不可

如何用 Go 获取 VMI 实时状态并判断是否真正可 SSH

仅看 VMI.Status.Phase == "Running" 不够 —— 它只表示 QEMU 进程已启动，不代表网卡就绪、cloud-init 完成、SSH 服务监听。得组合多个字段做判断。

实操建议：

• 轮询 client.VirtualMachineInstance(vmiNamespace).Get()，关注 VMI.Status.Interfaces 是否非空且 .IP 字段有值
• 同时检查 VMI.Status.Conditions 中是否有 type: "Ready" 且 status: "True" 的条目（这是 Kubevirt 0.50+ 引入的明确就绪信号）
• 避免硬编码等待时间，用 wait.PollImmediate(2*time.Second, 3*time.Minute, ...) 配合自定义 check 函数更可靠
• 注意：VMI.Status.Interfaces[0].IP 是 Pod 网络 IP，若用 NodePort 或 LoadBalancer 暴露 SSH，需额外查 Service 或路由规则

删除 VM 时为什么 delete() 返回成功但 VMI 还在运行

这是 Kubevirt 的级联删除行为导致的。默认 Delete() 只删 VirtualMachine 对象，不会自动删关联的 VirtualMachineInstance —— 因为 VM 是声明式“模板”，VMI 是运行时实例，二者生命周期解耦。

要真正清干净：

• 设置 PropagationPolicy：在 metav1.DeleteOptions{} 中传入 metav1.PropagationPolicy(metav1.DeletePropagationBackground) 或 DeletePropagationForeground，前提是 VM 的 .spec.template.spec 已正确配置 ownerReferences
• 更稳妥的做法是先删 VM，再主动调用 client.VirtualMachineInstance().Delete() 清理残留 VMI（加 context.WithTimeout 防卡死）
• 如果 VM 处于 Stopping 状态，直接删可能被控制器拦截；应先 patch .spec.running = false，等 VMI 自动终止后再删 VM

容易忽略的一点：Kubevirt 的 finalizer（如 kubevirt.io/vm-finalizer）若未清理，VM 对象会卡在 Terminating 状态，此时得手动 patch 删除 finalizers 字段。