4. 容量规划基础：资源需求、资源限制、请求与限制的关系、QoS等级
在 Kubernetes 集群中进行容量规划，核心前提是理解 Pod 如何声明和消耗计算资源。资源需求（Requests）与资源限制（Limits）是调度与隔离的基石，而服务质量等级（QoS）则决定了 Pod 在节点资源竞争时的生存优先级。本节将逐一拆解这些概念，并建立它们与容量规划的直接关联。
4.1 资源需求（Requests）与资源限制（Limits）
每个容器都可以在 Pod 规范中声明两类资源参数：
- Requests（需求）：容器保证能获得的最小资源量。Kubernetes 调度器依据 Requests 总和来选择节点，确保节点容量满足所有 Pod 的“最低保障”。
- Limits（限制）：容器允许使用的资源上限。当容器试图超过 Limits 时，CPU 会被节流（Throttle），内存不足（OOM）时会被杀死。
容量规划关键点： 集群的总容量规划应基于 Requests 而非 Limits。因为调度决策只认 Requests，超卖（Overcommit）正是通过设置 Limits > Requests 来实现的。
4.1.1 典型配置示例
apiVersion: v1
kind: Pod
metadata:
name: capacity-demo
spec:
containers:
- name: app
image: nginx
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"4.2 请求与限制的关系：三种配置模式
Requests 与 Limits 的组合关系直接决定了 Pod 的资源行为与 QoS 等级。下表总结了三种核心模式：
| 配置模式 | Requests | Limits | 典型场景 |
|---|---|---|---|
| Guaranteed（保证） | 等于 Limits | 等于 Requests | 延迟敏感型服务（数据库、核心 API） |
| Burstable（可爆发） | 小于 Limits | 大于 Requests | Web 服务、批处理任务（允许临时超卖） |
| BestEffort（尽力而为） | 未设置 | 未设置 | 低优先级、可中断的测试或缓存任务 |
容量规划建议： 在 Argo CD 多集群部署中，建议为生产集群的“核心工作负载”统一使用 Guaranteed 模式，以消除节点资源争用；为“弹性工作负载”使用 Burstable 模式，提高整体资源利用率。
4.3 QoS 等级（服务质量等级）
Kubernetes 根据 Pod 内所有容器的 Requests 与 Limits 设置，自动为每个 Pod 分配一个 QoS 等级。当节点资源不足时，kubelet 会按以下优先级驱逐 Pod：
- BestEffort（最低优先级）—— 最先被驱逐
- Burstable（中等优先级）—— 当资源压力持续时被驱逐
- Guaranteed（最高优先级）—— 最后被驱逐，仅当节点资源严重耗尽时
常见误区： 即使 Pod 设置了 Limits，但如果未设置 Requests，Kubernetes 会将 Requests 默认等于 Limits，从而自动归入 Guaranteed 等级。这可能导致容量规划时低估实际资源需求，造成节点过载。
4.4 资源关系与 QoS 决策流程
下图展示了从资源声明到 QoS 等级分配的完整决策路径，帮助容量规划者快速判断 Pod 的优先级行为：
4.5 容量规划中的资源模型总结
将上述概念映射到多集群容量规划，可归纳为以下核心公式与策略：
- 节点可调度容量 = 节点总容量 - 系统预留 - kubelet 预留 - 已分配 Requests 总和
- 超卖比 = 集群 Limits 总和 / 集群 Requests 总和。建议生产集群控制在 1.5~2.0 之间。
- QoS 分布策略：核心服务（Guaranteed）占比 40%~50%，弹性服务（Burstable）占比 40%~50%，BestEffort 占比不超过 10%。
Argo CD 多集群实践提示： 在 ApplicationSet 的模板中，可以通过
resources.requests 和 resources.limits 参数为不同集群环境（prod/staging/dev）设置差异化的资源声明，从而实现集群级别的容量策略统一管理。