2. Kubernetes 资源模型基础：Pod 的 Request 与 Limit、QoS 类别、资源单位换算

2.1 资源模型核心概念：Request 与 Limit

Kubernetes 的资源模型是调度与隔离的基石。每个 Pod 中的容器都可以声明两类资源约束：Request 和 Limit。理解这两者的区别，是进行节点资源画像和误差预算计算的前提。

2.2 资源单位换算

Kubernetes 使用两种资源类型：CPU（可压缩资源）和 Memory（不可压缩资源）。单位换算必须精确，否则会导致配置错误或容量估算偏差。

2.2.1 CPU 单位

• 1 CPU = 1 个 vCPU / 1 个 Hyperthread（AWS vCPU、GCP Core、Azure vCore）
• 最小单位：m（millicores），1 CPU = 1000m
• 常见表示：500m、1.5、250m
• 调度器按 m 累加，节点总 CPU 容量也以 m 为单位

2.2.2 内存单位

• 基础单位：字节（Byte）
• 支持两种后缀体系：
  • 十进制（SI）：E、P、T、G、M、K → 1000 进制
  • 二进制（IEC）：Ei、Pi、Ti、Gi、Mi、Ki → 1024 进制
• Kubernetes 内部统一使用 二进制（IEC） 进行计算

2.3 QoS 类别：资源保障的等级体系

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

2.4 QoS 类别判定规则

判定逻辑遵循“最严格原则”：只要有一个容器不满足条件，整个 Pod 的 QoS 就会降级。

resources:
  requests:
    cpu: "1"
    memory: "2Gi"
  limits:
    cpu: "1"
    memory: "2Gi"

resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "1"
    memory: "2Gi"

resources: {}

2.5 资源模型与容量规划的关联

2.6 实践建议：配置规范

1. 生产核心服务：必须使用 Guaranteed QoS，request == limit，确保资源保障和驱逐优先级最低。
2. 批处理/离线任务：可使用 Burstable，设置合理的 request，limit 可适当放大以利用空闲资源。
3. 禁止 BestEffort：在容量规划严格的集群中，应通过 准入控制器（如 LimitRange） 强制所有 Pod 至少设置 request。
4. 单位一致性：所有容量规划文档、监控面板、自动化脚本统一使用 二进制单位（Mi/Gi），避免换算错误。
5. 文档化超卖策略：在误差预算台账中明确记录每个节点池的 目标超卖比，并定期审计实际超卖情况。