3、容量评估核心概念：节点资源、Pod 资源请求与限制、集群资源利用率
集群升级前，容量评估是决定升级是否安全、平稳的核心前置动作。若节点资源不足、Pod 资源请求与限制配置不合理或集群整体利用率过高，升级过程中极可能出现 Pod 驱逐失败、节点压力过大甚至集群不可用的情况。本节将系统梳理容量评估的三大核心概念：节点资源、Pod 资源请求与限制、集群资源利用率，并给出可量化的评估方法与关键指标。
3.1 节点资源：CPU / 内存 / 磁盘
节点是集群中承载 Pod 运行的基本单元。升级前，必须逐节点评估以下三类资源的剩余容量与健康状态：
| 资源类型 | 关键指标 | 评估要点 | 升级前阈值建议 |
|---|---|---|---|
| CPU | Allocatable CPU、Requests CPU、Limits CPU、实际使用率 | 检查节点 CPU 是否被过度承诺（Overcommit），预留至少 10% 的突发缓冲 | Allocatable - Requests ≥ 节点总 CPU 的 10% |
| 内存 | Allocatable Memory、Requests Memory、Limits Memory、实际使用率 | 内存不可压缩，过度承诺可能导致 OOM；需关注 kubelet 与系统预留 | Allocatable - Requests ≥ 节点总内存的 15% |
| 磁盘 | 根分区使用率、容器镜像存储使用率、kubelet 数据目录使用率 | 磁盘写满会导致节点 NotReady、Pod 驱逐失败；升级过程需额外镜像缓存空间 | 根分区使用率 ≤ 70%，镜像存储分区使用率 ≤ 75% |
实操提示：使用
kubectl describe node <node-name> 查看 Allocatable 与 Capacity 字段；使用 kubectl top node 获取实时利用率。磁盘信息建议通过节点 SSH 或 Node Exporter 采集。
3.2 Pod 资源请求与限制
Pod 的资源请求（Requests）与限制（Limits）是调度与 QoS 分类的基础。升级前，需重点审查以下三类配置风险：
- 未设置 Requests / Limits：Pod 可能被调度到资源不足的节点，升级驱逐时无 QoS 保障，优先被杀死。
- Requests 与 Limits 差距过大：导致节点资源过度承诺，实际负载飙升时触发 CPU Throttling 或 OOM。
- Limits 设置过高：浪费集群资源，降低调度密度，升级时节点压力转移能力不足。
以下是一个标准的 Pod 资源声明示例：
apiVersion: v1
kind: Pod
metadata:
name: capacity-check-pod
spec:
containers:
- name: app
image: nginx
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
升级风险提示：若集群中存在大量
BestEffort QoS（未设置任何 Requests/Limits）的 Pod，升级驱逐时它们将最先被终止，可能导致业务中断。建议升级前至少为关键业务 Pod 设置 Guaranteed 或 Burstable QoS。
3.3 集群资源利用率
集群资源利用率是容量评估的宏观指标，反映整体资源水位与调度压力。升级前需从以下三个维度进行量化评估：
| 维度 | 计算公式 | 健康区间 | 升级风险等级 |
|---|---|---|---|
| CPU 利用率 | （集群 CPU 实际使用量 / 集群 CPU Allocatable） × 100% | 40% – 65% | > 80% 高风险 |
| 内存利用率 | （集群内存实际使用量 / 集群内存 Allocatable） × 100% | 50% – 70% | > 85% 高风险 |
| Pod 密度 | （集群运行 Pod 数 / 集群节点数） | 按节点规格评估，通常 ≤ 30 Pod/节点 | 接近节点 Pod 上限时高风险 |
下图展示了从节点资源到集群利用率的核心评估流程与数据流向：
关键结论：容量评估不是单一维度的数字检查，而是从节点资源 → Pod 资源声明 → 集群利用率的三层递进分析。只有三层数据均处于健康区间，升级过程才具备足够的资源缓冲与容错能力。