0. 调优思路：何时调内存，何时调 CPU？

在实际生产中，调整资源的侧重点通常取决于业务类型：

• 调大内存： 适用于数据密集型场景。例如：缓存服务（Redis）、大数据处理、内存计算、高并发下的状态存储。内存不足会导致 OOMKilled（进程被强制杀死）。
• 调大 CPU： 适用于计算密集型或高频请求场景。例如：加解密、压缩、复杂的业务逻辑运算、高频率的 API 调用。CPU 不足会导致 Throttling（限流），表现为接口响应变慢、延迟增加。

1. 什么是 K8s 资源配额？

资源配额用于管理 Pod 或 Namespace 对计算资源的使用，确保集群资源合理分配，防止单一服务耗尽集群资源。

资源特性对比

2. 核心概念：Requests 与 Limits

2.1 Requests (请求值)

• 定义： Pod 运行时所需的最小资源保障。
• 作用： 调度器 (Scheduler) 根据此值决定将 Pod 调度到哪个节点。
• 公式： 节点剩余资源 Pod Requests。

2.2 Limits (上限值)

• 定义： Pod 允许使用的最大资源边界。
• 作用： 防止因单个 Pod 异常（如内存泄漏）导致整个节点崩溃。

2.3 关系准则

• Requests Limits：常规配置。
• Requests Limits：资源固定，最稳定。
• 仅设置 Limits：K8s 会自动将 Requests 设置为与 Limits 相等。
• 不设置 Limits：Pod 可能无限制消耗节点资源，极具风险。

3. QoS (服务质量) 等级

K8s 根据 requests 和 limits 的配置自动划分优先级：

4. 资源配置实践指南

4.1 如何确定具体数值？

1. 监控先行： 通过 Prometheus/Grafana 观察应用在压测及生产环境中的 CPU/内存峰值与均值。
2. 留有余量： * Requests 正常业务负载的 1.1 - 1.2 倍。

• Limits 业务峰值的 1.2 - 1.5 倍。

3. 灰度调整： 根据实际运行情况动态调优，避免资源浪费。

4.2 Namespace 级别管控

ResourceQuota (资源配额)

限制整个命名空间的总资源。

1
2
3
4
5
6
7
8
9
10
11

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: my-namespace
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"

LimitRange (默认限制)

为未配置资源的容器提供默认值，并设定合法范围（Min/Max）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

apiVersion: v1
kind: LimitRange
metadata:
  name: limit-range
  namespace: my-namespace
spec:
  limits:
    - default:          # 默认 Limit
        cpu: "1"
        memory: "512Mi"
      defaultRequest:   # 默认 Request
        cpu: "500m"
        memory: "256Mi"
      type: Container

下一步建议： 如果您想了解如何通过 Vertical Pod Autoscaler (VPA) 自动建议这些资源数值，或者想看看具体的 Prometheus 查询语句来计算这些值，我可以为您提供进一步的指导。