如何解决K3s双Master嵌入式etcd集群中调用webhook.cert-manager.io失败的问题？

看起来你在多控制平面的K3s集群里碰到了cert-manager webhook调用超时的问题——单Master环境正常，双Master就出状况，这个场景我之前也遇到过，核心原因基本绕不开集群内部网络连通性、DNS解析或者控制平面组件同步这几个点。下面是一步步的排查和解决思路：

1. 先确认cert-manager Webhook的Service与Endpoint状态 #

Webhook的调用依赖Service正确关联到后端Pod，先把这部分基础检查做了：

k3s kubectl get svc,ep -n cert-manager

你需要确认：

• cert-manager-webhook Service的ClusterIP是正常分配的
• 对应的Endpoint条目里的IP，和cert-manager-webhook Pod的IP完全匹配
  如果Endpoint是空的或者IP不对应，说明Pod和Service关联出了问题，先尝试重启cert-manager-webhook Pod：

k3s kubectl delete pod -n cert-manager -l app=cert-manager-webhook

2. 测试集群内部到Webhook的连通性 #

在集群内启动一个临时Pod，直接测试访问webhook的接口，排除网络层面的问题：

k3s kubectl run -it --rm busybox --image=busybox:1.35 -- wget -O- https://cert-manager-webhook.cert-manager.svc:443/mutate --no-check-certificate

如果这个命令超时，说明集群内部的Pod网络存在连通性问题——比如K3s默认的Flannel CNI在多控制平面下配置异常。

3. 检查K3s控制平面组件状态 #

双Master嵌入式etcd架构下，kube-apiserver需要和所有etcd节点同步，也得能正常访问集群内的webhook服务。查看apiserver的日志：

# 替换VM1为你的主节点名称
k3s kubectl logs -n kube-system pods/kube-apiserver-VM1
# 或者查看K3s服务的系统日志
journalctl -u k3s.service -f

重点搜索和webhook、cert-manager相关的错误信息，比如是否有etcd同步延迟导致apiserver无法处理请求。

4. 验证CNI插件（Flannel）的状态 #

K3s默认用Flannel作为CNI，多控制平面集群里Flannel的网络配置很容易出问题：

# 查看Flannel Pod状态
k3s kubectl get pods -n kube-system -l app=flannel
# 查看Flannel日志，排查路由建立问题
k3s kubectl logs -n kube-system -l app=flannel

如果Flannel日志里有节点间路由无法建立的错误，先检查虚拟机之间的底层网络是否允许Flannel使用的UDP端口（默认8472）通信，或者调整Flannel的网络配置，避免和虚拟机本地网段冲突。

5. 临时禁用Webhook验证（用于排查） #

如果前面的排查都没找到问题，可以临时禁用cert-manager的webhook，验证是否是webhook本身的问题：

# 先卸载现有cert-manager
k3s kubectl delete -f https://github.com/cert-manager/cert-manager/releases/download/v1.8.0/cert-manager.yaml
# 重新安装并禁用webhook
k3s kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.8.0/cert-manager.yaml --set webhook.enabled=false

然后再应用你的ClusterIssuer清单，如果成功，说明问题确实出在webhook的网络可达性上，回到前面的步骤重点排查集群内部网络。

6. 检查节点DNS解析与Hostname配置 #

K3s多控制平面集群中，节点的hostname需要能被集群内部正确解析。你可以在临时Pod里测试解析webhook的Service：

k3s kubectl run -it --rm busybox --image=busybox:1.35 -- nslookup cert-manager-webhook.cert-manager.svc

如果解析失败，说明coredns有问题，查看coredns的日志排查：

k3s kubectl logs -n kube-system -l k8s-app=kube-dns

总结 #

因为单Master环境正常，双Master出问题，大概率是多节点之间的网络连通性、Flannel路由配置或者控制平面组件同步的问题。按上面的步骤一步步排查，应该能定位到具体原因。

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