Kubernetes滚动更新时HTTP请求被待销毁旧Pod响应该如何解决？

1. 优先使用kubectl rollout status阻塞等待滚动完成 #

比固定时长盲等更精准，直接在Step2和Step3之间加如下命令，针对你要更新的Deployment逐个执行即可，命令会阻塞直到对应Deployment的滚动更新完全完成、所有旧副本已下线：

# 替换成你的Deployment名称，可多次执行覆盖A、B两个Deployment
kubectl rollout status deployment/[你的Deployment名称] -n [你的Namespace] --timeout=5m

超时时间可根据你的服务实际启动时长调整，避免异常场景流水线一直卡住。

2. 优化Deployment的滚动更新和健康检查配置 #

从K8s资源层面保障旧副本完全下线前，新副本已经可以正常处理请求：

• 给Deployment A、B配置readinessProbe就绪探针，检测接口要覆盖数据库连接、服务初始化逻辑，只有探针检测通过的新Pod才会被加入服务后端端点列表
• 按需调整滚动更新参数，比如增加minReadySeconds配置（比如设为10~30s），让新Pod启动后稳定运行指定时长再开始下线旧Pod；根据你的集群资源情况调整maxSurge（最大超量副本数）和maxUnavailable（最大不可用副本数），优先保证新副本完全就绪再销毁旧副本
• 可配置terminationGracePeriodSeconds参数，给旧Pod预留足够的请求处理时间再销毁，避免运行中的请求被强制中断

3. 流水线增加端点校验步骤 #

在发起HTTP请求前，先校验服务对应的Endpoints列表中已经不存在旧Pod的IP，确保所有流量只会打到新启动的Pod上：
可以通过简单的shell脚本实现，先获取所有新Pod的IP，再和Service对应的Endpoints地址做比对，完全匹配后再执行后续的HTTP调用步骤。

4. 临时数据库场景专属优化 #

因为你是每日构建的临时场景、数据库不需要持久化，可直接将数据库Pod和A、B的部署生命周期绑定：

• 每次流水线执行时，先删除旧的数据库Pod，再启动新的数据库Pod，等数据库就绪后再执行A、B的滚动重启
• 给A、B的Pod配置Init容器，Init容器会检测数据库连接可用性，只有成功连接到当前运行的数据库Pod之后，主容器才会启动，这样旧Pod连接的是旧数据库，滚动完成后旧Pod会被完全销毁，不会再接收新请求

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