📚 课程目录第3章容量水位概念解析

3. 容量水位概念解析：CPU、内存、存储、Pod密度、节点剩余资源等关键指标

在集群升级前，容量水位检查是确保升级过程中业务不中断、资源不枯竭的核心前置动作。容量水位并非单一指标，而是由多个维度共同构成的资源健康度评估体系。本章将逐一解析CPU、内存、存储、Pod密度及节点剩余资源等关键指标的定义、计算方式与检查阈值。

3.1 容量水位定义与评估模型

容量水位（Capacity Water Level）指集群或节点上已使用资源与总可分配资源之间的比例关系。水位过高意味着资源紧张，升级过程中一旦出现节点临时不可用，极易引发Pod驱逐或调度失败。

评估模型采用三层水位线机制：

水位等级	使用率范围	升级风险	建议动作
安全水位	≤ 60%	低	可直接升级
警戒水位	60% ~ 80%	中	评估后升级，预留回退窗口
危险水位	> 80%	高	必须扩容或迁移负载后再升级

实践要点：水位阈值并非固定值，需根据集群实际规格（如节点规格、业务潮汐特征）动态调整。建议以节点可分配资源（Allocatable）为分母，而非节点总容量（Capacity）。

3.2 CPU容量水位

CPU水位衡量的是节点上所有Pod已请求（Request）和已使用（Usage）的CPU核心数与节点可分配CPU核心数的比例。升级过程中，kubelet和kube-apiserver等系统组件会额外消耗CPU，因此需预留缓冲。

核心指标：CPU Request水位、CPU Usage水位
计算公式：
CPU水位(%) = (已分配CPU Request / 节点可分配CPU) × 100%
升级前阈值：Request水位 ≤ 65%，Usage水位 ≤ 55%
风险场景：CPU Burst导致节点过载，触发Pod CPU Throttling

Kyverno策略示例：检查节点CPU Request水位是否超过65%，若超过则拒绝升级操作。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-cpu-water-level
spec:
  rules:
  - name: cpu-request-limit
    match:
      resources:
        kinds:
        - Node
    validate:
      message: "节点CPU Request水位超过65%，禁止升级"
      deny:
        conditions:
          any:
          - key: "{{ request.object.status.allocatable.cpu }}"
            operator: GreaterThan
            value: "0.65 * {{ request.object.status.capacity.cpu }}"

3.3 内存容量水位

内存水位比CPU更敏感，因为内存不可压缩（Non-compressible）。一旦内存耗尽，OOM Killer会直接杀死Pod，导致业务中断。

核心指标：内存Request水位、内存Usage水位、内存碎片率
计算公式：
内存水位(%) = (已分配内存Request / 节点可分配内存) × 100%
升级前阈值：Request水位 ≤ 70%，Usage水位 ≤ 60%
风险场景：内存碎片导致大页分配失败，系统OOM

内存类型	安全水位	警戒水位	危险水位
HugePages (2MiB)	≤ 50%	50% ~ 70%	> 70%
普通内存	≤ 60%	60% ~ 80%	> 80%

3.4 存储容量水位

存储水位包括节点本地存储（Ephemeral Storage）和PV持久化存储。升级过程中，容器镜像拉取、日志写入、临时文件生成都会消耗存储空间。

核心指标：Ephemeral Storage水位、PV使用率、Inode使用率
计算公式：
存储水位(%) = (已使用存储 / 总存储容量) × 100%
升级前阈值：Ephemeral ≤ 75%，PV ≤ 80%，Inode ≤ 70%
风险场景：磁盘写满导致Pod Eviction，容器无法启动

注意：Inode耗尽比容量耗尽更隐蔽。即使存储容量未满，Inode耗尽也会导致文件创建失败。建议在升级前执行 df -i 检查Inode使用率。

3.5 Pod密度与节点剩余资源

Pod密度指单个节点上运行的Pod数量。密度过高会导致kubelet调度压力增大、CNI网络规则膨胀、DNS缓存命中率下降。

核心指标：节点Pod数量、节点剩余可调度Pod数量、剩余CPU/内存
计算公式：
Pod密度 = 当前运行Pod数 / 节点最大Pod数
剩余可调度Pod = 节点最大Pod数 - 当前运行Pod数
升级前阈值：Pod密度 ≤ 70%，剩余可调度Pod ≥ 5
风险场景：升级过程中节点排水（Drain）时，剩余节点无法承载被驱逐的Pod

3.6 容量水位综合评估SVG图

下图展示了集群升级前需要检查的五大容量水位维度及其关联关系：

3.7 关键指标检查清单

以下为升级前容量水位检查的标准化清单，可直接用于自动化脚本或Kyverno策略编写：

检查项	指标名称	安全阈值	数据来源
CPU Request水位	cpu_request_ratio	≤ 65%	`kubectl describe node`
CPU Usage水位	cpu_usage_ratio	≤ 55%	Metrics Server / Prometheus
内存 Request水位	memory_request_ratio	≤ 70%	`kubectl describe node`
内存 Usage水位	memory_usage_ratio	≤ 60%	Metrics Server / Prometheus
Ephemeral Storage水位	ephemeral_storage_ratio	≤ 75%	`kubectl describe node`
Inode使用率	inode_usage_ratio	≤ 70%	`df -i` (节点内)
Pod密度	pod_density_ratio	≤ 70%	`kubectl get pods --all-namespaces --field-selector spec.nodeName=`
剩余可调度Pod	remaining_pods	≥ 5	`kubectl describe node` (Allocatable Pods)

3.8 节点剩余资源综合计算SVG图

节点剩余资源并非单一数值，而是由多个子资源共同决定的复合指标。下图展示了剩余资源的计算逻辑：

3.9 升级预留缓冲机制

升级过程中，kubelet、容器运行时、CNI插件等系统组件会额外消耗资源。因此，在计算剩余资源时，必须预留升级缓冲：

CPU缓冲：额外预留 5% 的可分配CPU，用于kubelet和容器运行时升级期间的CPU峰值
内存缓冲：额外预留 10% 的可分配内存，用于镜像拉取和临时日志写入
存储缓冲：额外预留 15% 的Ephemeral Storage，用于升级过程中的临时文件
Pod缓冲：至少预留 2 个Pod槽位，用于系统组件重启

Kyverno策略示例：检查节点剩余资源是否满足升级缓冲要求。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-upgrade-buffer
spec:
  rules:
  - name: remaining-resource-check
    match:
      resources:
        kinds:
        - Node
    validate:
      message: "节点剩余资源不足，无法满足升级缓冲要求"
      deny:
        conditions:
          any:
          - key: "{{ request.object.status.allocatable.cpu - sum(request.object.status.allocatable.cpu * 0.05) }}"
            operator: LessThan
            value: "0"

3.10 容量水位检查最佳实践

提前采集基线：在升级前至少7天开始采集容量水位数据，建立业务潮汐基线
多维度联合判断：不要仅依赖单一指标，CPU、内存、存储、Pod密度需同时满足安全水位
自动化策略执行：使用Kyverno ClusterPolicy将容量水位检查固化为升级前置条件
预留回退窗口：即使水位安全，也建议在升级计划中保留30分钟的回退时间
持续监控：升级完成后持续监控容量水位变化，确保没有资源泄漏