Kubernetes Service报无可用Active Endpoint错误问题求助

问题根因 #

Service没有可用Endpoint的核心原因是匹配到的web-server Pod未通过就绪探针检查，没有进入Ready状态，Kubernetes默认不会将未就绪的Pod加入Service的Endpoint列表，也就导致了ingress-nginx报错。从你提供的Deployment状态可以明确看到unavailableReplicas: 1、MinimumReplicasUnavailable的异常状态，也验证了这一点。

排查方案 #

• 第一步：查看Pod运行状态和事件
  执行以下命令获取web-server对应的Pod列表，以及Pod的事件信息，定位Pod无法就绪的直接原因：

# 查看命名空间下web-server对应的Pod
kubectl get pods -n <namespace> -l app=web-server
# 查看Pod的详细事件和状态
kubectl describe pod <web-server-pod-name> -n <namespace>

重点关注事件中的镜像拉取、配置挂载、探针失败相关报错。

• 第二步：验证就绪探针返回结果
  你的Deployment配置了/actuator/health路径的就绪探针，直接在集群内或者Pod内部访问该接口，确认返回状态是否为200：

# 进入Pod内部执行请求
kubectl exec -it <web-server-pod-name> -n <namespace> -- curl http://localhost:8080/actuator/health -i

如果返回非200状态码，需要检查web-server应用的启动日志、配置是否正确：

# 查看Pod应用日志
kubectl logs <web-server-pod-name> -n <namespace>
# 如果有前一次崩溃的日志，加-p参数查看
kubectl logs <web-server-pod-name> -n <namespace> -p

常见异常包括：配置文件读取错误、依赖服务（数据库、缓存、消息队列等）连接失败、端口监听异常、JVM启动内存不足等。

• 第三步：验证配置项正确性
  检查你挂载的<namespace>-config配置Map内容是否和应用预期一致，避免配置错误导致应用启动失败。

# 查看ConfigMap内容
kubectl get configmap <namespace>-config -n <namespace> -o yaml

• 第四步：临时屏蔽探针验证（可选，用于快速定位）
  如果需要快速确认是否为探针导致的问题，可以临时删除Deployment的readinessProbe配置，重新发布后观察Endpoint是否正常生成，如果恢复正常即可100%确认是探针导致的就绪失败。

• 第五步：检查另一组异常资源共性
  如果还有另一组资源也存在相同问题，重点排查这两组资源的共性：是否使用了相同的配置模板、是否依赖同一个故障的下游服务、是否使用了相同的镜像仓库前缀拉取镜像、是否配置了相同的探针规则。

内容的提问来源于stack exchange，提问作者C-nan