复核集群容量余量

概述

分配的 requests 看起来宽裕，直到某个节点消失。余量是集群可调度容量与峰值需求之间的差值，还要包含失去一个节点或一个可用区的场景。缺少定期复核时，新服务不断增加 requests、自动扩缩容上限却不变，余量会悄悄消失。

步骤

1. 记录每个节点的可分配 CPU 与内存，而不是实例规格：

kubectl get nodes -o custom-columns='NODE:.metadata.name,CPU:.status.allocatable.cpu,MEM:.status.allocatable.memory'

2. 查看每个节点的已分配 requests，找出最接近饱和的节点：

kubectl describe node node-1 | sed -n '/Allocated resources/,/Events/p'

3. 汇总所有 Pod 的内存 requests，与“总可分配减去最大节点”比较，判断 N-1 场景是否仍能调度。
4. 记录结论，并按需调整节点池、autoscaler 上限或副本数。

验证

预期能得到每个节点的分配百分比和全集群 requests 总量，并明确给出 N-1 后是否仍有 30% 余量的结论。抽查一个 Pending 事件，确认原因是 requests 碎片、污点还是拓扑约束，而不是简单归因于节点不足。

注意事项

• requests 是调度预留而非实际使用，requests 安全不代表真实负载下安全。
• N-1 计算需要考虑可用区分布和拓扑约束，实际可用容量可能更低。
• CPU 可压缩，内存压力会导致驱逐，内存余量应更保守。
• 扩容还受账户配额、IP 耗尽和节点组上限限制，必须确认 autoscaler 真能达到最大值。