kubernetes滚动升级流量受损主因是readinessprobe过早返回成功，未真实反映业务就绪；应区分liveness与readiness逻辑、合理设initialdelayseconds/periodseconds、禁用docker healthcheck、配置prestop与sigterm优雅退出。
Kubernetes滚动升级中因健康检查“太快”导致流量受损，本质不是检查频率高，而是探针在应用真正就绪前就成功返回，让K8s误判Pod已Ready，提前引入流量——结果请求打进来时应用还没初始化完，直接报错或超时。
要解决这个问题，关键不是“放慢检查”，而是让健康检查真实反映业务就绪状态，并与应用生命周期对齐。以下是四个核心方向：
健康检查必须区分 liveness 和 readiness，且逻辑不同
- livenessProbe：只管“进程是否活着”，用轻量HTTP或TCP探测即可，响应快没关系
-
readinessProbe：必须判断“能否处理业务请求”，需检查依赖是否就绪（如数据库连接池、缓存预热完成、配置加载完毕）
- ❌ 错误示例：
/health返回200仅表示服务进程在监听端口 - ✅ 正确做法：
/readyz接口内部校验DB.ping() && Redis.ping() && isCacheWarmed()，任一失败就返回503
- ❌ 错误示例：
合理设置 initialDelaySeconds 和 periodSeconds
-
initialDelaySeconds必须 ≥ 应用冷启动最长时间（含JVM加载、Spring Context初始化、连接池填充等）- Java应用常见需 20–45 秒，Node.js微服务一般 5–15 秒，Go通常
-
periodSeconds不宜过小（如设为 2s），否则高频失败会触发K8s反复踢出又加回Endpoint，造成抖动- 推荐值：readinessProbe 设为
10–15s，livenessProbe 设为10s
- 推荐值：readinessProbe 设为
避免 Docker HEALTHCHECK 与 K8s 探针共存引发冲突
- Dockerfile 中定义的
HEALTHCHECK在K8s环境下基本无效，K8s不读取该状态，只信任自己配置的livenessProbe/readinessProbe - 若同时启用，可能因Docker守护进程健康状态更新延迟，干扰
kubectl get pods的直观判断，增加排查难度- ✅ 建议：Dockerfile 中移除 HEALTHCHECK 指令，全部健康逻辑交由K8s YAML统一管理
加入优雅退出机制，防止旧Pod被删时仍在处理请求
- 在Deployment中配置
preStop生命周期钩子 + 容器内信号捕获：lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 10"] # 给正在处理的请求留出完成时间 - 同时应用代码需监听
SIGTERM，停止接收新请求，等待活跃连接关闭后再退出 - 配合
terminationGracePeriodSeconds: 30（默认30秒，可按需延长）
这些措施协同作用，能让新Pod真正“准备好了”才进流量，旧Pod“干完活了”才退出，滚动升级过程对用户完全无感。
