LoadBalancer-Dienstkonzepte

Mit diesem Dokument erhalten Sie eine allgemeine Übersicht über die Erstellung und Verwaltung von Google Cloud-Load-Balancern in Google Kubernetes Engine (GKE), wenn Sie ein Manifest für Kubernetes-LoadBalancer-Dienste anwenden. Es beschreibt die verschiedenen Arten von Load-Balancern und wie Einstellungen wie externalTrafficPolicy und GKE-Teileinstellung für interne L4-Load-Balancer bestimmen, wie die Load-Balancer konfiguriert werden.

Machen Sie sich vor dem Lesen dieses Dokuments mit den GKE-Netzwerkkonzepten vertraut.

Übersicht

Wenn Sie einen LoadBalancer-Dienst erstellen, konfiguriert GKE einen Google Cloud-Passthrough-Load-Balancer, dessen Eigenschaften von Parametern Ihres Dienstmanifest abhängen.

Load-Balancer-Dienst auswählen

Berücksichtigen Sie bei der Auswahl der zu verwendenden LoadBalancer-Dienstkonfiguration die folgenden Aspekte:

  • Der Typ der IP-Adresse des Load-Balancers. Der Load-Balancer kann eine interne oder externe IP-Adresse haben.
  • Die Anzahl und der Typ der Knoten, die der Load-Balancer unterstützt.

Nachdem Sie Ihre Anforderungen an die Netzwerkarchitektur ermittelt haben, können Sie anhand des folgenden Entscheidungsbaums bestimmen, welcher LoadBalancer-Dienst für Ihre Netzwerkkonfiguration ausgewählt werden soll.

Ein LoadBalancer-Dienst in GKE kann eine interne oder externe Adresse haben.
Abbildung: LoadBalancer-Dienst-Entscheidungsbaum

Externes oder internes Load-Balancing

Wenn Sie einen LoadBalancer-Dienst in GKE erstellen, geben Sie an, ob der Load-Balancer eine interne oder externe Adresse hat:

  • Wenn sich Ihre Clients im selben VPC-Netzwerk oder in einem Netzwerk befinden, das mit dem VPC-Netzwerk des Clusters verbunden ist, verwenden Sie einen internen LoadBalancer-Dienst. Interne LoadBalancer-Dienste werden mithilfe von internen Passthrough-Network Load Balancern implementiert. Clients, die sich im selben VPC-Netzwerk befinden oder mit dem VPC-Netzwerk des Clusters verbunden haben, können über die IP-Adresse des Load Balancers auf den Dienst zugreifen.

    Zum Erstellen eines internen LoadBalancer-Dienstes fügen Sie eine der folgenden Annotationen in die metadata.annotations[] des Dienstmanifests ein:

    • networking.gke.io/load-balancer-type: "Internal" (GKE 1.17 und höher)
    • cloud.google.com/load-balancer-type: "Internal" (Versionen vor 1.17)

  • Wenn sich Ihre Clients außerhalb des VPC-Netzwerks befinden, verwenden Sie einen externen LoadBalancer-Dienst. Sie können einen der folgenden Arten von externen Network Load Balancern verwenden, auf die im Internet zugegriffen werden kann (einschließlich Google Cloud-VMs mit Internetzugang):

Effekt von externalTrafficPolicy

Sie können externalTrafficPolicy auf Local oder Cluster festlegen, um zu definieren, wie Pakete an Knoten mit Bereitschafts- und Bereitstellungs-Pods weitergeleitet werden. Beachten Sie beim Definieren von externalTrafficPolicy die folgenden Szenarien:

  • Verwenden Sie externalTrafficPolicy: Local, um die ursprünglichen Client-IP-Adressen beizubehalten oder Unterbrechungen zu minimieren, wenn sich die Anzahl der Knoten ohne Pod-Bereitstellung im Cluster ändert.

  • Verwenden Sie externalTrafficPolicy: Cluster, wenn die Gesamtzahl der Knoten ohne Bereitstellungs-Pods in Ihrem Cluster konsistent bleibt, aber die Anzahl der Knoten mit Bereitstellungs-Pods ändert. Die ursprüngliche Client-IP-Adresse wird bei dieser Option nicht beibehalten.

Weitere Informationen dazu, wie sich externalTrafficPolicy auf das Paketrouting innerhalb der Knoten auswirkt, finden Sie unter Paketverarbeitung.

GKE-Teilmengeneinstellung

