K8S 生产排查台账：滚动更新发版偶发 502 (流量摘除延迟排查指南)

01 前置理论与核心机制

1. 为什么配了优雅停机依然会 502？

• 两条链路的时间差：K8s 下达删除 Pod 指令时，控制面（摘除路由）和数据面（关闭容器）是并行推进的，但生效时间完全不在一个节奏上。
• 数据面（关进程极快）：Kubelet 收到指令后，会立刻向容器内的 1 号进程发送 SIGTERM 信号。业务服务收到信号，瞬间关闭端口，闭门谢客。
• 控制面（摘路由极慢）：K8s 需要先更新 Endpoints，再通知所有节点的 Kube-proxy 修改 iptables/IPVS，最后同步给 Ingress/网关。这条链路走完可能需要 2~3 秒。

2. 竞态条件引发的 502

• 时间差酿成事故：因为网关摘除路由慢了这两三秒，它还以为旧容器活着，继续把前端进来的新流量往里打。但此时旧容器的端口已经关了，网关连不上，直接向用户抛出 502 Bad Gateway 或 Connection Refused。

---

02 故障排查与恢复闭环 SOP

遇到发版瞬间流量轻微跌零或报 502，不需要去查网络玄学或修改就绪探针，直接干预 Pod 的退出流程。

步骤一：观测端点摘除的真实状态

查看服务背后的端点映射，了解路由变更过程：

# 持续观察 Service 的 Endpoints 变动
kubectl get endpoints demo-svc -w

• 观测点：看起来只是一个 Pod 被删了，实际上 K8s 内部发生了一连串的端点解绑动作，这段时间足以让旧容器提早关机。

步骤二：给容器配置增加 preStop 钩子

核心解决思路：让旧 Pod 收到终止信号后别急着退出，在原地强行等上十几秒，给网关留足时间把路由摘干净。

编辑业务的 Deployment YAML（如 app-v2.yaml），在容器的 lifecycle 中加入 preStop 配置：

      containers:
      - name: demo-app
        image: demo-app:v2
        lifecycle:
          preStop:
            exec:
              # 收到删除指令后，先原地 sleep 15 秒，继续正常接客
              command: ["/bin/sh", "-c", "sleep 15"]

步骤三：调整宽限期参数防强杀

加了 sleep 15 后，必须确保 K8s 的强制宽限期 terminationGracePeriodSeconds 足够长（默认是 30 秒）。如果你的业务自身优雅停机需要 20 秒，加上 sleep 的 15 秒，总共需要 35 秒，就会被 K8s 提前强杀。

      # 确保该值大于 (preStop 耗时 + 业务框架优雅停机耗时)
      terminationGracePeriodSeconds: 60

步骤四：执行滚动更新并验证平滑度

重新应用配置，让它开始滚动更新：

kubectl apply -f app-v2.yaml

# 查看滚动更新进度
kubectl rollout status deployment demo-app

• 验证结果：此时能看到新 Pod 已经起来接流量了，旧 Pod 会处于 Terminating 状态并卡住 15 秒。在这 15 秒内，网关完成了路由摘除，旧 Pod 才真正开始关闭进程。流量实现 100% 平滑过渡。

---

03 真实生产故障现象与案例库

案例 1：Nginx Ingress 刷新延迟导致的 502

• 故障现象：每次 Jenkins 发布新版本，API 监控面板上总会出现 1~2 秒的 502 报错尖峰。
• 排查结果：Nginx Ingress Controller 依赖 K8s Endpoints 的变更来重载配置（Reload）。在大规模集群中，Endpoints 的变更通知推送到 Ingress 耗时达到 3 秒，而 Java 进程在 0.5 秒内就关闭了 Tomcat 端口。
• 根因与处置：典型的路由摘除时间差。加入 preStop: sleep 15 后，故障彻底消除。

案例 2：注册中心 (Nacos/Eureka) 摘除延迟

• 故障现象：微服务架构下，滚动更新时 RPC 消费者疯狂报错 Connection Refused。
• 排查结果：提供者 Pod 已经退出，但 Nacos 注册中心里的节点信息还没剔除，消费者依然拿到旧的 IP 发起调用。
• 根因与处置：除了加 sleep 等待 K8s 内部路由摘除，还需在 preStop 中加入主动调用注册中心下线 API 的命令，强制让 Nacos 提前摘除该节点，然后再 sleep。

案例 3：长连接业务 (WebSocket) 被无情切断

• 故障现象：带有 WebSocket 聊天的服务发版时，旧连接全被暴力掐断，导致客户端大面积重连。
• 排查结果：sleep 只能解决新流量不再进入，但无法解决已经建立的长连接。
• 根因与处置：除了 preStop 延迟关闭外，还需要在业务代码中捕获 SIGTERM 信号。收到信号后停止接受新连接，并主动向已有的客户端发送“请重连”指令，确保长连接平滑迁移。

---

04 生产排障速查表（发版 502）

遇到滚动更新掉线问题，按序排查配置：

