两个时间参数各管什么
最小就绪时长让副本在通过就绪检查后再观察一段时间才被计为可用，用来过滤那种起来几秒就崩的新版本。发布进度上限则定义发布停滞多久后判定为失败，触发滚动卡住的状态。前者控制发布推进的快慢，后者控制多久认定发布出了问题。
基本信息
| 适用平台 | Kubernetes 1.20+，部署对象字段 |
|---|---|
| 最小就绪时长 | 默认零，就绪即算可用 |
| 进度上限 | 默认 600 秒 |
| 判定结果 | 超过上限后发布被标记为进度停滞 |
| 前提依赖 | 需要就绪探针才能判断副本是否可用 |
典型使用场景
- 新版本存在启动后立即崩溃的隐患，需要观察窗口拦截
- 应用冷启动时间较长，默认上限过于紧张会误报失败
- 发布流水线需要知道何时该判定失败并告警
- 灰度验证阶段希望拖延推出节奏，缩小问题影响面
- 防止发布长期卡住却无人处理
配置示例
配置示例
spec:
minReadySeconds: 10 # 就绪后再观察 10 秒才算可用
progressDeadlineSeconds: 600 # 600 秒无进展判定发布卡住
template:
spec:
containers:
- name: web
image: registry.example.com/web:1.27.0
readinessProbe:
httpGet:
path: /healthz
port: 8080查看与等待
查看与等待
kubectl get deploy web -o jsonpath='{.spec.minReadySeconds} {.spec.progressDeadlineSeconds}'
kubectl rollout status deploy/web --timeout=15m # 等待发布结果
kubectl get deploy web -o jsonpath='{.status.conditions}' # 是否出现进度停滞
kubectl describe deploy web | grep -i progress参数读法
| 参数 | 作用 | 取值建议 |
|---|---|---|
| 最小就绪时长 | 就绪后继续观察的时段 | 按最快暴露缺陷的时间设置，常见十几秒到一分钟 |
| 进度上限 | 无进展多久算失败 | 大于最慢一次启动耗时，留出余量 |
| 就绪探针 | 判定副本是否可用的依据 | 没有它，观察窗口与进度判断都失去意义 |
| 发布条件 | 发布过程的最终判定 | 出现进度停滞说明需要人工介入 |
观察窗口过大反而拖慢发布，尤其在需要快速回滚的场景里，等待时间会明显增加。它的目标是拦截那种秒级崩溃的版本，而不是做长时间稳定性验证。
进度上限小于应用正常冷启动时间时会误报发布失败。先用真实环境量出最慢启动耗时，再据此设置，否则会频繁收到无效告警。