RollingUpdate 是什么
RollingUpdate 是无状态工作负载的默认发布策略：一边拉起新版本的副本，一边缩减旧版本的副本，用两个参数控制「最多能多出多少」与「最多允许多少不可用」。推进的条件是新副本通过就绪检查，因此配置好就绪探针之后，替换过程对外表现为持续可用。
另一种策略与卡住的情况
另一种策略是先删光旧副本再创建新副本，过程必然中断，只适合可以接受停机的场景。滚动更新卡住时表现为副本数长期停在中间、新副本一直不就绪，超过推进超时后状态条件会标记为超时期，此时应查看新副本的就绪原因，而不是急着重启控制器。
基本信息
| 适用环境 | 任何 Kubernetes 发行版的 Deployment 默认策略 |
|---|---|
| 配置位置 | spec.strategy.type 与 spec.strategy.rollingUpdate |
| 两个参数 | maxSurge 控制超出期望副本的上限，maxUnavailable 控制不可用上限 |
| 取值形式 | 整数或百分比，百分比按期望副本换算 |
| 推进条件 | 新副本就绪；就绪由就绪探针与稳定时长共同决定 |
| 超时判定 | 由 progressDeadlineSeconds 决定，超时后标记为推进超时 |
典型使用场景
- 日常发布：修改镜像标签后由控制器自动完成无中断替换
- 慢启动服务发布：放宽不可用上限、提高超时时间，给新版本足够准备时间
- 资源紧张时发布：把超出上限设为 0，用先缩后扩换取不多占资源
- 数据库迁移配套发布：把不可用上限设为 0，保证任意时刻都有可用实例
- 紧急修复：提高替换速度，尽快让新版本覆盖全部副本
- 回滚：切换回上一个修订版本，同样以滚动方式完成
策略配置
策略配置
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25% # 可超出期望副本的上限，数字或百分比
maxUnavailable: 25% # 更新期间允许不可用的上限
minReadySeconds: 10 # 新副本就绪后再稳定多久才计入可用
progressDeadlineSeconds: 600 # 超过此时长判定推进超时观察发布
观察发布
kubectl rollout status deploy/web --timeout=300s # 阻塞等待直到完成或超时
kubectl get rs -l app=web # 看新旧副本集的比例
kubectl get pods -l app=web -w # 观察逐个替换的过程
kubectl describe deploy web | grep -A5 Conditions # 卡住时看状态条件参数语义
| 参数 | 含义 | 取值建议 |
|---|---|---|
| maxSurge | 超出期望副本的 Pod 数上限，先扩后缩 | 节点有余量时提高，能加快发布速度 |
| maxUnavailable | 低于期望副本的可用数上限 | 对可用性敏感的服务设为 0 |
| 两者同时为 0 | 无效组合，发布无法推进 | 至少让其中一个大于 0 |
| minReadySeconds | 新副本就绪后需稳定多久才计入可用 | 启动期抖动明显的应用适当加长 |
| progressDeadlineSeconds | 多久没有进展就判定超时 | 慢启动应用要放宽，否则误报失败 |
发布不掉线的条件
- 就绪探针能真实反映「可以接流量」，而不是固定返回成功
- 副本数足够多，缩容期间剩下的实例能扛住流量
- 新实例启动时间与就绪判定匹配，避免过早进入后端
- 优雅终止逻辑正确，旧实例收到终止信号后能把在途请求处理完
百分比取值会按期望副本数换算并取整，副本数很少时要留意实际算出来的绝对值是否符合预期。
发布卡住时先看新副本为什么不就绪：镜像拉取、配置缺失、探针路径不对都可能，逐一排除比直接回滚更有价值。
把不可用上限设为 0 并用百分比表达超出上限时，集群需要有额外资源才能容纳新副本，否则新副本会因调度失败而卡住。