在Kubernetes中實現(xiàn)gRPC流量負載均衡

作者：Slagga 2023-10-27 12:36:37

云計算

云原生

后端 在嘗試將gRPC服務部署到Kubernetes集群中時，一些用戶（包括我）面臨的挑戰(zhàn)之一是實現(xiàn)適當?shù)呢撦d均衡。

萬安網(wǎng)站建設公司創(chuàng)新互聯(lián)公司,萬安網(wǎng)站設計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為萬安上千余家提供企業(yè)網(wǎng)站建設服務。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設要多少錢，請找那個售后服務好的萬安做網(wǎng)站的公司定做！

在嘗試將gRPC服務部署到Kubernetes集群中時，一些用戶（包括我）面臨的挑戰(zhàn)之一是實現(xiàn)適當?shù)呢撦d均衡。在深入了解如何平衡gRPC的方式之前，我們首先需要回答一個問題，即為什么需要平衡流量，如果Kubernetes已經(jīng)完成了這項工作。

本文關注于Kubernetes和Golang。

為什么在Kubernetes中無法適當?shù)仄胶鈍RPC流量？

之所以難以平衡gRPC流量的主要原因是人們將gRPC視為HTTP，這就是問題的根源。設計上它們是不同的，雖然HTTP為每個請求創(chuàng)建和關閉連接，但gRPC使用HTTP2協(xié)議，在長時間的TCP連接上運行，使得平衡更加困難，因為多個請求通過同一個連接進行多路復用。然而，這并不是配置gRPC服務在Kubernetes中出現(xiàn)平衡問題的唯一原因，以下是一些常見的錯誤配置：

• 錯誤的gRPC客戶端配置
• 錯誤的Kubernetes服務配置

錯誤的gRPC客戶端配置

設置gRPC客戶端時常見的情況是選擇默認配置，這對于1-1連接類型完全有效，但對于生產(chǎn)環(huán)境來說并不如我們所希望的有效。這背后的原因是因為默認的gRPC客戶端提供了使用簡單的IP/DNS記錄連接的可能性，這只會創(chuàng)建一個與目標服務的連接。

因此，需要為與多個服務器建立連接進行不同的設置，將連接類型從1-1轉(zhuǎn)換為1-N。

默認設置：

func main(){
  conn, err := grpc.Dial("my-domain:50051", grpc.WithInsecure())
  if err != nil {
    log.Fatalf("error connecting with gRPC server: %v", err)
  }
  
  defer conn.Close()
  cli := test.NewTestServiceClient(conn)
  rs, err := cli.DoSomething(context.Background(), ...)
  .
  .
  .
}

新的設置：

func main(){
  conn, err := grpc.Dial("my-domain:50051", grpc.WithInsecure())
  if err != nil {
    log.Fatalf("error connecting with gRPC server: %v", err)
  }
  
  defer conn.Close()
  cli := test.NewTestServiceClient(conn)
  rs, err := cli.DoSomething(context.Background(), ...)
  .
  .
  .
}

這里有兩個重要的更改需要注意：

• 地址： 最終解析的地址將類似于 dns:///my-domain:50051，之所以使用這種格式是因為Dial函數(shù)允許我們使用由Scheme://Authority/Endpoint組成的目標，而在我們的情況下，我跳過了Authority。因此，首先我添加了dns作為方案，因為我希望解析一個域并持續(xù)觀察其更改，解析器選項有透傳（默認）、dns和手動，更多詳情請參閱這里。
• 負載均衡器選項： 如果我們的客戶端現(xiàn)在連接到多個服務器，那么我們的gRPC客戶端可以根據(jù)所選擇的負載均衡算法平衡請求。

總結(jié)一下，我們的gRPC客戶端現(xiàn)在能夠創(chuàng)建不同的連接，前提是域名解析為多個A或AAAA記錄，而且不僅如此，現(xiàn)在還能夠?qū)⒄埱缶鶆虻胤峙涞讲煌姆掌鳌?/p>

現(xiàn)在讓我們看看如何讓它與Kubernetes一起工作的缺失部分。

錯誤的Kubernetes服務配置

在Kubernetes中創(chuàng)建服務非常簡單，我們只需要定義服務名稱、端口和選擇器，以便服務可以動態(tài)地將Pod分組并自動平衡請求，如下所示：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - name: grpc
      protocol: TCP
      port: 50051
      targetPort: 50051

