如何自动化Monorepo中Kubernetes Application资源的更新部署？

直接用GitLab CI、CircleCI这类成熟的CI工具是最快捷、易维护的方案，完全能满足你提交/推送代码后自动部署的需求。当然也有GitOps工具可选，但对当前场景来说，CI工具的上手成本更低，更直接。

用CI工具实现的具体步骤（以GitLab CI为例） #

1. 编写CI流水线配置文件 #

在你的Monorepo根目录创建.gitlab-ci.yml，根据不同环境的文件变更触发对应部署任务：

• 只在Kubernetes/environments/[环境名]/apps/下的YAML文件有提交时，才触发该环境的部署
• 示例配置：

deploy-staging:
  stage: deploy
  only:
    changes:
      - Kubernetes/environments/staging/apps/**/*.yaml
  script:
    # 切换到 staging 集群的上下文
    - kubectl config use-context staging-cluster
    # 递归部署该目录下所有YAML
    - kubectl apply -f Kubernetes/environments/staging/apps/ --recursive
  # 指定有权限访问K8s集群的Runner标签
  tags:
    - k8s-deploy-runner

deploy-production:
  stage: deploy
  only:
    changes:
      - Kubernetes/environments/production/apps/**/*.yaml
  # 生产环境建议加手动确认，避免误部署
  when: manual
  script:
    - kubectl config use-context production-cluster
    - kubectl apply -f Kubernetes/environments/production/apps/ --recursive
  tags:
    - k8s-deploy-runner

2. 配置CI Runner的K8s访问权限 #

• 给CI Runner对应的服务账号授予合适的权限（比如针对Application所在命名空间的edit角色）
• 或者把Kubeconfig文件加密存储在CI的密钥管理中，避免明文泄露

可选的GitOps方案补充 #

如果后续你需要更复杂的部署管控（比如自动版本回滚、环境一致性校验、配置漂移检测），可以考虑Argo CD、Flux这类GitOps工具：

• 这类工具会把Git仓库作为唯一可信源，持续同步仓库中的YAML配置到K8s集群
• 但对当前的手动转自动部署需求来说，GitOps工具需要额外部署运维控制器，上手成本比CI工具高

关键注意事项 #

• 生产环境一定要加手动审批或者保护分支规则，防止误提交直接触发部署
• 所有Kubeconfig、云服务商密钥都要加密存储，绝对不能明文放在代码仓库里
• 可以在部署脚本里加入kubectl diff命令，先预览变更内容再执行apply，降低风险

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