在一次內部JAVA服務審計中，我們發現一些請求沒有在Kube.NETes（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負載均衡器帶來明顯的性能開銷。
現在的Pod上的請求負載均衡
結論
定期進行徹底的服務審計是有益的，因為它可以揭示出未來對所有服務有益的優化點，并在解決那些本應該立即運行的功能的奇怪癥狀時為您節省時間。此外，花些時間查看文檔，測試，討論并了解在使用客戶端庫時關于連接設置和處理的默認設置的影響，以確保它們將按照您的預期行事。
