CPU 很低、请求仍然排队可能是业务偏向网络处理也可能是节点网卡、连接跟踪或外部依赖已经成为瓶颈。此时“换成 PPS 指标扩容”只解决了指标选择尚未解决容量问题。HPA 可以看什么不能保证什么Kubernetes HPA 文档明确支持通过autoscaling/v2使用自定义与外部指标。把原生 HPA 说成只懂 CPU、内存是不准确的。接入 PPS 或队列指标仍需匹配的指标适配器、稳定的资源标签和正确的聚合口径。例如业务总 PPS 除以副本数适合描述每副本负载节点 NIC 的 PPS 却可能包含同节点其他租户。把节点总量复制到每个 Pod 上再让控制器求和会把同一份负载重复计算。2026年10月6日的 cgroup v2 资源控制说明也提醒我们区分 requests、limits 与内核实际执行机制。CPU、内存的资源控制不能直接替代网卡带宽预留Pod 能被调度成功也不等于网络还有余量。先算需求再输出受约束的建议以下模型假定负载在副本间均匀分摊单位始终是 PPS。节点可用槽位来自外部容量盘点示例不声称能用一个通用公式算出 NIC 的真实瓶颈。from math import ceil, isfinite def plan(total_pps, target_pps, current, free_slots): values (total_pps, target_pps) if not all(isfinite(v) for v in values): raise ValueError(non-finite metric) if total_pps 0 or target_pps 0 or current 1 or free_slots 0: raise ValueError(invalid input) desired max(1, ceil(total_pps / target_pps)) if desired current free_slots: return {desired: desired, action: review_node_capacity} return {desired: desired, action: review_pod_scaling} assert plan(90000, 20000, 3, 1)[action] review_node_capacity assert plan(60000, 20000, 2, 2)[desired] 3 try: plan(float(nan), 20000, 2, 2) except ValueError: pass else: raise AssertionError(NaN must not produce a scaling decision) print(plan(90000, 20000, 3, 1))算出五个副本现有节点只容得下四个就应提示容量核查而不是反复修改副本数。反过来副本足够而连接集中在少数长连接上也要检查负载均衡与连接分布不能期待新 Pod 自动接走已有连接。若加入前瞻预测应把预测量与已观测负载分开标记用历史滚动回放验证提前量不能用预测值覆盖当前采集结果。本文的计划函数只使用已给定负载没有训练预测器。控制器需要慢一点的刹车真实接入前应测量指标延迟、聚合窗口、启动就绪时间与缩容扰动。用回放数据观察峰值经过多久才被采集、决策和调度预留足够的余量扩缩容的稳定窗口也要单独设计。超过某个 PPS 值不足以证明扩容一定能改善 P99。代码只验证容量建议与非法输入处理未运行 Kubernetes、指标适配器、网络压测或节点扩容。最后的落点是两张图Pod 负载分布与节点网络余量。两张图没有对齐以前先别让 Agent 把“网络拥塞”翻译成无休止地加副本。