现象或背景

我们一条 24 节点（16C64G，Kubernetes 1.28.9 + containerd 1.7.13，cgroup v2）的核心交易集群，Java 17 + Spring Boot 3.1，Pod 副本数 12，QPS 约 3200。

事故发生在一次普通的 kubectl rollout restart：

滚动更新 12 个 Pod，maxUnavailable=1，maxSurge=1；
更新完成总耗时约 4 分钟（12 × 20s 探针等待）；
但监控显示有 3 个 Pod 在被 terminate 的瞬间，收到了 502 错误，占比约 30%（约 960 个请求）；
用户侧表现为"偶尔下单失败，重试一次就成功"，客诉 17 单。

关键诡异点：Pod 的 terminationGracePeriodSeconds 设的是 30s，preStop 里只有 sleep 5，按理说 5 秒足够 kube-proxy 把流量摘掉了——并没有。

原理或根因分析

把整条链路拆开看，kubectl delete pod 之后发生的事情是异步的、且各节点独立的：

Kubelet 收到删除信号 → 执行 preStop hook（sleep 5）→ 发 SIGTERM → 等 terminationGracePeriodSeconds（30s）→ SIGKILL。
与此同时，Endpoint Controller 需要把该 Pod IP 从 Service 的 Endpoints 里摘掉。
再与此同时，每个节点的 kube-proxy 需要感知到 Endpoints 变更，然后更新 iptables / IPVS 规则。

问题出在第 2 和第 3 步：它们是 watch 驱动的，不是同步调用。具体延迟由以下因素叠加：

Endpoint Controller 的 reconcile 周期（默认 10s 级别，实际取决于 controller 负载）；
kube-proxy 的 --sync-period（默认 30s，但实际靠 watch 事件驱动）；
iptables 规则下发到内核 netfilter 的延迟（通常 < 100ms，但在高规则数节点上可 > 1s）；
最关键的一点：客户端（上游网关）到 Pod 的 TCP 连接是长连接。即使 iptables 规则更新了，已经建立的 TCP 连接不会被 iptables 丢弃——只有新建连接才会被拒绝。

所以 sleep 5 真正保护的是"新建连接不再进来"，而存量长连接上的 in-flight 请求完全不受保护。我们的上游网关（Envoy）维护着到每个 Pod 的 4 条 HTTP/2 长连接，sleep 5 期间这些连接上的请求继续飞过来，Pod 收到 SIGTERM 后开始 shutdown，Spring 的 ServerLifecycleHandler 会 server.shutdown=graceful（等 in-flight 完成），但 Envoy 不知道 Pod 要死了，继续往这条连接上塞请求 → 502。

用 tcpdump 抓到的时间线（Pod IP 10.244.7.33）：

T+0.000s  SIGTERM 到达（preStop sleep 5 开始）
T+5.002s  sleep 结束，Spring 开始 graceful shutdown
T+5.010s  仍有 3 个 in-flight 请求正在处理（日志可见）
T+5.030s  Envoy 继续往 fd=42 写新请求
T+5.031s  Spring 已关闭 accept 端口 → 连接被 RST
T+5.032s  Envoy 返回 502 给上游

根因总结：preStop sleep 5 只解决了"摘流"，没解决"存量连接排空"。

具体做法

步骤 1：让 Pod 主动从 Service 摘流（替代 sleep 5）

把 preStop 从 sleep 5 改成先摘流、再等、再退出：

# Deployment spec
terminationGracePeriodSeconds: 60
containers:
- name: app
  lifecycle:
    preStop:
      exec:
        command:
        - /bin/sh
        - -c
        - |
          # 1) 摘流：把 readiness 探针端口关掉（或调 /actuator/health/readiness 返回 503）
          #    这里用 curl 调 actuator 让 readiness 变 NOT_READY
          curl -s -X POST http://127.0.0.1:8080/actuator/health/readiness \
               -H 'Content-Type: application/json' \
               -d '{"status":"DOWN"}' || true
          # 2) 等 kube-proxy 同步 + 上游摘除（实测 2~3s 足够，留 5s 余量）
          sleep 5
          # 3) 不退出——后续由 SIGTERM 触发 Spring graceful shutdown