Die clusterweite Konfigurationsoption GKE-Teileinstellung für interne L4-Load-Balancer, oder GKE-Teileinstellung, verbessert die Skalierbarkeit interner Passthrough-Network Load Balancer durch effizientere Gruppierung von Knotenendpunkten für die Load Balancer-Back-Ends.

Das folgende Diagramm zeigt zwei Dienste in einem zonalen Cluster mit drei Knoten und aktivierter GKE-Teileinstellung. Jeder Dienst hat zwei Pods. GKE erstellt für jeden Dienst eine GCE_VM_IP-Netzwerk-Endpunktgruppe (NEG). Endpunkte in jeder NEG sind die Knoten mit den Bereitstellungs-Pods für den jeweiligen Dienst.

Sie können die GKE-Teileinstellung aktivieren, wenn Sie einen Cluster erstellen oder einen vorhandenen Cluster bearbeiten. Nach der Aktivierung kann die GKE-Teileinstellung nicht mehr deaktiviert werden. Weitere Informationen finden Sie unter GKE-Teileinstellung.

Für die GKE-Teileinstellung ist Folgendes erforderlich:

  • GKE-Version 1.18.19-gke.1400 oder höher.
  • Das HttpLoadBalancing-Add-on muss für den Cluster aktiviert sein. Dieses Add-on ist standardmäßig aktiviert. Der Cluster kann dann Load-Balancer verwalten, die Backend-Dienste verwenden.

Berücksichtigung der Knotenanzahl bei Aktivierung der GKE-Teileinstellung

Als Best Practice sollten Sie die GKE-Teileinstellung aktivieren, wenn Sie interne LoadBalancer-Dienste erstellen müssen. Mit der GKE-Teileinstellung können Sie mehr Knoten in Ihrem Cluster unterstützen:

  • Wenn die GKE-Teileinstellung deaktiviert ist, sollten Sie nicht mehr als 250 Knoten erstellen (unter allen Knotenpools). Wenn Sie mehr als 250 Knoten im Cluster erstellen, kann es bei internen LoadBalancer-Diensten zu einer ungleichmäßigen Traffic-Verteilung oder einem vollständigen Verbindungsverlust kommen.

  • Wenn für Ihren Cluster die GKE-Teileinstellung aktiviert ist, können Sie entweder externalTrafficPolicy: Local oder externalTrafficPolicy: Cluster verwenden, solange die Anzahl der eindeutigen Knoten mit mindestens einem Bereitstellungs-Pod Maximal 250 Knoten beträgt. Knoten ohne Bereitstellungs-Pod sind nicht relevant. Wenn Sie mehr als 250 Knoten mit mindestens einem Bereitstellungs-Pod benötigen, müssen Sie externalTrafficPolicy: Cluster verwenden.

Von GKE erstellte interne Passthrough-Network Load Balancer können Pakete nur auf 250 oder weniger Backend-Knoten-VMs verteilen. Diese Einschränkung besteht, da GKE keine Backend-Teileinstellung des Load-Balancers verwendet. Ein interner Passthrough-Network Load Balancer ist auf die Verteilung von Paketen auf 250 oder weniger Backends beschränkt, wenn die Backend-Teileinstellung des Load Balancers deaktiviert ist.

Knotengruppierung

Die Dienstmanifestannotationen und – für den internen LoadBalancer-Dienst – der Status der GKE-Teileinstellung bestimmen den resultierenden Google Cloud-Load-Balancer und den Typ der Back-Ends. Back-Ends für Passthrough-Load-Balancer von Google Cloud identifizieren die Netzwerkschnittstelle (NIC) des GKE-Knotens, nicht eine bestimmte Knoten- oder Pod-IP-Adresse. Der Typ des Load-Balancers und der Back-Ends bestimmen, wie Knoten in GCE_VM_IP-NEGs, Instanzgruppen oder Zielpools gruppiert werden.

GKE-LoadBalancer-Dienst Daraus resultierender Google Cloud-Load-Balancer Methode der Knotengruppierung
Interner LoadBalancer-Dienst, der in einem Cluster mit aktivierter GKE-Teileinstellung erstellt wurde1 Ein interner Passthrough-Network Load Balancer, dessen Backend-Dienst GCE_VM_IP-NEG-Backends (Network Endpoint Group) verwendet

Knoten-VMs werden zonal in GCE_VM_IP-NEGs pro Dienst gruppiert gemäß der externalTrafficPolicy des Dienstes und der Anzahl der Knoten im Cluster.

