跳到主要内容

高可用、备份与灾难恢复

Argo CD 控制面不可用时，已经运行的业务 Pod 通常不会停止，但 Git 变更无法同步、漂移无法纠正、发布与回滚受阻。高可用的目标是缩短交付控制面故障，而不是把所有组件盲目扩成多副本。

Argo CD 高可用与灾难恢复架构图

1. 高可用边界​

范围建议原因
argocd-server多副本 + 负载均衡UI、API 与 CLI 可用性
Repo Server多副本，按仓库与渲染负载扩容避免单点渲染瓶颈
Application Controller使用官方 HA 清单或经验证的分片方案调谐队列与集群规模决定容量
Redis使用官方支持的 HA 形态缓存与协调不能成为单点
Dex / SSO优先使用外部 IdP减少内置身份组件的恢复复杂度

官方 Manifest 有标准与 HA 变体。生产切换 HA 前，应在测试环境验证版本、资源请求、Pod 反亲和、PDB、存储和入口行为；不要把不同版本的标准、HA 清单混用。

2. 配置备份范围​

真正需要恢复的是声明和凭据元数据，而不是盲目备份所有缓存：

  • Application、ApplicationSet、AppProject；
  • argocd-cm、argocd-rbac-cm、通知和 SSO 配置；
  • 仓库、集群、仓库凭据相关 Secret；
  • 入口证书、NetworkPolicy 与平台侧依赖配置；
  • Git 部署仓库及其受保护分支策略。

优先将可声明配置放入 Git；Secret 使用受控加密或密钥管理服务备份。备份文件本身与集群管理员凭据同等敏感，应加密、限制访问并设置保留周期。

# 仅示例：导出非 Secret 的 Argo CD 自定义资源用于演练审阅
kubectl get applications,applicationsets,appprojects -n argocd -o yaml \
  > argocd-resources-backup.yaml

不要把未加密的 Secret 导出到个人电脑或普通构建产物。应使用团队批准的备份系统处理加密、访问控制和恢复审计。

3. 恢复顺序​

  1. 恢复 Kubernetes 集群、DNS、入口、存储和外部 IdP 等基础依赖；
  2. 使用固定版本的官方 Manifest 恢复 Argo CD 控制面；
  3. 恢复全局配置、Project、仓库和集群凭据；
  4. 恢复 ApplicationSet 与 Application；
  5. 先禁用或审查自动同步，确认渲染与目标集群边界；
  6. 分批同步，逐个验证 Synced + Healthy；
  7. 记录实际恢复时间、失败项和后续改进。
恢复时不要立即全量自动同步

恢复后的集群、凭据、CRD 或外部依赖可能与故障前不同。先比较差异并按环境分批同步，避免一次恢复操作触发大规模 Prune 或覆盖。

4. 升级与演练​

升级前阅读版本发布说明和兼容性矩阵，在测试控制面验证 CRD、SSO、插件、通知、Repo Server 渲染和关键 Application。备份恢复至少定期演练一次，并以“能否从干净控制面重新接管受管应用”为验收标准，而不是只确认备份文件存在。