Kubernetes缩容StatefulSet后终止Pod仍接收流量问题排查

在AWS环境中搭建了由2个Pod组成的StatefulSet，前端通过NodePort Service、AWS Ingress对外提供服务，流量经ALB端点转发至该Service。对StatefulSet执行补丁操作将Pod数量缩容至1个后，进入Terminating状态的不健康Pod仍能接收流量。

已配置的探针与策略如下：

存活与就绪探针 #

livenessProbe:
  exec:
    command: ["/bin/sh", "-c", "reply=$(curl -s -o /dev/null -w %{http_code} http://127.0.0.1:80/health); if [ \"$reply\" -lt 200 -o \"$reply\" -ge 400 ]; then exit 1; fi; cat /tmp/.health-check"]
  initialDelaySeconds: 30
  timeoutSeconds: 10
readinessProbe:
  exec:
    command: ["/bin/sh", "-c", "reply=$(curl -s -o /dev/null -w %{http_code} http://127.0.0.1:80/health); if [ \"$reply\" -lt 200 -o \"$reply\" -ge 400 ]; then exit 1; fi; cat /tmp/.health-check"]
  timeoutSeconds: 10
  failureThreshold: 2

生命周期策略 #

lifecycle:
  postStart:
    exec:
      command: ["/bin/touch", "/tmp/.health-check"]
  preStop:
    exec:
      command: ["sh", "-c", "rm -r /tmp/.health-check; sleep 60"]

终止宽限期 #

terminationGracePeriodSeconds: 60

事件时间线：

• 补丁StatefulSet：2023年6月25日 16:23:28 UTC
• Pod变为不健康（状态显示0/1）：2023年6月25日 16:23:47 UTC
• Pod-2接收最后一个请求：2023年6月25日 16:24:38 UTC

1. 验证Service与Pod的端点关联状态 #

执行kubectl describe service <你的Service名称>，查看Endpoints字段：

• 若Terminating的Pod仍在端点列表中：说明Kubernetes未及时摘除不健康Pod，需检查就绪探针的执行日志，确认探针是否正确触发Pod状态更新。
• 若已从列表中移除：问题出在ALB到NodePort Service的转发层面，需检查ALB目标组状态。

2. 检查ALB目标组的注册实例状态 #

登录AWS控制台，进入EC2 -> 负载均衡器 -> 对应ALB -> 目标组：

• 查看目标组中对应NodePort的EC2节点（或IP模式下的Pod IP）的健康状态，确认Terminating Pod对应的目标是否已被标记为不健康或注销。
• 核对目标组的健康检查配置，确认检查间隔、阈值是否与Kubernetes探针匹配，是否因延迟导致ALB仍转发流量给已不健康的目标。

3. 分析就绪探针的执行日志 #

执行kubectl logs <Terminating Pod名称> -c <容器名称> --previous（或直接查看容器实时日志）：

• 确认preStop钩子执行后，/tmp/.health-check文件是否被正确删除——探针最后一步执行cat /tmp/.health-check，文件不存在时该命令会返回非0值，触发就绪探针失败。
• 检查探针中curl请求是否正常返回2xx状态码，避免因应用/health接口异常导致探针逻辑失效。

4. 确认StatefulSet缩容时的Pod终止逻辑 #

执行kubectl describe pod <Terminating Pod名称>，查看事件日志：

• 确认preStop钩子是否按预期执行，是否在删除健康检查文件后等待了60秒。
• 检查terminationGracePeriodSeconds的生效情况，确认Kubernetes是否在等待钩子执行完成后才开始销毁Pod。

5. 验证NodePort Service的会话保持配置 #

执行kubectl get service <你的Service名称> -o yaml，查看sessionAffinity和sessionAffinityConfig字段：

• 若配置了会话保持，检查会话超时时间是否过长，是否存在未过期的会话导致流量仍转发到Terminating Pod。

6. 检查Ingress Controller的同步延迟 #

查看AWS Ingress Controller的日志（执行kubectl logs -n <控制器命名空间> <控制器Pod名称>）：

• 确认是否有端点更新的日志，排查控制器同步Kubernetes端点到ALB目标组的操作是否存在延迟。

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