Die externalTrafficPolicy des Dienstes steuert auch, welche Knoten die Load-Balancer-Systemdiagnose und die Paketverarbeitung bestehen.

Interner LoadBalancer-Dienst, der in einem Cluster mit deaktivierter GKE-Teileinstellung erstellt wurde Ein internen Passthrough-Network Load Balancer, dessen Backend-Dienst zonal nicht verwaltete Instanzgruppen-Backends verwendet

Alle Knoten-VMs werden in zonal nicht verwaltete Instanzgruppen platziert, die GKE als Backends für den Backend-Dienst des Network Load Balancers verwendet.

Der externalTrafficPolicy des Diensts steuert, welche Knoten die Load-Balancer-Systemdiagnose und die Paketverarbeitung bestehen.

Dieselben nicht verwalteten Instanzgruppen werden für andere Backend-Dienste des Load-Balancers verwendet, die aufgrund der Beschränkung für Instanzgruppen mit einzelnem Load-Balancing im Cluster erstellt wurden.
Externer LoadBalancer-Dienst mit der Annotation cloud.google.com/l4-rbs: "enabled"2 Ein Backend-Dienst-basierter externer Passthrough-Network Load Balancer, dessen Backend-Dienst zonal nicht verwaltete Instanzgruppen-Backends verwendet

Alle Knoten-VMs werden in zonal nicht verwaltete Instanzgruppen platziert, die GKE als Backends für den Backend-Dienst des Network Load Balancers verwendet.

Der externalTrafficPolicy des Diensts steuert, welche Knoten die Load-Balancer-Systemdiagnose und die Paketverarbeitung bestehen.

Dieselben nicht verwalteten Instanzgruppen werden für andere Backend-Dienste des Load-Balancers verwendet, die aufgrund der Beschränkung für Instanzgruppen mit einzelnem Load-Balancing im Cluster erstellt wurden.
Externer LoadBalancer-Dienst ohnecloud.google.com/l4-rbs: "enabled" Anmerkung3 Zielpoolbasierter externer Passthrough-Network Load Balancer, dessen Zielpool alle Knoten des Clusters enthält

Der Zielpool ist eine Legacy-API, die nicht auf Instanzgruppen angewiesen ist. Alle Knoten haben eine direkte Mitgliedschaft im Zielpool.

Der externalTrafficPolicy des Diensts steuert, welche Knoten die Load-Balancer-Systemdiagnose und die Paketverarbeitung bestehen.

1 Nur die internen Passthrough-Network Load Balancer, die nach der Aktivierung der GKE-Teilmenge erstellt wurden, verwenden GCE_VM_IP-NEGs. Alle internen LoadBalancer-Dienste, die vor der Aktivierung der GKE-Teilmengeneinstellung erstellt wurden, verwenden weiterhin nicht verwaltete Instanzgruppen-Back-Ends. Beispiele und Anleitungen zur Konfiguration finden Sie unter Interne LoadBalancer-Dienste erstellen.

2 GKE migriert vorhandene externe LoadBalancer-Dienste nicht automatisch von zielpoolbasierten externen Passthrough-Network Load Balancern zu Backend-Dienst-basierten externen Passthrough-Network Load Balancern. Um einen externen LoadBalancer-Dienst zu erstellen, der von einem Backend-Dienst-basierten Network Load Balancer unterstützt wird, müssen Sie die Annotation cloud.google.com/l4-rbs: "enabled" in das Dienstmanifest zum Zeitpunkt der Erstellung aufnehmen.

3 Wenn Sie die Annotation cloud.google.com/l4-rbs: "enabled" aus einem vorhandenen externen LoadBalancer-Dienst entfernen, der von einem Backend-Dienst-basierten externen Passthrough-Network Load Balancer bereitgestellt wird, erstellt GKE keinen zielpoolbasierter externer Passthrough-Network Load Balancer. Wenn Sie einen externen LoadBalancer-Dienst erstellen möchten, der von einem zielpoolbasierten Passthrough-Network Load Balancer bereitgestellt wird, müssen Sie die Annotation cloud.google.com/l4-rbs: "enabled" aus dem Dienstmanifest zum Zeitpunkt der Erstellung weglassen.

Knotenmitgliedschaft in GCE_VM_IP-NEG-Back-Ends

