这种情况并不在所有情况下都可见，因为它影响到多Pod服务，源Pod和目标Pod的数量不同。在本博文中，我将讨论我们采取的措施来负载均衡这组服务和Pod。
在我们的部署中，请求在Pod之间是如何均衡的？
两个源Pod向六个目标Pod发送请求。
可以清楚地看到请求分布在目标Pod之间存在不均衡。
但为什么会这样？
K8s负载均衡器（IPVS代理模式）的默认负载均衡调度程序设置为轮询（round robin）。IPVS提供了更多的选项来均衡流量到Pod后端。在测试这些选项时，我们发现当涉及到我们的服务时，不管配置如何，行为都相同，这些服务之间使用内部路由进行通信。
到底发生了什么？K8s中的IPVS根据连接来平衡流量，这在大多数情况下都表现得相当不错。我们的服务使用OkHttp作为相互通信的HTTP客户端。我们的问题与这个HTTP客户端的行为方式有关。使用默认配置，它会创建到服务器的连接，如果您不想在代码中显式关闭连接，因为这太昂贵，那么它会保持并重新建立到先前合作伙伴的连接。这意味着客户端尝试保持与目标的连接，并通过该特定连接发送请求。通常情况下，它会创建1:1的连接，这在K8s方面没有均衡。
该怎么办？
如果您需要扩展或希望使您的服务得到适当的负载均衡，您需要在客户端端更新配置。OkHttp提供了ConnectionPool功能。当使用ConnectionPool选项时，连接将在有限的时间段内建立，然后重复设置一个新的连接，因此IPVS可以进行负载均衡，因为它有大量的新连接，应该根据IPVS调度程序路由到目标。基本上，它的工作方式类似于机关枪而不是激光束。
我们在发布此更新后的效果如何？
使用更新的HTTP客户端和默认IPVS调度程序在多Pod服务之间实现了负载均衡的连接。
到底做了什么改变？
我们进行了大量的测试，使用各种配置来测量响应时间和性能开销，以确保负载均衡。下面是主要的代码更改，看起来没有明显的性能开销。
代码更改示例
有一个选项可以设置调度程序，以便能够并行发送更多的请求。在我们的情况下，这最终会建立一组最近关闭的连接，然后继续只使用一个连接。此外，我们试图防止过于频繁地打开新连接，因为执行请求比打开新连接要少要求得多。
结果如何？
网络和资源的使用现在比以前更加平衡 - 没有巨大或持续很长时间的峰值，也没有出现只影响部署中某些Pod的“嘈杂邻居”效应。现在几乎所有的Pod都以几乎相同的方式被利用，因此我们能够减少我们的部署中的Pod数量。我们知道这并不完美，但对于我们的用例来说已经足够好，因为它不会给服务或IPVS负载均衡器带来明显的性能开销。
现在的Pod上的请求负载均衡
结论
定期进行彻底的服务审计是有益的，因为它可以揭示出未来对所有服务有益的优化点，并在解决那些本应该立即运行的功能的奇怪症状时为您节省时间。此外，花些时间查看文档，测试，讨论并了解在使用客户端库时关于连接设置和处理的默认设置的影响，以确保它们将按照您的预期行事。
