📚 课程目录第3章资源请求与限制

3. 资源请求与限制：Requests与Limits的定义、CPU与内存的计量单位、服务质量等级

在Kubernetes集群中，资源管理是成本分摊与稳定性的基石。每个Pod中的容器都可以声明两类资源约束：Requests（请求） 和 Limits（限制）。理解这两者的定义、计量单位以及由此衍生的服务质量等级（QoS），是设计成本分摊模型的前提。

3.1 Requests与Limits的定义

属性	定义	调度影响	资源竞争影响
Requests	容器保证能获得的最小资源量。Kubernetes调度器依据Requests值选择节点。	调度决策依据：节点剩余可分配资源必须 ≥ Pod中所有容器Requests之和。	CPU按Requests权重分配时间片；内存保证至少Requests量不会被回收。
Limits	容器允许使用的资源上限。防止单个容器过度占用节点资源。	不影响调度（除非设置了 Guaranteed QoS）。	CPU：通过CFS配额限制上限；内存：超过Limits时容器可能被OOM Kill。

  关键原则：Requests ≤ Limits。如果未设置Limits，则默认等于Requests（取决于集群配置或准入控制器）；如果未设置Requests，则默认等于Limits。

3.2 CPU与内存的计量单位

CPU单位

核心（Core）： 1 个CPU核心对应一个物理核心或vCPU（虚拟机CPU）。
毫核（millicore）： 使用 m 后缀，1000m = 1 核心。例如 500m 表示半个CPU核心。
精度： 最小单位为 1m，但实际调度中通常以 10m 或 100m 为步长。

内存单位

字节（Bytes）： 基础单位，通常使用二进制单位（Ki、Mi、Gi）或十进制单位（K、M、G）。
二进制单位（推荐）： Ki（Kibibyte，1024字节）、Mi（Mebibyte，1024²字节）、Gi（Gibibyte，1024³字节）。
十进制单位： M（Megabyte，1000²字节）、G（Gigabyte，1000³字节）。

避坑提示： 在成本分摊场景中，务必统一使用二进制单位（Mi/Gi）进行计量和计费，避免因单位换算差异导致成本数据偏差。例如，1GB（十进制）= 0.931Gi（二进制），差异约7%。

3.3 服务质量等级（QoS Classes）

Kubernetes根据Pod中所有容器的Requests与Limits设置，自动为每个Pod分配一个QoS等级。该等级决定了节点资源紧张时Pod被驱逐的优先级。

3.4 三种QoS等级详解

QoS等级	触发条件	CPU管理	内存管理	驱逐优先级	成本分摊影响
Guaranteed	所有容器：Requests == Limits（CPU和内存均设置且相等）	CFS配额 = Requests，可突发至Limits	保证Requests，超过Limits触发OOM	最低（优先保留）	资源使用量稳定，适合按Requests计费
Burstable	至少一个容器：Requests < Limits 或仅设置Requests	CFS配额 = Requests，可突发至Limits	保证Requests，超过Limits触发OOM	中等	实际使用量波动大，需按实际用量分摊
BestEffort	所有容器：未设置任何Requests和Limits	无限制（共享空闲CPU）	无保证，节点内存不足时优先被Kill	最高（最先被驱逐）	成本最低但风险最高，适合批处理/低优先级任务

3.5 代码示例：不同QoS等级的Pod定义

# Guaranteed QoS：所有容器 Requests == Limits
apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "512Mi"
        cpu: "1"
      limits:
        memory: "512Mi"
        cpu: "1"

---
# Burstable QoS：Requests < Limits
apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "1Gi"
        cpu: "1"

---
# BestEffort QoS：未设置任何资源
apiVersion: v1
kind: Pod
metadata:
  name: besteffort-pod
spec:
  containers:
  - name: app
    image: busybox
    command: ["sleep", "3600"]

FinOps建议： 在成本分摊模型中，建议将Guaranteed Pod按Requests值进行固定成本分摊；Burstable Pod按实际资源使用量（通过Metrics Server或Prometheus采集）进行动态分摊；BestEffort Pod通常不计入核心成本，或按极低单价分摊。

3.6 资源模型与成本分摊的关联

Requests与Limits的设定直接影响成本分摊的准确性：

Requests 代表预留成本：即使Pod未使用全部Requests，该资源也被“锁定”给该Pod，其他Pod无法使用。这部分成本应计入Pod所属团队。
Limits 代表突发成本：当Pod实际使用量超过Requests但未超过Limits时，超出的部分使用的是节点上的“空闲资源”。这部分成本应基于实际使用量进行分摊。
QoS等级 影响资源竞争时的行为：Guaranteed Pod的稳定性最高，适合核心业务；BestEffort Pod成本最低但风险最高，适合非关键任务。

  核心结论： 在云原生成本分摊中，Requests 是成本分摊的锚点，Limits 是成本控制的边界，QoS等级 是成本优先级的风向标。合理设置这三者，才能实现既保证业务稳定性，又做到成本公平分摊。