高可用、备份与灾难恢复

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

1. 高可用边界

官方 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. 记录实际恢复时间、失败项和后续改进。

4. 升级与演练

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