集群容量规划（计算器）

"我们要建一套 100 张卡的训练集群" —— 这句话到能交给采购的配置单之间，有一串账要算。

这一节把账算清楚。核心结论会有点反直觉：决定集群能跑多少 Pod 的，往往不是 CPU 和内存。

第一刀：可分配不等于容量

一台 64 核 512 GiB 的机器，调度器看到的不是 64 核 512 GiB。中间被切掉三刀：

节点容量 Capacity
 ├─ system-reserved      留给 sshd、systemd 这些系统进程
 ├─ kube-reserved        留给 kubelet、容器运行时
 ├─ eviction-threshold   留给驱逐缓冲，默认 memory.available<100Mi
 └─ Allocatable          ← 调度器真正能分配的只有这一块

# 亲眼看一下这两个数的差距
kubectl get node <node> -o jsonpath='{.status.capacity}'
kubectl get node <node> -o jsonpath='{.status.allocatable}'

云厂商普遍采用一套分段公式来定预留量 —— 越大的机器预留比例越低，因为系统开销并不随规格线性增长：

第二刀：四条限制，最小的那条说话

算出单节点可分配资源之后，能跑多少 Pod 由四条限制里最小的那条决定：

这四条里，后两条是规划失误才会撞上的，而它们恰恰是最难改的：maxPods 要重启 kubelet，节点子网掩码改不了。

第三刀：控制面要多大

控制面的压力不来自业务流量，而来自节点数与对象数 —— apiserver 要缓存所有对象，etcd 要承受所有写入。

用计算器把账走一遍

下面这个计算器把上面三刀都实现了。左边改参数，右边会直接告诉你第一个撞上的限制是哪条 —— 这比总数更有用。

三个预设值得都点一遍，它们各自暴露一类典型问题：

• 通用业务集群 —— 常规配置，看看可分配比例
• GPU 训练集群 —— 注意每卡摊到多少 CPU，这个数决定数据加载会不会成为瓶颈
• 高密度小 Pod —— 资源还剩一大半，但 maxPods 已经封顶

GPU 集群的额外一笔账

GPU 集群有个容易漏的数：每张卡摊到多少 CPU 和内存。

训练任务里 GPU 负责算，但数据的读取、解码、增强都在 CPU 上。CPU 不够，GPU 就在等数据 —— 表现是 GPU 利用率上不去，而所有人第一反应都是去查网络和存储。

经验区间：

交付一份容量方案要写清的几件事

1. 节点规格与数量，以及可分配资源（不是容量）
2. 单节点 Pod 密度，以及它受限于哪一条 —— 这句话必须写出来
3. Pod CIDR 与每节点掩码，以及这套网段的规模上限和余量
4. 控制面规格，以及 etcd 盘的验收结论
5. GPU 集群补充：每卡摊到的 CPU 与内存
6. 扩容路径：加到多少台会撞上网段上限，撞上之后怎么办