ArgoCD 实战指南：基于 GitOps 的 Kubernetes 持续交付

1. 项目概述：为什么我们需要 ArgoCD？

如果你和我一样，在容器化和微服务这条路上摸爬滚打了好几年，那你一定对“部署”这件事又爱又恨。爱的是，Kubernetes 让应用的发布和管理变得前所未有的强大和灵活；恨的是，随之而来的复杂性也指数级增长。你可能会遇到这样的场景：开发团队用 Git 管理应用代码，用 Helm Chart 或 Kustomize 定义部署清单，然后运维同学需要手动kubectl apply -f，或者写一堆 CI/CD 流水线脚本去同步。版本不一致、配置漂移、回滚困难、谁在什么时间改了什么都成了糊涂账…… 这些问题，本质上都是“声明式”的 Kubernetes 遇到了“命令式”的部署流程。

ArgoCD 的出现，就是为了解决这个核心矛盾。它不是一个简单的部署工具，而是一个声明式的、GitOps 持续交付工具。简单来说，它把 Git 仓库作为你期望的、应用在 Kubernetes 中应该呈现的“唯一事实来源”。ArgoCD 会持续监控这个 Git 仓库，一旦仓库里的配置（比如 YAML 文件、Helm Chart）发生变化，它会自动或手动地将这些变更同步到你的 Kubernetes 集群中，确保集群的实际状态与 Git 中声明的期望状态始终保持一致。

这带来的好处是革命性的：部署过程可审计（所有变更通过 Git 提交记录）、可重复（任何环境都可以从同一个 Git 仓库同步）、回滚极其简单（直接 revert Git 提交）。对于运维和开发来说，它把部署从一项“操作”变成了一个“状态声明”的过程，极大地提升了安全性和效率。接下来，我们就从零开始，把它用起来。

2. 核心概念与架构拆解：理解 ArgoCD 的工作方式

在动手之前，我们必须先理清 ArgoCD 的几个核心概念，这能帮你更好地理解后续的配置和操作，而不是机械地复制命令。

2.1 GitOps 模型：期望状态 vs. 实际状态

这是 ArgoCD 的基石。在传统 CI/CD 中，CI 流水线构建镜像，然后 CD 流水线（或脚本）负责“推送”部署。在 GitOps 模型中，Git 仓库里存放的是你期望的整个应用的状态描述（不仅仅是代码）。ArgoCD 作为集群内的一个控制器，负责“拉取”这个状态，并将其与集群的实际状态进行对比。

• 期望状态：定义在 Git 仓库中的 Kubernetes 清单文件（如 deployment.yaml, service.yaml）或 Helm Chart、Kustomize 覆盖等。
• 实际状态：你的 Kubernetes 集群中，那些 Pod、Service、Deployment 等资源真实运行的状态。

ArgoCD 的核心工作就是持续比较这两者，并在出现偏差（Drift）时，根据你的策略进行修正（同步），使实际状态向期望状态靠拢。

2.2 核心组件与架构

ArgoCD 本身也是作为一组 Kubernetes 应用部署在你的集群里的，主要包含以下组件：

1. API Server：提供 gRPC/REST API，是 Web UI 和 CLI 工具的后端，处理所有操作逻辑。
2. Repository Server：一个内部服务，负责维护 Git 仓库的本地缓存，获取并生成 Kubernetes 清单（例如，渲染 Helm Chart，或执行 Kustomize build）。
3. Application Controller：这是大脑。它持续监控 Git 仓库中定义的应用，计算期望状态与实际状态的差异，并根据配置决定是否以及如何执行同步操作。它还负责管理子资源（如 Deployment 下的 Pods）的生命周期状态。
4. Redis：用于缓存，提升性能。
5. Web UI：直观的可视化管理界面，你可以看到所有应用的状态、健康情况、差异对比，并执行同步等操作。

它的工作流可以概括为：你通过 UI 或 CLI 创建一个“应用”（Application），这个应用指向一个 Git 仓库的特定路径（包含 Kubernetes 清单）。Application Controller 会指示 Repository Server 去拉取并生成清单，然后持续对比集群状态，并通过 Web UI 和 CLI 向你报告。

2.3 关键资源对象：Application 与 AppProject

