2. K8s资源模型基础：Pod与Container的资源请求与限制
2.1 核心概念：Request 与 Limit
Kubernetes 的资源管理模型围绕两个核心参数构建：Request（请求）和 Limit（限制）。这两个参数作用于 CPU 和内存两种可计量资源，分别定义在 Pod 内的每个 Container 上。
| 参数 | 语义 | 调度影响 | 运行时影响 |
|---|---|---|---|
| Request | 容器启动所需的最小资源保证量 | 调度器依据所有容器的 Request 总和选择满足条件的 Node | Kubelet 确保容器至少获得 Request 量的资源 |
| Limit | 容器允许使用的资源上限 | 不影响调度决策 | Kubelet 通过 cgroups 限制容器不能超过此值 |
关键原则：Request 用于调度决策和资源预留；Limit 用于运行时约束和资源隔离。CPU 是可压缩资源（超卖时降频），内存是不可压缩资源（超卖时 OOM Kill）。
2.2 资源单位与配置示例
CPU 以 cores（核）为单位，支持小数（如 0.5 表示 500m）。内存以 bytes 为单位，常用 Mi、Gi 后缀。
apiVersion: v1
kind: Pod
metadata:
name: resource-demo
spec:
containers:
- name: app
image: nginx
resources:
requests:
cpu: "500m" # 0.5 核
memory: "256Mi" # 256 兆字节
limits:
cpu: "1000m" # 1 核
memory: "512Mi" # 512 兆字节
实践建议：生产环境中，CPU 的 Request/Limit 比例通常控制在 1:1 到 1:2 之间；内存建议保持 1:1 或 1:1.5，避免因内存超卖导致 OOM。
2.3 QoS 类别：三种服务质量等级
Kubernetes 根据 Pod 内所有容器的 Request 和 Limit 设置，自动将 Pod 归入三种 QoS 类别之一。QoS 类别决定了当节点资源紧张时，哪些 Pod 优先被驱逐。
2.4 三类 QoS 的详细对比
| QoS 类别 | 触发条件 | 资源保证 | 驱逐优先级 | 典型场景 |
|---|---|---|---|---|
| Guaranteed | 所有容器 Request == Limit（CPU 和内存均需相等） | 最高保证，不会超卖 | 最低（最后被驱逐） | 数据库、关键中间件、有状态服务 |
| Burstable | 至少一个容器 Request < Limit，且所有容器都设置了 Request | 中等保证，可超卖 | 中等 | Web 服务、API 网关、批处理任务 |
| BestEffort | 至少一个容器未设置 Request（此时 Limit 也被忽略） | 无保证，完全超卖 | 最高（最先被驱逐） | 开发测试、临时任务、非关键日志收集 |
重要警告：BestEffort Pod 在节点内存压力下会最先被 OOM Kill。生产环境中应避免将核心业务 Pod 设置为 BestEffort。即使 Burstable Pod，也应设置合理的 Request 值，避免调度器过度超卖。
2.5 资源模型与 cgroups 的映射关系
Kubernetes 通过容器运行时（如 containerd）将 Request 和 Limit 转换为 Linux cgroups 参数。CPU 使用 cpu.shares（对应 Request）和 cpu.cfs_quota_us（对应 Limit）控制；内存使用 memory.limit_in_bytes 控制。
2.6 资源模型对性能优化的启示
- Guaranteed Pod 是性能稳定的基石：CPU 和内存均不超卖，避免资源争抢导致的延迟抖动。适合延迟敏感型服务。
- Burstable Pod 需要精细调参：Request 设置过低会导致调度器过度超卖，引发 CPU 节流（Throttling）和内存竞争。建议通过监控数据反向校准 Request 值。
- BestEffort Pod 应严格限制：仅用于非关键任务，且建议通过 NodeSelector 或 Taint 将其调度到独立节点，避免影响生产负载。
- CPU Limit 的陷阱：设置过低的 CPU Limit 会导致 CFS 配额强制节流，即使节点有空闲 CPU 也无法使用。对于 CPU 密集型服务，建议 Limit 不低于 Request 的 1.5 倍。
- 内存 Limit 与 OOM：当容器内存使用接近 Limit 时，内核会触发 OOM Killer。建议为 Java、Go 等内存管理型应用预留 25% 的 headroom。
性能优化切入点：本章后续将基于 QoS 类别，讲解如何通过动态校准 Request/Limit 比例、调整 cgroups 参数、优化 CPU 管理策略（如 CPU Manager）来提升容器运行时的资源利用率和性能稳定性。