Deployment的rollout restart与直接Kill Pod的区别是什么？

• 滚动更新的可控性
  rollout restart会严格遵循Deployment配置的maxSurge（最多额外启动的Pod数）和maxUnavailable（最多不可用的Pod数）规则，一步步替换旧Pod：先启动新Pod并等待就绪，再销毁对应的旧Pod，全程保证服务的可用性。而直接kill Pod的话，K8s只会立刻补一个新Pod，完全不考虑滚动策略——要是你一次性杀掉多个Pod，很可能导致服务暂时断档。

• ReplicaSet与版本追踪
  执行rollout restart时，K8s会给Deployment的Pod模板添加一个唯一的kubectl.kubernetes.io/restartedAt注解，触发创建新的ReplicaSet来生成新Pod，旧的ReplicaSet会被保留，方便后续用rollout undo回滚到之前的版本。直接kill Pod只是ReplicaSet层面的“补位”操作，Pod模板没有任何变化，新Pod和旧Pod属于同一个ReplicaSet，没有版本记录，没法通过Deployment的回滚机制恢复。

• 对节点负载的影响
  rollout restart会按照调度策略分批创建新Pod，比如优先调度到资源充足的节点，避免短时间内给单个节点添加大量负载。直接kill Pod后，K8s可能会直接在原节点补新Pod，如果该节点资源已经紧张，很可能出现调度失败或者节点压力陡增的情况。

• 批量操作的风险
  如果Deployment有多个Pod，rollout restart可以一次性触发所有Pod的更新，但过程是安全可控的，不会同时销毁所有旧Pod。而直接用命令批量删除Pod（比如kubectl delete pods -l app=xxx），会一下子干掉所有匹配的Pod，除非你手动控制每次删除的数量，否则很容易导致服务完全中断。

内容的提问来源于stack exchange，提问作者Mercer