GitOps 与 ArgoCD

传统 Push 部署模式的问题

阶段一结束后,最直接的部署方式是在流水线末尾追加一个 deploy 步骤,直接向集群下发命令:

deploy:
  needs: build
  steps:
    - run: |
        kubectl set image deployment/myapp \
          myapp=ghcr.io/org/myapp:${{ github.sha }}

这种方案可以工作,但引入了三个结构性问题:

问题一:配置漂移(Configuration Drift).集群状态可能因手动操作而偏离 Git 中的定义--有人用 kubectl scale 调整了副本数,用 kubectl edit 修改了环境变量.时间一长,Git 中记录的配置与集群实际运行的状态不再一致.当被问及"线上到底是什么配置"时,只能登录集群逐一 describe 资源来确认.

问题二:CI 系统持有集群凭证.流水线需要 kubectl 访问权限,这意味着 CI 系统必须持有集群管理员级别的凭证.一旦 CI 系统被攻破,集群将面临直接风险(这在第 02 篇中已作为凭证管理的核心安全议题讨论过).

问题三:回滚依赖人工追溯.上线后发现故障,需要确定上一个可用版本是什么,包含哪些变更.运维人员需要翻阅 CI 日志和沟通记录来拼凑信息,操作低效且容易出错.

这三个问题的根源一致:部署是一次性的推送动作,推送完成后没有任何机制持续守护集群的期望状态.

基础:声明式与调谐循环

理解 GitOps 的前提是理解 Kubernetes 的声明式(Declarative)设计.两种运维范式的对比:

Kubernetes 的控制器持续运行一个调谐循环(Reconciliation Loop):对比期望状态与实际状态,发现差异则执行操作以消除偏差.声明需要三个副本,其中某个 Pod 故障后,控制器会自动创建新的 Pod 来补足--运维人员无需介入.

GitOps 在此基础上做了进一步延伸:既然 Kubernetes 已经是声明式的,那么期望状态本身也应被管理起来--将所有期望状态的 YAML 文件纳入 Git,使 Git 成为期望状态的唯一来源(Single Source of Truth).

GitOps 的四项原则

OpenGitOps 标准定义了四项原则:

四项原则合在一起表达了同一个主张:Git 中的配置即系统真相,由代理持续监控集群状态,任何偏离 Git 定义的变更都会被自动拉回.

Pull 模型与 Push 模型

这是 GitOps 区别于传统部署模式的根本机制差异.

Push 模型(传统方式):外部 CI 系统主动将变更推入集群

[CI 流水线] ──kubectl/持有凭证──▶ [集群]
   持有集群密钥,从外部推送                   集群是被动接受方

Pull 模型(GitOps):集群内部署的代理主动拉取 Git 仓库并自我对齐

[Git 仓库] ◀──watch/pull── [集群内的 ArgoCD]
   期望状态                     集群自行拉取,自行应用,无需外部凭证

Pull 模型带来三个实质性改进:

• 凭证不离开集群:ArgoCD 部署在集群内部,对集群的变更是内部操作,无需将集群凭证提供给外部 CI 系统.攻击面因此大幅缩减.
• 持续而非一次性:Push 是推送后即结束;Pull 的代理持续运行,不断比对 Git 与集群状态,任何时间点产生的偏差都会被检测并纠正.
• 自然适配多集群:每个集群独立运行自己的代理,各自拉取相同或不同的 Git 仓库,无需通过单一中心节点向数十个集群推送变更.

ArgoCD 核心对象:Application

ArgoCD 是当前最广泛使用的 GitOps 工具.其核心是一个名为 Application 的自定义资源(Custom Resource),本质上定义了一组映射关系:将某个 Git 仓库的某个路径下的配置,同步到某个集群的某个命名空间.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  source:                                  # ① 期望状态的来源
    repoURL: https://github.com/org/myapp-config
    targetRevision: main                   #    跟踪的分支或 tag
    path: k8s/                             #    仓库中的配置目录
  destination:                             # ② 同步的目标
    server: https://kubernetes.default.svc #    目标集群(此处为本集群)
    namespace: myapp
  syncPolicy:                              # ③ 同步策略(详见下一节)
    automated:
      selfHeal: true
      prune: true

提交该 Application 后,ArgoCD 将持续监控 myapp-config 仓库中 k8s/ 目录的内容,将其中的所有 Deployment,Service,ConfigMap 等资源同步到集群.Application 的状态分为三类:

自动同步,自愈与回滚

自动同步(Auto-Sync)

启用 syncPolicy.automated 后,ArgoCD 在检测到 Git 有新提交时,会在数分钟内(或通过 webhook 即时触发)自动将变更同步到集群,无需人工操作.此机制将阶段一末尾"镜像如何上集群"的问题完全自动化:

[源代码提交] → [阶段一 CI<br/>构建可信镜像 :sha] → [CI 更新配置仓库中的<br/>镜像 tag → git commit] → [ArgoCD 检测到 Git 变更] → [自动同步到集群] → [新版本运行]

自愈(Self-Heal)

selfHeal: true 直接应对前述"问题一:配置漂移".若有人通过 kubectl edit 手动修改了集群中的副本数,ArgoCD 检测到实际状态与 Git 定义的偏差后,会立即将集群恢复到 Git 中声明的值.

修剪(Prune)与回滚

prune: true:当从 Git 中删除一个资源定义后,ArgoCD 也会将集群中对应的资源删除,避免残留不再被管理的资源.

在 GitOps 模型下,回滚是 Git 操作的自然延伸:

$ git revert <有问题的提交>    # 将配置仓库回退至上一个可用状态
$ git push
# ArgoCD 检测到 Git 变更 → 自动将集群同步回旧版本.回滚完成.

相比前述"问题三:回滚依赖人工追溯",此时回滚即一次标准的 Git 操作,且执行者,执行时间,回退了什么内容,全部记录在 Git 历史中.这正是第 01 篇中 DORA 指标"故障恢复时间"得以大幅压缩的技术基础.

规模化:ApplicationSet 与 App of Apps

管理少量应用时,手工编写 Application 资源是可行的.但当微服务数量达到数十个,需要跨 dev/staging/prod 等多套集群时,手工维护数百个 Application 将带来显著的维护负担.以下两种模式用于解决此问题.

ApplicationSet:模板化批量生成

ApplicationSet 是一个"生成 Application 的工厂".定义一个模板配合一个生成器(generator),由其自动展开为一组 Application.例如,为每个环境各生成一个 Application:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapp-all-envs
spec:
  generators:
    - list:                       # 枚举环境列表
        elements:
          - env: dev
          - env: staging
          - env: prod
  template:                       # 每个环境套用同一模板
    metadata:
      name: 'myapp-{{env}}'
    spec:
      source:
        path: 'overlays/{{env}}'  # 各环境读取各自的配置目录(第 06 篇)
      destination:
        namespace: 'myapp-{{env}}'

这与第 02 篇的可复用 Workflow,第 06 篇的模板化配置理念一致:定义一次,批量展开,修改模板即同时更新所有实例.

App of Apps:层级化管理

App of Apps 模式的核心思想是创建一个根 Application,其指向的 Git 路径中存放的并非普通 Kubernetes 资源,而是一组子 Application 定义.同步根 Application 即同步其下所有子 Application,进而部署整个平台.