• Application：这是 ArgoCD 管理的基本单元。一个 Application 资源代表了一个你希望部署的应用。它包含了源信息（Git 仓库 URL、分支、路径、Helm 参数等）和目标信息（目标 Kubernetes 集群的 API Server 地址和命名空间）。
• AppProject：用于对 Applications 进行逻辑分组和权限隔离。你可以通过 Projects 来设置哪些源仓库、目标集群和命名空间可以被其下的 Applications 使用，以及设置同步策略、角色权限等。这在多团队环境中至关重要。

理解这些概念后，你就知道，使用 ArgoCD 的核心就是“定义和管理 Application 资源”。

3. 安装与初始配置：让 ArgoCD 在你的集群里跑起来

理论说再多不如动手。我们假设你有一个可用的 Kubernetes 集群（可以是 Minikube、Kind 本地集群，也可以是云上的 EKS、ACK 等）。安装 ArgoCD 有多种方式，这里我们使用最通用的 Manifest 方式，它兼容性最好。

3.1 安装 ArgoCD 核心组件

首先，创建一个独立的命名空间来安装 ArgoCD，这是一个好习惯。

kubectl create namespace argocd

接下来，应用官方的安装清单。这里我们安装稳定版本。

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

这个命令会部署我们之前提到的所有组件。等待几分钟，直到所有 Pod 都进入Running状态。

kubectl get pods -n argocd --watch

注意：在某些云环境或特定网络策略下，镜像拉取可能会慢或失败。如果遇到问题，可以尝试先拉取镜像到本地，或者检查网络连通性。一个常见的技巧是使用imagePullPolicy: IfNotPresent并提前将镜像加载到本地（如使用 Minikube 的minikube image load）。

3.2 访问 ArgoCD Web UI

默认安装下，ArgoCD Server 是以 ClusterIP 类型 Service 暴露的，无法从集群外部直接访问。我们有几种方式暴露它：

方式一：端口转发（最快捷，适合本地测试）

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

然后浏览器访问https://localhost:8080（注意是 HTTPS）。由于是自签名证书，浏览器会提示不安全，需要手动接受风险继续访问。

方式二：修改为 NodePort 或 LoadBalancer（适合临时外部访问）

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}' # 或者 NodePort # kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "NodePort"}}'

然后通过kubectl get svc -n argocd查看分配的外部 IP 或端口进行访问。

方式三：通过 Ingress 暴露（生产推荐）你需要有一个 Ingress Controller（如 Nginx Ingress, Traefik）。然后创建如下的 Ingress 资源：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argocd-server-ingress namespace: argocd annotations: # 这里以 nginx ingress 为例，根据你的 Ingress Controller 调整 nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" nginx.ingress.kubernetes.io/ssl-passthrough: "true" # 如果 ArgoCD 使用 TLS # 如果 ArgoCD 配置了 TLS，通常需要 ssl-passthrough 或配置正确的证书 spec: ingressClassName: nginx rules: - host: argocd.your-domain.com http: paths: - path: / pathType: Prefix backend: service: name: argocd-server port: number: 443

重要提示：生产环境务必为 ArgoCD 配置 TLS 证书，并考虑启用 SSO 集成（如 OIDC）以加强认证安全。默认的 admin 密码方式不适合多人协作环境。

3.3 获取初始管理员密码

首次登录，用户名是admin。密码存储在名为argocd-initial-admin-secret的 Secret 中，可以通过以下命令获取：

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

复制输出的密码，登录 Web UI。登录后第一件事就是修改这个密码。

3.4 安装 ArgoCD CLI 工具 (argocd)

CLI 工具对于自动化和脚本操作非常有用。安装方法如下（以 Linux/macOS 为例）：

# 下载最新版，请从官方 GitHub Release 页面获取最新版本号 VERSION=$(curl --silent "https://api.github.com/repos/argoproj/argo-cd/releases/latest" | grep '"tag_name"' | sed -E 's/.*"([^"]+)".*/\1/') sudo curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/$VERSION/argocd-linux-amd64 # 如果是 macOS，将 URL 中的 `linux-amd64` 替换为 `darwin-amd64` sudo chmod +x /usr/local/bin/argocd

安装后，需要登录到你的 ArgoCD Server。如果你用了端口转发，可以这样登录：

argocd login localhost:8080 --username admin --password <你刚才获取的密码> --insecure # --insecure 是因为自签名证书

4. 第一个应用：从 Git 到 Kubernetes 的自动同步

现在，让我们创建一个最简单的应用，体验 GitOps 的魔力。我们需要准备两样东西：一个包含 Kubernetes 清单的 Git 仓库，以及在 ArgoCD 中定义这个应用。

