第 8 章 · 03 GitOps与ArgoCD

文档摘要

第 8 章 · 03 GitOps与ArgoCD 传统 CD 是"推送式"：流水线把清单推给集群，集群被动接受。GitOps 换了个方向：Git 仓库是唯一事实来源，集群主动从 Git 拉取期望状态并收敛现实。ArgoCD 是这个理念在 Kubernetes 上的旗舰实现。本节讲透 GitOps 哲学、ArgoCD 的核心对象与同步机制，以及 Argo Rollouts 的渐进式发布与自动回滚。

第 8 章 · 03 GitOps与ArgoCD

传统 CD 是"推送式"：流水线把清单推给集群，集群被动接受。GitOps 换了个方向：Git 仓库是唯一事实来源，集群主动从 Git 拉取期望状态并收敛现实。ArgoCD 是这个理念在 Kubernetes 上的旗舰实现。本节讲透 GitOps 哲学、ArgoCD 的核心对象与同步机制，以及 Argo Rollouts 的渐进式发布与自动回滚。

学习目标

理解 GitOps 的声明式理念与拉取式模型
掌握 Application 的 source/destination 结构与 Project 分组
说清同步周期、自动/手动同步、自愈与自动剪枝
理解 App of Apps 模式与多集群管理
理解 Argo Rollouts 的蓝绿/金丝雀发布与 Analysis 自动回滚

一、GitOps：Git 成为部署的唯一事实来源

ArgoCD 的官方定位：Kubernetes 的声明式 GitOps 持续交付工具。核心理念："应用定义、配置和环境应该是声明式且受版本控制的；应用部署与生命周期管理应该是自动化、可审计、易于理解的。"

GitOps 仓库：存放应用配置的仓库（通常由 CI/CD 流程或运维工程师更新）。ArgoCD 追踪它并在检测到变化时应用变更——期望状态的唯一事实来源。支持 Kubernetes YAML、Helm Charts 与 Kustomize（不限于 YAML）。

GitOps 的优势：全部配置集中在一个地方、以代码形式定义（透明、易调整、易复现）；所有人走同一接口（Git 的 PR/评审流程）；工程师不再手工敲命令碰运气；即使有人手动覆盖集群状态，也会被自动纠正。

拉取式（Pull）模型：ArgoCD 周期性地从 Git 仓库拉取期望状态并比对集群实际状态——区别于 Jenkins 等推送式（CI 系统推送到集群）。ArgoCD 与 Kubernetes 同一生态：作为集群的扩展运行，复用 K8s controller（监控差异）与 etcd（存储数据）——"把 ArgoCD 装进集群"与"把 Jenkins 搬进集群"有本质不同。

维度	Jenkins	ArgoCD
职责	CI/CD 均可	只做 CD，仍需 CI 系统
环境	独立应用	K8s 原生，装进命名空间即用
部署状态可见性	需额外步骤	同集群实时跟踪
回滚	依赖流水线记录	切回旧 commit 即触发同步回滚

二、Application：ArgoCD 的主资源

Application 是 ArgoCD 的主资源（一个 CRD），负责把应用资源部署并同步到 Kubernetes 集群：


apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: some-app
  namespace: argocd
spec:
  project: default              # 所属 Project（逻辑分组）
  source:                       # 期望状态从哪来
    repoURL: https://github.com/bregman-arie/devops-exercises
    targetRevision: HEAD        # 分支/commit/tag
    path: main                  # 仓库内 manifest 目录
  destination:                  # 同步到哪里
    server: http://some.kubernetes.cluster.svc
    namespace: devopsExercises
  syncPolicy:
    automated:
      prune: true               # 自动剪枝
      selfHeal: true            # 自愈

Project：把多个 Application 逻辑分组的 CRD——团队的边界。Repository：ArgoCD 追踪的应用配置仓库。

同步机制：默认同步周期是 3 分钟（不是 3 小时）。每个周期：收集所有标记 auto-sync 的应用 → 获取每个仓库的 Git 状态 → 与集群实际状态比对——有差异标记 out-of-sync（按配置自动同步），一致标记 synced。周期可在 argocd-cm ConfigMap 中改（timeout.reconciliation: 300s）；设为 0s 会禁用同步。

