NodeAllocatable是调度器决策唯一依据，计算公式为Capacity−kube-reserved−system-reserved−eviction-hard；需按节点角色差异化配置预留值，并配合eviction策略与强制cgroup执行确保稳定性。
核心在于让调度器“看得到真实可用资源”，同时确保系统关键进程不被挤占。NodeAllocatable 不是性能参数，而是资源边界声明——它直接决定 Pod 能否被调度到该节点，也间接影响节点稳定性。
明确 allocatable 的计算逻辑
NodeAllocatable = Node Capacity − kube-reserved − system-reserved − eviction-hard（内存驱逐阈值）
这个值才是 scheduler 做调度决策的唯一依据。哪怕节点空闲内存还有 5Gi，只要所有已调度 Pod 的 requests 总和 ≥ allocatable.memory，新 Pod 就会被拒绝调度。
- Capacity 是硬件总资源（如
memory: 16Gi），但不可全用于 Pod - kube-reserved 预留资源给 kubelet、kube-proxy、容器运行时等 Kubernetes 组件
- system-reserved 预留资源给 sshd、journald、udev、内核缓存等 OS 级进程
- eviction-hard 是 kubelet 主动驱逐 Pod 的内存底线（如
memory.available<500Mi），它参与 allocatable 计算，但本身不预留物理 cgroup 限制
按节点角色差异化配置 reserved 值
不能一套参数打天下。8 核 32Gi 的控制面节点和 64 核 256Gi 的 GPU 计算节点，预留策略必须不同。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 通用型工作节点（CPU/MEM 密集）：建议
--kube-reserved=cpu=500m,memory=1Gi，--system-reserved=cpu=500m,memory=1.5Gi - GPU 节点：额外为 nvidia-container-runtime、dcgm-exporter 等预留，例如
--system-reserved=memory=2.5Gi；避免 GPU 内存被误计入 allocatable - 高 IO 节点（大量本地盘/SSD）：ephemeral-storage 预留需同步增加，防止 inode 或空间耗尽触发驱逐
- 小规格边缘节点（如 2C4G）：可适当降低 kube-reserved（如
cpu=200m,memory=512Mi），但 system-reserved 不宜低于 512Mi，否则 systemd 可能 OOM
配合 eviction 策略做主动防御
allocatable 是静态边界，eviction 是动态兜底。二者要协同，不能只设前者不调后者。
- 内存驱逐阈值建议设为
memory.available<800Mi（而非默认的 100Mi），给系统缓冲空间 - 启用软驱逐（
--eviction-soft）并配超时（如memory.available<1Gi:5m），提前预警并优雅驱逐低优先级 Pod - 务必设置
--enforce-node-allocatable=pods，否则 kubelet 不会强制执行 cgroup 限制，reserved 形同虚设 - 验证是否生效：检查
/sys/fs/cgroup/cpu/kubepods/cpu.max和/sys/fs/cgroup/memory/kubepods/memory.max是否反映预留后余量
上线前必须做的三件事
参数写进 kubelet 启动项只是第一步，没验证=没生效。
- 用
kubectl describe node <name>确认 Allocatable 数值已更新，且与预期公式一致 - 部署一个 requests=allocatable.memory−100Mi 的测试 Pod，观察是否能成功调度并稳定运行 10 分钟以上
- 模拟压测：用 stress-ng 持续申请内存至接近 allocatable 上限，确认 kubelet 正确触发驱逐，且 ssh、docker ps 仍可响应（未假死）
