搭建CI/CD流水线可以显著提升开发团队的交付效率，本人结合近期的实际工作经历，介绍非常经典且高效的 GitOps 架构方案 — 基于GitLab CI + ArgoCD搭建流水线。在这种设计中，ArgoCD 作为“单一真理来源”的中枢，负责协调代码仓库与多个 Kubernetes 集群之间的状态一致性。这里先回答2个问题：
为什么选择GitLab CI？
在我刚加入团队的时候，开发团队仍然将代码托管在Gitee互联网上，出于企业数据资产安全性考虑，我们在内部服务器上搭建了GitLab社区版，将代码迁移至了内网。GitLab社区版的流水线功能已经非常完整，足以满足我们团队的所有需求。 相比于Jenkins，GitLab CI在代码仓库的集成上会省去一些配置的工作。 促使我选择GitLab CI的另外一个很重要的原因，是因为流水线中的某些阶段，如部署测试环境和生产环境，往往需要人工介入触发进行部署。Jenkins默认的input机制会占用节点资源，使得流水线一直处于构建中的状态（直到超时），而GitLab默认的manual机制则无此问题。当然Jenkins也有解决方案，就是选择Build/Delivery Pipeline Plugin来组合多条流水线来达成目的（有兴趣的读者可以了解）。
为什么选择ArgoCD?
不论使用何种CI工具，传统的自动化部署方式都是花费很多时间去编写复杂的脚本，让CI连接目标环境（如K8S集群）做自动化操作完成应用的部署，我们不希望花费太多时间在开发和维护自动化脚本上；另外目标环境也可能被人为修改而重新部署，我们期望任何修改都在一个地方操作，并有相应的审计记录。ArgoCD通过PULL模式自动监控配置代码文件修改、保持配置定义和目标环境始终一致的方式，非常符合我们的需求。
核心架构图 (GitOps Workflow)
架构组件及流程详解
GitLab CI (持续集成):
- 职责：负责代码编译、单元测试、镜像构建。
- 关键动作：CI 流程结束时，不直接操作
kubectl，而是修改 GitOps配置仓库（通常是 Helm Chart 或 Kustomize 文件）中的镜像 Tag。这实现了 CI 与 CD 的解耦。
GitOps配置仓库:
- 这是一个独立的 Git 仓库，存放 Kubernetes 的声明式 YAML 文件。ArgoCD 持续监听该仓库的变化。
ArgoCD (持续部署/中枢):
- 部署位置：安装在研发测试集群中。
- 多集群管理：ArgoCD 通过
Cluster Secret（保存生产集群的 API Server 地址和凭证）连接并管理生产集群。 - 状态同步：当 GitOps配置仓库 更新后，ArgoCD 自动对比集群当前状态。如果发现不一致（Out of Sync），则调用目标集群（测试或生产）的 API 执行更新。
K8s 集群隔离:
- 研发测试集群：既运行 ArgoCD 控制面，也运行开发环境的业务 Pod。
- 生产集群：仅运行生产业务，保持纯净，通过网络策略仅允许来自 ArgoCD 集群的受控访问。