是否应仅在ConfigMap变更时执行kubectl rollout restart部署？

先直接给结论：优先做变更检测，仅当configmap.yml变更时执行rollout restart；如果暂时不想做检测，每次都执行也不是致命问题，但没必要。

分场景分析 #

• 仅修改deployment.yml的情况：
  如果你的变更涉及Deployment的spec.template字段（比如镜像版本、Pod资源限制、直接定义在Deployment里的环境变量），Kubernetes本身会自动触发滚动更新——因为Pod模板的哈希值变了，K8s会自动创建新Pod替换旧Pod。这时候额外执行kubectl rollout restart属于冗余操作，只会多一次无意义的滚动更新。
  要是你改的是Deployment里不影响Pod模板的字段（比如metadata注释、非Pod模板的labels），那rollout restart不会带来任何实际效果，纯粹是浪费时间。

• 修改configmap.yml的情况：
  ConfigMap的变更不会自动触发Deployment的滚动更新（除非你用了特殊的工具或者配置了卷挂载的subPath，但后者有局限性）。这时候必须执行rollout restart，才能让新Pod加载更新后的配置，否则旧Pod会一直使用缓存的配置。

具体建议 #

1. 最优解：实现条件执行
   在你的CI/CD流水线里添加文件变更检测逻辑，只当configmap.yml发生修改时才执行第三步的rollout restart。不同工具的实现方式：

   • GitLab CI：用rules:changes关键字指定只在configmap.yml变更时触发该步骤
   • GitHub Actions：在job的if条件里用contains(github.event.head_commit.modified, 'configmap.yml')判断
   • Jenkins：借助Git插件获取变更文件列表，通过脚本判断是否包含configmap.yml

2. 退而求其次：每次都执行（仅适合无状态服务）
   如果暂时不想做变更检测，每次流水线都执行rollout restart也不会导致服务不可用——K8s的滚动更新会保证新旧Pod交替，只要你配置了合理的maxUnavailable和maxSurge参数。但缺点是会增加流水线执行时间，频繁重启对有状态服务可能有影响（比如丢失临时数据），所以不推荐长期这么做。

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