CI/CD流水线中kubectl set image与kubectl apply最佳实践对比

1. 直接全量使用kubectl apply替代kubectl set image是否可行？ #

完全可行。你只需要在CI构建出新镜像后，先将deployment manifest文件里的image字段更新为新的镜像地址（比如us.gcr.io/my-org/myapp.4），再执行kubectl apply -f <manifest文件路径>即可完成部署，不需要再单独执行set image命令。

2. kubectl set image和kubectl apply的适用场景 #

• kubectl set image适用场景：
  • 仅需要更新容器镜像，其他deployment配置完全不需要修改的快速部署场景
  • 紧急热修复，不需要修改manifest文件即可快速推送新镜像
  • 服务配置长期稳定，几乎不会调整资源、副本数等参数的简单部署
• kubectl apply适用场景：
  • 需要同时更新镜像和其他deployment配置（比如资源限制、副本数、环境变量、挂载卷等）的场景
  • 希望将deployment manifest作为唯一配置可信源，所有配置变更可追溯、可版本控制的规范化CI/CD流程
  • 配置变更和镜像发布需要走同一套审核、发布流程的场景

3. kubectl apply是否可以同时处理镜像更新和其他配置变更？ #

是的。kubectl apply的工作逻辑是对比本地manifest文件和集群中当前运行的资源配置，将所有差异项同步更新到集群。只要你本地的manifest文件同时更新了镜像tag和其他配置项（比如把cpu limit从1000m改成1500m），一次apply操作就会把所有变更同步生效，不需要分多次操作。

4. 全量使用kubectl apply对比仅用kubectl set image的优缺点 #

优点 #

• 配置可追溯：所有deployment配置都可以存入Git做版本控制，所有变更（镜像更新、配置调整）的操作人、操作时间、变更内容都可以查询，避免集群配置和本地配置不一致的“配置漂移”问题
• 流程统一：不管是镜像更新还是配置调整，都走同一套CI发布流程，不需要区分操作类型，减少手动操作出错的概率
• 变更可校验：执行apply前可以通过kubectl diff -f <manifest文件路径>提前预览所有变更内容，确认无误后再推送，降低误发布风险

缺点 #

• 多了manifest更新步骤：相比直接执行set image，你需要在CI流程中新增一步镜像tag替换操作，可以用envsubst、kustomize等轻量工具实现，不需要复杂配置
• 若manifest管理不规范，比如多人修改未同步、本地manifest版本落后于集群配置，apply操作可能会把旧配置覆盖到集群，引发故障

适配你的场景的建议 #

你当前是单副本部署、无强可用性要求，全量使用kubectl apply完全适配，还能解决你之前需要手动apply改配置的痛点。你只需要把deployment manifest存入代码仓库，CI构建出新镜像后先替换manifest中的镜像tag，再执行apply即可，后续调整资源限制等配置直接修改仓库里的manifest文件就行，不需要再手动操作集群。

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