2. Argo CD 核心架构：组件及其在故障排查中的角色

Argo CD 遵循 Kubernetes 原生的控制器模式，由三个核心组件构成：API Server、Repo Server 和 Application Controller。在多租户网络拓扑中，每个组件都可能成为故障的根源或传播路径上的关键节点。理解每个组件的职责、通信方式以及故障表现，是进行高效排查的基础。

2.1 三大核心组件概览

下表从职责、关键端口、数据流向和典型故障四个维度，对比了三个组件的核心特征：

2.2 组件间通信与故障排查要点

三个组件之间的通信链路构成了 Argo CD 的数据平面。在多租户场景下，网络策略、TLS 证书和 RBAC 配置是常见的故障点。

2.2.1 API Server

• 故障排查角色： 作为所有用户请求的入口，API Server 是排查“用户侧”问题的第一站。常见的故障包括： 过期、RBAC 绑定错误、以及 gRPC 网关超时。
• 关键排查命令：

  # 检查 API Server Pod 状态
  kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server
  
  # 查看 API Server 日志，过滤认证错误
  kubectl logs -n argocd deployment/argocd-server --tail=50 | grep -i "error\|unauthorized"

2.2.2 Repo Server

• 故障排查角色： Repo Server 是“配置源”的守护者。当 Application 显示“OutOfSync”但 Manifest 未变更时，通常需要排查 Repo Server 的缓存或 Git 连接问题。
• 关键排查命令：

  # 强制刷新 Repo Server 缓存
  argocd app get <app-name> --hard-refresh
  
  # 检查 Repo Server 是否能够访问 Git 仓库
  kubectl exec -n argocd deployment/argocd-repo-server -- \
    git ls-remote https://github.com/example/repo.git

2.2.3 Application Controller

• 故障排查角色： Controller 负责执行“同步”动作。当同步操作卡在“Running”状态或反复失败时，Controller 的日志是核心排查依据。
• 关键排查命令：

  # 查看 Controller 日志，过滤特定 Application
  kubectl logs -n argocd deployment/argocd-application-controller --tail=100 | \
    grep "<app-name>"
  
  # 检查 Controller 与目标集群的连接状态
  kubectl exec -n argocd deployment/argocd-application-controller -- \
    kubectl --kubeconfig /app/config/<cluster-secret> get nodes

2.3 核心架构与故障排查路径

下面的 SVG 图展示了 Argo CD 三个组件之间的数据流，以及典型的故障排查路径。图中使用不同颜色的节点标识组件，箭头表示请求方向，红色虚线标注了最常见的故障点。

2.4 多租户场景下的组件隔离

在多租户网络拓扑中，每个租户通常拥有独立的 Git 仓库和目标集群。Argo CD 的组件需要能够安全地访问这些隔离的资源。以下是组件隔离的常见实现方式：

2.5 组件健康检查与故障自愈

在生产环境中，Argo CD 组件自身的健康状态直接影响整个 GitOps 流水线。以下是与组件健康检查相关的关键配置和排查方法：

• Readiness Probe： API Server 和 Repo Server 都配置了 Readiness Probe。如果 Probe 失败，组件将从 Service Endpoint 中移除，导致请求被拒绝。
• Liveness Probe： 用于检测组件是否死锁。如果 Liveness Probe 连续失败，Kubelet 将重启容器。
• 资源限制： Repo Server 在处理大型 Helm Chart 或大量 Application 时，容易因内存不足（OOM）被 Kill。建议为 Repo Server 设置 resources.limits.memory 并监控其实际使用量。