为什么要先压测再扩容

很多团队在Kubernetes集群出现资源告急时，第一反应是“加节点”。但在没有摸清单节点真实承载能力之前，扩容数量只能靠估算，容易出现两种浪费：一种是加得过多，节点长期低负载，成本居高不下；另一种是加得过少，Pod频繁被驱逐或Pending，业务仍然抖动。压力测试的价值，就是用一个可复现的方法回答一个问题：在当前业务负载特征下，一个节点到底能稳定承载多少工作负载？有了这个上限，扩容节点数量才有依据。

压测前需要明确的三个边界

1. 节点的可分配资源边界

节点总资源不等于可调度资源。kubelet、容器运行时、系统进程会占用CPU和内存，节点还会预留eviction阈值。压测时应记录Allocatable而非Capacity，并观察系统组件在高负载下的资源占用变化。忽略这部分差异，往往会让计划中的“剩余容量”被高估。

2. 业务负载的形态边界

不同业务的压力特征差异很大：CPU密集型、内存常驻型、高并发短连接型、IO密集型，对节点的消耗方式完全不同。压测负载应尽量贴近真实业务的requests/limits比例、Pod密度、网络模型和存储访问模式，否则得到的上限只适用于压测脚本本身。

3. 稳定性与故障容忍边界

“跑得起来”不等于“跑得稳”。需要事先定义可接受的指标区间，例如调度延迟、Pod启动时间、API Server响应延迟、网络丢包与重传、节点负载水位等。超出这些区间的临界点，才是真正可用于规划的节点上限。

一次可落地的压测流程

1. 固定基线环境：保持节点规格、K8s版本、CNI/CSI插件、内核参数一致，避免不同批次节点混测导致结果不可比。
2. 分级加压：从低负载起步，按固定步长逐步增加Pod数量或并发请求量，每级压力下保持足够长的稳态观察时间。
3. 采集指标：同时采集节点层（CPU、内存、磁盘IO、网络带宽、load average）、K8s层（调度成功率、Pending Pod数、驱逐事件、API延迟）和业务层（P95/P99延迟、错误率、吞吐）指标。
4. 找到临界点：当某一项关键指标开始非线性恶化，或出现驱逐、调度失败、超时时，记录此时的Pod密度与资源使用量，作为该负载模型下的节点上限。
5. 留出安全余量：建议在实际规划中按临界值的一定比例折算，为业务波峰、滚动发布、节点故障迁移预留空间。
6. 形成容量基线：把结果沉淀为“每节点可承载XX个标准业务Pod”或“每节点可支撑XX QPS”的基线，作为后续扩缩容输入。

从节点上限推导扩容节点数

得到单节点上限后，扩容计算可以简化为三个步骤：

• 估算目标负载：按业务峰值而非平均值计算总资源需求，并考虑未来一段时间的增长系数。
• 扣除现有可用容量：现有集群中已使用但未充分利用的资源、预留资源都应纳入计算，避免重复扩容。
• 按上限与安全水位折算：用目标负载除以单节点可承载容量，再按安全水位取整，同时考虑节点故障时的N+1冗余需求。

需要强调的是，扩容不仅是数量问题，也涉及节点规格选择。如果压测发现瓶颈出现在单节点网络带宽或本地磁盘IO，单纯增加节点数量未必能解决问题，可能需要调整实例规格或拆分负载类型。

压测结果如何持续复用

容量基线不是一次性结论。业务代码迭代、中间件版本升级、CNI插件更换、内核参数调整，都可能改变单节点承载能力。建议在以下场景重新执行或复核压测：

• 业务架构或流量模型发生明显变化；
• 集群组件、运行时或节点镜像大版本升级；
• 引入新的存储、网络或可观测性组件；
• 节点规格更换或新增不同规格的节点池。

把压测脚本、指标看板和容量基线一并纳入运维资产，扩容决策就能从“经验判断”转向“数据驱动”，既控制成本，也保障业务稳定性。