谁能给我解释一下为什么当我在一个pod上运行负载测试时，它会提供更好的TPS，而不是扩展到两个pod。
我期望在两个pod上运行相同配置的相同场景时，TPS会增加，但事实并非如此。
横向扩展不能提高请求总数，这是正常的行为吗?
请注意，我在一个pod上没有遇到任何故障，只是扩展到2个以获得高可用性。
如果您正在使用任何类型的数据库，那么这就是优化以提高TPS的地方。原因如下:
假设你的数据库运行得尽可能快——pod可以处理网络连接和对数据库的查询，但是数据库很慢，因为CPU/内存/TPS已经达到最大值;增加pod 1的TPS量不会增加您的TPS，因为DB TPS是限制因素。
现在，如果你添加pod 2，你的DB仍然已经达到了CPU/内存/TPS的上限，但是现在它必须使用一些CPU，它之前使用来完成事务，管理来自pod 2的DB连接，这些连接必须排队，直到DB的CPU/内存可以处理它们;最终降低DB的TPS和整个应用的TPS。
TLDR:如果你的数据库是最大的，添加pod来对它进行事务处理会降低TPS，因为DB必须使用正在积极处理事务的资源(TPS的限制因素)来处理排队的DB连接。
要解决这个问题，垂直扩展你的写数据库，水平扩展你的读数据库，用索引或更好的查询优化DB事务，使用PGBouncer管理DB连接，并确保你的DB事务类型对你的用例是最有效的。
这取决于你的pod做了什么。正如@spencer提到的。除此之外，还有很多因素会影响你的期望:
- 你的pod有leader选举吗? QPS/Burst设置(控制器，因为我不知道你的pod做了什么)。
- …
根据你的情况，我猜你的舱不是TPS的限制因素。
基本上增加荚果的复制至少不会降低TPS。
...my load test on one pod it gives better TPS rather than when scaling to two pods.
当两个pod竞争相同的资源并产生瓶颈时，就会发生这种情况。
Is this normal behaviour that scaling horizontal not improve the total number of requests?
客户端(web)请求可以改进，但后端(有时也包括中间件)的容量需要跟上。