📚 课程目录第4章节点资源模型

4、节点资源模型：可分配资源、容量、预留、硬性限制、软性限制、资源超卖概念

在 Kubernetes 集群中，每个节点都是一个资源池。理解节点的资源模型是进行 Pod 调度、资源预留和容量规划的基础。本章将系统梳理节点资源模型中的核心概念，帮助你在升级窗口和日常运维中准确评估节点承载能力。

4.1 核心概念定义

节点资源模型涉及多个层次的概念，它们共同决定了 Pod 能否被调度到节点上以及 Pod 运行时的资源保障。下表对比了最关键的几个术语：

概念	英文	定义	影响对象
容量	Capacity	节点物理资源总量，如 CPU 核数、内存大小	节点本身
可分配资源	Allocatable	节点上可供 Pod 使用的资源量 = 容量 - 系统预留 - Kubelet 预留 - 硬性限制	Pod 调度
预留	Reservation	为系统守护进程和 Kubelet 保留的资源，Pod 不可抢占	节点稳定性
硬性限制	Hard Limit	Pod 资源使用上限，超过则触发 OOM Kill 或 CPU 节流	单个 Pod
软性限制	Soft Limit / Request	Pod 声明的最低资源保证，调度器据此分配节点	调度决策
资源超卖	Overcommit	所有 Pod 的软性限制之和超过节点可分配资源	集群利用率

实践要点：在升级窗口期间，节点可分配资源是调度器判断 Pod 能否迁移到目标节点的唯一依据。务必在升级前通过 kubectl describe node 确认目标节点的 Allocatable 值。

4.2 节点资源分配层次结构

从节点容量到 Pod 实际可用资源，中间经过多层扣除。下图展示了完整的资源分配链路：

  关键公式：

  Allocatable = Capacity - Reserved - KubeReserved - eviction-thresholds

  其中 eviction-thresholds 是节点压力驱逐阈值，默认通常为 100Mi 内存。

4.3 硬性限制与软性限制的调度差异

Pod 的资源声明包含两个维度：Requests（软性限制）和Limits（硬性限制）。调度器只关心 Requests，而运行时 kubelet 会强制实施 Limits。

维度	软性限制（Requests）	硬性限制（Limits）
调度依据	是，调度器累加所有 Pod 的 Requests 与节点 Allocatable 比较	否，调度器不检查 Limits
运行时行为	提供最低资源保证，但不限制突发使用	强制上限，CPU 节流 / 内存 OOM
超卖场景	Requests 之和可超过 Allocatable（超卖）	Limits 之和通常远大于 Allocatable
升级窗口影响	决定 Pod 能否被调度到目标节点	决定 Pod 在目标节点上是否会被限流

升级窗口风险提示：如果目标节点上所有 Pod 的 Requests 之和已经接近 Allocatable，即使节点仍有空闲内存（因为 Pod 实际使用量低于 Requests），新迁入的 Pod 也可能因资源竞争被 OOM Kill。建议在升级前预留 10%-20% 的缓冲资源。

4.4 资源超卖机制

资源超卖（Overcommit）是 Kubernetes 提高集群利用率的核心手段。它允许所有 Pod 的 Requests 总和超过节点的 Allocatable，前提是 Pod 的实际资源使用量不会同时达到峰值。

超卖的程度由 超卖比 衡量：

超卖比 = 所有 Pod Requests 之和 / 节点 Allocatable

示例：
节点 Allocatable = 8 CPU / 16Gi 内存
Pod A: requests 4 CPU / 8Gi
Pod B: requests 4 CPU / 8Gi
Pod C: requests 2 CPU / 4Gi

CPU 超卖比 = (4+4+2) / 8 = 1.25
内存超卖比 = (8+8+4) / 16 = 1.25

超卖带来的收益与风险：

收益：集群整体利用率可从 30% 提升至 60%-80%，降低硬件成本。
风险：当多个 Pod 同时突发使用资源时，可能触发节点压力驱逐（Node Pressure Eviction），导致 Pod 被重新调度。

4.5 升级窗口中的资源模型应用

在集群升级窗口期间，节点资源模型直接影响以下决策：

目标节点选择：调度器检查目标节点的 Allocatable 是否 ≥ 待迁移 Pod 的 Requests 之和。
资源预留策略：建议在升级前对目标节点执行 kubectl taint 或设置 descheduler 策略，预留 5%-10% 的 Allocatable 作为安全缓冲。
超卖监控：使用 kubectl top node 观察节点实际资源使用率，避免超卖比超过 1.5 时进行大规模 Pod 迁移。
硬性限制检查：确认待迁移 Pod 的 Limits 不超过目标节点的 Capacity，否则即使调度成功，Pod 也可能因 CPU 节流导致性能下降。

最佳实践：在升级窗口前，使用以下命令快速评估节点资源状态：
kubectl describe node <node-name> | grep -A 5 "Allocatable"
kubectl get pods --field-selector spec.nodeName=<node-name> -o json | jq '.items[].spec.containers[].resources.requests'

4.6 资源模型对比总结

下表从调度、运行、升级三个维度对比各概念的实际作用：

场景	容量	可分配资源	预留	硬性限制	软性限制	超卖
调度决策	不直接使用	核心依据	已扣除	不检查	核心依据	允许存在
运行时保障	物理上限	Pod 可用上限	系统进程保障	强制实施	尽力保障	可能触发驱逐
升级窗口影响	决定 Pod 能否运行	决定 Pod 能否调度	影响节点稳定性	影响 Pod 性能	影响调度成功率	影响迁移风险