GKE集群部署Kubevirt后创建VM遇webhook调用超时问题求助

问题背景 #

在GKE集群中部署Kubevirt时，已完成以下配置：

• 创建基于ubuntu/containerd、n1-standard（CPU≥Haswell）的GKE集群
• 生成启用嵌套虚拟化的自定义镜像，替换原有实例模板并完成节点池滚动更新
• 成功安装Kubevirt与virtctl工具

但执行kubectl apply -f https://kubevirt.io/labs/manifests/vm.yaml创建VM时，出现Webhook超时错误：

Error from server (InternalError): error when creating "https://kubevirt.io/labs/manifests/vm.yaml": Internal error occurred: failed calling webhook "virtualmachines-mutator.kubevirt.io": failed to call webhook: Post "https://virt-api.kubevirt.svc:443/virtualmachines-mutate?timeout=10s": context deadline exceeded

排查步骤 #

1. 检查Kubevirt核心组件状态 #

Kubevirt的Webhook依赖virt-api服务，首先确认组件正常运行：

• 查看Kubevirt命名空间下所有Pod状态：

  kubectl get pods -n kubevirt
  

  确保virt-api、virt-controller等Pod处于Running状态，无重启或CrashLoopBackOff情况。
• 查看virt-apiPod日志，排查启动或运行异常：

  kubectl logs -n kubevirt -l kubevirt.io=virt-api
  

2. 验证Webhook与服务可达性 #

• 检查MutatingWebhookConfiguration是否存在且配置正确：

  kubectl get mutatingwebhookconfigurations virtualmachines-mutator.kubevirt.io
  

• 在集群内测试virt-api服务的连通性，使用临时Pod发起请求：

  kubectl run -it --rm --image=curlimages/curl curl-test -n default -- curl -k https://virt-api.kubevirt.svc:443/virtualmachines-mutate
  

  如果请求超时或失败，说明服务存在网络连通问题。
• 确认virt-api服务的端口配置正确：

  kubectl describe svc virt-api -n kubevirt
  

  检查是否有443端口的TCP监听，且Endpoint指向正常运行的virt-apiPod。

3. 排查集群网络限制 #

• 检查Kubevirt命名空间的网络策略，确认未阻止其他命名空间的请求：

  kubectl get networkpolicies -n kubevirt
  

  如果存在限制访问的策略，需要调整规则允许跨命名空间的443端口通信。
• 确认GKE节点的防火墙规则，允许Pod之间的内部通信（默认GKE允许，但需确认无自定义规则拦截）。

4. 验证嵌套虚拟化配置 #

虽然Webhook超时看似与虚拟化无关，但组件异常可能与节点能力不匹配有关：

• 在集群节点上检查VMX/SVM扩展是否启用：

  # 通过DaemonSet临时工具Pod检查所有节点
  kubectl apply -f - <<EOF
  apiVersion: apps/v1
  kind: DaemonSet
  metadata:
    name: node-check
    namespace: default
  spec:
    selector:
      matchLabels:
        app: node-check
    template:
      metadata:
        labels:
          app: node-check
      spec:
        containers:
        - name: busybox
          image: busybox
          command: ["sleep", "3600"]
          securityContext:
            privileged: true
  EOF
  # 查看每个节点的CPU扩展情况
  kubectl get pods -l app=node-check -o name | xargs -I {} kubectl exec {} -- grep -E '(vmx|svm)' /proc/cpuinfo
  # 清理临时资源
  kubectl delete daemonset node-check
  

• 检查节点的Kubevirt能力标签，确认节点被正确识别为支持虚拟化：

  kubectl describe nodes | grep -A3 -B3 "kubevirt.io"
  

解决建议 #

1. 修复Kubevirt组件异常
   如果virt-apiPod运行异常，重启部署：

   kubectl rollout restart deployment virt-api -n kubevirt
   

   若持续异常，检查镜像拉取、资源配额或RBAC配置是否存在问题。

2. 调整网络策略
   如果网络策略阻止了Webhook请求，添加允许跨命名空间访问virt-api的规则：

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-webhook-access
     namespace: kubevirt
   spec:
     podSelector:
       matchLabels:
         kubevirt.io: virt-api
     ingress:
     - from:
       - namespaceSelector: {}
       ports:
       - protocol: TCP
         port: 443
   

   执行kubectl apply -f <policy-file.yaml>生效。

3. 确认嵌套虚拟化配置
   若节点未启用VMX，重新检查自定义镜像是否包含enable-vmx许可证，确保节点池已完成滚动更新，所有节点使用新镜像：

   # 检查实例模板的镜像配置
   gcloud compute instance-templates describe <new-template-name> --format="value(properties.disks[0].initializeParams.sourceImage)"
   

4. 调整Webhook超时时间
   临时调整Webhook超时时间，避免因网络延迟导致失败：

   kubectl edit mutatingwebhookconfigurations virtualmachines-mutator.kubevirt.io
   

   将timeoutSeconds字段从10修改为30，保存退出。

内容的提问来源于stack exchange，提问作者Sreelal Vu