滚动重启是什么
rollout restart 用滚动方式重建工作负载的全部 Pod，底层做法是往 Pod 模板上加一个时间戳注解，让控制器认为模板发生了变化，从而生成新的副本集并逐个替换。它最常用来让新的配置对象或密钥生效——因为这些内容注入容器后不会自动更新。
为什么不用删除 Pod
手工删除 Pod 也能触发重建，但过程不可控：一次性删掉多个会造成容量骤降，也不会遵循更新策略里的比例参数。滚动重启把这件事交给控制器，按策略逐步替换，配合就绪检查保证替换期间仍然有可用实例。
基本信息
| 适用环境 | 任何 Kubernetes 发行版，支持工作负载类资源 |
|---|---|
| 语法 | kubectl rollout restart <资源>/<名称> |
| 生效原理 | 更新模板中的重启时间注解，触发一次新的发布 |
| 适用对象 | 工作负载控制器；裸 Pod 不适用 |
| 发布节奏 | 沿用该工作负载的更新策略参数 |
| 常见前置 | 确认副本数足够、就绪检查可靠，避免重启期间容量不足 |
典型使用场景
- 配置对象更新后使其生效：把新配置注入的容器需要重建才能读到
- 密钥轮换：修改凭据后让所有实例重新加载
- 证书更新：挂载的证书变化后重建实例以加载新证书
- 清理运行态异常：个别实例出现难以解释的状态时统一重建
- 验证配置变更：结合小范围副本先观察效果再全量替换
- 应用自身要求重启：部分运行时只在启动阶段读取配置
常用示例
常用示例
kubectl rollout restart deploy/web # 重建工作负载全部实例
kubectl rollout restart sts/db -n prod # 有状态负载按序重建
kubectl rollout restart ds/node-agent # 守护进程按节点重建
kubectl rollout status deploy/web --timeout=180s # 观察重建进度
kubectl get pods -l app=web -w # 观察逐个替换不同负载的重建特点
| 负载类型 | 重建方式 | 注意 |
|---|---|---|
| 无状态负载 | 按更新策略比例替换 | 配置好就绪检查可做到不中断 |
| 有状态负载 | 按序逐个重建，通常逆序 | 成员逐个不可用，注意数据一致性 |
| 守护进程 | 按节点滚动重建 | 节点上的采集或插件会短暂停 |
| 裸 Pod | 不适用 | 只能删除后重建 |
配置注入方式影响是否需要重启：以文件方式挂载的配置，大多数情况会自动更新，但通过子路径挂载的单个文件不会。
重启期间容量会短暂下降，单副本应用会有一段时间完全不可用，执行前应评估实例数量与流量情况。