中興AX5400Pro+上手體驗(yàn)：再升級 雙2.5G網(wǎng)口+USB 3.0這次全都有
2021年11月的時(shí)候，中興先后發(fā)布了兩款路由器產(chǎn)品，中興AX5400和中興AX5400 Pro，從產(chǎn)品命名上就不難看出這是隸屬于同一系列的，但在外觀設(shè)計(jì)上這兩款產(chǎn)品可以說是完全沒一點(diǎn)關(guān)系
在嘗試將gRPC服務(wù)部署到Kubernetes集群中時(shí)，一些用戶（包括我）面臨的挑戰(zhàn)之一是實(shí)現(xiàn)適當(dāng)?shù)呢?fù)載均衡。在深入了解如何平衡gRPC的方式之前，我們首先需要回答一個(gè)問題，即為什么需要平衡流量，如果Kubernetes已經(jīng)完成了這項(xiàng)工作。
本文關(guān)注于Kubernetes和Golang。
之所以難以平衡gRPC流量的主要原因是人們將gRPC視為HTTP，這就是問題的根源。設(shè)計(jì)上它們是不同的，雖然HTTP為每個(gè)請求創(chuàng)建和關(guān)閉連接，但gRPC使用HTTP2協(xié)議，在長時(shí)間的TCP連接上運(yùn)行，使得平衡更加困難，因?yàn)槎鄠€(gè)請求通過同一個(gè)連接進(jìn)行多路復(fù)用。然而，這并不是配置gRPC服務(wù)在Kubernetes中出現(xiàn)平衡問題的唯一原因，以下是一些常見的錯(cuò)誤配置：
設(shè)置gRPC客戶端時(shí)常見的情況是選擇默認(rèn)配置，這對于1-1連接類型完全有效，但對于生產(chǎn)環(huán)境來說并不如我們所希望的有效。這背后的原因是因?yàn)槟J(rèn)的gRPC客戶端提供了使用簡單的IP/DNS記錄連接的可能性，這只會(huì)創(chuàng)建一個(gè)與目標(biāo)服務(wù)的連接。
因此，需要為與多個(gè)服務(wù)器建立連接進(jìn)行不同的設(shè)置，將連接類型從1-1轉(zhuǎn)換為1-N。
默認(rèn)設(shè)置：
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(), ...) . . .}新的設(shè)置：
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(), ...) . . .}這里有兩個(gè)重要的更改需要注意：
總結(jié)一下，我們的gRPC客戶端現(xiàn)在能夠創(chuàng)建不同的連接，前提是域名解析為多個(gè)A或AAAA記錄，而且不僅如此，現(xiàn)在還能夠?qū)⒄埱缶鶆虻胤峙涞讲煌姆?wù)器。
現(xiàn)在讓我們看看如何讓它與Kubernetes一起工作的缺失部分。
在Kubernetes中創(chuàng)建服務(wù)非常簡單，我們只需要定義服務(wù)名稱、端口和選擇器，以便服務(wù)可以動(dòng)態(tài)地將Pod分組并自動(dòng)平衡請求，如下所示：
apiVersion: v1kind: Servicemetadata: name: my-servicespec: selector: app: my-app ports: - name: grpc protocol: TCP port: 50051 targetPort: 50051那么，對于先前的設(shè)置，問題在于默認(rèn)的Kubernetes服務(wù)只創(chuàng)建了一個(gè)DNS記錄，鏈接到單個(gè)IP。因此，當(dāng)您執(zhí)行類似 nslookup my-service.{namespace}.svc.cluster.local 的操作時(shí)，返回的是一個(gè)單個(gè)IP，這使得在常見的gRPC實(shí)現(xiàn)中連接圖看起來像這樣：
例如，使用默認(rèn)的Kubernetes服務(wù)的連接圖：
綠線表示與客戶端的活動(dòng)連接，黃色表示未活動(dòng)的Pod。客戶端與Kubernetes服務(wù)創(chuàng)建了持久連接，同時(shí)服務(wù)也與其中一個(gè)Pod創(chuàng)建了連接，但這并不意味著服務(wù)與其余的Pod沒有連接。
讓我們使用一個(gè)無頭服務(wù)來解決這個(gè)問題：
apiVersion: v1kind: Servicemetadata: name: my-servicespec: clusterIP: None **this is the key*** selector: app: my-app ports: - name: grpc protocol: TCP port: 50051 targetPort: 50051創(chuàng)建了無頭服務(wù)后，nslookup看起來有些不同，現(xiàn)在它返回與之關(guān)聯(lián)的記錄（將Pod的IP分組到服務(wù)中），從而使gRPC客戶端更好地了解需要連接的服務(wù)器數(shù)量。
現(xiàn)在您已經(jīng)看到了gRPC客戶端的配置，您必須知道為什么Kubernetes服務(wù)返回與一組Pod關(guān)聯(lián)的IP非常重要。原因是客戶端可以看到所有需要建立連接的服務(wù)器。在這一點(diǎn)上，您可能已經(jīng)意識(shí)到了一個(gè)注意事項(xiàng)，即平衡的責(zé)任現(xiàn)在在客戶端部分，而不在Kubernetes的一側(cè)。我們現(xiàn)在需要從Kubernetes那里得到的主要任務(wù)是保持與服務(wù)關(guān)聯(lián)的Pod列表的最新狀態(tài)。
例如，在具有無頭Kubernetes服務(wù)的連接圖中，可以看到連接發(fā)生了一些變化，現(xiàn)在我們不通過Kubernetes服務(wù)來訪問Pod，而是使用Kubernetes服務(wù)來檢索與域名關(guān)聯(lián)的Pod列表，然后直接與Pod建立連接。但是不要因?yàn)橹苯舆B接到Pod而感到驚慌，因?yàn)槲覀冊诳蛻舳酥性O(shè)置了DNS解析器類型，該解析器將持續(xù)監(jiān)視與無頭服務(wù)的更改，并將與可用的Pod保持最新的連接。
如果可以的話，請使用服務(wù)網(wǎng)格，因?yàn)樵诜?wù)網(wǎng)格中，所有這些設(shè)置都是透明的，而且最重要的是它是與編程語言無關(guān)的。關(guān)鍵區(qū)別在于服務(wù)網(wǎng)格利用了Sidecar模式和控制平面來編排入站和出站流量，還可以看到所有網(wǎng)絡(luò)和流量類型（HTTP、TCP等），從而能夠正確平衡請求。簡而言之，如果您不使用服務(wù)網(wǎng)格，那么您需要直接從每個(gè)客戶端連接到多個(gè)服務(wù)器，或者連接到一個(gè)L7代理來幫助平衡請求。
盡管先前的設(shè)置可以工作，但我在嘗試在alpine Linux映像中進(jìn)行Pod輪換或擴(kuò)展時(shí)重新平衡連接時(shí)遇到了問題。經(jīng)過一些研究，我意識(shí)到我并不是唯一遇到這種問題的人，可以查看這里和這里的一些相關(guān)的GitHub問題。這就是為什么我決定創(chuàng)建自己的解析器的原因，您可以在這里查看我創(chuàng)建的自定義解析器，我創(chuàng)建的自定義解析器非常基礎(chǔ)，但現(xiàn)在可以正常工作，gRPC客戶端現(xiàn)在可以再次監(jiān)聽域名的更改，我還為該庫添加了一個(gè)可配置的監(jiān)聽器，它每隔一段時(shí)間查找域名并更新提供給gRPC連接管理器的IP集合，如果您想貢獻(xiàn)，歡迎加入。
另一方面，因?yàn)槲蚁肷钊肓私猓晕覜Q定創(chuàng)建自己的gRPC代理（我也學(xué)到了很多東西），利用了gRPC的http2基礎(chǔ)，我可以創(chuàng)建一個(gè)代理，而無需更改proto負(fù)載消息或甚至不知道proto文件的定義（還使用了前面提到的自定義解析器）。
最后，我想說的是，如果您的gRPC客戶端需要與許多服務(wù)器連接，我強(qiáng)烈建議使用代理作為平衡的機(jī)制，因?yàn)閷⑦@個(gè)機(jī)制放在主應(yīng)用程序中將增加復(fù)雜性和資源消耗，嘗試保持許多打開的連接并重新平衡它們，想象一下，如果最終的平衡在應(yīng)用程序中，您將有一個(gè)與N個(gè)服務(wù)器連接的實(shí)例（1-N），但是使用代理，您將有一個(gè)與M個(gè)代理連接到N個(gè)服務(wù)器的實(shí)例（1-M-N），其中M<N，因?yàn)槊總€(gè)代理實(shí)例可以處理與不同服務(wù)器的許多連接。
本文鏈接：http://www.tebozhan.com/showinfo-26-15439-0.html在Kubernetes中實(shí)現(xiàn)gRPC流量負(fù)載均衡
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)