注意：如果你的 readiness 探针是 httpGet 到 /actuator/health/readiness，那让接口返回 503 就等价于摘流。比 sleep 5 强在：Endpoint Controller 会立刻把 Pod 从 Endpoints 里移除（因为 readiness 变 NOT_READY），而不是等 kube-proxy 的 watch 轮询。

步骤 2：Spring 侧开启 graceful shutdown

# application.yml
server:
  shutdown: graceful
spring:
  lifecycle:
    timeout-per-shutdown-phase: 25s   # 留 5s 给 preStop，总共 < 30s terminationGracePeriod

这会让 Tomcat 在收到 SIGTERM 后：停止 accept → 等 in-flight 完成 → 关闭连接。

步骤 3：上游网关侧配合（Envoy / Nginx）

如果上游是 Envoy，确认 drain_timeout 配置：

# Envoy config（上游网关）
clusters:
- name: order-service
  type: STRICT_DNS
  drain_timeout: 10s          # 摘除 endpoint 后，等 10s 排空存量连接
  health_checks:
    - timeout: 2s
      interval: 5s
      unhealthy_threshold: 3
      healthy_threshold: 2
    http_health_check:
      path: /actuator/health/liveness

如果是 Nginx upstream，确认 max_fails / fail_timeout 不会把"摘流后的一次 502"直接标记为不可用（否则下一个请求会打到正在 shutdown 的 Pod）。

步骤 4：加一个"下线前确认"的防御层

在 preStop 脚本里，sleep 5 之后加一个主动探测：确认自己已经不在 Endpoints 里了再退出：

# preStop 脚本（续）
sleep 5
# 确认自己已从 Endpoints 摘除（通过 K8s API）
MY_IP=$(hostname -i | awk '{print $1}')
for i in $(seq 1 10); do
  EP=$(kubectl get endpoints order-service -n production -o jsonpath='{.subsets[0].addresses[?(@.ip=="'"$MY_IP"'")]}' 2>/dev/null)
  if [ -z "$EP" ]; then
    echo "[preStop] confirmed removed from endpoints"
    break
  fi
  echo "[preStop] still in endpoints, waiting... ($i/10)"
  sleep 1
done

生产环境建议用 ServiceAccount token 替代 kubectl，直接 curl K8s API。

踩过的坑或反直觉之处

坑 1：`terminationGracePeriodSeconds` 不是"shutdown 时间"，是"SIGTERM 到 SIGKILL 的窗口"

很多人以为设 30s 就是"给你 30 秒优雅退出"。实际上这 30 秒包含了 preStop 的执行时间。如果你的 preStop 里 sleep 5 + 探测循环 10s = 15s，那留给 Spring graceful shutdown 的只有 15s。我们第一次改完就踩了：timeout-per-shutdown-phase 设了 25s，但实际窗口只有 15s，Tomcat 在 15s 时被 SIGKILL，in-flight 请求被硬切。

正确算法：terminationGracePeriodSeconds ≥ preStop 耗时 + timeout-per-shutdown-phase + 5s 余量。

坑 2：readiness 摘流 ≠ 立刻没有流量

即使 readiness 变 NOT_READY、Endpoint 已摘除，存活的 TCP 长连接上的请求仍然会进来。这不是 bug，是 TCP 协议本身——连接一旦建立，内核不会因为你改了 iptables 就 RST 掉已有连接（除非你主动 ss -K 杀连接）。所以上游必须配合 drain，单靠 Pod 侧摘流不够。

坑 3：`sleep 5` 的 5 秒到底够不够？

取决于你的集群规模。我们 24 节点、400+ Endpoints 的场景下，Endpoint Controller reconcile 平均 800ms，kube-proxy 同步 200ms，实测 1.2s 就摘干净了。但另一个 80 节点、2000+ Endpoints 的集群，我们测到 3.7s 还没摘干净。所以 sleep 5 在小集群够用、大集群可能不够——...[truncated]

0赞 0收藏 0评论 2浏览

K8s Pod启动失败的三大根因与实战修复方案