1. 课程导论：Argo CD 资源配额校准的背景、目标与课程整体架构
1.1 背景：为什么需要资源配额校准？
在云原生生产环境中，Argo CD 作为 GitOps 的核心组件，其 Application Controller 和 ApplicationSet Controller 需要频繁与 Kubernetes API Server 通信，以维持集群状态与 Git 仓库的同步。当集群规模增长至数百个微服务、数千个 Application 对象时，Argo CD 的默认资源配额与通信参数往往成为性能瓶颈。
常见的生产痛点包括：
- API Server 限流：Argo CD 控制器默认的 QPS（每秒查询数）与 Burst（突发请求数）过低，导致同步延迟飙升。
- 资源竞争与 OOMKill：控制器内存与 CPU 配额不足，在大型集群中频繁触发 OOM（内存溢出）或 CPU Throttling。
- Reconciliation 风暴：默认的同步周期与重试策略不合理，导致集群在变更期间产生大量无效的 API 调用。
- 状态缓存失效：本地缓存大小与 TTL（生存时间）配置不当，造成控制器反复从 API Server 拉取全量数据。
生产案例警示： 某金融科技公司在 500+ 微服务的集群中，因未校准 Argo CD 的
--kube-api-qps 与 --kube-api-burst 参数，导致 API Server 在部署高峰期返回 429 Too Many Requests 错误，最终引发全集群同步中断长达 40 分钟。
1.2 核心目标：校准什么？
本课程围绕三个核心维度展开资源配额校准，确保 Argo CD 在大型集群中稳定、高效运行：
| 维度 | 校准目标 | 关键参数示例 |
|---|---|---|
| 通信参数 | 优化 Argo CD 与 API Server 的网络交互效率，避免限流与超时 | --kube-api-qps, --kube-api-burst, --kube-api-request-timeout |
| 资源配额 | 为控制器 Pod 分配合理的 CPU、内存与存储资源，防止 OOM 与资源争抢 | requests.cpu, limits.memory, --cache-size |
| 同步策略 | 调整 Reconciliation 周期、重试机制与并发度，平衡实时性与系统负载 | --status.enabled, --self-heal-timeout-seconds, --operation-processors |
1.3 课程整体架构
本课程共分为 30 章，按照“基础认知 → 参数详解 → 实战校准 → 监控调优 → 高阶扩展”的递进逻辑组织。下图展示了课程的整体知识体系与章节分布：
1.4 课程适用人群与前置知识
| 角色 | 核心收益 | 前置要求 |
|---|---|---|
| SRE / 平台工程师 | 掌握 Argo CD 生产级参数调优方法，提升集群稳定性 | 熟悉 Kubernetes 基础操作与 Argo CD 基本使用 |
| DevOps 工程师 | 学会通过 GitOps 实践优化 CI/CD 流水线性能 | 了解 GitOps 理念与 Helm/Kustomize 工具链 |
| 云原生架构师 | 获得大规模集群下 Argo CD 的架构设计经验 | 具备多集群管理与网络通信基础知识 |