4. Argo CD 资源配额基础：Kubernetes Resource Quota 与 LimitRange 原理、Argo CD 默认资源限制分析

4.1 为什么需要资源配额？

在共享 Kubernetes 集群中部署 Argo CD 时，如果没有资源配额约束，单个 Application Controller 或 Repo Server 的异常内存泄漏可能耗尽节点资源，导致集群内其他关键服务（如 CoreDNS、kube-system 组件）不可用。Kubernetes 提供 ResourceQuota 和 LimitRange 两种原生机制来防止此类“吵闹邻居”问题。

4.2 ResourceQuota 原理与配置

ResourceQuota 作用于 命名空间级别，限制该命名空间内所有 Pod 的资源总和上限。它不限制单个 Pod，而是限制聚合值。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: argo-cd-quota
  namespace: argocd
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "5"
    count/deployments.apps: "10"
    count/secrets: "50"

4.3 LimitRange 原理与配置

LimitRange 弥补 ResourceQuota 的粒度不足——它定义 单个 Pod 或容器 的资源默认值、最小值、最大值。当 Pod 未显式设置资源时，LimitRange 会自动注入默认值，确保所有 Pod 都符合资源约束。

apiVersion: v1
kind: LimitRange
metadata:
  name: argo-cd-limits
  namespace: argocd
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "250m"
      memory: "256Mi"
    min:
      cpu: "50m"
      memory: "64Mi"
    max:
      cpu: "2"
      memory: "2Gi"
  - type: PersistentVolumeClaim
    min:
      storage: "1Gi"
    max:
      storage: "50Gi"

4.4 Argo CD 默认资源限制分析

Argo CD 官方 Helm Chart 和 Operator 为每个组件预设了资源请求与限制。以下为 v2.12+ 版本的默认值（单位：CPU 为 millicores，内存为 MiB）：

4.5 ResourceQuota 与 LimitRange 协同工作流

下图展示了当 Argo CD 组件 Pod 被调度时，Kubernetes 准入控制器的资源校验顺序：

4.6 默认资源限制的潜在风险

• Application Controller 内存瓶颈： 默认 2Gi limit 在管理 500+ Application 时可能触发 OOM，建议根据 argocd-application-controller 的 metrics 中 go_memstats_alloc_bytes 动态调整。
• Repo Server 并发限制： 默认 1 核 CPU limit 在并发处理多个 Git 仓库时可能导致 manifest 生成超时（默认 60s 超时）。
• Redis 无持久化限制： 默认 512Mi 内存 limit 在缓存大量 Application 状态时可能被驱逐，建议启用 --persistence 或增大 limit。
• QoS 降级风险： Burstable 类 Pod 在节点内存压力下会被优先驱逐，导致 Argo CD 控制面短暂不可用。

4.7 生产环境资源配额建议