K8s Service ClusterIP 不通但 Pod IP 直连正常：Readiness Probe 引发的诡异故障
1. 问题现象
- 应用 A 通过 Service ClusterIP（10.96.x.x:8080）调用应用 B，持续报 connection refused 或超时
- 直接 curl Pod IP（172.17.x.x:8080）却是通的
kubectl get svc显示 Service 存在，CLUSTER-IP 正常分配kubectl get endpoints显示对应的 Endpoints 列表里有这个 Pod IP
2. 排查过程
Step 1 —— 确认 Pod 本身没问题
kubectlexec-it<pod-a>--curlhttp://<pod-b-ip>:8080/health# ✅ 200 OKPod 直接通信正常，排除应用层问题。
Step 2 —— 确认 Service 和 Endpoints
kubectl get svc app-b-svc-oyaml kubectl get endpoints app-b-svc-oyamlEndpoints 里 Pod IP 存在，说明 selector 匹配没问题。
Step 3 —— 检查 kube-proxy 规则
# iptables 模式iptables-save|grepapp-b-svc# IPVS 模式ipvsadm-Ln|grep<ClusterIP>发现 iptables 规则存在，但 KUBE-SVC-xxx 链只配了 --probability 给旧 Pod IP，新 Pod 的 DNAT 规则缺失。
Step 4 —— 关键线索：kubectl describe ep
kubectl describe endpoints app-b-svc输出：
Subsets: Addresses: 192.168.1.10 NotReadyAddresses: <empty>但实际上 Pod B 有两个副本，新 Pod 的状态是 Running 但 Readiness gate 未就绪——这时候 Pod 不会出现在 Endpoints 的 Addresses 列表中，而旧 Pod 已经销毁了。
Step 5 —— 深挖 Readiness Probe
kubectl get pod app-b-xxx-oyaml|grep-A10readinessProbe发现 readinessProbe 指向的/actuator/health/readiness返回 503——因为 Pod 启动后需要约 60s 加载配置，但探针initialDelaySeconds只设了 10s。
3. 根因
Readiness Probe 配置不当，导致 Pod 长时间处于 Running but NotReady 状态：
- 滚动更新时，新 Pod 启动慢，readiness 一直失败
- kube-proxy 不会将 NotReady 的 Pod 写入 iptables/IPVS 转发规则
- 旧 Pod 已被终止，但新 Pod 还没 Ready → Service 背后短时间内无可用 Endpoint
- 正好在这个窗口期，所有发往 Service ClusterIP 的请求全部失败
这解释了"诡异的矛盾"——Pod IP 直连通（Pod 在运行），但 ClusterIP 不通（kube-proxy 没有将流量转发到它）。
4. 解决方案
治本：调整探针参数
readinessProbe:httpGet:path:/actuator/health/readinessport:8080initialDelaySeconds:60# 给足启动时间periodSeconds:10failureThreshold:5# 容错 50s治标：滚动更新加保护
strategy:type:RollingUpdaterollingUpdate:maxUnavailable:0# 确保至少有一个 Ready PodmaxSurge:1# 先启动新 Pod 再杀旧 Pod监控补全
# PromQL 告警：Service Endpoint 数低于预期count(kube_endpoint_address_available) by (endpoint) < 15. 复盘总结
- Pod Running ≠ 能接流量：Readiness Probe 是 Service 流量的唯一准入标准
- 启动慢的应用不能忽略 initialDelaySeconds：Java/Spring Boot 等重框架启动 30-60s 很常见
- 滚动更新 + 短探针 = 流量黑洞：新 Pod 被 kube-proxy 排除、旧 Pod 已销毁 → 无 Pod 可用
- 排查 ClusterIP 不通的优先步骤：
describe endpoints→ 看 NotReadyAddresses → 查 Readiness Probe
应用场景：Kubernetes 1.26+、Java/Spring Boot 微服务
关键词：K8s Service、ClusterIP、Readiness Probe、kube-proxy、Endpoints、滚动更新
