Containernatives Load-Balancing

Containernatives Load-Balancing ermöglicht es verschiedenen Load-Balancern, Pods direkt anzusteuern und Traffic gleichmäßig auf Pods zu verteilen.

Für das containernative Load-Balancing wird ein Datenmodell mit dem Namen Netzwerk-Endpunktgruppen (NEGs) genutzt. Dies sind Sammlungen von Netzwerkendpunkten, die durch IP-Port-Paare dargestellt werden.

Wenn NEGs mit GKE Ingress verwendet werden, erleichtert der Ingress-Controller das Erstellen aller Aspekte des L7-Load-Balancers. Dazu gehören das Erstellen der virtuellen IP-Adresse, Weiterleitungsregeln, Systemdiagnosen, Firewallregeln usw.

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 L7-Load-Balancers verantwortlich.

Vorteile

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 containernativem Load-Balancing haben Sie Einblick in die Umlaufzeit vom Client zum HTTP(S)-Load-Balancer und außerdem Stackdriver-UI-Unterstützung. Dies vereinfacht die Behebung von Dienstfehlern auf NEG-Ebene.
Unterstützung für erweiterte Load-Balancing-Features
Containernatives Load-Balancing bietet native Unterstützung in Google Kubernetes Engine für verschiedene Funktionen des HTTP(S)-Load-Balancings, unter anderem die Einbindung in Google Cloud-Dienste wie Google Cloud Armor, Cloud CDN und Identity-Aware Proxy. Außerdem stehen Load-Balancing-Algorithmen zur genauen Verteilung des Traffics zur Verfügung.
Unterstützung für Traffic Director
Das NEG-Datenmodell muss Traffic Director verwenden, die vollständig verwaltete Traffic-Steuerungsebene der 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.

Bei containernativem Load-Balancing durch eingehenden Traffic werden automatisch Pod-Readiness-Gates für folgende Cluster aktiviert:

  • v1.13-GKE-Cluster mit v1.13.8 und höher
  • v1.14-GKE-Cluster mit v1.14.4 und höher
  • v1.15 und höher

Mit Readiness-Gates wird die Rate von Rolling Updates gesteuert. Bei den oben aufgeführten GKE-Versionen werden automatisch Readiness-Gates zu den Pods hinzugefügt. 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. Daher 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.

Anforderungen

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

Google Kubernetes Engine v1.13.8 oder v1.14.4

Containernative Load-Balancer sind für folgende Cluster allgemein verfügbar:

  • v1.13-GKE-Cluster mit v1.13.8 und höher
  • v1.14-GKE-Cluster mit v1.14.4 und höher
VPC nativ

Damit containernatives Load-Balancing verwendet werden kann, müssen Cluster VPC-nativ sein. Weitere Informationen finden Sie unter VPC-native Cluster mithilfe von Alias-IP-Adressen erstellen.

HTTP-Load-Balancing

Damit Sie das containernative Load-Balancing verwenden können, muss für den Cluster das HTTP-Load-Balancing aktiviert sein. Für GKE-Cluster ist das HTTP-Load-Balancing standardmäßig aktiviert. Sie dürfen es nicht deaktivieren.

Beschränkungen

Containernative Lastenausgleichsmodule funktionieren nicht mit Legacy-Netzwerken.

Einschränkungen

Containernative Load-Balancer unterstützen keine internen TCP/UDP-Load-Balancer oder Netzwerk-Load-Balancer.

Preise

Es wird Ihnen der HTTP(S)-Load-Balancer berechnet, 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