4.1 准备示例 Git 仓库

为了演示，你可以直接使用 ArgoCD 官方的示例仓库，或者自己在 GitHub/GitLab 上创建一个。这里我们使用一个经典的“guestbook”应用示例。

假设你的 Git 仓库地址是：https://github.com/your-username/argocd-example-apps在仓库里创建一个文件夹guestbook，里面放入以下两个文件：

guestbook/guestbook-deployment.yaml

apiVersion: apps/v1 kind: Deployment metadata: name: guestbook-ui spec: replicas: 2 selector: matchLabels: app: guestbook-ui template: metadata: labels: app: guestbook-ui spec: containers: - name: guestbook-ui image: gcr.io/heptio-images/ks-guestbook-demo:0.2 ports: - containerPort: 80

guestbook/guestbook-service.yaml

apiVersion: v1 kind: Service metadata: name: guestbook-ui spec: ports: - port: 80 targetPort: 80 selector: app: guestbook-ui type: LoadBalancer # 或 NodePort，方便我们访问

提交并推送到你的远程仓库。

4.2 通过 Web UI 创建应用

1. 登录 ArgoCD Web UI。
2. 点击左侧导航栏的“+ NEW APP”。
3. 填写应用详情：
   • Application Name:my-guestbook(任意名称，在 ArgoCD 内唯一)
   • Project:default(使用默认项目)
   • SYNC POLICY: 选择Manual(我们先手动同步，感受过程)
4. SOURCE部分：
   • Repository URL:https://github.com/your-username/argocd-example-apps
   • Revision:HEAD(指向最新提交，也可指定分支如main)
   • Path:guestbook(指向存放 YAML 文件的目录)
5. DESTINATION部分：
   • Cluster:https://kubernetes.default.svc(这是 ArgoCD 所在的集群，即“就地部署”)
   • Namespace:default(将应用部署到 default 命名空间，也可以新建一个)
6. 点击右上角的“CREATE”。

创建完成后，你会在应用列表看到my-guestbook，状态可能是Missing或OutOfSync。这是因为我们还没有执行同步操作。

4.3 执行同步与观察状态

1. 点击进入my-guestbook应用详情页。
2. 你会看到一个直观的拓扑图，显示了 Git 仓库中的资源（期望状态）和集群中的资源（实际状态，目前为空）之间的差异。
3. 点击顶部的“SYNC”按钮。
4. 在弹出的对话框中，你可以看到将要被创建的资源（Deployment 和 Service）。保持默认选项，点击“SYNCHRONIZE”。

同步开始后，ArgoCD 会开始创建资源。回到应用详情页，你可以实时看到状态变化：从Progressing到Healthy。同时，拓扑图中的资源会从灰色变为绿色。

4.4 验证部署结果

同步完成后，我们可以用kubectl验证：

kubectl get deployment,svc -l app=guestbook-ui -n default

你应该能看到 Deployment 和 Service 已经创建，并且 Pod 正在运行。如果 Service 类型是LoadBalancer或NodePort，你还可以获取外部 IP 或端口，在浏览器中访问该应用。

至此，你已经完成了第一次 GitOps 交付！应用的状态完全由 Git 仓库中的 YAML 文件定义。

5. 核心功能深度解析：让 ArgoCD 更强大

仅仅同步 YAML 文件只是开始。ArgoCD 提供了丰富的功能来应对复杂场景。

5.1 同步策略：自动 vs. 手动 vs. 策略化

创建应用时，我们选择了Manual（手动）同步。在实际生产中，我们往往需要自动化。

• 手动同步：安全，适合关键生产环境，变更需人工审核后触发。
• 自动同步：在创建应用时，勾选AUTOMATED选项。当 Git 仓库中的配置发生变更时，ArgoCD 会自动执行同步，无需人工干预。谨慎使用，建议配合其他检查（如 PR 评审、CI 流水线）。
• 同步策略：这是更精细的控制。你可以在应用或项目级别设置syncOptions。
  • Prune（修剪）：同步时，自动删除在 Git 中已不存在的集群资源。这是一个危险操作，但也是保持集群纯净的关键。启用前务必确认。
  • CreateNamespace：如果目标命名空间不存在，则自动创建。
  • ApplyOutOfSyncOnly：仅同步那些处于OutOfSync状态的资源，提高同步效率。
  • RespectIgnoreDifferences：在比较差异时，忽略某些字段（如 Deployment 的image字段，如果你希望由其他工具管理镜像更新）。

