Kubernetes能否通过配置/AdmissionControllers触发Deployment滚动重启

可以，以下是实现方法，但会说明为何该方案属于极不推荐的不良实践（Very Bad Idea™）。

核心原理 #

首先要明确kubectl rollout restart没有任何特殊的底层魔法，执行命令时kubectl客户端做的唯一操作，就是给目标Deployment的spec.template.metadata.annotations字段新增/更新固定注解kubectl.kubernetes.io/restartedAt，值为命令执行时刻的RFC3339格式时间戳。Kubernetes的Deployment控制器只要检测到Pod模板（即spec.template下的任意内容）发生变更，就会按照预设的滚动更新策略替换所有旧Pod，这个逻辑和你修改容器镜像、环境变量、资源限制触发滚动更新的逻辑完全一致。

常规配置变更实现方式（官方推荐的等价方案） #

你完全不需要依赖kubectl rollout命令，直接修改Deployment的YAML配置，在Pod模板的注解段加上对应字段即可实现完全同等的效果，配置片段示例：

spec:
  template:
    metadata:
      annotations:
        kubectl.kubernetes.io/restartedAt: "2024-05-20T14:30:00+08:00"

每次需要触发滚动重启时，把这个时间戳修改为当前最新时间，再通过kubectl apply应用配置，最终效果和执行kubectl rollout restart命令没有任何区别。

Mutating Admission Controller实现方式 #

Mutating Admission Controller确实可以实现自动触发滚动重启的效果：你只需要开发一个符合Kubernetes准入控制规范的MutatingWebhook，配置匹配规则拦截目标Deployment的CREATE、UPDATE请求，在webhook逻辑里自动给请求对象的spec.template.metadata.annotations注入/更新kubectl.kubernetes.io/restartedAt字段为当前时间戳，再把修改后的对象返回给API Server即可。只要有对应请求命中webhook规则，就会自动触发滚动重启。

为什么这是极不推荐的不良实践 #

• 完全违背Kubernetes声明式设计的核心逻辑：用户提交的配置预期和集群实际运行状态会出现不可控偏差，用户可能只是修改副本数、调整标签、甚至执行一次无配置变更的kubectl apply操作，就会触发全量Pod的非预期重启，完全打破正常操作预期。
• 存在极高的线上故障风险：非预期的滚动重启会直接中断业务长连接、导致流量波动，如果应用存在启动依赖、预热周期长的问题，很容易直接触发服务不可用的生产事故。
• 排障成本极高：webhook对资源的修改对普通用户透明，出现非预期重启时，用户排查Deployment变更记录、审计日志时很难第一时间定位到根因，会大幅拉长故障处理时间。
• 会破坏Deployment滚动更新的保护机制：你配置的maxUnavailable、maxSurge等滚动更新策略本来是用来控制变更风险的，无意义的频繁重启会让这些保护机制完全失效，甚至可能导致Deployment长期处于滚动更新中无法收敛到稳定状态。

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