Containernatives Load-Balancing

Auf dieser Seite wird erläutert, was containernatives Load-Balancing in Google Kubernetes Engine (GKE) ist. Containernatives Load-Balancing ermöglicht es verschiedenen Load-Balancern, Pods direkt anzusteuern und Traffic gleichmäßig auf Pods zu verteilen.

Architektur von containernativem Load-Balancing

Containernatives Load-Balancing verwendet GCE_VM_IP_PORT-Netzwerk-Endpunktgruppen (NEGs). Die Endpunkte der NEG sind Pod-IP-Adressen.

Das containernative Load-Balancing wird immer für das interne GKE-Ingress verwendet und ist für das externe Ingress optional. Der Ingress-Controller erstellt den Load-Balancer, einschließlich der virtuellen IP-Adresse, Weiterleitungsregeln, Systemdiagnosen und Firewallregeln.

Informationen zur Verwendung des containernativen Load-Balancing mit Ingress finden Sie unter Containernatives Load-Balancing über Ingress.

Sie können auch eigenständige NEGs erstellen, um die Flexibilität zu erhöhen. In diesem Fall sind Sie für das Erstellen und Verwalten aller Aspekte des Load-Balancers verantwortlich.

Vorteile von containernativem Load-Balancing

Das containernative Load-Balancing bietet folgende Vorteile:

Pods sind Kernobjekte für das Load-Balancing.
kube-proxy konfiguriert die iptables-Regeln von Knoten, um Traffic an Pods zu verteilen. Ohne containernatives Load-Balancing wird der Load-Balancer-Traffic erst an die Knoteninstanzgruppen und dann über iptables-Regeln an Pods weitergeleitet, die sich im selben Knoten befinden können, aber nicht müssen. Mit containernativem Load-Balancing wird der Load-Balancer-Traffic direkt an die Pods verteilt, die den Traffic empfangen sollen. Damit fällt der zusätzliche Netzwerk-Hop weg. Containernatives Load-Balancing verbessert außerdem Systemdiagnosen, da Pods direkt angesteuert werden.

Vergleich des Standardverhaltens (links) mit containernativem Verhalten von Load-Balancern
Verbesserte Netzwerkleistung
Da der containernative Load-Balancer direkt mit den Pods kommuniziert und Verbindungen mit weniger Netzwerk-Hops auskommen, werden sowohl Latenz als auch Durchsatz verbessert.
Bessere Übersicht
Mit dem containernativen Load-Balancing haben Sie Einblick in die Latenz des Anwendungs-Load-Balancers zu Pods. Sichtbar ist die Latenz vom Application Load Balancer zu jedem Pod, der mit dem node-IP-basierten Container-nativen Load-Balancing aggregiert wurde. Dies vereinfacht die Behebung von Dienstfehlern auf NEG-Ebene.
Unterstützung für erweiterte Load-Balancing-Features
Das containernative Load-Balancing in GKE unterstützt mehrere Features externer Anwendungs-Load-Balancer, z. B. die Einbindung in Google Cloud-Dienste wie.Google Cloud Armor ,Cloud CDN undIdentity-Aware Proxy. eine Außerdem stehen Load-Balancing-Algorithmen zur genauen Verteilung des Traffics zur Verfügung.
Unterstützung für Cloud Service Mesh
Das NEG-Datenmodell ist erforderlich, um Cloud Service Mesh zu verwenden. Vollständig verwaltete Traffic-Steuerungsebene von Google Cloud für Service Mesh

Pod-Bereitschaft

Für relevante Pods verwaltet der entsprechende Ingress-Controller ein Readiness-Gate vom Typ cloud.google.com/load-balancer-neg-ready. Der Ingress-Controller fragt den Status der Systemdiagnose des Load-Balancers ab, einschließlich der Zustände aller Endpunkte in der NEG. Wenn der Status der Systemdiagnose des Load-Balancers anzeigt, dass der einem bestimmten Pod entsprechende Endpunkt fehlerfrei ist, setzt der Ingress-Controller den Wert des Readiness-Gates des Pods auf True. Das Kubelet, das auf jedem Knoten ausgeführt wird, berechnet dann die tatsächliche Bereitschaft des Pods. Dafür wird sowohl der Wert des Readiness-Gates berücksichtigt als auch die Bereitschaftsprüfung des Pods, sofern diese definiert wurde.

Pod-Readiness-Gates werden bei Verwendung von containernativem Load-Balancing über Ingress automatisch aktiviert.