实操心得：对于生产环境，我个人的经验是采用“自动同步 + Prune 禁用 + 需要人工确认”的折中方案。即设置自动同步，但通过 ArgoCD 的syncWindows（同步窗口）功能，限制在非业务高峰时段自动同步，并且对于删除操作（Prune）或特定敏感资源，仍然设置为手动确认。这既保证了效率，又控制了风险。

5.2 健康检查与钩子

ArgoCD 不仅仅是部署，它还关心应用部署后的健康状态。

• 健康检查：对于内置的 Kubernetes 资源类型（如 Deployment, StatefulSet, Service 等），ArgoCD 有预定义的健康检查逻辑。例如，一个 Deployment 只有在所有副本都就绪时才是Healthy。对于自定义资源（CRD），你可以编写 Lua 脚本来定义健康检查逻辑。
• 资源钩子：允许你在同步生命周期的特定时刻运行一些 Kubernetes 资源。这是实现复杂部署流程（如数据库迁移、预热、通知）的关键。钩子类型包括：
  • PreSync: 同步开始前执行（如备份、检查）。
  • Sync: 替代默认的kubectl apply行为（很少用）。
  • PostSync: 同步成功后执行（如运行测试、发送通知、更新状态）。
  • SyncFail: 同步失败时执行（如告警、清理）。

例如，一个Job资源可以通过添加注解argocd.argoproj.io/hook: PostSync来成为一个 PostSync 钩子。这个 Job 会在主应用部署成功后自动运行，执行数据迁移脚本，并在完成后被删除（如果配置了hook-delete-policy: HookSucceeded）。

5.3 配置管理：Helm 与 Kustomize 集成

现实中的应用配置很少是纯静态的 YAML。ArgoCD 原生深度集成了 Helm 和 Kustomize 这两种最流行的配置管理工具。

使用 Helm：在创建应用的 SOURCE 部分，将“PATH”改为你的 Chart 目录（如./my-chart），并将“TARGET REVISION”留空或指定 Chart 版本。在下方会出现“Helm”参数区域。

• Values Files: 可以指定一个或多个 values 文件（如values-production.yaml）。
• Parameters: 可以覆盖具体的 values 值（如image.tag=v1.2.3）。
• Release Name: 设置 Helm Release 的名称。

使用 Kustomize：如果你的源码目录包含kustomization.yaml文件，ArgoCD 会自动识别并使用 Kustomize 进行渲染。你可以在 SOURCE 的“Directory”部分配置递归、是否包含.env文件等选项。

工具选型建议：如果你的应用配置相对简单，且跨环境差异不大，Kustomize 的纯声明式、无模板的方式更清晰。如果你的应用配置非常复杂，需要大量的条件逻辑、变量和共享库，Helm 的模板引擎更强大。很多团队会结合使用，比如用 Helm 管理第三方应用，用 Kustomize 管理内部应用。

5.4 多集群与多租户管理

ArgoCD 可以管理多个 Kubernetes 集群。在“Settings” -> “Clusters”中，你可以添加外部集群。

1. 首先，你需要获取目标集群的 kubeconfig。
2. 在 ArgoCD 中，点击“+ CONNECT CLUSTER”，通常选择“VIA SERVICE ACCOUNT”方式（更安全）。这会在目标集群中创建一个 ServiceAccount 和对应的 ClusterRoleBinding，然后 ArgoCD 会使用这个 ServiceAccount 的 Token 来访问目标集群。
3. 连接成功后，在创建应用时，DESTINATION 的 Cluster 下拉列表中就会出现这个新集群。

结合AppProject，你可以实现多租户隔离。例如：

• 创建一个名为team-a的 Project。
• 限制其 Source Repositories 只能访问https://github.com/company/team-a-*的仓库。
• 限制其 Destinations 只能部署到cluster-1的namespace-a和namespace-b。
• 然后为 Team A 的成员分配只能操作team-a这个 Project 的权限。

这样，不同团队就可以在同一个 ArgoCD 实例中安全地工作，互不干扰。

6. 高级实践与运维技巧

掌握了基础，我们来看看一些提升效率和可靠性的高级玩法。

6.1 应用集与多应用管理

当你有数十上百个微服务时，逐个管理 Application 是灾难。ArgoCD 提供了ApplicationSet控制器来解决这个问题。

