什么是 GitOps
GitOps 是一套由 Weaveworks 于 2017 年提出的运维方法论。核心理念是：将 Git 仓库作为系统基础设施和应用配置的唯一真实来源（Single Source of Truth），通过自动化工具持续同步 Git 中的声明式配置到目标系统（如 Kubernetes 集群）。
当工程师想要修改生产环境时，他不再直接 kubectl apply，而是提交一个 Pull Request 到配置仓库，经过 Code Review 后合并，ArgoCD 自动将变更同步到集群。这意味着所有操作都有完整的 Git 历史记录，回滚只需 git revert。
GitOps 四大原则
OpenGitOps 社区总结了 GitOps 的四大核心原则，ArgoCD 完整实现了这四点：
1. 声明式
系统所有配置必须以声明式方式描述（YAML/JSON），而非命令式脚本。描述"期望状态"，而不是"如何操作"。Kubernetes 本身就是声明式的，GitOps 要求配置管理工具也必须是声明式的。
2. 版本化且不可变
所有期望状态必须存储在支持版本控制的系统中（通常是 Git），具有不可变历史记录。任何变更都能追溯到具体的 commit、PR、作者和时间，提供完整审计链。
3. 自动应用
经过批准的配置变更（Git commit 合并到主分支）应自动且立即应用到目标系统，无需人工手动操作。ArgoCD 监听 Git 仓库变更，自动触发同步。
4. 持续协调
软件代理（ArgoCD 的 Application Controller）持续观察实际系统状态，当检测到与期望状态的偏差（漂移/Drift）时，自动尝试修复。这赋予系统自愈（Self-Healing）能力。
GitOps vs 传统 CI/CD
传统的 CI/CD（如 Jenkins Pipeline）通常是 Push 模式：CI 系统推送变更到集群。GitOps 是 Pull 模式：集群内的代理主动拉取 Git 配置并同步。这个区别极其重要。
| 对比维度 | 传统 CI/CD（Push） | GitOps（Pull） |
|---|---|---|
| 凭证存储 | CI 系统需持有集群 kubeconfig（高风险） | ArgoCD 在集群内，无需外部持有凭证 |
| 配置漂移 | 无法检测，手动 kubectl 改动无法发现 | 持续检测，自动修复漂移 |
| 回滚 | 需要重新触发 Pipeline | git revert + ArgoCD 自动同步 |
| 可审计性 | 依赖 CI 日志，分散 | Git 历史完整记录所有变更 |
| 多集群 | 需要为每个集群配置凭证和 Pipeline | ArgoCD 统一管理，AppSet 批量部署 |
| 灾备恢复 | 依赖 Pipeline 重新执行 | 新建集群后 ArgoCD 自动从 Git 恢复 |
GitOps 的安全优势
传统 CI/CD 中，Jenkins 等系统需要持有目标集群的高权限 kubeconfig，一旦 CI 系统被攻破，攻击者可以直接操控生产集群。GitOps 中 ArgoCD 运行在集群内部，外部系统无需直接访问集群，大幅缩小攻击面。
ArgoCD 架构详解
ArgoCD 是一个声明式的、GitOps 持续交付工具，由多个核心组件构成：
ArgoCD 架构图 ┌────────────────────────── argocd namespace ──────────────────────────────┐ │ │ │ ┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐ │ │ │ API Server │ │ Repo Server │ │ App Controller │ │ │ │ gRPC/REST/WS │ │ 克隆仓库/渲染 │ │ 同步调和循环 │ │ │ │ UI 后端+CLI │ │ Helm/Kustomize │ │ 漂移检测 │ │ │ └────────┬────────┘ └────────┬─────────┘ └────────┬────────┘ │ │ │ │ │ │ │ ┌────────▼──────────────────────▼───────────────────────▼────────┐ │ │ │ argocd-redis (状态缓存) │ │ │ └────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌───────────────┐ │ │ │ Dex Server │ SSO 身份提供者 (GitHub/GitLab/LDAP) │ │ └───────────────┘ │ └──────────────────────────────────────────────────────────────────────────┘ │ Watch │ Clone │ Apply/Delete ┌────────▼────────┐ ┌─────────▼──────┐ ┌──────▼──────────────┐ │ K8s API Server │ │ Git Repository │ │ Target K8s Cluster │ └─────────────────┘ └────────────────┘ └─────────────────────┘
API Server
ArgoCD 的主入口，提供 gRPC API（供 argocd CLI 使用）、REST API（供 Web UI 使用）和 WebSocket（实时推送）。负责认证授权、Application CRUD、手动触发同步等操作。
Repo Server
负责克隆 Git 仓库并渲染 Kubernetes 清单文件。支持 Helm（template/dependency update）、Kustomize（build）、Jsonnet，以及自定义插件（Config Management Plugin）。渲染结果缓存到 Redis。
Application Controller
ArgoCD 的核心控制器。持续运行调和循环（Reconciliation Loop），对比 Git 中的期望状态与集群实际状态，计算 Diff，执行同步（kubectl apply/delete）。每个 Application 都由一个 goroutine 持续监控。
Dex Server
内置 OpenID Connect 身份提供者，实现 SSO。对接 GitHub、GitLab、LDAP、SAML 等外部身份系统，将外部用户映射到 ArgoCD 角色。
Redis
缓存层，存储应用状态缓存和 Repo Server 的渲染结果，减少对 Git 仓库和 K8s API Server 的重复请求，提升性能。
安装 ArgoCD
方式一：kubectl apply（快速安装）
# 创建命名空间
kubectl create namespace argocd
# 应用官方安装清单（包含所有 CRD、RBAC、Deployment）
kubectl apply -n argocd -f \
https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# 等待所有 Pod 就绪
kubectl wait --for=condition=Ready pod --all -n argocd --timeout=120s
# 查看安装状态
kubectl get pods -n argocdNAME READY STATUS RESTARTS
argocd-application-controller-0 1/1 Running 0
argocd-applicationset-controller-xxx 1/1 Running 0
argocd-dex-server-xxx 1/1 Running 0
argocd-notifications-controller-xxx 1/1 Running 0
argocd-redis-xxx 1/1 Running 0
argocd-repo-server-xxx 1/1 Running 0
argocd-server-xxx 1/1 Running 0方式二：Helm Chart 安装（推荐生产）
# 添加 Argo Helm 仓库
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
# 查看可用版本
helm search repo argo/argo-cd --versions | head -5
# 安装（自定义 values）
helm install argocd argo/argo-cd \
--namespace argocd \
--create-namespace \
--version 7.x.x \
-f argocd-values.yaml# argocd-values.yaml 基础配置示例
server:
replicas: 2
ingress:
enabled: true
hostname: argocd.example.com
tls: true
applicationSet:
replicas: 2
controller:
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
cpu: 1000m
memory: 1Gi首次登录与 CLI 配置
获取初始密码
# 初始 admin 密码存储在 Secret 中
kubectl get secret argocd-initial-admin-secret \
-n argocd -o jsonpath="{.data.password}" | base64 -d
# 临时端口转发访问 UI（本地开发）
kubectl port-forward svc/argocd-server -n argocd 8080:443
# 浏览器访问: https://localhost:8080安装并配置 argocd CLI
# macOS
brew install argocd
# Linux
curl -sSL -o argocd \
https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
chmod +x argocd && sudo mv argocd /usr/local/bin/
# 登录 ArgoCD（需先端口转发或配置 Ingress）
argocd login localhost:8080 \
--username admin \
--password <initial-password> \
--insecure
# 修改初始密码
argocd account update-password
# 查看 ArgoCD 版本
argocd version
# 列出所有 Application
argocd app list生产部署注意事项
生产环境务必：① 通过 Ingress + TLS 暴露 ArgoCD UI，而非直接 NodePort；② 登录后立即修改 admin 密码或禁用 admin 账户并启用 SSO；③ 安装后删除 argocd-initial-admin-secret。
核心术语速查
Application
ArgoCD 中的核心资源（CRD）。定义了"从哪个 Git 仓库的哪个路径，部署到哪个集群的哪个命名空间"。是 ArgoCD 管理的基本单元。
AppProject
应用项目，用于多租户隔离。定义一组 Application 能访问的 Git 仓库范围、目标集群/命名空间范围，以及允许部署的 K8s 资源类型白名单。
同步 / Sync
将 Git 中的期望状态应用到目标集群的操作。可以手动触发（argocd app sync）或配置为自动同步（auto-sync）。同步成功后 Application 状态为 Synced。
漂移 / Drift
集群实际状态与 Git 期望状态不一致的情况。常见原因：有人直接 kubectl edit 修改了资源，或集群发生了不受 ArgoCD 管理的变更。漂移时 Application 状态为 OutOfSync。
自愈 / Self-Heal
启用自愈后，当 Application Controller 检测到漂移时，自动触发同步将集群状态恢复到 Git 定义的期望状态，无需人工干预。
Health Status
应用健康状态：Healthy（所有资源健康）、Degraded（有资源异常）、Progressing（有资源仍在部署中）、Suspended（已暂停）、Unknown（无法判断）。
本章小结
GitOps 的核心是将 Git 作为事实来源，通过四大原则（声明式、版本化、自动应用、持续协调）实现安全可审计的部署。ArgoCD 由 API Server、Repo Server、Application Controller 和 Dex 四大组件构成，以 Pull 模式持续同步集群状态。下一章将深入 Application CRD 的核心配置。