命令定位
kubectl wait 阻塞等待资源满足某个条件（就绪、可用、删除完成）或消失，是脚本里替代 sleep 的正确做法。适用平台是 Kubernetes。它让发布流程从「猜多久能好」变成「确定好了才继续」，CI 里先 wait 再跑冒烟测试，能显著减少偶发失败；代价是需要把超时和条件写对，否则会一直等到超时退出。
基本信息
| 适用平台 | Kubernetes（kubectl 1.11 起引入，用法在 1.14 后稳定） |
|---|---|
| 语法 | kubectl wait --for=<条件> <资源>/<名称> [--timeout=30s] |
| 支持条件 | --for=condition=<类型>、--for=jsonpath='{.路径}'=<值>、--for=delete |
| 退出码 | 条件满足返回 0，超时或资源不存在返回非零 |
典型使用场景
- 发布流水线等待就绪：部署后等 Deployment Available 再执行接口冒烟
- 等待单个 Pod Ready：调试场景下确认目标 Pod 进入可服务状态
- 等待删除完成：释放固定端口或节点资源前，确认旧 Pod 已彻底消失
- 等 Job 完成：批处理任务结束后再触发下游步骤，避免读到中间状态
- 串联多步变更：等 ConfigMap 相关 Pod 全部就绪后再切流量
常用示例
常用示例
kubectl wait --for=condition=Available deploy/web --timeout=180s # 等部署可用
kubectl wait --for=condition=Ready pod/web-x --timeout=120s # 等单个 Pod 就绪
kubectl wait --for=jsonpath='{.status.phase}'=Running pod/web-x # 按字段值等待
kubectl wait --for=delete pod/web-x --timeout=60s # 等对象被删除
kubectl wait --for=condition=complete job/batch-1 --timeout=600s # 等批任务完成
kubectl rollout status deploy/web --timeout=180s # 部署类场景更常用的等价手段常用条件对照
| 资源 | 可用条件 | 说明 |
|---|---|---|
| Deployment | Available | 可用副本达到要求，滚动更新完成时也满足 |
| Pod | Ready | 所有容器就绪探针通过 |
| Job | complete | 任务成功结束；失败看 failed |
| 资源删除 | --for=delete | 对象从 API 消失即返回 |
| 自定义字段 | --for=jsonpath=... | 按任意可读字段判断，灵活但需路径正确 |
默认超时是 30 秒，生产脚本务必显式写 --timeout，避免因为默认值太短而误判失败。
wait 只会检查现有对象：若资源尚未创建，会立即报 not found 而不是等待，所以顺序应是先 apply 再 wait。
脚本写法建议
- 先 apply 再 wait：对象不存在时 wait 直接失败，顺序写反会让流水线误报
- 把 --timeout 设成发布窗口的上限值，超时即刻失败，避免整条流水线挂死
- 检查退出码后再执行冒烟测试：kubectl wait ... || exit 1，比依赖后续步骤报错更清晰
- 多个对象用 -l 选择器批量等待，比循环调用更快，也少写一堆重复命令