Mit Readiness-Gates wird die Rate von Rolling Updates gesteuert. Wenn Sie ein Rolling Update initiieren, wird für jeden neuen, von GKE erstellten Pod ein Endpunkt zu einer NEG hinzugefügt. Wenn der Endpunkt aus der Sicht des Load-Balancers fehlerfrei ist, setzt der Ingress-Controller das Readiness-Gate auf True. Es muss mindestens das Readiness-Gate des neu erstellten Pods den Status "True" haben, bevor GKE einen alten Pod entfernt. Dadurch wird sichergestellt, dass der dem Pod entsprechende Endpunkt bereits die Systemdiagnose des Load-Balancers bestanden hat und dass die Back-End-Kapazität beibehalten wird.

Wenn das Readiness-Gate eines Pods aufgrund eines fehlerhaften Container-Images oder einer falsch konfigurierten Load-Balancer-Systemdiagnose nicht angibt, dass der Pod bereit ist, leitet der Load-Balancer keinen Traffic an den neuen Pod weiter. Tritt ein solcher Fehler beim Einführen eines aktualisierten Deployments auf, wird die Einführung nach dem Versuch, einen neuen Pod zu erstellen, angehalten, da das Readiness-Gate dieses Pods nie den Status "True" aufweist. Informationen dazu, wie Sie herausfinden können, ob dieses Problem vorliegt und wie Sie es beheben können, finden Sie im Abschnitt "Fehlerbehebung".

Ohne containernatives Load-Balancing und Readiness-Gates kann GKE nicht feststellen, ob die Endpunkte eines Load-Balancers fehlerfrei sind, bevor GKE die entsprechenden Pods als bereit markiert. Bei älteren Kubernetes-Versionen haben Sie die Rate, mit der Pods entfernt und ersetzt werden, gesteuert, indem Sie in der Deployment-Spezifikation mit minReadySeconds eine Verzögerung angegeben haben.

GKE setzt den Wert von cloud.google.com/load-balancer-neg-ready für einen Pod auf True, wenn eine der folgenden Bedingungen erfüllt ist:

  • Keine der IP-Adressen des Pods ist ein Endpunkt, der in einer GCE_VM_IP_PORT-NEG gespeichert ist, die von der GKE-Steuerungsebene verwaltet wird.
  • Eine oder mehrere IP-Adressen des Pods sind Endpunkte in einer GCE_VM_IP_PORT-NEG, die von der GKE-Steuerungsebene verwaltet wird. Die NEG ist mit einem Backend-Dienst verknüpft. Der Backend-Dienst hat eine erfolgreiche Systemdiagnose für den Load-Balancer.
  • Eine oder mehrere IP-Adressen des Pods sind Endpunkte in einer GCE_VM_IP_PORT-NEG, die von der GKE-Steuerungsebene verwaltet wird. Die NEG ist mit einem Backend-Dienst verknüpft. Bei der Systemdiagnose des Load-Balancers für den Backend-Dienst tritt eine Zeitüberschreitung auf.
  • Eine oder mehrere IP-Adressen des Pods sind Endpunkte in einer oder mehreren GCE_VM_IP_PORT-NEGs. Keine der NEGs ist an einen Backend-Dienst angehängt. Es sind keine Daten zur Load-Balancer-Systemdiagnose verfügbar.

Sitzungsaffinität

Containernatives Load-Balancing unterstützt Pod-basierte Sitzungsaffinität.

Anforderungen für die Verwendung von containernativem Load-Balancing

Für containernative Load-Balancer über eingehenden Traffic in GKE gelten folgende Anforderungen:

  • Der Cluster muss VPC-nativ sein.
  • Für den Cluster muss das Add-on HttpLoadBalancing aktiviert sein. Für GKE-Cluster ist das Add-on HttpLoadBalancing standardmäßig aktiviert. Sie sollten es nicht deaktivieren.

Einschränkungen für containernative Load-Balancer

Für containernative Load-Balancer über eingehenden Traffic in GKE gelten folgende Einschränkungen:

  • Unterstützen Sie keine externen Passthrough-Netzwerk-Load-Balancer.
  • Sie dürfen die Konfiguration des von GKE erstellten Anwendungs-Load-Balancers nicht manuell ändern oder aktualisieren. Alle vorgenommenen Änderungen werden von GKE überschrieben.

Preise für containernative Load-Balancer

Es wird Ihnen der Anwendungs-Load-Balancer in Rechnung gestellt, der von der Ingress-Ressource bereitgestellt wird, die Sie in dieser Anleitung erstellen. Informationen zu Load-Balancer-Preisen finden Sie auf der Seite „VPC-Preise“ unter Load-Balancing und Weiterleitungsregeln.

Nächste Schritte