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

2. K8s资源模型基础：Pod与Container的资源请求(Request)与限制(Limit)概念、QoS等级分类

2.1 资源请求与限制：Pod 调度的“准入线”与“安全线”

在 Kubernetes 中，每个 Container 都可以声明两类资源参数：Request（请求）和 Limit（限制）。这两者共同决定了 Pod 在节点上的调度资格、CPU 共享权重以及内存回收优先级。

参数	含义	调度影响	运行时影响
Request	容器保证能获得的最小资源量	调度器按 Request 总和选择节点	CPU 按 Request 比例分配时间片；内存不足时优先回收超用 Pod
Limit	容器允许使用的资源上限	不影响调度决策	CPU 被 CFS 配额限制；内存超过 Limit 触发 OOM Kill

压测调优关键点：后端压测库（如 Locust、k6、wrk）的 Pod 通常需要较高的 CPU Request 来保证调度到资源充足的节点，同时设置合理的 CPU Limit 防止压测流量波动时抢占同节点其他业务 Pod 的资源。

2.2 CPU 与内存的资源单位

Kubernetes 使用标准化的单位来表达资源量，避免不同云环境下的单位歧义。

CPU：以 m（毫核）为单位，1 CPU = 1000m。支持小数如 0.5 等价于 500m。
内存：以字节为单位，常用后缀 Ki、Mi、Gi（二进制单位）或 M、G（十进制单位）。压测场景推荐使用二进制单位避免精度误差。

# 示例：压测 Pod 的资源声明
resources:
  requests:
    cpu: "500m"        # 保证 0.5 核
    memory: "256Mi"    # 保证 256 MiB
  limits:
    cpu: "1000m"       # 最多使用 1 核
    memory: "512Mi"    # 最多使用 512 MiB

2.3 QoS 等级：资源超卖与保障的三种策略

Kubernetes 根据 Pod 中所有 Container 的 Request 与 Limit 配置组合，自动将 Pod 划分为三个 QoS（服务质量）等级。等级决定了节点资源紧张时的驱逐顺序。

2.4 三种 QoS 等级的配置判定条件

QoS 等级	判定条件	典型配置示例	压测场景推荐度
Guaranteed	所有容器均设置 CPU 和内存的 Limit，且每个资源的 Request == Limit	`cpu: "1" / memory: "512Mi"`（Request 与 Limit 相同）	⭐⭐⭐ 强烈推荐
Burstable	至少一个容器设置了 Request 或 Limit，且不满足 Guaranteed 条件	`cpu: 500m/1000m` 或仅设置 Request	⭐⭐ 允许，需监控驱逐风险
BestEffort	所有容器均未设置任何 Request 和 Limit	不写 resources 字段	⭐ 不推荐，压测稳定性差

压测库调优警告：BestEffort 等级的 Pod 在节点内存压力下会最先被 OOM Kill，导致压测中断、数据丢失。即使压测库本身支持断点续压，频繁重启也会引入额外的冷启动延迟，影响压测结果的准确性。务必为压测 Pod 显式设置 Request 和 Limit。

2.5 资源限制对压测库性能的影响

后端压测库（如 Locust、k6、wrk）通常需要大量 CPU 来生成并发请求，以及足够的内存来维护连接状态和响应数据。资源限制设置不当会导致以下问题：

CPU 限制过低：压测库的请求发送速率被 CFS 配额限制，无法达到目标 QPS。
内存限制过低：压测库在维持大量 HTTP 连接时触发 OOM Kill，Pod 频繁重启。
Request 设置过高：调度器找不到足够资源的节点，Pod 处于 Pending 状态。
Limit 设置过高：压测库可能抢占同节点其他业务 Pod 的资源，引发生产环境问题。

  最佳实践：压测库 Pod 的 Request 应基于压测目标 QPS 的 70% 估算，Limit 设置为 Request 的 1.2~1.5 倍，既保证调度成功率，又允许短时突发流量。同时将 QoS 等级设为 Guaranteed，确保压测过程中不被驱逐。