📚 课程目录第2章 Kubernetes资源模型基础

2. Kubernetes 资源模型基础：Pod 与 Container 的资源请求与限制

在 Kubernetes 集群中，资源管理是性能调优与成本分摊的基石。每个 Pod 和 Container 都可以声明其所需的计算资源（CPU 和内存），集群调度器根据这些声明做出调度决策，kubelet 则依据这些声明对容器进行资源隔离与限制。理解资源模型是掌握 QoS 类别和后续成本分摊的前提。

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

Kubernetes 为每个容器定义了两种资源规格：Request（请求）和 Limit（限制）。

Request：容器启动时保证获得的最小资源量。调度器依据所有容器的 Request 总和判断节点是否满足 Pod 运行需求。
Limit：容器运行时允许使用的资源上限。当容器试图使用超过 Limit 的资源时，系统会进行限流（CPU）或直接终止（内存）。

CPU 资源以 cores（核）或 millicores（毫核，1000m = 1 core）为单位；内存资源以 bytes（字节）为单位，常用 Mi、Gi 等后缀。

  关键原则：Request ≤ Limit。如果只设置 Limit 而未设置 Request，则 Request 默认等于 Limit；如果只设置 Request 而未设置 Limit，则 Limit 默认为节点容量上限（无硬限制）。

2.2 资源模型对比表

属性	CPU	内存
Request 含义	保证的最小 CPU 时间片	保证的最小内存分配
Limit 含义	CPU 使用上限（可突发）	内存使用硬上限（OOM 风险）
超限行为	CPU 被限流（throttle）	容器被 OOM Kill
调度依据	Request 总和	Request 总和
计费依据	通常按 Request 计费	通常按 Request 计费

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

Kubernetes 根据 Pod 内所有容器的 Request 和 Limit 设置情况，将 Pod 划分为三种 QoS（Quality of Service） 类别。当节点资源紧张时，kubelet 按照 QoS 优先级驱逐 Pod：BestEffort 最先被驱逐，Burstable 次之，Guaranteed 最后被驱逐。

调优启示：核心业务 Pod 应配置为 Guaranteed 类别，以获得最高的稳定性保障；批处理或低优先级任务可配置为 BestEffort 以降低成本。

2.3.1 Guaranteed（保证型）

条件：Pod 内每个容器都设置了 CPU 和内存的 Request 与 Limit，且 Request == Limit。
行为：调度器保证资源，kubelet 优先保护，几乎不会被驱逐。
适用场景：数据库、关键微服务、有状态应用。

2.3.2 Burstable（可突发型）

条件：Pod 内至少有一个容器设置了 Request 或 Limit，且不满足 Guaranteed 条件（即 Request < Limit 或只设置了 Request）。
行为：容器在资源空闲时可突发使用超出 Request 的资源，但不超过 Limit。
适用场景：Web 服务、API 网关、有流量波动的应用。

2.3.3 BestEffort（尽力型）

条件：Pod 内所有容器都没有设置任何 Request 和 Limit。
行为：无资源保证，可占用空闲资源，但节点压力大时最先被驱逐。
适用场景：开发测试、批处理、非关键任务。

2.4 QoS 类别决策流程（SVG 图）

2.5 资源模型与成本分摊的关系

在云原生成本分摊实践中，Request 是计费的核心依据，而非 Limit。这是因为 Request 代表了集群为 Pod 预留的、不可被其他 Pod 抢占的资源量。即使 Pod 实际使用量低于 Request，集群仍然为该 Pod 保留了这部分资源。

常见误区：不要将 Limit 设置为远大于 Request 的值来“预留”资源。这会导致节点资源利用率虚低，成本分摊失真，且可能引发调度失败。合理的做法是：根据实际负载曲线设置 Request，将 Limit 设置为 Request 的 1.2~2 倍以应对突发流量。

2.6 资源模型配置示例

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"

上述示例中：

容器保证获得 256Mi 内存和 0.5 核 CPU（Request）。
容器最多可使用 512Mi 内存和 1 核 CPU（Limit）。
由于 Request < Limit，该 Pod 属于 Burstable 类别。
成本分摊时，按 256Mi 内存和 500m CPU 的 Request 值进行计费。

2.7 三种 QoS 类别对比总结

QoS 类别	配置条件	资源保证	驱逐优先级	典型场景
Guaranteed	所有容器 Request == Limit	完全保证	最低（最后被驱逐）	数据库、核心微服务
Burstable	部分容器设置 Request/Limit，且不满足 Guaranteed	部分保证	中等	Web 服务、API 网关
BestEffort	所有容器未设置 Request 和 Limit	无保证	最高（最先被驱逐）	开发测试、批处理

2.8 资源模型与成本分摊协同（SVG 图）

2.9 实践建议

核心服务使用 Guaranteed：将关键业务 Pod 的 Request 和 Limit 设置为相同值，确保资源独占性和稳定性。
弹性服务使用 Burstable：为有流量波动的服务设置合理的 Request（基线负载）和 Limit（峰值上限），兼顾成本与弹性。
非关键任务使用 BestEffort：开发测试、CI/CD 等任务不设置资源规格，利用集群空闲资源运行。
定期审计 Request 合理性：通过监控工具（如 Prometheus）分析实际资源使用率，调整 Request 以匹配真实负载，避免资源浪费。
成本分摊以 Request 为准：在成本报表中，统一使用 Request 值作为计费基准，确保分摊逻辑透明、可审计。