4. 集群容量规划基础：资源请求(Request)与限制(Limit)、QoS等级、资源利用率指标
在 Kubernetes 集群中，容量规划的核心在于精确理解工作负载的资源需求与集群实际供给能力之间的映射关系。本章将深入剖析资源请求（Request）与限制（Limit）的语义差异、Pod 服务质量（QoS）等级的划分逻辑，以及关键资源利用率指标的采集与解读方法。这些基础概念是后续实现节点自动扩缩容与成本优化的理论基石。
4.1 资源请求（Request）与限制（Limit）
Kubernetes 通过 requests 和 limits 两个字段对容器资源进行管控。它们分别对应调度保证与资源上限，理解其差异是避免资源争抢和浪费的前提。
| 属性 | 语义 | 调度影响 | 运行时行为 |
|---|---|---|---|
| Request | 容器启动所需的最小资源保证 | kube-scheduler 依据所有容器的 Request 总和选择节点 | CPU 使用受 CFS 配额保障；内存不足时优先触发 OOM |
| Limit | 容器允许使用的资源硬上限 | 不影响调度决策 | CPU 使用被 throttled；内存超过 Limit 时容器被 OOMKill |
关键原则：Request 决定调度可行性，Limit 决定运行时安全边界。生产环境中建议将 Request 设置为基于历史 P99 使用量的 1.1~1.3 倍，Limit 设置为 Request 的 1.5~2 倍，以平衡资源利用率与稳定性。
以下是一个典型的 Pod 资源声明示例：
apiVersion: v1
kind: Pod
metadata:
name: capacity-demo
spec:
containers:
- name: app
image: nginx:latest
resources:
requests:
memory: "256Mi"
cpu: "500m"
limits:
memory: "512Mi"
cpu: "1000m"4.2 QoS 等级：资源保障的优先级模型
Kubernetes 根据 Pod 中所有容器的 Request 与 Limit 配置组合，自动将 Pod 划分为三种 QoS（Quality of Service）等级。该等级决定了节点资源紧张时 Pod 被驱逐的优先级。
QoS 等级是节点压力驱逐（Node Pressure Eviction）的核心排序依据。 当节点内存或磁盘资源不足时，kubelet 会按 BestEffort → Burstable → Guaranteed 的顺序逐级驱逐 Pod。
4.3 核心资源利用率指标
容量规划依赖精确的指标数据。以下指标是评估集群资源水位、触发扩缩容决策的关键输入。
4.3.1 节点级指标
- CPU 利用率：
node_cpu_seconds_total（Prometheus）或kube_node_status_capacity_cpu_cores。建议关注 5 分钟平均利用率，避免瞬时尖峰干扰。 - 内存利用率：
node_memory_MemTotal_bytes与node_memory_MemAvailable_bytes。注意available包含缓存与缓冲区，比free更准确。 - 磁盘 I/O 压力：
node_disk_io_time_seconds_total与node_disk_io_time_weighted_seconds_total。高 I/O 等待时间可能导致节点被标记为DiskPressure。 - 网络带宽：
node_network_receive_bytes_total与node_network_transmit_bytes_total。用于判断是否达到节点网络上限。
4.3.2 Pod 级指标
- CPU 使用率 vs Request：
rate(container_cpu_usage_seconds_total[5m]) / container_spec_cpu_quota。当持续超过 80% 时考虑扩容。 - 内存使用率 vs Limit：
container_memory_working_set_bytes / container_spec_memory_limit_bytes。超过 90% 时存在 OOMKill 风险。 - OOMKill 计数：
container_last_seen结合container_oom_events_total。频繁 OOM 表明 Limit 设置过低。
4.3.3 集群级聚合指标
| 指标名称 | 计算公式 | 用途 |
|---|---|---|
| 集群 CPU 分配率 | sum(request) / sum(capacity) | 判断整体 CPU 资源是否过载 |
| 集群内存分配率 | sum(request) / sum(capacity) | 判断整体内存资源是否过载 |
| 节点资源碎片率 | 1 - (max(request_per_node) / capacity_per_node) | 评估节点间资源分布均匀性 |
| Pod 密度 | count(pod) / count(node) | 评估节点可调度 Pod 数量上限 |
常见误区：仅依赖 CPU 和内存指标进行容量规划。实际生产中，磁盘 IOPS、网络带宽、PID 限制、inode 耗尽同样可能导致节点不可用。建议将
node_nf_conntrack_entries、node_filefd_allocated 等指标纳入监控体系。
4.4 指标驱动的容量规划流程
将上述指标与 QoS 等级结合，可以构建一个闭环的容量规划流程：
- 数据采集：通过 Prometheus 或云厂商监控服务，持续采集节点级与 Pod 级指标。
- 基线建立：基于过去 7~30 天的 P50/P95/P99 使用量，为每个工作负载生成 Request 与 Limit 建议值。
- QoS 审计：检查所有 Pod 的 QoS 等级，确保核心业务为 Guaranteed，非关键业务为 BestEffort。
- 碎片分析：计算节点资源碎片率，识别因 Pod 调度不均导致的资源浪费。
- 扩缩容触发：当集群 CPU/内存分配率超过 80% 或节点碎片率低于 20% 时，触发节点自动扩缩容。
实践建议：在 Prometheus 中创建以下记录规则（Recording Rule），用于实时计算集群资源分配率：
:cluster_cpu_request_ratio:avg = sum(kube_pod_container_resource_requests_cpu_cores) / sum(node_cpu_cores):cluster_memory_request_ratio:avg = sum(kube_pod_container_resource_requests_memory_bytes) / sum(node_memory_MemTotal_bytes)