📚 课程目录第4章 CPU与内存配额

4. CPU与内存配额：requests/limits 配置、超卖与服务质量(QoS)等级

在Kubernetes集群中，CPU和内存是两种可压缩与不可压缩的资源。合理配置requests（请求量）和limits（上限）是保障容器稳定运行、提升集群资源利用率的核心手段。本章将深入解析配额模型、超卖机制以及由此衍生的QoS（服务质量）等级。

4.1 requests与limits核心概念

参数	含义	调度依据	运行时行为
requests	容器保证能获得的资源下限	调度器根据节点剩余可分配资源进行调度	CPU按权重分配；内存不足时触发OOM Killer
limits	容器允许使用的资源上限	不影响调度决策	CPU被CFS配额限制；内存超限直接OOM Kill

关键区别：CPU是可压缩资源，超限时仅被限流（throttle）；内存是不可压缩资源，超限时容器会被终止（OOM Kill）。因此内存的limits配置必须谨慎。

4.2 配置示例与单位说明

以下是一个典型的Pod资源配额配置，展示了CPU和内存的requests/limits写法：

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: app
    image: nginx:1.25
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "1000m"

CPU单位：1 CPU = 1 vCPU / 1 核；500m = 0.5 核。最小精度为1m（千分之一核）。
内存单位：Mi（Mebibyte，2^20字节）、Gi（Gibibyte，2^30字节）。注意与MB/GB的十进制差异。
配置原则：limits ≥ requests。若只设limits，requests默认等于limits；若只设requests，limits视为无上限。

4.3 超卖（Overcommit）机制

超卖是指节点上所有Pod的requests总和超过节点实际可分配资源的现象。Kubernetes允许超卖，但依赖QoS等级来保障关键容器的稳定性。

  超卖公式：超卖率 = (所有Pod requests总和) / (节点可分配资源) × 100%。

  例如：节点可分配4核CPU，所有Pod requests总和为6核，则CPU超卖率为150%。

超卖带来的收益与风险：

收益：显著提升资源利用率，降低集群成本。
风险：节点资源争抢加剧，低优先级Pod可能被驱逐或限流。

4.4 服务质量（QoS）等级

Kubernetes根据Pod内容器的requests和limits配置，自动将Pod划分为三个QoS等级。等级决定了节点资源紧张时的驱逐顺序。

QoS等级	判定条件	资源保障	驱逐优先级
Guaranteed	所有容器requests == limits，且每个资源类型都设置	最高，完全按需保障	最低（最后被驱逐）
Burstable	至少一个容器requests < limits，或只设requests	中等，可突发使用空闲资源	中等
BestEffort	所有容器均未设置requests和limits	最低，无任何保障	最高（最先被驱逐）

生产建议：核心业务应用应配置为Guaranteed等级（requests == limits），避免因节点资源竞争导致意外驱逐。测试或批处理任务可使用Burstable或BestEffort以提升整体利用率。

4.5 QoS等级与驱逐决策流程

下图展示了节点资源不足时，kubelet根据QoS等级和资源使用量驱逐Pod的决策路径：

4.6 生产实践建议

Guaranteed Pod：数据库、消息队列、API网关等有状态或延迟敏感服务，配置requests == limits。
Burstable Pod：Web应用、微服务等允许突发流量的无状态服务，设置requests较低、limits较高。
BestEffort Pod：批处理、数据清洗、CI/CD任务等可中断工作负载，不设置资源配额。
监控与告警：持续监控CPU Throttle率和OOM事件，及时调整配额配置。

最佳实践：使用Vertical Pod Autoscaler（VPA）分析历史资源使用数据，自动推荐合理的requests/limits值，减少人工调优成本。