許多剛剛接觸gRPC用戶或是剛剛把gRPC服務部署到kubernetes中感到驚訝的是，發現Kubernetes的默認負載均衡通常無法與gRPC一起使用。例如，當您使用一個簡單的gRPC Node.js微服務應用程序并將其部署在Kubernetes上時，將發生以下情況：

盡管此處顯示的服務具有多個Pod，但從Kubernetes的CPU圖形可以清楚地看到，只有一個Pod實際上正在執行所有工作-因為只有一個Pod正在接收任何流量。為什么？

gRPC使用性能增強的HTTP/2協議。 HTTP/2具備更低的延遲的特點，其實是通過利用單個長期存在的TCP連接并在其上多路復用請求/響應。這會給第4層（L4）負載均衡器帶來問題，因為它們的級別太低，無法根據接收到的流量類型做出路由決策。這樣，嘗試對HTTP/2流量進行負載均衡的L4負載均衡器將打開一個TCP連接，并將所有連續的流量路由到該相同的長期連接，從而實際上取消了負載均衡。

Kubernetes的kube-proxy本質上是一個L4負載均衡器，因此我們不能依靠它來均衡微服務之間的gRPC調用。

gRPC負載均衡方式

實際上gRPC負載均衡有以下兩種實現方式：

• Proxy（代理負載均衡在某些文獻中也稱為服務器端負載均衡）
• Client side

在代理負載均衡與客戶端負載均衡之間進行選擇其實是結構的選擇。在代理負載均衡中，客戶端將RPC發送給負載均衡器（LB）代理。 LB將RPC調用分發到實現了實際服務調用邏輯的可用后端服務器之一。 LB跟蹤每個后端的負載，并實現用于公平分配負載的算法。客戶端本身不了解后端服務器。客戶可能不受信任。此體系結構通常用于面向用戶的服務，開放式Internet的客戶端可以將其連接到數據中心中的服務器，如下圖所示。在這種情況下，客戶端向LB（＃1）發出請求。 LB將請求傳遞給后端之一（＃2），后端將報告加載到LB（＃3）。

在客戶端負載均衡中，客戶端知道多個后端服務器，并為每個RPC選擇一個。客戶端從后端服務器獲取負載報告，并且客戶端實施負載均衡算法。在更簡單的配置中，不考慮服務器負載，客戶端只能在可用服務器之間進行輪詢。如下圖所示。如您所見，客戶端向特定后端（＃1）發出請求。后端通常在執行客戶端RPC的同一連接上以負載信息（＃2）進行響應。客戶端然后更新其內部狀態。

下邊是兩種模式的對比分析：

ProxyClient Side優勢客戶端可以專心業務邏輯，無需感知后端，與不受信任的客戶端一起使用高性能，因為少了一層代理劣勢延遲更高，LB吞吐量可能會限制可伸縮性客戶端變復雜，客戶端跟蹤服務器的負載和運行狀況，客戶端實現負載均衡算法，每個語言的實現和維護負擔，客戶端需要被信任，或者信任邊界需要由后備LB處理。

為什么不選擇客戶端負載均衡方式？

使用gRPC客戶端負載均衡器，該負載均衡器被嵌入到gRPC客戶端庫中。這樣，每個客戶端微服務都可以執行自己的負載均衡。但是，最終的客戶非常脆弱，需要大量的自定義代碼來提供任何形式的彈性，指標或日志記錄，所有這些我們都需要針對管道中使用的每種不同語言重復多次。

而且在云原生時代，整個基礎架構升級，表現為

• 越來越多的公司采用了kubernetes
• 以istio為代表的service mesh服務治理方案成為一個趨勢
• dapper的出現，代表著不斷將基礎架構的功能放到代理層執行，減小基礎架構組件升級對業務代碼的影響

選擇代理的負載均衡模式，對于擁抱云原生的公司更加有意義和可拓展性。

我們真正需要的是更智能的負載均衡器。

選擇更智能的復雜均衡代理

我們需要第7層（L7）負載均衡器，因為它們在應用程序層運行，并且可以檢查流量以做出路由決策。最重要的是，它們可以支持HTTP/2協議。

L7負載均衡器有很多不同的選項，包括NGINX和HAProxy，但事實證明，大多數選項太過沉重，無法輕松加入我們的微服務架構。我們將選擇權縮減為兩個關鍵競爭者-Envoy和Linkerd。兩者都是在考慮微服務架構的情況下開發的，并且都支持gRPC。

雖然兩個代理都有許多理想的功能，但我們最終的決定權還是取決于代理的范圍。為此，有一個明顯的贏家。特使很小。它使用C ++ 11編寫，沒有基于Java的Linkerd附帶的企業級功能。

確定Envoy之后，我們便開始深入研究其功能集，并且有很多值得一看的地方。

Envoy由Lyft編寫和開源，是多年來與通常在微服務體系結構中發生的復雜路由問題作斗爭的直接結果。它實質上是為解決我們的問題而設計的，并且具有：

• 雙向均支持HTTP/2和SSL
• 高透明度和出色的性能
• 成熟的文檔集
• 不依賴任何給定的語言

而且新版本的envoy將會支持wasm，意味著未來的很多擴展可以直接使用你熟悉的語言來完成，而且具備原生的性能。

使Envoy適應我們的基礎架構

在您的架構中，如果暫時沒有使用service mesh。可以采取下面的方案。

在Kubernetes中，一組一個或多個容器被稱為Pod。可以復制Pod以提供擴展，并封裝在稱為服務的抽象中，這些抽象為訪問基礎Pod提供了穩定的IP地址。從Kubernetes 1.2開始，請求服務IP的默認行為是將返回一個隨機的后端Pod。但是，您可以將服務重新配置為headless的，以便服務IP將返回可用的pod IP的整個列表，從而使您能夠執行自己的服務發現。

Envoy被設計為作為Sidecar容器運行，并與客戶端容器并排放置，以模塊化的方式補充了其功能。在Kubernetes中，這轉換為在同一容器中運行客戶端容器和Envoy容器。我們將服務配置為headless的，以便為Envoy提供端點以用于服務發現。而且由于Envoy輸出了大量指標，因此我們能夠輕松觀察到連續gRPC調用的循環負載均衡，以確認其按預期運行。

最終效果如下：

當然最終的方案是service mesh。除了可以解決gRPC負載均衡的問題，會帶來更多的優勢。

總結

以上是生活随笔為你收集整理的网页加载出现没有合适的负载均衡器_gRPC实战--Kubernetes中使用envoy负载均衡gRPC流量...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。