Kubernetes 资源模型基础：Request、Limit、QoS 与资源配额
在 Kubernetes 集群中，资源管理是容量规划与稳定性治理的基石。理解 Request、Limit、QoS（服务质量） 以及 ResourceQuota（资源配额） 这四个核心概念，是后续治理版本漂移和实现精细化容量控制的前提。本节将系统梳理这些概念的定义、作用机制以及它们之间的关联。
2.1 资源请求（Request）与资源限制（Limit）
每个 Pod 中的容器都可以声明两类资源参数：CPU 和 内存。Kubernetes 通过这两个参数决定 Pod 的调度位置与运行时的资源边界。
| 参数 | 含义 | 调度依据 | 运行时行为 |
|---|---|---|---|
| Request | 容器保证能获得的最小资源量 | kube-scheduler 根据所有 Node 上已分配 Request 之和进行调度 | CPU 使用受 CFS 配额保障；内存不足时可能触发 OOM Kill |
| Limit | 容器允许使用的资源上限 | 不参与调度决策 | CPU 会被 throttled（节流）；内存超过 Limit 时容器会被 OOM Kill |
实践要点：Request 必须 ≤ Limit。如果未设置 Limit，则默认等于 Request（取决于集群配置或 LimitRange）。生产环境中建议始终显式设置两者，避免资源争抢与突发流量导致的节点过载。
2.2 服务质量（QoS）等级
Kubernetes 根据 Pod 中所有容器的 Request 与 Limit 设置，自动为每个 Pod 分配一个 QoS 等级。该等级决定了节点资源紧张时 Pod 被驱逐的优先级。
QoS 等级速查表：
- Guaranteed：所有容器均设置 Request == Limit，且不为 0。最高优先级，最稳定。
- Burstable：至少一个容器设置了 Request 或 Limit，但不满足 Guaranteed 条件。中等优先级。
- BestEffort：所有容器均未设置 Request 和 Limit。最低优先级，节点压力下最先被驱逐。
2.3 资源配额（ResourceQuota）
ResourceQuota 是命名空间级别的资源约束机制，用于限制一个命名空间内所有 Pod 的资源总和，防止单个团队或应用过度消耗集群资源。
以下是一个典型的 ResourceQuota 配置示例：
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-team-quota
namespace: dev
spec:
hard:
requests.cpu: "4"
requests.memory: "8Gi"
limits.cpu: "8"
limits.memory: "16Gi"
pods: "20"
persistentvolumeclaims: "5"
configmaps: "10"
services: "10"
注意：ResourceQuota 仅限制 命名空间级别 的资源总量，不限制单个 Pod 的资源声明。若需要限制单个 Pod 或容器的资源范围，应配合使用 LimitRange 策略。
2.4 Request、Limit、QoS 与 ResourceQuota 的协同关系
这四个概念共同构成了 Kubernetes 资源管理的核心闭环：
- Request/Limit 定义单个容器的资源边界。
- QoS 根据 Request/Limit 自动派生，决定 Pod 在节点压力下的驱逐优先级。
- ResourceQuota 在命名空间层面汇总所有 Pod 的 Request/Limit，实施总量控制。
在容量规划实践中，团队应首先为每个工作负载设定合理的 Request 与 Limit，然后通过 ResourceQuota 为每个命名空间划定资源上限，最后利用 QoS 等级保障关键业务 Pod 的稳定性。这种分层治理模型是后续使用 Kyverno 策略自动化治理版本漂移的基础。