2、Argo CD 架构回顾：核心组件及其在节点池中的部署角色

在深入分析节点池部署失败根因之前，必须对 Argo CD 的架构有清晰的认识。Argo CD 遵循 Kubernetes 原生控制器模式，由四个核心组件构成一个闭环的 GitOps 工作流。在节点池（Node Pool）场景下，每个组件的部署位置、资源需求与网络拓扑直接影响集群的稳定性与故障恢复能力。

2.1 核心组件总览

2.2 组件交互流程与节点池依赖

下图展示了 Argo CD 核心组件之间的数据流，以及每个环节对节点池基础设施的依赖关系：

2.3 各组件在节点池中的部署角色详解

2.3.1 API Server — 节点池流量网关

• 角色：所有外部请求（CLI、UI、Webhook、CI/CD 触发器）的唯一入口。
• 节点池部署要点：
  • 建议部署在 控制面节点池，与集群 Ingress Controller 或 API Gateway 同池。
  • 需要配置 Pod 反亲和性，避免多个副本调度到同一故障域节点。
  • 节点池网络必须允许 443/TCP 与 8080/TCP 入站流量。
• 故障模式：节点池节点不可用导致 API Server Pod 重建，期间所有 Argo CD 操作（Sync、Rollback、UI 访问）全部中断。

2.3.2 Repo Server — 节点池计算与 I/O 敏感型组件

• 角色：从 Git 仓库拉取代码，执行 Helm template / Kustomize build / YAML 渲染，生成最终 Kubernetes Manifest。
• 节点池部署要点：
  • 推荐部署在 计算型节点池，配备本地 SSD 或高性能云盘以加速 Git 操作与缓存。
  • 内存需求较高（建议 ≥ 2Gi），节点池需保证足够的内存资源，避免 OOMKill。
  • 需要配置 Git 代理（如企业内网环境），节点池出口网络必须可达 Git 服务器。
• 故障模式：节点池磁盘 IOPS 打满导致 Manifest 生成超时（>60s），触发 Repo Server 健康检查失败。

2.3.3 Application Controller — 节点池控制循环核心

• 角色：运行主控制循环，定期对比 Git 期望状态与集群实际状态，执行 Sync、Prune、Self-Heal 操作。
• 节点池部署要点：
  • 必须部署在 能够访问所有目标集群 API Server 的节点池。
  • 节点池 DNS 配置必须正确解析目标集群的 API Server 地址（内部 Service 或外部 Endpoint）。
  • 需要 ClusterRole 与 ServiceAccount 绑定，节点池的 RBAC 策略不能阻断 Controller 的 List/Watch 权限。
• 故障模式：节点池网络策略（NetworkPolicy）误拦截 Controller 到目标集群的 6443/TCP 流量，导致状态同步停滞。

2.3.4 Redis — 节点池有状态缓存

• 角色：缓存 Repo Server 生成的 Manifest 与 Application Controller 的状态快照，降低重复计算开销。
• 节点池部署要点：
  • 使用 StatefulSet 部署，确保 Pod 名称与 PVC 绑定稳定。
  • 节点池必须提供 持久化存储（PVC），避免 Pod 漂移导致缓存丢失。
  • 建议部署在 专用节点池，避免与 Repo Server 或 Controller 争抢 CPU/Memory。
• 故障模式：节点池节点重启后 Redis Pod 调度到新节点，PVC 未跟随导致缓存空，引发 Repo Server 与 Controller 同时回源，造成 缓存雪崩。

2.4 组件间通信与节点池网络拓扑

下表总结了组件间通信协议与节点池网络必须满足的条件：