ApplicationSet 允许你通过模板，基于一些生成器（如 Git 目录列表、集群列表、Pull Request 等）自动创建和管理一大批 Application。

例如，你有一个微服务仓库，每个服务一个目录。你可以定义一个 ApplicationSet，使用git生成器，扫描仓库的所有子目录，为每个包含kustomization.yaml或Chart.yaml的目录自动创建一个 Application。

示例 ApplicationSet YAML (app-of-apps 模式简化版):

apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: my-microservices namespace: argocd spec: generators: - git: repoURL: https://github.com/company/microservices-repo.git revision: HEAD directories: - path: services/* template: metadata: name: '{{path.basename}}' spec: project: default source: repoURL: https://github.com/company/microservices-repo.git targetRevision: HEAD path: '{{path}}' destination: server: https://kubernetes.default.svc namespace: '{{path.basename}}' syncPolicy: automated: prune: true selfHeal: true

这个 ApplicationSet 会为services/目录下的每个子文件夹（每个微服务）创建一个同名的 Application，并部署到同名的命名空间中。

6.2 配置漂移检测与自动修复

GitOps 的一大优势是能检测并修复配置漂移。假设有人手动用kubectl edit修改了 Pod 的副本数，这会导致实际状态与 Git 中声明的期望状态不一致。

ArgoCD 默认会定期（可配置）比较状态。在 UI 中，漂移的资源会显示为“OutOfSync”。

• 手动修复：点击 “Sync” 即可将集群状态恢复成 Git 中定义的状态。
• 自动修复：在同步策略中启用“Self-Heal”（自愈）。当 ArgoCD 检测到漂移（且非由钩子引起）时，它会自动触发同步来修复。生产环境慎用，因为它可能会覆盖一些有意的临时调整。

6.3 金丝雀与蓝绿部署

ArgoCD 本身不直接提供金丝雀或蓝绿部署的“一键按钮”，但它与Argo Rollouts控制器完美集成，实现了高级部署策略。

Argo Rollouts 是一个 Kubernetes CRD 控制器，它提供了比原生 Deployment 更强大的部署功能（金丝雀、蓝绿、渐进式交付）。你可以这样配合使用：

1. 在集群中安装 Argo Rollouts。
2. 在 Git 仓库中，用Rollout资源（来自argoproj.io/v1alpha1API）替代传统的Deployment。
3. 在 Rollout 资源中定义你的金丝雀策略（如分 10% 流量，暂停 1 小时，分析指标，再全量）。
4. ArgoCD 负责将这个 Rollout 资源同步到集群。
5. Argo Rollouts 控制器会接管这个资源，按照你定义的策略执行复杂的发布流程。
6. 你可以在 ArgoCD UI 中看到 Rollout 的详细状态和步骤，并通过 Argo Rollouts 的 Kubectl 插件或 UI 来手动推进、中止、回滚发布。

这种组合将“配置声明”（GitOps）和“发布过程控制”（渐进式交付）完美解耦又紧密结合。

6.4 秘钥管理：集成外部 Secrets 工具

Kubernetes Secret 资源虽然能存密码，但明文存储在 Git 里是绝对的安全禁忌。ArgoCD 通过Secret 插件或与外部 Secrets 管理工具集成来解决这个问题。

主流方案有：

• Sealed Secrets：使用公钥加密 Secret，将加密后的密文存入 Git。集群中的 Sealed Secrets 控制器用私钥解密并创建对应的 Kubernetes Secret。ArgoCD 只需要同步 SealedSecret 资源即可。
• External Secrets Operator (ESO)或AWS Secrets Manager / HashiCorp Vault 集成：在 Git 中存放的是对外部 Secret 的“引用”（ExternalSecret 资源）。ESO 控制器会根据这个引用，从 AWS Secrets Manager 或 Vault 中拉取真正的 secret 值，并在集群内创建对应的 Kubernetes Secret。ArgoCD 同步的是 ExternalSecret 资源。

配置示例 (使用 ExternalSecret):你的 Git 仓库里存放的是这样的文件：

# external-secret.yaml apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: my-app-db-secret spec: refreshInterval: 1h secretStoreRef: name: vault-backend kind: SecretStore target: name: my-app-db-secret # 最终生成的 K8s Secret 的名字 data: - secretKey: password remoteRef: key: /secret/data/myapp property: db_password

