Minikube部署SeldonDeployment触发webhook连接拒绝错误的排查方法

这类connection refused类webhook报错，和提交的SeldonDeployment YAML内容无关，本质是集群内承载Seldon准入校验功能的后端服务未正常运行，导致Kubernetes API Server向webhook地址发起校验请求时，无法建立TCP连接。从反馈的其他资源提交无异常、仅SeldonDeployment提交报错的特征，可以直接排除集群网络、kube-proxy配置异常的问题，故障范围完全锁定在Seldon组件自身的webhook服务链路中。

1. 核查webhook关联的Service与后端Pod状态 #

• 执行命令查看webhook对应的Service配置：kubectl get svc -n seldon-system seldon-webhook-service -o wide
  核对返回的ClusterIP是否和报错日志中的地址一致，确认Service的443端口映射配置正常，检查Service的selector标签是否与实际运行的Seldon控制器Pod标签匹配。
• 执行命令查看Seldon控制器Pod的运行状态：kubectl get pods -n seldon-system -l app.kubernetes.io/name=seldon-controller-manager
  重点排查Pod是否处于正常Running状态，是否存在CrashLoopBackOff、容器启动失败的情况。Seldon 1.8.0-dev版本在Minikube v1.19.0环境下，很多人都踩过这个坑：Helm安装时默认的证书生成开关没开，控制器启动时因为找不到TLS证书文件，直接退出，根本起不来443的监听端口，这时候Service虽然创建了，但是后面没接任何Pod，API Server连过来自然就被拒绝连接。

2. 校验Service的可用后端端点 #

Service配置正常不代表有可转发的后端节点，执行命令查看端点列表：kubectl get endpoints -n seldon-system seldon-webhook-service
如果返回的ENDPOINTS字段为空，说明Service没有匹配到健康的后端Pod，需要回到上一步检查Pod状态、标签匹配规则，直到列表中出现对应控制器Pod的IP与443端口映射项，链路才算打通。

3. 本地测试环境的应急校验方案 #

如果需要快速验证自写的SeldonDeployment YAML本身没有语法错误，可以临时移除准入webhook配置跳过校验流程（仅适用于本地Minikube测试环境，生产集群禁止执行该操作）：

• 删除现有webhook准入配置：kubectl delete validatingwebhookconfiguration v1.vseldondeployment.kb.io
• 重新执行kubectl apply提交iris模型的部署配置
• 等Seldon控制器Pod完全启动就绪、所有组件状态正常后，再重新安装webhook准入配置，恢复校验能力。

4. 当前版本组合的针对性修复动作 #

结合使用的Seldon 1.8.0-dev、Minikube v1.19.0的版本组合，需要完成两个修复动作彻底解决问题：

• 检查Minikube的kube-apiserver启动参数，确认ValidatingAdmissionWebhook插件未被禁用，可通过查看kube-apiserver的启动参数文件，确认没有--disable-admission-plugins将该插件加入禁用列表。
• 通过Helm重新升级Seldon组件，开启自动生成webhook证书的开关，解决证书加载失败导致的控制器启动异常：
  执行升级命令：helm upgrade seldon seldonio/seldon-core --namespace seldon-system --set webhook.generateCertificates=true
  该配置会让Helm自动生成webhook服务需要的TLS证书，挂载到控制器Pod中，保证控制器可以正常监听443端口接收校验请求。

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