顺序	排查层级	执行命令 / 观测点	异常定性	处置动作
01	策略核查	检查 strategy: RollingUpdate	maxUnavailable 配成了 100%	调整为 25% 或 1，避免一口气全删
02	探针核查	检查 readinessProbe	就绪探针未配或时间太短	补充就绪探针，确保新 Pod 真活了再引流
03	钩子核查	检查 lifecycle.preStop	未配置停机钩子	增加 sleep 15 抵消网络与网关延迟
04	宽限期核查	检查 terminationGracePeriodSeconds	默认 30 秒，但 sleep + 停机耗时超过 30	调大该参数至 60 甚至 120 秒防强杀
05	注册中心	检查 RPC 报错日志	K8s 内正常，但微服务网关报错	在 preStop 先执行 curl 下线 API 再休眠

---

05 面试应答参考话术

面试官问：“K8s 滚动更新明明配了 0 宕机，也做了优雅停机，为什么每次发版还是会偶发 502？”

可以这样回答：

这个问题不在 Pod，也不在探针，而是在于控制面和数据面之间有两三秒的时间差。

发版的时候，K8s 会同时干两件事：一是去删容器进程，二是去更新 Endpoints 和网关路由。 这两件事生效时间完全不在一个节奏上。网关摘除路由是一条很长的链路，从 Endpoints 到 Kube-proxy 再到 Ingress，走完往往需要两三秒。 但容器那边收到 SIGTERM 信号后，服务立刻关掉端口闭门谢客。网关慢了这两三秒，还以为旧容器活着，继续往里打流量，502 就来了。

解决起来很简单：直接在 Deployment 里给容器加上一个 preStop 停机钩子，里面写上 sleep 15。 它的作用就是让旧 Pod 收到终止信号后别急着退出，先在原地继续接客 15 秒。这 15 秒足够网关把这条路由彻底摘干净，然后再把容器进程平滑关掉。这样就能彻底消除滚动更新时那一瞬间的 502 报错。

---

06 面试高频追问与应答预案

追问 1：加了 sleep 15 之后，那 Pod 真正完全退出需要多久？

• 回答要点：
  • 总耗时 = preStop 耗时 (15秒) + 业务框架处理旧请求的耗时。
  • 必须特别注意，K8s 有一个兜底参数 terminationGracePeriodSeconds（默认 30 秒）。如果你的 sleep 加上业务停机时间超过了 30 秒，K8s 会直接发 SIGKILL 把你强杀。所以加了 sleep 后，通常要把这个宽限期参数调高到 60 秒。

追问 2：我们的集群不用 Ingress，用的是 Service Mesh（比如 Istio），还需要配 preStop 吗？

• 回答要点：
  • 依然需要。Istio 的 Envoy Sidecar 同样依赖控制面 (Istiod) 下发的 EDS (Endpoint Discovery Service) 更新路由。只要有路由分发机制，就必然存在网络延迟与时间差。加 preStop 是屏蔽这种分布式系统延迟的最通用解法。

---

07 自动巡检脚本（check_prestop.sh）

该脚本用于快速扫描指定 Namespace 下的所有 Deployment，找出未配置 preStop 钩子的潜在发版掉线风险对象。

#!/usr/bin/env bash
# ==============================================================================
# 脚本名称: check_prestop.sh
# 功能描述: 自动化扫描 K8s 集群中缺失 preStop 钩子的 Deployment (纯只读)
# 使用方式: 运行在具备 kubectl 权限的机器上，可传入 namespace 参数
# ==============================================================================

set -o pipefail

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[0;33m'
BLUE='\033[0;34m'
PLAIN='\033[0m'

NAMESPACE=${1:-"default"}

echo -e "${BLUE}================================================================${PLAIN}"
echo -e "${BLUE}       Deployment 发版平滑度 (preStop 钩子) 安全巡检            ${PLAIN}"
echo -e "${BLUE}================================================================${PLAIN}"
echo -e "${YELLOW}[INFO] 当前检查的 Namespace: ${NAMESPACE}${PLAIN}\n"

# 获取指定 Namespace 下的所有 Deployment 名称
DEPLOYS=$(kubectl get deploy -n "$NAMESPACE" -o custom-columns=":metadata.name" --no-headers)

if [ -z "$DEPLOYS" ]; then
    echo -e "${GREEN}[OK] 该 Namespace 下暂无 Deployment 资源。${PLAIN}"
    exit 0
fi

RISK_COUNT=0

for deploy in $DEPLOYS; do
    # 提取 preStop 配置内容
    PRESTOP=$(kubectl get deploy "$deploy" -n "$NAMESPACE" -o jsonpath='{.spec.template.spec.containers[*].lifecycle.preStop}' 2>/dev/null)
    
    if [ -n "$PRESTOP" ]; then
        echo -e "  -> ${GREEN}[OK] Deployment: ${deploy} 包含 preStop 配置，具备抗发版 502 能力。${PLAIN}"
    else
        echo -e "  -> ${RED}[WARN] Deployment: ${deploy} 缺失 preStop 钩子！发版时极易出现微秒级路由断层报错。${PLAIN}"
        ((RISK_COUNT++))
    fi
done

echo -e "\n${BLUE}================================================================${PLAIN}"
if [ "$RISK_COUNT" -gt 0 ]; then
    echo -e "${RED}[汇总] 发现 $RISK_COUNT 个无 preStop 防护的 Deployment，建议补充 lifecycle.preStop: sleep 15。${PLAIN}"
else
    echo -e "${GREEN}[汇总] 巡检通过！所有 Deployment 均已配置平滑下线钩子。${PLAIN}"
fi
echo -e "${BLUE}================================================================${PLAIN}"

完整内容已隐藏

请联系作者或在线获取阅读密码。

获取密码