3. 资源抽象与 QoS：Requests 与 Limits 定义、Pod QoS 类别、资源超卖原理

在 Kubernetes 集群中，资源管理是容量调优的核心。理解 Requests 与 Limits 的语义差异、掌握 Pod QoS 类别 的判定逻辑，并合理运用 资源超卖 机制，是提升集群资源利用率、保障关键业务稳定性的关键。

3.1 Requests 与 Limits：资源预留与硬限制

Kubernetes 通过 resources.requests 和 resources.limits 两个字段定义容器的资源约束。Requests 用于调度决策（资源预留），Limits 用于运行时限制（硬上限）。

3.2 Pod QoS 类别：三种服务质量等级

Kubernetes 根据 Pod 内所有容器的 Requests 与 Limits 配置，自动将 Pod 归入三类 QoS 等级。该等级决定了节点资源竞争时的驱逐优先级。

3.3 QoS 类别对比与驱逐优先级

3.4 资源超卖原理与实现

资源超卖（Overcommit）是指节点上所有 Pod 的 Requests 总和超过节点实际可分配资源（Allocatable）的现象。Kubernetes 允许超卖，但需要理解其风险与收益。

3.4.1 超卖模型

3.4.2 超卖控制策略

• CPU 超卖： 安全度较高。Linux CFS 调度器按权重分配时间片，超卖时仅导致 CPU 竞争和性能下降，不会导致进程死亡。建议超卖率控制在 1.5~3.0 之间。
• 内存超卖： 风险较高。当节点内存不足时，kubelet 会触发 OOM Killer 按 QoS 优先级和 oom_score_adj 驱逐 Pod。建议内存超卖率不超过 1.2~1.5。
• 磁盘/网络超卖： 通常不推荐。磁盘 IO 和网络带宽缺乏有效的硬限制机制，超卖可能导致性能抖动。

3.5 超卖配置示例

以下是一个典型的 Burstable Pod 配置，允许 CPU 超卖 2 倍，内存超卖 1.5 倍：

apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: app
    image: nginx:latest
    resources:
      requests:
        cpu: "500m"        # 预留 0.5 核
        memory: "256Mi"    # 预留 256 MiB
      limits:
        cpu: "1000m"       # 上限 1 核（超卖 2 倍）
        memory: "512Mi"    # 上限 512 MiB（超卖 2 倍）

对应的 QoS 类别判定：

• CPU：Requests (500m) ≠ Limits (1000m) → 不满足 Guaranteed
• 内存：Requests (256Mi) ≠ Limits (512Mi) → 不满足 Guaranteed
• 至少设置了 Requests 和 Limits → Burstable

3.6 容量调优中的超卖决策