2. K8s资源模型基础：Pod资源请求与限制、QoS类别与资源单位

在Kubernetes集群中，资源管理是调度与容量调优的基石。每个Pod都需要明确声明其所需的计算资源，集群才能做出合理的调度决策，并在资源紧张时进行优先级排序。本章将深入解析资源请求（Request）与限制（Limit）的概念、QoS类别以及资源单位，为后续HPA与VPA的协同工作打下坚实基础。

2.1 资源请求（Request）与限制（Limit）

Kubernetes通过两个关键参数来定义Pod中每个容器的资源需求：

  • Request（请求）：容器启动时保证获得的最小资源量。调度器依据所有容器的Request总和来决定Pod可以调度到哪个节点。
  • Limit（限制）：容器运行时允许使用的资源上限。当容器试图使用超过Limit的资源时，系统会进行限制（CPU节流）或终止（内存OOM）。
核心原则： Request <= Limit。如果未设置Limit，则默认与Request相等（取决于集群配置或命名空间LimitRange）。

以下是一个典型的Pod资源声明示例：

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

在这个例子中，容器保证获得0.5个CPU核心和256MiB内存，但最多可以使用1个CPU核心和512MiB内存。

2.2 QoS类别：Guaranteed / Burstable / BestEffort

Kubernetes根据Pod中所有容器的Request和Limit设置，将Pod划分为三种QoS（服务质量）类别。当节点资源不足时，QoS类别决定了Pod被驱逐的优先级。

QoS类别 判定条件 资源保障 驱逐优先级 典型场景
Guaranteed 所有容器：Request == Limit（CPU和内存均需设置） 最高，资源完全预留 最低（最后被驱逐） 数据库、关键业务服务
Burstable 至少一个容器：Request < Limit 或仅设置Request 中等，基础资源有保障 中等 Web应用、微服务
BestEffort 所有容器：未设置任何Request和Limit 最低，无任何保障 最高（最先被驱逐） 批处理任务、开发测试
重要提示： 在资源紧张时，kubelet会按BestEffort → Burstable → Guaranteed的顺序驱逐Pod。同一QoS类别内，按内存使用超出Request的比例排序，超出越多越优先被驱逐。
QoS类别与资源保障层级 Guaranteed（保证型） Request == Limit | 最高资源保障 | 最低驱逐优先级 典型：数据库、关键业务服务 Burstable（可爆发型） Request < Limit | 中等资源保障 | 中等驱逐优先级 典型：Web应用、微服务 BestEffort（尽力型） 未设置Request/Limit | 无资源保障 | 最高驱逐优先级 驱逐优先级：BestEffort > Burstable > Guaranteed

2.3 资源单位：mCPU与MiB

Kubernetes使用标准化的单位来表示CPU和内存资源，确保跨平台一致性。

CPU单位

  • 核心（Core）：1个CPU核心对应1个物理核心或vCPU（虚拟机CPU）。
  • 毫核（mCPU）：1核心 = 1000m。例如，500m表示0.5个CPU核心。
  • 精度：最小单位为1m，但实际调度时通常以10m或100m为粒度。

内存单位

  • 字节（Bytes）：基础单位，如 536870912 表示512MiB。
  • MiB（Mebibytes）：二进制单位，1 MiB = 2^20 Bytes = 1,048,576 Bytes。推荐使用MiB、GiB等二进制单位。
  • MB（Megabytes）：十进制单位，1 MB = 10^6 Bytes。Kubernetes也支持，但建议优先使用MiB以避免混淆。
资源类型 单位 示例 说明
CPU m（毫核） 500m 0.5个CPU核心
CPU 无后缀 1 1个完整CPU核心
内存 Mi 256Mi 256 Mebibytes
内存 Gi 2Gi 2 Gibibytes
内存 M 300M 300 Megabytes（十进制）
最佳实践： 在生产环境中，始终使用二进制单位（Mi、Gi）声明内存资源，使用m单位声明CPU资源。这可以避免因十进制与二进制换算差异导致的资源分配偏差。
Kubernetes资源单位换算关系 CPU 单位 1 Core = 1000m 示例：500m = 0.5 Core 内存 单位 1 Gi = 1024 Mi 1 Mi = 1024 Ki = 2^20 Bytes 单位使用建议 • CPU：使用 m 单位（如 500m），避免小数（如 0.5） • 内存：使用 Mi/Gi 二进制单位，避免 M/G 十进制单位 • 统一单位：集群内保持单位一致，便于监控与自动化工具解析

2.4 资源模型与QoS的协同意义

理解资源模型是进行容量调优的前提。Request决定了Pod的调度位置和资源预留，Limit控制了资源使用的上限，QoS类别则决定了资源竞争时的行为。在后续章节中，HPA将基于Pod的CPU/内存使用率（相对于Request）进行水平扩缩，而VPA则动态调整Request和Limit的值。三者协同工作时，必须确保QoS类别不会因VPA的调整而发生非预期的变化，从而影响Pod的稳定性。

关键洞察： 对于生产环境的关键业务，建议使用Guaranteed QoS类别，确保资源完全预留。对于弹性工作负载，Burstable是合理选择，允许在资源空闲时爆发使用。BestEffort仅适用于非关键、可中断的任务。
← 上一章 📖 返回目录 下一章 →