K8s Operator准入Webhook代码更新不生效，求排查建议

• 确认本地构建产物是否包含新代码

  • 直接运行本地编译的二进制文件：./bin/manager，手动触发Webhook验证（比如创建对应CR），观察日志是否符合预期，排除代码编译错误。
  • 检查Docker镜像内的二进制：执行docker run --rm my-operator:latest sh -c "ls -l /manager"（假设二进制路径为/manager），对比本地bin/manager的修改时间，确认镜像内是最新构建产物。

• 验证集群内Deployment是否更新到位

  • 查看Deployment的镜像配置：kubectl get deployment <your-operator-deployment> -n <operator-namespace> -o yaml | grep -A5 image，确认镜像为my-operator:latest，且imagePullPolicy不是Never（避免拉取旧镜像）。
  • 检查Deployment滚动更新状态：kubectl rollout status deployment/<your-operator-deployment> -n <operator-namespace>，确认所有Pod已完成更新。

• 检查Webhook配置与服务关联

  • 查看Webhook配置：kubectl get validatingwebhookconfiguration <your-webhook-name> -o yaml（验证型Webhook），确认clientConfig.service字段指向的服务名称、命名空间与你的operator服务完全一致，避免请求发到旧实例。
  • 检查Webhook的CA证书配置，确保证书未过期或配置错误导致请求被拦截（可查看apiserver日志确认）。

• 查看Pod日志确认运行逻辑

  • 查看operator Pod的启动日志：kubectl logs <operator-pod-name> -n <operator-namespace>，检查是否有新代码的初始化日志输出。
  • 触发一次Webhook操作（如创建/更新CR），实时查看Pod日志：kubectl logs -f <operator-pod-name> -n <operator-namespace>，确认是否执行新的验证逻辑与日志输出。

• 确认kind集群镜像加载正确性

  • 确认操作的目标集群：kind get clusters，确保是test-cluster。
  • 进入kind控制节点：docker exec -it kind-test-cluster-control-plane bash，执行crictl images | grep my-operator，对比本地docker images中my-operator:latest的镜像ID，确保两者一致。若不一致，重新执行kind load docker-image my-operator:latest --name test-cluster。

• 清理旧资源重新部署

  • 删除旧的operator资源：kubectl delete deployment <your-operator-deployment> -n <operator-namespace>，kubectl delete validatingwebhookconfiguration <your-webhook-name>。
  • 重新执行make deploy IMG=my-operator:latest，确保所有资源从零开始创建。

• 检查代码与Webhook注册逻辑

  • 确认修改的是正确的Webhook处理函数（如ValidateCreate/ValidateUpdate），未写错函数名或未将修改后的函数注册到Webhook中。
  • 执行make manifests重新生成Webhook配置文件，检查config/webhook/manifests.yaml是否包含最新的Webhook规则与路径，确保controller-gen正确生成了配置。

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