同步策略：自动同步（检测到差异即应用）、手动同步（只识别不纠正，人点击 sync）、自动剪枝 auto-prune（Git 中删除的内容对应集群资源被删）、自愈 self-heal（手动改动被 Git 状态纠正——也可配置为只告警不纠正）。

三、健康状态与典型工作流

Health Status 六种：Healthy、Missing（资源不存在）、Suspended（暂停）、Progressing（有机会变健康）、Degraded（不健康）、Unknown。

健康判定要点：Deployment 等控制器不是"Pod 在跑就算健康"——而是期望状态 == 实际状态（含副本数）；Ingress 健康看 status.loadBalancer.ingress 非空；自定义资源用 Lua 脚本定义判定。

典型端到端工作流（CI 与 CD 分工）：

开发者提交变更到应用仓库；
Jenkins 流水线对变更执行 CI；
成功则基于新代码构建镜像并推送 registry；
更新独立的配置仓库中的 K8s manifest；
ArgoCD 追踪配置仓库 → 检测到变化 → 应用变更到集群。

App of Apps 模式：一个根 Application 指向一个含多个子 Application 的仓库，根应用统一管理子应用。典型用例：集群引导（一次性部署多个应用）、多环境（同一应用多版本）、多集群（同一应用部署到多个 K8s 集群）。

多集群管理：一个 ArgoCD 实例即可管理多个外部集群（argocd cluster add）——不需要每集群装一个。

多环境更新策略：GitOps 仓库一更新所有环境同时变——按环境分分支（dev 测试 → merge staging → 验证 → merge prod），或用 Kustomize overlays 按流水线控制同步范围。

灾难恢复：集群崩溃后，把 ArgoCD 指向新集群 + 同一 GitOps 仓库，配置即可恢复。

常用命令：argocd app create（--project/--repo/--path/--dest-namespace/--dest-server）、argocd app list、argocd app get、argocd cluster add/list。

四、Argo Rollouts：渐进式发布与自动回滚

Rollouts 是 Kubernetes 控制器，用不同策略执行应用部署：Blue/Green、Canary，还支持 A/B 测试、自动回滚、集成指标分析。

发布新版本时发生什么：创建新的 ReplicaSet（新版本），旧版本仍存活；ArgoCD 将应用标记为 out-of-sync（属正常现象）。

与 ArgoCD 的关系：可独立使用（Rollouts 是控制器，ArgoCD 是 CD 工具），只是配合很好。

Analysis（分析）：随 Rollout 一起部署的资源，定义执行回滚的条件与指标阈值——把人工 smoke test 变成全自动回滚：


apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service-name
  metrics:
  - name: success-rate
    interval: 4m          # 每 4 分钟查询一次
    count: 3              # 最多查询 3 次
    successCondition: result[0] >= 0.90   # 成功率 >= 90% 继续发布
    provider:
      prometheus:
        address: http:/some-prometheus-instance:80
        query: sum(response_status{app="{{args.service-name}}",role="canary",status=~"2.*"})/sum(response_status{app="{{args.service-name}}",role="canary"})

解读：从 Prometheus 取金丝雀版本 2xx 响应占比；≥0.90 继续发布，<0.90 判定失败、自动回滚。支持 Datadog、NewRelic、Prometheus 等指标提供商。

常用命令（kubectl 插件）：kubectl argo rollouts list rollouts / get rollout / status / set image（发布新版本）/ promote（手动提升）/ get rollout --watch。

小结

本节完成了交付管线的最后闭环：GitOps 用"Git 为唯一事实来源"解决部署状态的一致性问题；ArgoCD 的 Application 定义"从哪拉到哪"，同步周期 + 自愈 + 剪枝让集群自动收敛；App of Apps 与多集群管理覆盖规模化场景；Rollouts 把发布从"全量切换"升级为"金丝雀渐进 + 指标自动回滚"。至此，从代码提交到生产发布的全链路自动化已经贯通——但发布之后呢？系统的健康、性能与故障原因，需要可观测性来回答。

下一节预告

第 9 章《云平台与网络》将讲解云计算的三种服务模型与 AWS 的核心服务（计算/存储/网络），第 10 章《可观测性与数据》再回到质量度量与故障定位。