日常运维与故障排查

排查 Argo CD 故障时，先区分是控制面、仓库渲染、目标集群连接、同步策略还是应用自身健康问题。不要在未保存证据前反复强制同步或删除 Application，这会掩盖最初的失败原因。

1. 每日巡检

# 查看控制面 Pod 是否正常、是否频繁重启
kubectl get pods -n argocd -o wide

# 查看所有应用的同步和健康状态
argocd app list

# 查看已注册目标集群连接状态
argocd cluster list

重点关注长期 OutOfSync、Degraded、未知健康状态、Repo Server 错误、目标集群失联和同步队列堆积。正常的短暂 Progressing 不应直接升级为事故。

2. 固定排查顺序

Application 状态 -> Git revision / 渲染 -> 同步计划 -> Kubernetes 事件与日志 -> 控制面组件

# 获取单个应用的源、目标、条件与资源树
argocd app get user-center-prod --refresh
argocd app resources user-center-prod

# 对比 Git 渲染结果与集群状态；只读操作，不会同步
argocd app diff user-center-prod --refresh

3. 常见问题

仓库拉取或渲染失败

检查 repo URL、revision、Deploy Key/令牌、Git CA 证书、Chart 版本和 values 路径。Repo Server 日志通常包含最早的有用错误：

kubectl logs -n argocd deploy/argocd-repo-server --tail=300

同步失败但渲染正常

查看目标 Kubernetes API 返回的事件和 RBAC 拒绝。常见原因包括 Namespace 不允许、CRD 不存在、资源不可变字段变更、Webhook 拒绝和 PDB 阻塞。

# 查看某个受管资源在目标 Namespace 中的事件
kubectl get events -n user-center --sort-by=.lastTimestamp

# 查看 Application Controller 的同步错误
kubectl logs -n argocd statefulset/argocd-application-controller --tail=300

应用 Synced 但 Degraded

这说明 Git 已成功应用，但资源未达到健康状态。检查 Deployment 副本、Pod 日志、Readiness、Job 失败、Ingress 后端与自定义健康规则；不要通过忽略健康状态来让流水线“变绿”。

同步变慢或队列堆积

检查 Controller CPU/内存、Repo Server 渲染负载、Git 仓库体积、集群 API 延迟和应用数量。优先减少无关资源扫描、优化仓库布局和按官方 HA/分片方式扩容，而不是随意提高并发导致 API 限流。

4. 证据与升级

一次可复现的故障记录应包含 Application 名称、Git revision、目标集群、开始时间、状态条件、受影响资源、相关事件和控制器日志片段。日志中若含仓库 URL、用户标识或 Token，应先脱敏再发往外部系统。