Kubernetes使用OkHttp客户端进行网络负载均衡

在一次内部Java服务审计中，我们发现一些请求没有在Kubernetes（K8s）网络上正确地实现负载均衡。导致我们深入研究的问题是HTTP 5xx错误率的急剧上升，由于CPU使用率非常高，垃圾收集事件的数量很多以及超时，但这仅发生在一些特定的Pod中。这种情况并不在所有情况下都可见，因为它影响到多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负载均衡器带来明显的性能开销。