滚动更新通过就绪探针和滚动策略实现无感知发布：readinessProbe确保仅就绪Pod接收流量，maxSurge与maxUnavailable控制扩缩节奏，配合资源限制与合理探针配置可保障零中断。
滚动更新是 Kubernetes 实现无感知发布的核心机制，关键在于新旧 Pod 交替上线、流量平滑切换，同时保障服务可用性。它不是简单重启容器，而是通过控制器（如 Deployment）按策略逐步替换实例，并配合就绪探针（readinessProbe）控制流量接入时机。
滚动更新如何做到“无感知”？
无感知发布的本质是避免请求被发往尚未就绪或正在退出的 Pod。Kubernetes 依靠两个核心机制协同实现：
- 就绪探针（readinessProbe）：只有探测成功后，Pod 才会被加入 Service 的 Endpoint 列表，开始接收流量；更新过程中，新 Pod 必须通过该检查才对外提供服务。
-
滚动更新策略（rollingUpdate）：通过
maxSurge和maxUnavailable控制扩缩节奏。例如设置maxSurge=1, maxUnavailable=0，表示允许临时多起 1 个新 Pod，且全程不减少可用副本数——这是真正零中断的关键配置。
实战：一次安全的滚动更新操作
以一个 Nginx Deployment 为例，执行更新只需两步：
- 修改镜像版本：
kubectl set image deploy/nginx-deployment nginx=nginx:1.25 - 观察过程：
kubectl rollout status deploy/nginx-deployment，等待提示deployment "nginx-deployment" successfully rolled out
过程中可随时用 kubectl get pods -w 查看新旧 Pod 状态变化，新 Pod 启动后先 Running，再变为 Ready（说明 readinessProbe 通过），老 Pod 在确认无流量后才被终止。
常见问题与避坑建议
看似自动，但实际容易因配置疏漏导致请求失败或延迟：
- 忘记配 readinessProbe：新 Pod 还没加载完静态资源就进流量，返回 404 或 502。务必为每个容器定义合理的 HTTP 或 TCP 就绪检查路径和超时时间。
-
livenessProbe 过于激进：健康检查失败触发重启，可能在更新中途反复重启新 Pod，拖慢进度甚至卡住 rollout。liveness 应比 readiness 更宽松，例如延后首次探测时间（
initialDelaySeconds）。 -
未设资源限制：新旧 Pod 并存时内存/ CPU 突增，引发节点压力驱逐或 OOM。建议在容器 spec 中明确
requests和limits。
进阶：灰度与回滚控制
滚动更新天然支持渐进式发布，结合工具链可实现更精细控制：
- 用
kubectl rollout pause deploy/暂停更新，在部分新 Pod 上线后人工验证效果； - 用
kubectl rollout undo deploy/一键回退至上一版本，或指定特定 revision 回滚； - 搭配 Istio 或 Nginx Ingress，将少量流量切到新版本做金丝雀测试，再扩大比例——此时滚动更新作为底层支撑，上层由服务网格接管路由逻辑。
不复杂但容易忽略细节。只要 probe 配得准、策略调得稳、资源控得住，滚动更新就能成为你日常发布的可靠基础能力。
