Kubernetes重部署服务频繁出现502/503错误？已配置探针仍存在流量调度异常

• 滚动更新策略设置不合理：不少人部署时直接沿用Deployment的默认参数，对单副本服务来说，默认的maxUnavailable=25%规则会在更新时直接删掉唯一的运行实例，新Pod还没启动完成的空窗期就会直接触发服务中断；更激进的配置会把maxUnavailable设为100%，等于直接销毁所有旧实例，完全靠新实例启动补位，一定会出现无实例可接流量的空洞。
• 优雅关停流程缺失：绝大多数旧Pod残留流量的问题，都来自没有配置preStop钩子。Pod收到删除信号后，K8s会启动grace period倒计时，没有preStop的缓冲，应用一旦接收到SIGTERM就立刻退出，此时kube-proxy、Ingress的流量规则可能还没把当前Pod的IP从转发列表里移除，流量会持续打到已经退出的实例上，直接返回502。
• 探针配置和应用实际启动节奏不匹配：比如把readinessProbe的探测间隔设得极短、failureThreshold设为1，应用刚完成基础启动、还在加载本地缓存、初始化数据库连接池的阶段，第一次探测成功就立刻被纳入流量池，此时打过来的请求大概率因为应用未预热完成超时，触发503。还有的livenessProbe配置过于激进，在应用启动阶段就触发重启，直接拉长更新周期，放大流量空窗的影响。
• 流量转发模式配置不合理：不少人用Service的默认externalTrafficPolicy: Cluster模式，流量会跨节点转发，一旦出现节点间的kube-proxy规则同步延迟，跨节点的流量会被打到已经退出的Pod上，放大502的概率；如果没有特殊需求，对延迟敏感的服务可以改成externalTrafficPolicy: Local，减少跨节点转发的同步影响。
• 入口层健康检查逻辑缺失：如果集群流量入口走Ingress或者七层网关，很多人默认靠K8s的Endpoint列表转发流量，忽略了Ingress本身的同步延迟，甚至关闭了Ingress侧的主动健康检查，一旦Endpoint和实际Pod状态出现偏差，流量就会被转发到异常实例上。

• 首先明确核心逻辑：minReadySeconds是Deployment控制器层面的滚动更新节奏控制参数，不是流量接入的开关。它的判定规则是：当新Pod的所有容器启动、readinessProbe探测通过后，需要连续稳定运行指定时长，Deployment控制器才会把这个Pod算作“可用副本”，推进后续的旧Pod销毁流程。
• 它确实可以用来延后滚动更新的节奏，避免新Pod刚就绪就立刻删除旧Pod的问题，但要避开两个常见误区：
  1. 它不会控制Endpoint的同步时机——只要新Pod的readinessProbe通过，哪怕还没到minReadySeconds的等待时长，Endpoint资源就会把这个Pod的IP加进后端列表，网络层的流量立刻就可以转发过来。如果想让新Pod完全预热完成后再接流量，必须把预热逻辑写到readinessProbe的判定条件里，不能只靠minReadySeconds。
  2. 它没法解决旧Pod端的流量残留问题——minReadySeconds只管新Pod的就绪判定节奏，旧Pod的流量摘除、优雅关停流程完全不受这个参数影响，该丢的包还是会丢。
• 合理的使用方式是：把minReadySeconds设为和应用实际预热周期匹配的时长（比如应用需要30秒完成缓存加载，就设为30s），确保新Pod经过完整预热、稳定运行后，Deployment才开始销毁旧Pod，避免新Pod刚能服务就立刻接满全量流量。

排查路径 #

• 第一步先定位错误流量的实际后端：故障发生时第一时间拉取对应Service的Endpoint列表，核对502/503时间窗内的后端条目，区分流量是被打到了已进入终止流程的旧Pod，还是尚未完成预热的新Pod。可以登录对应工作节点，核对节点上的iptables/ipvs转发规则，确认是否存在kube-proxy规则与Endpoint不同步的情况。
• 第二步核对Pod生命周期的全流程事件：查每个异常Pod的事件记录，确认旧Pod的preStop钩子是否正常执行、grace period时长是否足够覆盖优雅关停的时间；确认新Pod的readinessProbe探测历史，看探针是在应用预热完成前就通过，还是探测过程中存在反复失败重启的情况。
• 第三步核对入口层的日志：从Ingress、负载均衡网关的日志里提取对应时间窗的502/503记录，按上游Pod IP做聚合，看错误是因为连接被拒绝（对端已退出）、上游超时（对端负载过高未完成预热）、还是上游主动返回错误。

监控埋点 #

• 埋滚动更新全流程的阶段耗时指标：从发布动作触发开始，逐段记录新Pod创建时间、新Pod探针首次通过时间、新Pod被纳入Endpoint的时间、旧Pod从Endpoint摘除的时间、旧Pod实际终止时间，计算每个阶段的时间差，定位哪个环节出现了顺序颠倒或延迟异常。
• 埋网络控制面的同步延迟指标：统计Pod Ready状态变更到Endpoint更新完成的延迟、Endpoint更新完成到kube-proxy规则同步到各节点的延迟，一旦延迟超过阈值就提前告警，避免因为同步滞后导致流量打错后端。
• 埋入口侧错误率的维度拆分：把Ingress/网关侧的502/503错误率按上游Pod版本、Pod IP打标签，当错误突增时第一时间判断是新版本实例的问题，还是旧版本实例的流量残留问题，缩短排查时间。

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