直接回答：容量规划的锚点是 requests：调度按 requests 装箱，节点可分配的 requests 总和决定能放多少 Pod。超卖指 limits 总和超过节点物理资源——CPU 超卖相对安全（超了只是限速争抢），内存超卖危险（超了 OOM 杀进程）。经验基线：在线服务 CPU limits 总和可到核数的 2~4 倍（看流量相关性），内存 limits 总和控制在物理内存的 90% 内，且关键服务 Guaranteed。
展开解析：规划流程：先用历史监控（Prometheus 的 container 用量 P95）校准 requests 的水位，requests 虚高是集群利用率低的第一元凶（VPA recommendation 模式可以先只出建议）；再按业务增长曲线与未来半年峰值（大促按峰值打 1.2~1.5 系数）推算节点规模；节点规格选择上少量大节点优于大量小节点（系统 DaemonSet 与内核保留的固定摊销更低、装箱碎片更少），但爆炸半径与 Pod 密度上限（每节点 110 Pod 默认）要权衡。碎片化是隐性问题：requests 粒度不齐导致节点上“凑不出一个整块”，CA 弹不出新节点而扩容 Pending，统一几档 requests 规格能缓解。持续运营：把集群装箱率（requests 总和/可分配总和）与实际利用率（usage/requests）做成看板，前者超 80% 触发扩容采购，后者低于 30% 推动 requests 治理。
追问方向：装箱率高但实际利用率低说明什么？突发型负载怎么做容量缓冲？
（约 480 字）