压测是峰值保障的前置动作
容器集群的承载能力并不是节点数量的简单相加。调度策略、镜像拉取、网络转发、存储挂载、监控采集等环节，都可能在压力上升时成为瓶颈。与其在业务峰值到来时被动响应，更稳妥的做法是提前开展压力测试，用可复现的数据验证集群在目标负载下的表现，再据此完成扩容与参数调优。
压测需要验证的几类能力
资源与调度
- 节点资源余量：CPU、内存、磁盘与临时存储在高负载下是否仍保留合理空间。
- 调度效率：大量 Pod 同时创建时，调度组件与 kubelet 的处理速度能否跟上扩容节奏。
- 配额设置合理性：不合理的 request/limit 会造成节点资源碎片化，或导致 Pod 频繁被驱逐。
网络与入口
- Service、Ingress 或网关在目标并发连接数与请求量下的转发能力与延迟表现。
- 东西向流量的连接复用、域名解析压力，以及网络插件在大规模 Pod 场景下的稳定性。
存储与依赖
- 镜像仓库的并发拉取能力，必要时配合镜像预热以缩短冷启动时间。
- 有状态服务所依赖的存储卷挂载与 IO 吞吐，是否与业务峰值相匹配。
弹性与自愈
- 弹性伸缩策略是否及时触发，是否会出现反复扩缩的抖动。
- 节点故障、Pod 驱逐等场景下的重建速度与业务可用性。
一次完整的压测大致包含哪些步骤
- 明确目标：把业务峰值换算成可量化的指标，例如并发数、请求量、单请求资源开销与可接受的响应时间。
- 准备环境：尽量在与生产一致的集群版本、节点规格与网络配置下进行，避免结论失真。
- 分级加压：从低负载逐级提升，观察各项指标的变化拐点，而不是一次性打到极限。
- 记录数据：同步采集集群侧与应用侧指标，便于定位瓶颈出现在哪一层。
- 复盘优化：针对暴露出的问题调整配置或架构，并复测验证。
从压测结果到扩容方案
压测的价值在于把“感觉够用”变成“有依据地留出余量”。制定扩容方案时，可以重点关注以下方面：
- 水位预留：根据压测得到的单副本承载能力，反推所需副本数与节点数，并为突发流量和节点故障保留缓冲。
- 扩容方式选择：无状态业务优先通过增加副本横向扩展；受限于单实例性能的场景，再考虑提升节点规格。
- 节点池规划：按业务类型划分节点池，减少不同负载之间的资源争抢。
- 弹性策略配合：在手动扩容的基础上配置自动伸缩，同时设置上下限，避免弹性策略本身成为新的不稳定因素。
- 容量与成本平衡：扩容并非越多越好，应结合业务峰值的持续时间，选择长期扩容或临时扩容。
常见误区
- 只压应用、不看集群：应用指标正常，但节点资源已接近上限。
- 用单次压测代替持续验证：业务版本与依赖组件变化后，历史结论可能不再适用。
- 忽略冷启动：新扩容出的 Pod 需要经历镜像拉取与预热，实际可承载时间晚于预期。
- 忽略下游依赖：集群扩容后，数据库、缓存、消息队列等能否承接同等增量。
与基础设施侧的协同
容器集群的扩容最终会落到计算、网络与带宽资源上。建议把压测结论同步到基础设施规划环节，提前确认机柜、电力、出口带宽与专线资源的可用余量，必要时与服务商沟通扩容窗口与交付周期，让集群扩容与机房侧准备同步推进，避免出现“集群已就绪、资源未到位”的情况。
