3. 成本调优基础：Kubernetes 资源请求（Requests）与限制（Limits）在 Argo CD 中的最佳实践
在云原生成本调优中，资源请求（Requests）与资源限制（Limits）是 Kubernetes 调度与资源隔离的基石。Argo CD 作为 GitOps 的持续交付工具，其管理的应用清单中如果缺乏合理的 Requests/Limits 配置，将直接导致集群资源利用率低下、节点碎片化严重，甚至引发 OOMKill 或 CPU 节流等异常事件。本章将深入剖析 Requests/Limits 的核心机制，并给出在 Argo CD 中落地的最佳实践。
3.1 Requests 与 Limits 的核心差异
| 维度 | Requests（请求） | Limits（限制） |
|---|---|---|
| 调度依据 | Kubernetes 调度器根据 Pod 的 Requests 总和选择节点 | 不参与调度决策，仅用于运行时资源上限控制 |
| CPU 行为 | 保证 Pod 至少获得该 CPU 时间片 | 超过 Limits 时触发 CPU 节流（Throttling） |
| 内存行为 | 保证 Pod 至少拥有该内存量 | 超过 Limits 时触发 OOMKill（进程被终止） |
| 成本影响 | 决定集群水位与节点数量，直接影响账单 | 决定 Pod 的突发能力与稳定性风险 |
| 最佳实践 | 基于历史 P99 使用量设置，避免过度预留 | 设置上限防止失控，通常为 Requests 的 1.2~2 倍 |
关键认知：Requests 是成本基线，Limits 是安全护栏。在 Argo CD 中，如果只设置 Limits 而不设置 Requests，Kubernetes 会自动将 Requests 设置为与 Limits 相同，这会导致严重的资源浪费。
3.2 未合理配置 Requests/Limits 的典型异常事件
在 Argo CD 管理的生产集群中，以下三种异常事件最为常见：
- CPU 节流（Throttling）：当 Pod 的 CPU 使用率持续超过 Limits 时，内核会强制限制其 CPU 时间片，导致应用延迟飙升。在 Argo CD 的观测面板中，表现为
container_cpu_cfs_throttled_seconds_total指标持续增长。 - OOMKill：内存使用超过 Limits 时，Pod 中的进程被内核杀死。Argo CD 事件日志中会出现
OOMKill或Out of memory事件，通常伴随 CrashLoopBackOff 状态。 - 节点资源碎片化：由于 Requests 设置过高，导致节点上可调度资源碎片化严重，大量小 Pod 无法被调度，集群整体利用率低于 40%。
避坑提示：不要在生产环境中使用
resources: {} 空配置。Argo CD 的 Sync 策略应强制校验资源字段，否则未设置 Requests 的 Pod 会默认使用节点上所有可用资源，极易引发节点过载。
3.3 Argo CD 中的资源请求与限制最佳实践
3.3.1 在 Application 清单中显式声明资源
在 Argo CD 管理的 Helm Chart 或 Kustomize 清单中，必须为每个容器显式声明 Requests 和 Limits。以下是一个生产级示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: payment-service
spec:
template:
spec:
containers:
- name: payment
image: payment:1.2.3
resources:
requests:
cpu: "500m" # 0.5 核
memory: "512Mi"
limits:
cpu: "1000m" # 1 核
memory: "768Mi"3.3.2 使用 Argo CD 的 Resource Customization 进行自动注入
对于大规模集群，手动为每个工作负载配置资源字段容易遗漏。Argo CD 支持通过 Resource Customization 或 Config Management Plugins (CMP) 自动注入默认资源限制：
# argocd-cm ConfigMap 中的 resource.customizations
resource.customizations: |
apps/Deployment:
ignoreResourceUpdates:
jsonPointers:
- /spec/replicas
health.lua: |
hs = {}
hs.status = "Healthy"
return hs
# 自动注入资源字段（需配合 Lua 脚本或 CMP）
# 推荐使用 CMP 或 Admission Webhook 实现
推荐方案：使用 Kyverno 或 OPA Gatekeeper 作为 Admission Controller，在 Argo CD 同步前自动为缺失资源字段的 Pod 注入默认 Requests/Limits。这比在 Argo CD 内部做资源注入更灵活、可审计。
3.3.3 基于历史数据的 Requests 调优策略
成本调优的核心是让 Requests 贴近实际使用量。建议采用以下步骤：
- 采集基线数据：使用 Prometheus 采集过去 7 天的
container_cpu_usage_seconds_total和container_memory_working_set_bytes。 - 计算 P99 使用量：通过 PromQL 计算每个容器的 P99 使用量，作为 Requests 的参考值。
- 设置安全余量：在 P99 基础上增加 10%~20% 的余量，避免因瞬时尖峰导致 OOMKill。
- 通过 Argo CD 滚动更新：将调整后的资源字段提交到 Git 仓库，Argo CD 自动检测差异并执行滚动更新。
3.4 Requests/Limits 与成本调优的关系图
3.5 通过 Argo CD 观测资源水位与异常事件
Argo CD 本身不存储监控数据，但可以通过以下方式集成观测能力：
- Application 健康状态：Argo CD 内置了 Deployment、StatefulSet 等资源的健康检查，当 Pod 因 OOMKill 或 CrashLoopBackOff 处于不健康状态时，Argo CD UI 会显示红色状态。
- Resource Events 集成：在 Argo CD 的 Application 详情页中，可以查看 Kubernetes 原生事件，包括
OOMKilling、BackOff、FailedScheduling等。 - Prometheus + Grafana 联动：将 Argo CD 的指标（如
argocd_app_info）与容器资源指标关联，构建延迟水位与异常事件的统一观测面板。
3.6 常见配置陷阱与规避方案
| 陷阱场景 | 错误配置 | 正确做法 |
|---|---|---|
| 只设置 Limits 不设置 Requests | limits: {cpu: "1", memory: "1Gi"} |
显式设置 Requests，避免自动继承导致资源浪费 |
| Requests 设置过高 | Requests = Limits = 实际使用的 3 倍 | 基于 P99 使用量 + 15%~20% 余量设置 |
| 所有容器使用相同资源规格 | 所有微服务统一使用 500m/512Mi | 按服务实际负载差异化配置 |
| 忽略 CPU 节流监控 | 只关注内存 OOMKill | 同时监控 CPU Throttling 指标 |
自动化建议：在 Argo CD 的 PreSync 钩子中执行资源校验脚本，检查每个容器的 Requests/Limits 是否满足组织规范（如 CPU Requests 不低于 100m，内存 Limits 不超过 Requests 的 2 倍）。不符合规范的 Application 将被阻止同步。