Wenn die GKE-Teileinstellung für einen Cluster aktiviert ist, erstellt GKE in jeder Zone für jeden internen LoadBalancer-Dienst eine eindeutige GCE_VM_IP-NEG. Im Gegensatz zu Instanzgruppen können Knoten Mitglieder von mehr als einer GCE_VM_IP-NEG mit Load-Balancing sein. Der externalTrafficPolicy des Dienstes und die Anzahl der Knoten im Cluster bestimmen, welche Knoten den Endpunkten GCE_VM_IP des Dienstes als Endpunkte hinzugefügt werden.

Die Steuerungsebene des Clusters fügt Knoten zu den GCE_VM_IP-NEGs als Endpunkte gemäß dem Wert der externalTrafficPolicy des Dienstes und der Anzahl der Knoten im Cluster hinzu, wie in der folgenden Tabelle zusammengefasst.

externalTrafficPolicy Anzahl der Knoten im Cluster Endpunktmitgliedschaft
Cluster 1 bis 25 Knoten GKE verwendet alle Knoten im Cluster als Endpunkte für die NEGs des Dienstes, auch wenn ein Knoten keinen Bereitstellungs-Pod für den Dienst enthält.
Cluster Mehr als 25 Knoten GKE verwendet eine zufällige Teilmenge von bis zu 25 Knoten als Endpunkte für die NEGs des Dienstes, auch wenn ein Knoten keinen Bereitstellungs-Pod für den Dienst enthält.
Local Beliebig viele Knoten1 GKE verwendet nur Knoten, die mindestens einen der Bereitstellungs-Pods des Dienstes haben, als Endpunkte für die NEGs des Dienstes.

1 Beschränkt auf 250 Knoten mit Bereitstellungs-Pods für interne LoadBalancer-Dienste. Mehr als 250  Knoten können im Cluster vorhanden sein, aber interne Passthrough-Network Load Balancer werden nur auf 250 Backend-VMs verteilt, wenn die Backend-Teileinstellung des internen Passthrough-Network Load Balancers deaktiviert ist. Auch wenn die GKE-Teileinstellung aktiviert ist, konfiguriert GKE nie interne Netzwerk-Passthrough-Network Load Balancer mit der Backend-Teileinstellung des Network Load Balancers. Weitere Informationen zu diesem Limit finden Sie unter Maximale Anzahl von VM-Instanzen pro internem Backend-Dienst.

Beschränkung einer einzelnen Instanzgruppe mit Load-Balancing

Die Compute Engine API verhindert, dass VMs Mitglieder von mehr als einer Instanzgruppe mit Load-Balancing sind. GKE-Knoten unterliegen dieser Einschränkung.

Bei Verwendung von nicht verwalteten Instanzgruppen-Back-Ends erstellt oder aktualisiert GKE nicht verwaltete Instanzgruppen, die alle Knoten aus allen Knotenpools in jeder Zone enthalten, die der Cluster verwendet. Diese nicht verwalteten Instanzgruppen werden verwendet für:

  • Interne Passthrough-Network Load Balancer, die für interne LoadBalancer-Dienste erstellt werden, wenn die GKE-Teileinstellung deaktiviert ist
  • Backend-Dienst-basierte externe Passthrough-Network Load Balancer für externe LoadBalancer-Dienste mit der cloud.google.com/l4-rbs: "enabled"-Annotation
  • Externe Application Load Balancer, die für externe GKE-Ingress-Ressourcen erstellt wurden, den GKE-Ingress-Controller verwenden, aber kein containernatives Load-Balancing nutzen.

Da Knoten-VMs keine Mitglieder von mehr als einer Instanzgruppe mit Load-Balancing sein können, kann GKE keine internen Passthrough-Network Load Balancer, Backend-Dienst-basierten externen Network Load Balancer und externen Application Load Balancer für GKE-Ingress-Ressourcen erstellen und verwalten, wenn eine der folgenden Bedingungen true ist:

  • Außerhalb von GKE haben Sie mindestens einen Backend-Dienst-basierten Load-Balancer erstellt und die verwalteten Instanzgruppen des Clusters als Backends für den Backend-Dienst des Load-Balancers verwendet.
  • Außerhalb von GKE erstellen Sie eine benutzerdefinierte nicht verwaltete Instanzgruppe, die einige oder alle Knoten des Clusters enthält, und hängen diese benutzerdefinierte nicht verwaltete Instanzgruppe dann an einen Backend-Dienst für einen Load-Balancer an.