ArgoCD 将这个文件同步到集群，ESO 控制器会去 Vault 里拿真正的密码，并生成一个名为my-app-db-secret的标准 Kubernetes Secret，供你的应用 Pod 挂载使用。

7. 常见问题与排查技巧实录

在实际使用中，你肯定会遇到各种问题。这里记录了几个最典型的坑和排查思路。

7.1 应用状态一直卡在 “Progressing” 或 “Unknown”

这是最常见的问题之一。

1. 检查资源是否真的部署成功：首先用kubectl直接检查目标命名空间下的 Pod、Deployment 状态。看看是不是镜像拉取失败、资源配额不足、健康检查不通过等 Kubernetes 层面的问题。ArgoCD 只是报告者，问题根源通常在集群里。
2. 检查 ArgoCD 的日志：查看相关组件的日志，尤其是argocd-repo-server和argocd-application-controller。

   kubectl logs -n argocd deploy/argocd-application-controller -c application-controller

   关注是否有 Git 拉取错误、清单渲染错误（Helm/Kustomize 报错）、权限错误等。
3. 检查仓库连接和认证：在 UI 中进入 “Settings” -> “Repositories”，检查你应用所使用的仓库连接状态是否为 “Successful”。如果失败，可能是 URL 错误、证书问题（自签名证书需要额外配置）或认证信息（如私有仓库的 SSH 密钥或用户名密码）错误。
4. 检查目标集群连接：在 “Settings” -> “Clusters” 中，检查目标集群的连接状态。

7.2 同步失败，报错 “manifest generation error”

这通常发生在使用 Helm 或 Kustomize 时，意味着 Repository Server 无法正确渲染出最终的 Kubernetes 清单。

• 对于 Helm：
  • 检查values.yaml文件语法是否正确。
  • 检查 Chart 依赖（requirements.yaml或Chart.yaml中的dependencies）是否已下载。你可以在仓库中运行helm dependency build并提交charts/目录，或者在 ArgoCD 的应用配置中启用 “Skip Crds” 等选项试试。
  • 检查 Helm 版本兼容性。ArgoCD 内置了特定版本的 Helm，可能与你本地开发使用的版本不兼容。
• 对于 Kustomize：
  • 检查kustomization.yaml文件语法。
  • 检查引用的资源文件（如resources:列表中的文件）路径是否正确，是否存在于 Git 仓库中。
  • 检查是否有需要的外部变量（configMapGenerator或secretGenerator引用的文件）。

一个有用的调试技巧是使用 ArgoCD CLI 的argocd app manifests命令，它可以模拟 Repository Server 的行为，输出渲染后的清单，帮助你定位问题：

argocd app manifests my-guestbook

7.3 如何回滚？

GitOps 下的回滚极其简单和清晰。

1. 找到想要回滚到的 Git 提交：在 ArgoCD UI 的应用详情页，点击 “HISTORY AND ROLLBACK”。你会看到该应用所有的同步历史，对应着 Git 的提交记录。
2. 执行回滚：选中你想要回滚到的那个历史版本，点击 “ROLLBACK” 按钮。ArgoCD 会立即将集群状态同步到那个历史提交所定义的状态。

重要提示：这依赖于你的 Git 历史是线性的且包含完整的配置。确保你的团队遵循“所有配置变更都通过 Git 提交”的原则。如果有人在集群里手动修改了东西，回滚可能无法完全恢复到过去的状态，这就是为什么我们要杜绝手动操作。

7.4 权限管理与 RBAC 配置

默认的 admin 用户权限太大。生产环境必须配置基于角色的访问控制（RBAC）。

ArgoCD 的 RBAC 规则可以在argocd-cmConfigMap 中配置。你可以定义策略（policy.csv），格式类似：

p, role:developer, applications, get, */*, allow p, role:developer, applications, sync, project-a/*, allow g, alice, role:developer

这条规则表示：定义角色developer，允许其对所有应用有get权限，但只允许对project-a项目下的应用执行sync操作；然后将用户alice赋予developer角色。

更复杂的权限（如基于资源标签过滤）可以通过argocd-rbac-cmConfigMap 配置。结合 Projects 对资源进行隔离，可以构建出非常精细的权限体系。

避坑技巧：在配置 RBAC 时，先在非生产环境用一个小权限角色测试。一个常见的坑是权限配置过松或过紧，导致 UI 上某些按钮消失或操作失败，错误信息又不明显。仔细阅读官方文档中关于 RBAC 的部分，理解action、object和effect的匹配规则。