扩容到2个pod未提升TPS反而低于单pod，是什么原因导致的？

这种情况完全符合实际生产环境的常见表现，并非异常问题，核心原因是性能瓶颈并不在Pod副本数量上，且你本次扩容的核心目标本身就是高可用而非性能提升，没有获得TPS增益属于预期范围内的结果。

常见原因 #

• 上下游资源先于Pod达到瓶颈
  如果你的应用依赖数据库、缓存、第三方接口等外部服务，或者入口处的Ingress、负载均衡的带宽/处理能力已经被打满，新增的Pod根本拿不到更多的下游资源，反而会因为多Pod争抢连接、锁资源带来额外开销，最终导致总TPS不升反降。
• 流量分发策略异常
  如果负载均衡配置了会话保持策略，或者服务发现规则存在配置问题，测试流量可能全部被转发到其中一个Pod上，另一个Pod完全没有承接请求，相当于实际还是单Pod在处理流量，还额外增加了负载均衡的规则判断开销，导致TPS比纯单Pod场景更低。
• 测试负载未达到单Pod性能瓶颈
  你沿用了单Pod场景的相同测试配置，如果设置的并发请求数本身就在单Pod的处理能力范围内，新增的Pod没有需要处理的冗余请求，自然不会带来TPS提升，甚至会因为多了一层负载转发的开销，导致TPS轻微下降。
• 分布式额外开销抵消性能增益
  多Pod部署会引入服务发现、状态同步、分布式锁争抢等额外的分布式架构开销，如果单Pod还未到达性能瓶颈，这些新增开销甚至会超过多副本带来的性能增益，最终表现为总TPS下降。

排查与验证建议 #

• 先查看两个Pod的实时监控数据，确认CPU、内存、请求接收量是否基本均分，如果流量倾斜先调整负载均衡分发策略。
• 检查上下游依赖组件的资源使用率，确认是否存在数据库、缓存等组件先被打满的情况。
• 调高测试的并发请求数，当单Pod的CPU/内存使用率达到70%以上的瓶颈水位后，再对比单Pod和双Pod的TPS表现，如果此时双Pod TPS明显更高，说明之前的测试负载过低，没有触发副本扩容的性能增益效果。
• 如果你扩容的核心目标是高可用，只需要验证单Pod宕机时服务无中断、剩余Pod能承接全部流量且TPS符合业务要求，就已经达到了扩容目标，不需要强求双Pod TPS高于单Pod。

内容的提问来源于stack exchange，提问作者Marwa Mohamed Mahmoud