Zur Umgehung dieser Einschränkung können Sie GKE anweisen, nach Möglichkeit NEG-Back-Ends zu verwenden:

  • Aktivieren Sie die GKE-Teileinstellung. Daher verwenden neue interne LoadBalancer-Dienste stattdessen GCE_VM_IP-NEGs.
  • Konfigurieren Sie externe GKE-Ingress-Ressourcen für das Verwenden von containernativem Load-Balancing. Weitere Informationen finden Sie unter Containernatives GKE-Load-Balancing.

Load-Balancer-Systemdiagnosen

Für alle GKE-LoadBalancer-Dienste ist eine Systemdiagnose erforderlich. Die Systemdiagnose des Load-Balancers wird außerhalb des Clusters implementiert und unterscheidet sich von einer Bereitschafts- oder Aktivitätsprüfung.

Die externalTrafficPolicy des Diensts definiert, wie die Systemdiagnose des Load-Balancers funktioniert. In allen Fällen senden die Systemdiagnosetests des Load-Balancers Pakete an die Software kube-proxy, die auf jedem Knoten ausgeführt wird. Die Systemdiagnose des Load-Balancers ist ein Proxy für Informationen, die vom kube-proxy erfasst werden, z. B. ob ein Pod vorhanden ist, ausgeführt wird und die Bereitschaftsprüfung bestanden hat. Systemdiagnosen für LoadBalancer-Dienste können nicht an Bereitstellungs-Pods weitergeleitet werden. Die Systemdiagnose des Load-Balancers ist so konzipiert, dass neue TCP-Verbindungen an Knoten weitergeleitet werden.

In der folgenden Tabelle wird das Verhalten der Systemdiagnose beschrieben:

externalTrafficPolicy Welche Knoten die Systemdiagnose bestehen Welcher Port verwendet wird
Cluster Alle Knoten des Clusters bestehen die Systemdiagnose auch dann, wenn der Knoten keine Bereitstellungs-Pods hat. Wenn auf einem Knoten ein oder mehrere Bereitstellungs-Pods vorhanden sind, besteht der Knoten die Systemdiagnose des Load-Balancers auch dann, wenn die Bereitstellungs-Pods beendet werden oder die Bereitschaftsprüfungen nicht bestehen. Der Systemdiagnose-Port des Load-Balancers muss der TCP-Port 10256 sein. Er kann nicht angepasst werden.
Local

Nur die Knoten mit mindestens einem Bereitschafts-, nicht-beendenden Bereitstellungs-Pod bestehen die Systemdiagnose des Load-Balancers. Knoten ohne einen Bereitstellungs-Pod, Knoten, deren Bereitstellungs-Pods die Bereitschaftsprüfungen nicht bestehen, und Knoten, deren Bereitstellungs-Pods alle beendet werden, bestehen die Systemdiagnose des Load-Balancers nicht.

Während Statusübergängen besteht ein Knoten weiterhin die Systemdiagnose des Load-Balancers, bis der Fehlerschwellenwert des Load-Balancers erreicht ist. Der Übergangsstatus tritt auf, wenn alle Bereitstellungs-Pods auf einem Knoten die Bereitschaftsprüfungen nicht zu bestehen beginnen oder wenn alle Bereitstellungs-Pods auf einem Knoten beendet werden. Wie das Paket in dieser Situation verarbeitet wird, hängt von der GKE-Version ab. Weitere Informationen finden Sie im nächsten Abschnitt Paketverarbeitung.

 Der Port für die Systemdiagnose ist der TCP-Port 10256, sofern Sie keinen benutzerdefinierten Port für die Systemdiagnose angeben.

Paketverarbeitung

In den folgenden Abschnitten wird beschrieben, wie der Load-Balancer und die Clusterknoten arbeiten, um für LoadBalancer-Dienste empfangene Pakete weiterzuleiten.

Passthrough-Load-Balancing

Der Passthrough-Load-Balancer von Google Cloud leitet Pakete an die nic0-Schnittstelle der Knoten des GKE-Clusters weiter. Jedes von einem Knoten empfangene Paket mit Load-Balancing hat die folgenden Eigenschaften:

  • Die Ziel-IP-Adresse des Pakets entspricht der IP-Adresse der Weiterleitungsregel des Load-Balancers.
  • Der Protokoll- und Zielport des Pakets stimmen mit beiden überein:
    • ein Protokoll und einen Port, die in den spec.ports[] des Servicemanifests angegeben sind
    • ein Protokoll und einen Port, die in der Weiterleitungsregel des Load-Balancers konfiguriert sind

Zielnetzwerkadressübersetzung auf Knoten

