Argo CD灾备准入策略审计与故障诊断 - 第2节

Argo CD 核心架构回顾：控制平面与数据平面

在深入灾备与准入策略之前，必须重新理解 Argo CD 的架构本质。Argo CD 遵循典型的 控制平面 / 数据平面 分离模式，这种设计直接决定了其灾备恢复的复杂度与策略选择。

架构核心认知：控制平面是 Argo CD 的大脑，负责决策与状态管理；数据平面是 Git 仓库与目标集群之间的实际交付通道。灾备策略必须分别覆盖这两个平面的故障场景。

控制平面 vs 数据平面

维度 控制平面 数据平面
职责 编排、决策、状态存储、API 暴露 实际资源同步、部署执行、健康检查
核心组件 API Server、Application Controller、状态存储 Repo Server、Redis（缓存层）
故障影响 无法创建/更新 Application，状态丢失 同步停滞，新部署无法下发
灾备重点 etcd 备份、API Server 多副本、Controller 选举 Repo Server 缓存预热、Redis 重建
Argo CD 控制平面与数据平面架构 控制平面 API Server Application Controller etcd（状态存储） Redis（缓存） 数据平面 Repo Server Git 仓库 目标集群 说明： 控制平面通过 API Server 与 Repo Server 交互获取清单，Application Controller 负责将清单同步到目标集群。 etcd 存储所有 Application 状态，Redis 缓存 Repo Server 的 Git 数据以加速同步。

核心组件详解

1. API Server

API Server 是 Argo CD 的入口组件，所有用户交互、CLI 命令、Web UI 请求、CI/CD 系统集成均通过 gRPC/REST API 接入。它负责认证、授权、请求路由与业务逻辑编排。

  • 认证与授权：支持本地用户、OIDC、LDAP、GitHub/GitLab OAuth，RBAC 策略在此执行。
  • 请求代理：将 Application 创建/更新请求写入 etcd，将同步请求转发给 Application Controller。
  • 高可用：无状态设计，多副本部署，前端通过 Ingress/Service 负载均衡。
灾备要点：API Server 本身无状态，灾备主要依赖 etcd 的可用性。API Server 重启后可从 etcd 恢复全部状态，无需额外数据恢复操作。

2. Repo Server

Repo Server 负责与 Git 仓库交互，生成 Kubernetes 清单。它是数据平面的核心执行者，也是性能瓶颈的常见来源。

功能 说明 灾备影响
Git 克隆与拉取 维护本地 Git 缓存，支持浅克隆与稀疏检出 缓存丢失后需重新克隆，首次同步延迟增加
清单生成 执行 Helm/Kustomize/Ksonnet 等模板引擎 无状态，但 CPU 密集，需预留资源
缓存管理 使用 Redis 缓存生成的清单，避免重复计算 Redis 故障导致缓存穿透，Repo Server 负载飙升

3. Application Controller

Application Controller 是 Argo CD 的“执行大脑”，负责监控 Application 状态、执行同步操作、管理生命周期。它运行在控制平面，但直接操作数据平面（目标集群）。

  • 状态循环：每个 Application 对应一个 goroutine，定期对比期望状态（Git）与实际状态（集群）。
  • 同步引擎：调用 Repo Server 获取清单，通过 Kubernetes API 应用到目标集群。
  • 健康评估：内置资源健康检查，支持自定义健康检查 Lua 脚本。
  • 选举机制：多副本部署时通过 leader election 确保同一时间只有一个 Controller 执行同步。
故障排查关键：Application Controller 的 leader election 依赖 etcd 的租约机制。etcd 网络分区或性能下降会导致 Controller 频繁 re-elect，造成同步抖动甚至双主风险。

状态存储：etcd 与 Redis

Argo CD 使用两种存储系统，分别承载不同维度的数据，灾备策略必须区分对待。

etcd — 持久化状态存储

etcd 存储 Argo CD 的全部持久化状态，包括 Application 定义、同步状态、历史记录、RBAC 配置、Project 定义等。它是灾备恢复的第一优先级。

数据类别 示例 恢复优先级
Application CRD Application 名称、源仓库、目标集群、同步策略 最高
同步状态 当前同步阶段、资源状态哈希、操作历史 高
RBAC 配置 角色、绑定、策略规则 高
Project 定义 项目边界、允许的源仓库、目标集群白名单 高
集群凭证 目标集群 kubeconfig 加密存储 最高（需配合加密密钥）

Redis — 缓存与临时状态

Redis 主要用作 Repo Server 的缓存层，存储 Git 仓库的已生成清单、仓库元数据、会话令牌等。Redis 数据丢失不会导致永久性故障，但会引发性能下降。

  • 清单缓存：避免每次同步都重新执行 Helm/Kustomize 渲染，减少 Repo Server 负载。
  • 仓库缓存：存储 Git 仓库的 commit SHA、分支引用，加速后续拉取。
  • 会话存储：Web UI 与 API 的 JWT 令牌黑名单、CSRF 令牌。
灾备策略差异：etcd 需要定期快照备份与跨区域复制；Redis 可采用主从 + 持久化（RDB/AOF），但灾备恢复时允许缓存预热重建，优先级低于 etcd。
状态存储灾备优先级对比 etcd（持久化存储） 灾备优先级：★★★★★ Application 定义 同步状态历史 RBAC / Project 集群凭证（加密） Redis（缓存存储） 灾备优先级：★★★☆☆ 清单缓存 仓库元数据 会话令牌 可重建（非关键） etcd 丢失 = 灾难性故障；Redis 丢失 = 性能降级，可通过缓存预热恢复

组件交互流程

理解组件间的数据流是故障排查的基础。以下是一个典型的 Application 同步流程：

  1. 用户触发同步：通过 CLI/API/Web UI 向 API Server 发送 Sync 请求。
  2. API Server 验证：检查用户权限、Project 约束、源仓库可访问性。
  3. 请求转发：API Server 将 Sync 请求写入 etcd，Application Controller 通过 watch 机制感知状态变更。
  4. Controller 获取清单：Application Controller 调用 Repo Server 的 GenerateManifest gRPC 接口。
  5. Repo Server 处理：从 Git 拉取最新代码，执行模板渲染，返回生成的 Kubernetes 清单。
  6. Controller 应用：通过 Kubernetes API 将清单应用到目标集群，记录同步结果到 etcd。
  7. 状态回写：Application Controller 更新 etcd 中的 Application 状态，API Server 通过 watch 推送给用户。
故障排查切入点：当同步卡住时，优先检查 Repo Server 的 Git 拉取日志（步骤 5）和 Application Controller 与目标集群的连通性（步骤 6）。etcd 的 watch 延迟通常表现为状态更新滞后。

架构设计对灾备的影响

架构特性 灾备优势 灾备挑战
控制/数据平面分离 控制平面故障不影响已部署的应用运行 故障排查时需分别定位两个平面的问题
无状态 API Server 快速扩缩容，重启不丢数据 依赖 etcd 可用性，etcd 故障导致 API 不可用
etcd 作为单一事实源 备份恢复简单，只需恢复 etcd 快照 etcd 数据损坏影响全局，恢复时间取决于快照大小
Redis 缓存层 缓存丢失不影响数据一致性 大规模集群下缓存重建可能导致 Repo Server 过载
Application Controller 选举 支持多副本高可用 etcd 性能抖动导致频繁 re-elect，同步中断
← 上一章 📖 返回目录 下一章 →