3、节点资源抽象：Node Capacity、Allocatable、Reserved、Eviction Thresholds 的计算逻辑与配置方法

在 Kubernetes 集群中，一个节点的物理资源（CPU、内存、磁盘、PID）并非全部可供 Pod 使用。Kubelet 通过一套严格的资源抽象模型，将原始硬件容量逐层扣除系统预留、Kubernetes 守护进程预留和驱逐阈值，最终得到 Pod 可用的 Allocatable 资源。理解这一计算链条是容量评估与资源配额规划的基础。

3.1 核心概念与计算逻辑

节点资源从物理总量到 Pod 可用量的转换遵循以下公式：

Allocatable = Node Capacity - Reserved - Eviction Thresholds

其中：
Reserved = System Reserved + Kube Reserved

各层含义如下：

3.2 计算流程与配置方法

Kubelet 在启动时按以下顺序计算并注册节点资源：

1. 读取 Node Capacity：从 cgroups 或 /proc 文件系统获取 CPU、内存、磁盘、PID 的硬件总量。
2. 扣除 System Reserved：根据 --system-reserved 参数值（如 cpu=500m,memory=1Gi）从 Capacity 中减去。
3. 扣除 Kube Reserved：根据 --kube-reserved 参数值（如 cpu=200m,memory=512Mi）继续减去。
4. 扣除 Eviction Thresholds：根据 --eviction-hard 参数（如 memory.available<100Mi）从剩余量中减去阈值对应的资源量。
5. 注册 Allocatable：将最终结果写入 Node Status 的 status.allocatable 字段。

3.3 驱逐阈值（Eviction Thresholds）的详细机制

驱逐阈值是节点资源抽象中容易被忽视但至关重要的部分。它决定了节点在资源紧张时何时开始驱逐 Pod，从而影响实际可用容量。

3.4 节点资源抽象全景图

下图展示了从 Node Capacity 到 Allocatable 的完整计算链路，以及各层预留的归属关系：

3.5 查看与验证方法

通过以下命令可以查看节点的实际资源分配情况：

# 查看节点 Allocatable 和 Capacity
kubectl describe node <node-name> | grep -A 5 "Capacity"

# 输出示例：
# Capacity:
#   cpu:                4
#   memory:             16387412Ki
#   ephemeral-storage:  102350Mi
# Allocatable:
#   cpu:                3
#   memory:             15287412Ki
#   ephemeral-storage:  92350Mi

# 查看 kubelet 配置（需在节点上执行）
ps aux | grep kubelet | grep -- '--system-reserved\|--kube-reserved\|--eviction-hard'

3.6 常见配置误区与避坑指南

• 误区一： 认为 Capacity 就是 Pod 可用量。实际上，未配置预留时默认值可能为 0，导致节点在资源紧张时出现系统级故障。
• 误区二： 驱逐阈值设置过高（如 memory.available<5%），导致 Allocatable 被过度扣除，造成资源浪费。
• 误区三： 忽略 PID 和 inode 的预留。在运行大量 sidecar 或短生命周期 Pod 的集群中，PID 耗尽比内存耗尽更常见。
• 误区四： 所有节点使用相同的预留配置。不同规格的节点（如 4C16G vs 32C128G）应使用不同的预留比例。