Nachdem der Knoten das Paket empfangen hat, führt der Knoten eine zusätzliche Paketverarbeitung durch. In GKE-Clustern ohne aktiviertes GKE Dataplane V2 verwenden Knoten iptables, um Pakete mit Load-Balancing zu verarbeiten. In GKE-Clustern mit aktivierter GKE Dataplane V2 verwenden Knoten stattdessen eBPF. Die Paketverarbeitung auf Knotenebene umfasst immer die folgenden Aktionen:

  • Der Knoten führt DNAT für das Paket aus und legt seine Ziel-IP-Adresse auf eine Bereitstellungs-Pod-IP-Adresse fest.
  • Der Knoten ändert den Zielport des Pakets in den targetPort der entsprechenden spec.ports[] des Dienstes.

Quellnetzwerkadressübersetzung auf Knoten

Die externalTrafficPolicy bestimmt, ob die Paketverarbeitung auf Knotenebene auch eine Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) sowie den Pfad ausführt, den das Paket vom Knoten zum Pod nimmt:

externalTrafficPolicy Knoten-SNAT-Verhalten Routingverhalten
Cluster Der Knoten ändert die Quell-IP-Adresse von Paketen mit Load-Balancing, damit sie mit der IP-Adresse des Knotens übereinstimmt, der ihn vom Load-Balancer empfangen hat.

Der Knoten leitet Pakete an einen beliebigen Bereitstellungs-Pod weiter. Der Bereitstellungs-Pod kann sich auf demselben Knoten befinden.

Wenn dem Knoten, der die Pakete vom Load-Balancer empfängt, kein Pod zur Bereitstellung vorhanden ist, leitet der Knoten die Pakete an einen anderen Knoten weiter, der einen Pod enthält, der einsatzbereit ist. Antwortpakete vom Pod werden von seinem Knoten zurück an den Knoten weitergeleitet, der die Anfragepakete vom Load-Balancer erhalten hat. Dieser erste Knoten sendet dann die Antwortpakete mithilfe von Direct Server Return an den ursprünglichen Client.
Local Der Knoten ändert nicht die Quell-IP-Adresse von Paketen mit Load-Balancing.

In den meisten Fällen leitet der Knoten das Paket an einen Bereitstellungs-Pod weiter, der auf dem Knoten ausgeführt wird, der das Paket vom Load-Balancer empfangen hat. Dieser Knoten sendet Antwortpakete mit Direct Server Return an den ursprünglichen Client. Dies ist der primäre Intent dieser Art von Trafficrichtlinie.

In einigen Situationen empfängt ein Knoten Pakete vom Load-Balancer, obwohl dem Knoten ein bereiter, nicht-terminierender Bereitstellungs-Pod für den Dienst fehlt. Diese Situation tritt auf, wenn die Systemdiagnose des Load-Balancers noch nicht den Fehlerschwellenwert erreicht hat, aber ein zuvor bereiter und bereitstellender Pod nicht mehr bereit ist oder beendet wird (z. B. bei einem Rolling Update). der Wie die Pakete in dieser Situation verarbeitet werden, hängt ab von der GKE-Version, davon, ob der Cluster GKE Dataplane V2 verwendet, und vom Wert von externalTrafficPolicy:

  • Ohne GKE Dataplane V2 ist in GKE 1.26 und höher und mit GKE Dataplane V2 in den GKE-Versionen 1.26.4-gke.500 und höher die Option Proxy-Beendigung von Endpunkten aktiviert. Pakete werden als letztes Mittel an einen beendenden Pod weitergeleitet, wenn alle folgenden Bedingungen erfüllt sind:
    • Wenn alle Bereitstellungs-Pods beendet werden und externalTrafficPolicy = Cluster ist.
    • Wenn alle Bereitstellungs-Pods auf dem Knoten beendet werden und externalTrafficPolicy den Wert Local hat.
  • Bei allen anderen GKE-Versionen antwortet der Kernel des Knotens mit einem TCP-Reset auf das Paket.

Preise und Kontingente

Die Netzwerkpreise gelten für Pakete, die von einem Load-Balancer verarbeitet werden. Weitere Informationen finden Sie unter Preise für Cloud Load Balancing und Weiterleitungsregeln. Sie können die Kosten auch mit dem Preisrechner von Google Cloud schätzen.

Die Anzahl der Weiterleitungsregeln, die Sie erstellen können, wird durch Kontingente für den Load-Balancer gesteuert:

Nächste Schritte