wake-up-neo.com

gRPC-Lastausgleich

Ich habe die Seite zum Lastausgleich unter https://github.com/grpc/grpc/blob/master/doc/load-balancing.md zum Start gelesen, bin aber immer noch verwirrt, was den richtigen Ansatz für das Load-Balancing angeht zwischen den Back-End-GRPC-Instanzen. Wir implementieren mehrere gRPC-Instanzen "microservice" und möchten, dass unsere anderen gRPC-Clients zwischen ihnen geroutet werden können. Wir setzen diese als Pods in kubernetes (eigentlich Google Container Engine) ein.

Kann jemand den "empfohlenen" Ansatz zum Load-Balancing von gRPC-Clientanforderungen zwischen den gRPC-Servern erläutern? Es scheint, dass die Kunden über die Endpunkte informiert sein müssen. Ist es nicht möglich, den integrierten LoadBalancer in der Container-Engine zur Unterstützung zu nutzen?

kubernetesgoogle-container-enginegrpcgrpc-java
8
user3707

Ich kann nicht über kubernetes sprechen, aber bezüglich gRPC-Lastausgleich gibt es im Wesentlichen zwei Ansätze:

  1. In einfachen Anwendungsfällen können Sie Round-Robin für die Liste der Adressen aktivieren, die für einen bestimmten Namen zurückgegeben werden (dh die Liste der IP-Adressen, die für service.foo.com zurückgegeben werden). Die Vorgehensweise ist sprachabhängig. Für C++ würden Sie grpc::ChannelArguments::SetLoadBalancingPolicyName mit "round_robin" als Argument verwenden (in der Zukunft wäre es auch möglich, über " Dienstkonfiguration " auszuwählen, aber das Design dafür, wie diese Konfiguration in DNS-Einträgen zu kodieren, ist noch nicht abgeschlossen.
  2. Verwenden Sie das Protokoll Grpclb. Dies ist für komplexere Bereitstellungen geeignet. Diese Funktion erforderte den c-ares DNS-Resolver , den # 11237 einführt (dieser PR steht kurz vor dem Zusammenführen). Dies ist das Stück, das fehlt, damit Grpclb in Open Source funktioniert. Im Speziellen:
    • Schauen Sie sich dieses Dokument an. Es werden die DNS-Konfigurationsänderungen vorgenommen, die erforderlich sind, um zu steuern, welche Adressen als Balancer gekennzeichnet sind. Es ist derzeit ein "Vorschlag", der in Kürze zu einem Doc befördert werden soll. Es kann durchaus autoritativ genommen werden, es ist das, was # 11237 für die Balancer-Erkennung implementiert.
    • Schreiben Sie einen regulären gRPC-Server (in einer beliebigen Sprache), der das Load Balancer-Protokoll implementiert. Dies ist der Server, der in Ihren DNS-Einträgen als Balancer gekennzeichnet werden soll (wie in dem oben genannten Dokument beschrieben), mit dem die grpclb des Clients die Liste der Backend-Adressen abrufen wird (was Serverlisten ). Es liegt an Ihnen, die Logik in diesem Balancer so einfach oder so komplex zu gestalten, wie Sie möchten.
    • Der Client würde beim Erstellen eines Kanals den DNS-Namen des balancer verwenden. Beachten Sie auch, dass der DNS-Name Ihres Balancers auf mehrere Adressen verweisen kann. Wenn einer oder mehrere von ihnen als Balancer gekennzeichnet sind, wird grpclb verwendet. Welcher Balancer wird abgeholt, wenn es mehr als einen gibt? Der erste, mit dem sich der Client verbindet.

Lassen Sie mich wissen, wenn Sie Fragen haben.

8
David García Quintas

Wie von Samarendra erwähnt

Envoy , Ursprünglich in Lyft gebaut.

Es bietet erstklassige Unterstützung für HTTP/2 und gRPC für eingehende und ausgehende Verbindungen.

  • L7-Lastausgleich für gRPC
  • cluster Discovery Service (zB Konsul)

Wir haben envoy für unsere gRPC-Dienste bei gojek eingesetzt, was uns unter recht hoher Last gut tut. 

3
Mehak Kahlon

Für den Lastausgleich zwischen Grpc-Server wird der Standard-Lastausgleich von kubernates nicht hilfreich sein, da es sich um einen L4-Lastausgleich handelt. Sie würden L7-Lastausgleich benötigen.

Warum L7?

grpc verwendet http2, wobei die Verbindungen dauerhaft sind und die Anforderung über dieselbe Verbindung gesendet wird. Der L4-Lastausgleich wird mit TCP-Verbindungen ausgelastet. Sie benötigen jedoch einen Lastausgleich auf Anforderungsebene, sodass ein L7-Lastausgleich erforderlich ist. vor allem, wenn die Kommunikation zwischen GRPC-Servern erfolgt.

es gibt ein paar Optionen, Sie könnten Linkered/Envoy dafür verwenden, sie funktionieren gut mit kubernates und bieten auch ein gutes Service-Mesh.

um Ihre Dienste für die Außenarbeit verfügbar zu machen, können Sie den Ingh-Controller nghttpx und nghttpx verwenden.

sie können auch clientseitige Lastverteilung verwenden, aber ich sehe darin keinen guten Nutzen.

1
Samarendra

Vielleicht möchten Sie nghttpx und die nghttpx Ingress Controller - Projekte überprüfen. Diese Projekte ermöglichen den L7-Lastausgleich für HTTP/2-Streams.

Unter https://cloud.google.com/endpoints/docs/architecture-overview finden Sie weitere Informationen zum Endpoint Management, das in der Google Cloud Platform enthalten ist.

0
MarkNS

Wenn in AWS/ECS ein https://aws.Amazon.com/blogs/aws/new-network-load-balancer-effortless-scaling-to-millions-of-requests-per-second/ funktionieren wird Robin Verbindungen zwischen Ihren Zielgruppen abzurunden.

Sie müssen etwas tun, um die Gesundheitsprüfung anzuhören, die NLBs nur in HTTP1 ausführen können. Sie können auch Ihr eigenes SSL kündigen.

0
jdwyah