【K8S】云原生时代的GitOps最佳实践 —— ArgoCD

【K8S】云原生时代的GitOps最佳实践 --------- ArgoCD

文章目录

- 1、云原生时代的GitOps
- - [什么是 GitOps？](#什么是 GitOps？)
  - [GitOps、DevOps 和平台工程](#GitOps、DevOps 和平台工程)
  - 程序的本质是流程自动化
- 2、ArgoCD是什么
- - [ArgoCD 介绍](#ArgoCD 介绍)
  - [ArgoCD 工作原理](#ArgoCD 工作原理)
  - [ArgoCD 为什么脱颖而出](#ArgoCD 为什么脱颖而出)
- 3、ArgoCD实践上手
- - 实战操作
  - 高级特性与应用

1、云原生时代的GitOps

什么是 GitOps？

GitOps 是一种以 Git 为事实来源管理基础设施和应用发布的实践。它不是简单地"把 YAML 放进 Git"，而是把环境的期望状态写成声明式配置，通过 Pull Request 评审后合并，再由集群内的控制器持续对比 Git 与 Kubernetes 的实际状态，并把集群收敛到 Git 中描述的状态。

传统发布常见做法是：CI 构建镜像后，流水线直接连接集群执行 kubectl apply 或 helm upgrade。这种方式能完成部署，但问题也明显：流水线要保存集群凭证，线上变更不一定都有清晰审计，手动修改容易造成配置漂移，回滚也经常依赖临时脚本和个人经验。

GitOps 的发布链路更清晰：

开发提交代码，CI 构建镜像并推送到镜像仓库。
修改部署仓库中的镜像 tag、Helm values 或 Kustomize patch。
通过代码评审合并到目标分支。
GitOps Controller 检测 Git 变化，对比集群实际状态。
如果发现差异，自动或手动同步到 Kubernetes。

这里有两个关键词：声明式、可审计。声明式配置描述最终状态，例如 Deployment 副本数是 3、镜像版本是 v1.2.0、Service 暴露 8080 端口。至于如何从旧状态变成新状态，由 Kubernetes 和 GitOps 工具处理。Git 则负责记录每一次变更、评审、回滚和权限边界。

一个简单的期望状态如下：

yaml 复制代码

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80

当这段配置进入 Git，它就不只是部署文件，而是环境状态的版本化记录。发布是合并提交，回滚是回退提交，审计是查看 Git 历史。GitOps 真正解决的是交付秩序：用 Git 管变更入口，用控制器管执行，用 Kubernetes 管最终状态。

GitOps、DevOps 和平台工程

DevOps 更像组织协作方式，强调开发、测试、运维共同对交付质量负责；GitOps 是一套落地方法，把协作结果沉淀到 Git 和自动化控制器中。它不是替代 DevOps，而是让 DevOps 在 Kubernetes 场景下更容易标准化。

平台工程关注的是把复杂能力产品化，例如标准化集群、命名空间、CI 模板、发布模板、日志监控、权限模型和回滚流程。GitOps 与平台工程天然契合：平台团队维护基础模板和策略，业务团队通过提交配置完成发布，集群内控制器负责执行。

企业里常见的仓库拆分方式是：

应用源码仓库：保存业务代码和 Dockerfile，触发 CI 构建镜像。
部署配置仓库：保存 Kubernetes YAML、Helm values 或 Kustomize overlay。
平台基线仓库：保存 Ingress、监控、日志、权限、策略等集群基础能力。

这种模式的好处是权限边界清楚。CI 不必直接访问生产集群，只需要更新部署仓库；生产集群凭证保存在 ArgoCD 所在集群内。发布动作从"外部推送到集群"变成"集群内部拉取 Git 并同步"，这就是 GitOps 常说的 Pull 模式。Pull 模式减少了凭证暴露面，也让每一次生产变更都能回到 Git 中追踪。

程序的本质是流程自动化

程序的价值在于把可重复流程自动化。Kubernetes 已经把"如何运行容器"抽象成声明式 API，GitOps 进一步把"如何变更环境"抽象成可审计流程。

人工发布依赖经验，GitOps 发布依赖规则。比如发布一个服务，人工流程可能是登录机器、切上下文、执行脚本、观察日志、口头通知；GitOps 流程则可以固化为改配置、评审、合并、同步、观测、回滚。流程越标准，团队越不依赖个别熟手。

ArgoCD 的价值就在这里：它不是又一个发布按钮，而是把 Git、Kubernetes、权限、同步、健康检查和可视化串成一条稳定链路。

2、ArgoCD是什么

GitOps 领域目前公认的事实标准工具是 Argo CD 和 Flux CD。两者均为云原生计算基金会（CNCF）的毕业级项目。

如果你看重直观的 UI 仪表盘和多集群统一管控，建议首选 Argo CD；如果偏好命令行操作、追求极致的轻量与资源高可控，Flux CD 也可以成为你的选择。

Argo CD 在市场份额和活跃度上占据绝对主导地位，集群采用率约为 60%，而 Flux CD 约为 11% 至 15%。

ArgoCD 介绍

ArgoCD 是 Kubernetes 生态中最常用的 GitOps 持续交付工具。它运行在集群内，持续监听 Git 仓库中的应用配置，并将集群资源同步到 Git 描述的期望状态。

ArgoCD 支持原生 YAML、Kustomize、Helm、Jsonnet 和自定义配置管理插件。用户通常通过一个 Application 资源声明应用来源、目标集群、目标命名空间和同步策略。

一个最小 Application 示例：

yaml 复制代码

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-demo
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/gitops-demo.git
    targetRevision: main
    path: apps/nginx
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

这段配置表达了四件事：应用名是 nginx-demo；配置来自 Git 仓库的 apps/nginx 目录；目标是当前集群的 default 命名空间；开启自动同步，且允许删除 Git 中已经移除的资源，并自动修复集群内的手动漂移。

ArgoCD 工作原理

ArgoCD 的工作可以概括为四步：获取、渲染、对比、同步。

获取：repo-server 拉取 Git 仓库内容。如果应用使用 Helm 或 Kustomize，它会先渲染出最终 Kubernetes manifests。

对比：application-controller 读取目标集群当前资源状态，并和 Git 渲染出的期望状态做 diff。两边一致时，应用是 Synced；不一致时是 OutOfSync。

健康检查：ArgoCD 会根据资源类型判断运行状态。例如 Deployment 的可用副本是否满足期望，Service 是否存在，Ingress 是否创建成功。常见状态包括 Healthy、Progressing、Degraded、Missing。

同步：如果开启自动同步，ArgoCD 会主动 apply 资源；如果是手动同步，则需要用户在 UI 或 CLI 中执行 sync。

核心组件包括：

argocd-server：提供 Web UI、API 和 CLI 入口。
argocd-application-controller：负责监听 Application、对比状态和执行同步。
argocd-repo-server：负责拉取仓库并生成 manifests。
argocd-dex-server：可选 SSO 认证组件。
redis：缓存仓库、应用状态等数据。

排障时要区分两个状态：Synced 只表示配置已和 Git 一致，不代表应用一定可用；Healthy 才表示资源运行达到预期。因此 Synced / Degraded 很常见，含义是配置已经下发，但 Pod 可能因为镜像拉取、探针失败、资源不足等原因没有正常运行。

ArgoCD 为什么脱颖而出

ArgoCD 流行主要有四个原因。

第一，可视化强。它能把 Application、Deployment、ReplicaSet、Pod、Service、Ingress 等资源关系展示成拓扑图，发布状态、健康状态、事件和 diff 都能直接查看。

第二，和 Kubernetes 模型贴合。ArgoCD 本身通过 CRD 工作，Application 也可以放进 Git 管理，形成"用 GitOps 管 GitOps"的模式。

第三，权限和审计好做。结合 RBAC、SSO、AppProject，可以限制谁能同步哪个项目、哪个命名空间、哪个集群。测试环境可以自动同步，生产环境可以保留人工确认。

第四，生态成熟。它支持 Helm、Kustomize、多集群、同步钩子、差异忽略、自定义健康检查、ApplicationSet 等能力，能覆盖从单应用到多集群平台的大部分场景。

3、ArgoCD实践上手

实战操作

前提：已有 Kubernetes 集群，并且本地 kubectl 能访问该集群。

安装 ArgoCD：

bash 复制代码

kubectl create namespace argocd
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl get pods -n argocd

本地临时访问 UI：

bash 复制代码

kubectl port-forward svc/argocd-server -n argocd 8080:443

浏览器访问 https://localhost:8080。初始用户名是 admin，初始密码通过 Secret 获取：

bash 复制代码

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

建议首次登录后修改密码：

bash 复制代码

argocd login localhost:8080
argocd account update-password

准备部署仓库目录：

text 复制代码

gitops-demo/
  apps/
    nginx/
      deployment.yaml
      service.yaml

service.yaml 可以很简单：

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
  name: nginx-demo
spec:
  selector:
    app: nginx-demo
  ports:
    - port: 80
      targetPort: 80

创建 Application：

bash 复制代码

argocd app create nginx-demo \
  --repo https://github.com/example/gitops-demo.git \
  --path apps/nginx \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace default
argocd app sync nginx-demo
argocd app get nginx-demo

也可以把 Application 本身写成 YAML 放入 Git，由 ArgoCD 管理 ArgoCD。验证资源：

bash 复制代码

kubectl get deploy,svc,pod -l app=nginx-demo

之后修改 Git 中的 replicas 或镜像版本并合并。ArgoCD 会检测到应用变为 OutOfSync，自动同步或等待手动同步。回滚也建议通过 Git 完成：

bash 复制代码

git revert <commit-id>
git push origin main

这样发布和回滚都有审计记录，也不会绕开 GitOps 流程。

高级特性与应用

生产环境使用 ArgoCD，重点不是"能部署"，而是"可控地部署"。

多集群管理。默认 ArgoCD 管理自己所在集群，如果要接入其他集群，先确保本地 kubeconfig 能访问目标集群，再执行：

bash 复制代码

argocd cluster add <context-name>
argocd cluster list

接入后，Application 的 destination.server 可以指向远端集群。平台团队可以用一个中心 ArgoCD 管多个业务集群，也可以按环境拆分多个 ArgoCD，降低单点影响。

AppProject。它用于限制应用边界，例如允许使用哪些 Git 仓库、允许部署到哪些集群和命名空间、允许创建哪些资源。生产环境不要长期使用宽泛的 default 项目，建议按团队或业务线拆分。

yaml 复制代码

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: payment
  namespace: argocd
spec:
  sourceRepos:
    - https://github.com/example/payment-gitops.git
  destinations:
    - namespace: payment-*
      server: https://kubernetes.default.svc

同步策略。prune 表示 Git 删除资源后集群也删除；selfHeal 表示集群被手动改动后自动修复；CreateNamespace=true 可以自动创建目标命名空间。生产环境开启这些能力前要明确边界，尤其是 prune，它能保持环境干净，也可能删除不该由该应用管理的资源。

同步波次和钩子。复杂应用有顺序要求，例如先创建 CRD，再创建业务资源；先跑数据库迁移，再发布应用。ArgoCD 可以通过注解控制顺序：

yaml 复制代码

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"
    argocd.argoproj.io/hook: PreSync

差异忽略。有些字段会被 Kubernetes 或其他控制器自动改写，例如 HPA 修改副本数、Webhook 注入 sidecar、云厂商控制器回填字段。此时 ArgoCD 可能持续显示 OutOfSync。可以配置 ignore differences，但只建议忽略确定由系统管理的字段。

ApplicationSet。多集群、多环境、多服务场景下，不适合手写大量 Application。ApplicationSet 可以根据 Git 目录、集群列表或矩阵批量生成应用，适合平台团队管理一批服务。

推荐落地原则：

开发环境可自动同步，生产环境建议手动同步或增加审批。
基础资源、平台组件、业务应用分仓库或分目录管理。
使用 AppProject、RBAC、SSO 控制项目和环境权限。
禁止长期手改集群，紧急手改后必须回写 Git。
生产镜像避免使用 latest，使用明确 tag 或 digest。
监控 ArgoCD 本身，关注同步失败、仓库拉取失败和应用健康状态。

一个常见目录结构：

text 复制代码

platform-gitops/
  clusters/
    dev/
    prod/
  services/
    order/
      base/
      overlays/dev/
      overlays/prod/
    payment/
      base/
      overlays/dev/
      overlays/prod/

最后总结：GitOps 解决的是"变更如何可信地进入集群"，ArgoCD 解决的是"如何持续对齐 Git 与 Kubernetes"。小团队可以先从单集群、单应用、手动同步开始；流程稳定后，再逐步引入自动同步、多集群、ApplicationSet、SSO 和项目隔离。先让每次发布都可追踪、可回滚、可复现，价值就已经很明显。

参考资料：1, 2, 3, 4