那么，對于先前的設置，問題在于默認的Kubernetes服務只創(chuàng)建了一個DNS記錄，鏈接到單個IP。因此，當您執(zhí)行類似 nslookup my-service.{namespace}.svc.cluster.local 的操作時，返回的是一個單個IP，這使得在常見的gRPC實現(xiàn)中連接圖看起來像這樣：

例如，使用默認的Kubernetes服務的連接圖：

綠線表示與客戶端的活動連接，黃色表示未活動的Pod。客戶端與Kubernetes服務創(chuàng)建了持久連接，同時服務也與其中一個Pod創(chuàng)建了連接，但這并不意味著服務與其余的Pod沒有連接。

讓我們使用一個無頭服務來解決這個問題：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
 clusterIP: None **this is the key***
 selector:
    app: my-app
  ports:
    - name: grpc
      protocol: TCP
      port: 50051
      targetPort: 50051

創(chuàng)建了無頭服務后，nslookup看起來有些不同，現(xiàn)在它返回與之關聯(lián)的記錄（將Pod的IP分組到服務中），從而使gRPC客戶端更好地了解需要連接的服務器數(shù)量。

現(xiàn)在您已經(jīng)看到了gRPC客戶端的配置，您必須知道為什么Kubernetes服務返回與一組Pod關聯(lián)的IP非常重要。原因是客戶端可以看到所有需要建立連接的服務器。在這一點上，您可能已經(jīng)意識到了一個注意事項，即平衡的責任現(xiàn)在在客戶端部分，而不在Kubernetes的一側(cè)。我們現(xiàn)在需要從Kubernetes那里得到的主要任務是保持與服務關聯(lián)的Pod列表的最新狀態(tài)。

例如，在具有無頭Kubernetes服務的連接圖中，可以看到連接發(fā)生了一些變化，現(xiàn)在我們不通過Kubernetes服務來訪問Pod，而是使用Kubernetes服務來檢索與域名關聯(lián)的Pod列表，然后直接與Pod建立連接。但是不要因為直接連接到Pod而感到驚慌，因為我們在客戶端中設置了DNS解析器類型，該解析器將持續(xù)監(jiān)視與無頭服務的更改，并將與可用的Pod保持最新的連接。

為什么不使用服務網(wǎng)格？

如果可以的話，請使用服務網(wǎng)格，因為在服務網(wǎng)格中，所有這些設置都是透明的，而且最重要的是它是與編程語言無關的。關鍵區(qū)別在于服務網(wǎng)格利用了Sidecar模式和控制平面來編排入站和出站流量，還可以看到所有網(wǎng)絡和流量類型（HTTP、TCP等），從而能夠正確平衡請求。簡而言之，如果您不使用服務網(wǎng)格，那么您需要直接從每個客戶端連接到多個服務器，或者連接到一個L7代理來幫助平衡請求。

附加信息

盡管先前的設置可以工作，但我在嘗試在alpine Linux映像中進行Pod輪換或擴展時重新平衡連接時遇到了問題。經(jīng)過一些研究，我意識到我并不是唯一遇到這種問題的人，可以查看這里和這里的一些相關的GitHub問題。這就是為什么我決定創(chuàng)建自己的解析器的原因，您可以在這里查看我創(chuàng)建的自定義解析器，我創(chuàng)建的自定義解析器非常基礎，但現(xiàn)在可以正常工作，gRPC客戶端現(xiàn)在可以再次監(jiān)聽域名的更改，我還為該庫添加了一個可配置的監(jiān)聽器，它每隔一段時間查找域名并更新提供給gRPC連接管理器的IP集合，如果您想貢獻，歡迎加入。

另一方面，因為我想深入了解，所以我決定創(chuàng)建自己的gRPC代理（我也學到了很多東西），利用了gRPC的http2基礎，我可以創(chuàng)建一個代理，而無需更改proto負載消息或甚至不知道proto文件的定義（還使用了前面提到的自定義解析器）。

最后，我想說的是，如果您的gRPC客戶端需要與許多服務器連接，我強烈建議使用代理作為平衡的機制，因為將這個機制放在主應用程序中將增加復雜性和資源消耗，嘗試保持許多打開的連接并重新平衡它們，想象一下，如果最終的平衡在應用程序中，您將有一個與N個服務器連接的實例（1-N），但是使用代理，您將有一個與M個代理連接到N個服務器的實例（1-M-N），其中M
網(wǎng)站欄目：在Kubernetes中實現(xiàn)gRPC流量負載均衡
本文地址：http://m.5511xx.com/article/cococcp.html