kubectl rollout restart 是什么
rollout restart 是不改配置就重启工作负载的标准做法：它在 Pod 模板上加一个带时间戳的注解，触发一次滚动更新，按 maxUnavailable 与 maxSurge 逐个替换实例，过程中可用性不掉。修改 ConfigMap 或 Secret 后让它生效的常用动作就是它——尤其是通过环境变量注入的配置，必须重建 Pod 才会重新读取。
基本信息
| 命令 | kubectl rollout restart deploy/web，也支持 statefulset 与 daemonset |
|---|---|
| 实现原理 | 在 Pod 模板写 kubectl.kubernetes.io/restartedAt 注解 |
| 滚动行为 | 按 maxUnavailable 与 maxSurge 参数逐个替换实例 |
| 观察方式 | kubectl get pods -w 看替换过程，rollout status 看结果 |
| 适用范围 | 只对有控制器管理的工作负载有效，单个裸 Pod 不适用 |
典型使用场景
- 配置生效：改完用环境变量注入的 ConfigMap 或 Secret 后重建实例
- 证书轮换：Secret 中的证书更新后让应用重新加载
- 内存回落：长期运行的实例内存上涨，重启释放后继续观察趋势
- 演练验证：验证滚动更新策略是否符合预期，提前发现参数问题
- 依赖恢复：下游恢复后重启上游实例，重新建立连接
使用示例
使用示例
kubectl rollout restart deploy/web -n dev # 触发滚动重启
kubectl rollout status deploy/web -n dev # 等待并确认滚动完成
kubectl get pods -l app=web -w # 观察实例逐个替换
kubectl rollout history deploy/web # 查看版本历史与 revision
kubectl rollout undo deploy/web # 有问题时回滚到上一版重启方式对照
| 方式 | 可用性 | 可追踪性 | 建议 |
|---|---|---|---|
| rollout restart | 滚动不中断 | 有 revision 记录 | 推荐 |
| 手工删 Pod | 控制器补齐 | 顺序不可控 | 仅用于单实例故障 |
| 改镜像触发更新 | 滚动不中断 | 有 revision 记录 | 发布新版本时使用 |
| 删除 Deployment 重建 | 中断 | 记录断档 | 不推荐 |
以数据卷方式挂载的 ConfigMap 最终会一致（通常分钟级），但通过环境变量注入的配置不会自动更新，必须重建 Pod 才生效——rollout restart 就是为这一类场景准备的。
重启之前先确认配置本身是对的：如果新实例因为配置错误起不来，滚动过程会卡住甚至把可用实例逐个换掉，反而把原本还能服务的版本替换掉。