零中断滚动更新关键在于“换得稳”，需 readinessProbe、preStop 钩子与 maxUnavailable=0/maxSurge≥1 三者协同：就绪探针确保新 Pod 真正可服务才导流，preStop 延迟旧 Pod 终止以完成请求，参数配置保障更新中始终有足够可用实例。
滚动更新能实现零中断，关键不在“换得快”，而在“换得稳”——新实例真正就绪后再下线旧实例，中间不出现服务空窗期。这需要配置、探针、钩子三者协同，缺一不可。
确保新 Pod 真正就绪再接入流量
只靠容器启动完成并不够，Kubernetes 必须确认应用已加载完依赖、监听端口、能响应业务请求，才把流量导过去。这就靠 readinessProbe：
- 必须显式配置，不能省略；路径（如
/health）、端口、超时和间隔都要匹配实际服务行为 -
initialDelaySeconds要留足应用冷启动时间，比如 Spring Boot 项目常设为 15–30 秒 - 探测失败时，Pod 不会加入 Service 的 Endpoint，自然不收流量
给旧 Pod 留出优雅退出窗口
新 Pod 上线后，旧 Pod 不能立刻被杀掉——它可能还在处理未完成的请求。直接发 SIGTERM 会导致连接重置或 502 错误。正确做法是：
- 配置 preStop hook，例如执行
sleep 10，让反向代理（如 nginx、Traefik）有时间从上游列表中摘除该 Pod - 应用层也要捕获 SIGTERM，在收到信号后停止接受新连接，并等待已有请求完成（如 Go 的
srv.Shutdown()、Java 的 graceful shutdown） - 避免在极简镜像（如 distroless）里用 shell 命令，优先在代码中实现退出逻辑
用参数控制更新节奏，守住可用底线
滚动更新不是越快越好，而是要在速度和稳定性之间找平衡。核心是两个参数：
-
maxUnavailable: 0：强制要求更新期间所有副本始终在线（适合单副本或高 SLA 场景） -
maxSurge: 1：允许临时多跑 1 个 Pod，保障服务能力不降级 - 若副本数为 3，
maxUnavailable: 1表示最多 1 个 Pod 不可用，此时至少还有 2 个可用——需确认业务能承受这个容量缺口
验证更新过程是否真正无中断
上线前别只看 Pod 状态，要模拟真实请求流：
- 用
curl或vegeta持续压测健康检查端点和服务接口，观察是否有 5xx 或超时 - 检查 Service 的 Endpoints，确认新旧 Pod 在切换过程中始终有重叠期（如 v1.0 ×2 + v1.1 ×1）
- 翻看 kube-proxy 或 Ingress controller 日志，确认 endpoint 变更与流量切换同步，无“路由到终止中 Pod”的记录
