LoadBalancer-Services

Autopilot Standard

Auf dieser Seite 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. Darin werden LoadBalancer-Typen und Konfigurationsparameter beschrieben und Best Practices empfohlen.

Machen Sie sich vor dem Lesen dieser Seite mit den GKE-Netzwerkkonzepten vertraut.

Übersicht

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

LoadBalancer-Dienst anpassen

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

• Load Balancer-Typ: intern oder extern
• Richtlinie für externen Traffic
• Gewichtetes Load Balancing
• Zonale Affinität

Abbildung: Entscheidungsbaum für LoadBalancer-Dienst

Typ des Load-Balancers: Intern oder extern

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

• Externe LoadBalancer-Dienste werden mithilfe von externen Passthrough-Network Load Balancern implementiert. Clients außerhalb Ihres VPC-Netzwerk und Google CloudVMs mit Internetzugriff können auf einen externen LoadBalancer-Dienst zugreifen.

  Wenn Sie einen LoadBalancer-Dienst erstellen und keine benutzerdefinierten Einstellungen angeben, wird standardmäßig diese Konfiguration verwendet.

  Als Best Practice sollten Sie beim Erstellen eines externen LoadBalancer-Dienstes die Annotation cloud.google.com/l4-rbs: "enabled" in das Dienstmanifest aufnehmen. Wenn Sie diese Annotation in das Dienstmanifest einfügen, wird ein Backend-Dienst-basierter externer Passthrough-Network-Load-Balancer erstellt.

  LoadBalancer-Dienstmanifeste, in denen die Annotation cloud.google.com/l4-rbs: "enabled" fehlt, erstellen einen zielpoolbasierten externen Passthrough-Network Load Balancer. Die Verwendung zielpoolbasierter externer Passthrough-Network Load Balancer wird nicht mehr empfohlen.

• 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 auf einen internen LoadBalancer-Dienst zugreifen.

  So erstellen Sie einen internen LoadBalancer-Dienst:

  • Es hat sich bewährt, die GKE-Teilmengeneinstellung zu aktivieren, damit GKE Knoten mithilfe von GCE_VM_IP-Netzwerk-Endpunktgruppen (NEGs) effizient gruppieren kann. Die GKE-Teileinstellung ist nicht erforderlich, wird aber dringend empfohlen.

  • Fügen Sie die Annotation networking.gke.io/load-balancer-type: "Internal" in das Dienstmanifest ein.

Effekt von externalTrafficPolicy

Der Parameter externalTrafficPolicy steuert Folgendes:

• Welche Knoten empfangen Pakete vom Load-Balancer?
• Ob Pakete zwischen Knoten im Cluster weitergeleitet werden können, nachdem der Load Balancer die Pakete an einen Knoten gesendet hat
• Ob die ursprüngliche Client-IP-Adresse beibehalten wird oder verloren geht

Der externalTrafficPolicy kann entweder Local oder Cluster sein:

• Verwenden Sie externalTrafficPolicy: Local, um dafür zu sorgen, dass Pakete nur an einen Knoten mit mindestens einem bereitgestellten, einsatzbereiten, nicht beendeten Pod gesendet werden, wobei die ursprüngliche Quell-IP-Adresse des Clients beibehalten wird. Diese Option eignet sich am besten für Arbeitslasten mit einer relativ konstanten Anzahl von Knoten mit Bereitstellungs-Pods, auch wenn die Gesamtzahl der Knoten im Cluster variiert. Diese Option ist erforderlich, um gewichtetes Load-Balancing zu unterstützen.

Hinweis: Bei Verwendung der Richtlinie Local funktioniert die Beibehaltung der Quell-IP-Adressen nicht, wenn ip-masq-agent in Ihrem Cluster ausgeführt wird und der IP-Adressbereich des Pods nicht von der IP-Maskierung ausgeschlossen ist. Eine Anleitung zum Ausschließen von IP-Adressbereichen bei der Maskierung finden Sie unter custom nonMasqueradeCIDRs list in the ip-masq-agent configMap.

• Verwenden Sie externalTrafficPolicy: Cluster, wenn die Gesamtzahl der Knoten in Ihrem Cluster relativ konstant ist, aber die Anzahl der Knoten mit Bereitstellungs-Pods variiert. Bei dieser Option werden die ursprünglichen Client-Quell-IP-Adressen nicht beibehalten. Außerdem kann es zu Latenz kommen, da Pakete möglicherweise an einen Serving-Pod auf einem anderen Knoten weitergeleitet werden, nachdem sie von einem Load Balancer an einen Knoten gesendet wurden. Diese Option ist nicht mit dem gewichteten Load Balancing kompatibel.

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

Wichtig: Bei internen LoadBalancer-Diensten bestimmt externalTrafficPolicy auch indirekt, wie viele Knoten mit Bereitstellungs-Pods unterstützt werden. Weitere Informationen finden Sie unter Überlegungen zur Knotenanzahl.

Gewichtetes Load Balancing

Externe LoadBalancer-Dienste unterstützen gewichtetes Load-Balancing. Dadurch können Knoten mit mehr bereitgestellten, einsatzbereiten und nicht beendeten Pods einen größeren Anteil an neuen Verbindungen erhalten als Knoten mit weniger Pods. Weitere Informationen dazu, wie sich Load-Balancer-Konfigurationen mit gewichtetem Load Balancing ändern, finden Sie unter Auswirkungen des gewichteten Load Balancings.

Abbildung: Traffic-Verteilung beim gewichteten Load Balancing

Wie im Diagramm dargestellt, werden bei Diensten mit aktiviertem gewichteten Load-Balancing neue Verbindungen proportional zur Anzahl der bereiten Pods auf jedem Knoten verteilt. So wird dafür gesorgt, dass Knoten mit mehr Pods einen größeren Anteil an neuen Verbindungen erhalten.

Damit Sie das gewichtete Load Balancing verwenden können, müssen alle folgenden Anforderungen erfüllt sein:

• Ihr GKE-Cluster muss Version 1.31.0-gke.1506000 oder höher verwenden.

• Das HttpLoadBalancing-Add-on muss für Ihren Cluster aktiviert sein. Dieses Add-on ist standardmäßig aktiviert. Der Cluster kann dann Load-Balancer verwalten, die Backend-Dienste verwenden.

• Sie müssen die Annotation cloud.google.com/l4-rbs: "enabled" in das LoadBalancer-Dienstmanifest aufnehmen, damit GKE einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer erstellt. Zielpoolbasierte externe Passthrough-Network Load Balancer unterstützen kein gewichtetes Load-Balancing.

• Sie müssen die Annotation networking.gke.io/weighted-load-balancing: pods-per-node in das LoadBalancer-Dienstmanifest aufnehmen, um die Funktion für gewichtetes Load Balancing zu aktivieren.

• Im Manifest des LoadBalancer-Dienstes muss externalTrafficPolicy: Local verwendet werden. GKE verhindert nicht, dass Sie externalTrafficPolicy: Cluster verwenden, aber externalTrafficPolicy: Cluster deaktiviert effektiv das gewichtete Load Balancing, da das Paket nach dem Load-Balancer möglicherweise an einen anderen Knoten weitergeleitet wird.

Informationen zur Verwendung des gewichteten Load Balancings finden Sie unter Gewichtetes Load Balancing aktivieren.

Zonale Affinität

Interne LoadBalancer-Dienste unterstützen die zonale Affinität (Vorschau), mit der neue Verbindungen zu Knoten mit Bereitstellungs-Pods in derselben Zone wie ein Client weitergeleitet werden können. Wenn Sie den Traffic innerhalb einer Zone halten, können Sie zonenübergreifenden Traffic minimieren und so Kosten und Latenz reduzieren.

Informationen zur Verwendung der zonalen Affinität finden Sie unter Zonale Affinität verwenden. Weitere Informationen dazu, wie sich Load-Balancer-Konfigurationen mit zonaler Affinität ändern, einschließlich des Zeitpunkts, zu dem Sie Traffic in einer Zone halten können, finden Sie unter Auswirkungen der zonalen Affinität. Weitere Informationen dazu, wie sich die zonale Affinität und externalTrafficPolicy auf das Paketrouting auf Knoten-VMs auswirken, finden Sie unter Source Network Address Translation und Routing auf Knoten.

Besondere Überlegungen für interne LoadBalancer-Dienste

In diesem Abschnitt wird die GKE-Teileinstellung beschrieben, die nur für interne LoadBalancer-Dienste verfügbar ist. Außerdem wird erläutert, wie die GKE-Teileinstellung mit externalTrafficPolicy interagiert, um die maximale Anzahl von Load-Balancing-Knoten zu beeinflussen.

GKE-Teilmengeneinstellung

Best Practice:

Aktivieren Sie die GKE-Teilmengeneinstellung, um die Skalierbarkeit interner LoadBalancer-Dienste zu verbessern.

Die GKE-Teileinstellung, auch GKE-Teileinstellung für interne L4-Load-Balancer genannt, ist eine clusterweite Konfigurationsoption, die die Skalierbarkeit interner Passthrough-Network Load Balancer verbessert, indem Knotenendpunkte effizienter in GCE_VM_IP-Netzwerk-Endpunktgruppen (NEGs) gruppiert werden. Die NEGs werden als Back-Ends des Load-Balancers verwendet.

Das folgende Diagramm zeigt zwei Dienste in einem zonalen Cluster mit drei Knoten. Für den Cluster ist die GKE-Teilmengeneinstellung aktiviert. Jeder Dienst hat zwei Pods. GKE erstellt für jeden Dienst eine GCE_VM_IP-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 aktualisieren. Nach der Aktivierung kann die GKE-Teilmengeneinstellung nicht mehr deaktiviert werden. 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.

Hinweis :Die GKE-Teileinstellung unterscheidet sich von der Google Cloud-Backend-Teileinstellung des internen Passthrough-Network Load Balancers. Internal passthrough Network Load Balancers created by GKE are never configured to use internal passthrough Network Load Balancer backend subsetting.

Knotenanzahl

In einem Cluster mit deaktivierter GKE-Teileinstellung kann es bei internen LoadBalancer-Diensten zu Problemen kommen, wenn der Cluster mehr als 250 Knoten (in allen Knotenpools) enthält. Das liegt daran, dass von GKE erstellte interne Passthrough-Network Load Balancer Pakete nur auf 250 oder weniger Backend-Knoten-VMs verteilen können. Diese Einschränkung hat die folgenden zwei Gründe:

• GKE verwendet keine Load-Balancer-Backend-Teileinstellung.
• 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.

Ein Cluster mit GKE-Teileinstellung unterstützt interne LoadBalancer-Dienste in Clustern mit mehr als 250 Knoten insgesamt.

• Ein interner LoadBalancer-Dienst, der externalTrafficPolicy: Local in einem Cluster mit aktivierter GKE-Teileinstellung verwendet, unterstützt bis zu 250 Knoten mit Bereitstellungs-Pods, die diesen Dienst unterstützen.

• Ein interner LoadBalancer-Dienst, der externalTrafficPolicy: Cluster in einem Cluster mit aktivierter GKE-Teileinstellung verwendet, unterliegt keiner Beschränkung hinsichtlich der Anzahl der Knoten mit Bereitstellungs-Pods, da GKE nicht mehr als 25 Knotenendpunkte in GCE_VM_IP-NEGs konfiguriert. Weitere Informationen finden Sie unter Knotenmitgliedschaft in GCE_VM_IP-NEG-Backends.

Traffic-Verteilung

Standardmäßig werden mit internen und externen LoadBalancer-Diensten Passthrough-Network Load Balancer mit der auf NONE eingestellten Sitzungsaffinität erstellt. Passthrough-Network-Load-Balancer verwenden Sitzungsaffinität, Systemdiagnoseinformationen und unter bestimmten Umständen Details wie die Gewichtung, um ein geeignetes Knoten-Backend für eine neue Verbindung zu ermitteln und auszuwählen.

Bei neuen Verbindungen werden Einträge in der Tabelle zum Nachverfolgen der Verbindung erstellt. Diese werden verwendet, um nachfolgende Pakete für die Verbindung schnell an das zuvor ausgewählte geeignete Knoten-Backend weiterzuleiten. Weitere Informationen dazu, wie Passthrough-Network Load Balancer geeignete Back-Ends identifizieren und auswählen und wie sie das Verbindungs-Tracking verwenden, finden Sie unter:

• Traffic-Verteilung für interne Passthrough-Network Load Balancer

• Traffic-Verteilung für externe Passthrough-Network Load Balancer

Auswirkung von gewichtetem Load Balancing

Wenn Sie gewichtetem Load-Balancing für einen externen LoadBalancer-Dienst konfigurieren, aktiviert GKE gewichtetes Load-Balancing für den entsprechenden externen Passthrough-Network-Load-Balancer. GKE konfiguriert die kube-proxy- oder cilium-agent-Software so, dass ein Antwortheader in die Antwort auf die Systemdiagnose des Load-Balancers aufgenommen wird. Dieser Antwortheader definiert eine Gewichtung, die proportional zur Anzahl der bereitgestellten, einsatzbereiten und nicht beendeten Pods auf jedem Knoten ist.

Der Load-Balancer verwendet die Gewichtungsinformationen so:

• Die Menge der infrage kommenden Knoten-Back-Ends des Load-Balancers besteht aus allen fehlerfreien Knoten mit einem Gewicht von mehr als null.

• Der Load-Balancer berücksichtigt das Gewicht, wenn er eines der infrage kommenden Knoten-Back-Ends auswählt. Wenn der Dienst externalTrafficPolicy: Local verwendet (erforderlich für ein effektives gewichtetes Load-Balancing), wird ein infrage kommendes Knoten-Back-End mit mehr bereitgestellten, bereiten, nicht terminierenden Pods mit größerer Wahrscheinlichkeit ausgewählt als ein infrage kommendes Knoten-Back-End mit weniger Pods.

Auswirkung der zonalen Affinität

Wenn Sie zonale Affinität für einen internen LoadBalancer-Dienst konfigurieren, konfiguriert GKE den entsprechenden internen Passthrough-Network-Load-Balancer mit der Option ZONAL_AFFINITY_SPILL_CROSS_ZONE und einem Spillover-Verhältnis von null.

Bei dieser Konfiguration der zonenbasierten Affinität beschränkt der Load-Balancer die ursprüngliche Gruppe der infrage kommenden Knoten-Back-Ends auf die infrage kommenden Knoten-Back-Ends, die sich in derselben Zone wie der Client befinden, wenn alle der folgenden Bedingungen erfüllt sind:

• Der Client ist mit der zonalen Affinität kompatibel.

• Mindestens ein fehlerfreies, berechtigtes Knoten-Backend befindet sich in der Zone des Clients.

In allen anderen Situationen verwendet der Load Balancer weiterhin die ursprüngliche Gruppe der infrage kommenden Knoten-Back-Ends, ohne dass eine Optimierung der zonalen Affinität erfolgt.

Weitere Informationen dazu, wie sich die Konfiguration der zonalen Affinität auf das Verhalten des Load-Balancers auswirkt, finden Sie in der Dokumentation unter Zonale Affinität.

Knotengruppierung

Die GKE-Version, die Dienstmanifestannotationen und – für interne LoadBalancer-Dienste – die Option GKE-Teileinstellung bestimmen den resultierenden Google Cloud Load-Balancer und den Typ der Back-Ends. Der Typ des Load-Balancers und der Back-Ends bestimmen, wie Knoten in GCE_VM_IP-NEGs, Instanzgruppen oder Zielpools gruppiert werden. In allen Fällen identifizieren Google CloudPassthrough-Load-Balancer die Netzwerkschnittstelle (NIC) des GKE-Knotens, nicht eine bestimmte Knoten- oder Pod-IP-Adresse.

GKE-LoadBalancer-Dienst	Daraus resultierender Google Cloud Load Balancer	Methode der Knotengruppierung
Interner LoadBalancer-Dienst, der in einem Cluster mit aktivierter GKE-Teileinstellung erstellt wurde^1	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, die auf einen Cluster angewendet wird, auf dem GKE-Version 1.32.2-gke.1652000 oder höher ausgeführt wird^4	Ein Backend-Dienst-basierter externer 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.
Externer LoadBalancer-Dienst mit der Annotation cloud.google.com/l4-rbs: "enabled"^2, die auf einen Cluster angewendet wird, auf dem eine GKE-Version vor 1.32.2-gke.1652000 ausgeführt wird^4	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" Anmerkung^3	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.

¹ 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.

² 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.

³ 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 zielpoolbasierten externen 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.

⁴ GKE migriert vorhandene externe LoadBalancer-Dienste, die von Backend-Dienst-basierten externen Passthrough-Network Load Balancern mit Instanzgruppen-Backends bereitgestellt werden, nicht automatisch zu Backend-Dienst-basierten externen Passthrough-Network Load Balancern mit GCE_VM_IP-NEG-Backends. Wenn Sie einen externen LoadBalancer-Dienst erstellen möchten, der von einem Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer unterstützt wird, der GCE_VM_IP NEG-Backends verwendet, müssen Sie die Annotation cloud.google.com/l4-rbs: "enabled" in das Dienstmanifest aufnehmen und das Manifest auf einen Cluster anwenden, auf dem GKE-Version 1.32.2-gke.1652000 oder höher ausgeführt wird. Eine Anleitung zur manuellen Migration finden Sie unter Zu GCE_VM_IP-NEG-Back-Ends migrieren.

Knotenmitgliedschaft in GCE_VM_IP-NEG-Back-Ends

Wenn die GKE-Teileinstellung für einen Cluster aktiviert ist oder externe Passthrough-Network-Load-Balancer mit cloud.google.com/l4-rbs: "enabled" in GKE-Version 1.32.2-gke.1652000 oder höher erstellt wurden, erstellt GKE in jeder Zone für jeden 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.

Hinweis: Die NEG GCE_VM_IP unterscheidet sich vom Typ GCE_VM_IP_PORT zonaler NEG, die für containernatives Ingress-Load-Balancing verwendet wird. GCE_VM_IP NEGs identifizieren Netzwerkschnittstellen von Knoten-VMs anhand der IP-Adresse des Knotens. Pakete haben jedoch Ziele, die mit der IP-Adresse der Weiterleitungsregel des Load-Balancers und einem der konfigurierten Ports für die Weiterleitungsregel übereinstimmen.

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 den folgenden Tabellen zusammengefasst.

Knoten in internen Passthrough-Network Load Balancern

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 Knoten^1	GKE verwendet nur Knoten, die mindestens einen der Bereitstellungs-Pods des Dienstes haben, als Endpunkte für die NEGs des Dienstes.

¹ Beschränkt auf 250 Knoten mit Bereitstellungs-Pods. Mehr als 250 Knoten können im Cluster vorhanden sein, aber interne Passthrough-Network Load Balancer können nur auf 250 Backend-VMs verteilt werden, 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.

Knoten in externen Passthrough-Network-Load-Balancern

externalTrafficPolicy	Anzahl der Knoten im Cluster	Endpunktmitgliedschaft
Cluster	1 bis 250 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 250 Knoten	GKE verwendet eine zufällige Teilmenge von bis zu 250 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 Knoten^1	GKE verwendet nur Knoten, die mindestens einen der Bereitstellungs-Pods des Dienstes haben, als Endpunkte für die NEGs des Dienstes.

¹ Beschränkt auf 3.000 Knoten mit Bereitstellungs-Pods. Im Cluster können mehr als 3.000 Knoten vorhanden sein,aber GKE unterstützt nur die Erstellung von bis zu 3.000 Endpunkten, wenn Backend-Dienst-basierte externe Passthrough-Network-Load-Balancer erstellt werden,die GCE_VM_IP-NEG-Backends verwenden.

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 wird eine Load-Balancer-Systemdiagnose implementiert. Das System zur Systemdiagnose des Load-Balancers wird außerhalb des Clusters ausgeführt und unterscheidet sich von einer Bereitschafts-, Aktivitäts- oder Startprüfung für Pods.

Pakete für Systemdiagnosen des Load-Balancers werden entweder von der Software kube-proxy (Legacy-Dataplane) oder cilium-agent (GKE Dataplane V2) beantwortet, die auf jedem Knoten ausgeführt wird. Load-Balancer-Systemdiagnosen für LoadBalancer-Dienste können nicht von Pods beantwortet werden.

Der externalTrafficPolicy des Dienstes bestimmt, welche Knoten die Load-Balancer-Systemdiagnose bestehen. Weitere Informationen dazu, wie der Load-Balancer Systemdiagnoseinformationen verwendet, finden Sie unter Trafficverteilung.

externalTrafficPolicy	Welche Knoten die Systemdiagnose bestehen	Welcher Port verwendet wird
Cluster	Alle Knoten des Clusters bestehen die Systemdiagnose, auch Knoten ohne Bereitstellungs-Pods. Wenn auf einem Knoten mindestens ein Bereitstellungs-Pod vorhanden ist, besteht der Knoten die Systemdiagnose des Load-Balancers unabhängig vom Status des Pods.	Der Systemdiagnose-Port des Load-Balancers muss der TCP-Port 10256 sein. Er kann nicht angepasst werden.
Local	Bei der Systemdiagnose des Load-Balancers gilt ein Knoten als fehlerfrei, wenn auf dem Knoten mindestens ein Bereitschafts-, nicht-beendender Bereitstellungs-Pod vorhanden ist, unabhängig vom Status anderer Pods. 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 für die Systemdiagnose 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.	Die Kubernetes-Steuerungsebene weist den Port für die Systemdiagnose aus dem Knotenportbereich zu, sofern Sie keinen benutzerdefinierten Port für die Systemdiagnose angeben.

Wenn gewichtetes Load Balancing aktiviert ist, verwendet der Load-Balancer sowohl Systemdiagnose- als auch Gewichtungsinformationen, um die Gruppe der infrage kommenden Knoten-Back-Ends zu ermitteln. Weitere Informationen finden Sie unter Auswirkungen des gewichteten Load-Balancing.

Wenn die zonale Affinität aktiviert ist, kann der Load-Balancer die Gruppe der infrage kommenden Knoten-Back-Ends verfeinern. Weitere Informationen finden Sie unter Auswirkungen der zonalen Affinität.

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

Passthrough-Network-Load-Balancer leiten Pakete an die nic0-Schnittstelle der Knoten des GKE-Cluster 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, die die Legacy-Datenebene verwenden, 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 und Routing auf Knoten

Die folgende Tabelle zeigt die Beziehung zwischen externalTrafficPolicy und der Frage, ob der Knoten, der Load-Balancing-Pakete empfangen hat, eine Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) durchführt, bevor er die Load-Balancing-Pakete an einen Pod sendet:

externalTrafficPolicy	SNAT-Verhalten
Cluster	In GKE-Clustern, die den Legacy-Dataplane verwenden, ändert jeder Knoten, der Load-Balancing-Pakete empfängt, immer die Quell-IP-Adresse dieser Pakete so, dass sie mit der IP-Adresse des Knotens übereinstimmt. Das gilt unabhängig davon, ob der Knoten die Pakete an einen lokalen Pod oder an einen Pod auf einem anderen Knoten weiterleitet. In GKE-Clustern, die GKE Dataplane V2 verwenden, ändert jeder Knoten, der Load-Balanced-Pakete empfangen hat, die Quell-IP-Adresse dieser Pakete so, dass sie der IP-Adresse des Knotens entspricht, aber nur, wenn der empfangende Knoten die Pakete an einen Pod auf einem anderen Knoten weiterleitet. Wenn der Knoten, der Pakete mit Load-Balancing empfangen hat, die Pakete an einen lokalen Pod weiterleitet, ändert der Knoten die Quell-IP-Adresse dieser Pakete nicht.
Local	Jeder Knoten, der Pakete mit Load-Balancing empfangen hat, leitet die Pakete ausschließlich an einen lokalen Pod weiter. Der Knoten ändert nicht die Quell-IP-Adresse dieser Pakete.

In der folgenden Tabelle sehen Sie, wie externalTrafficPolicy steuert, wie Knoten Load-Balancing-Pakete und Antwortpakete weiterleiten:

externalTrafficPolicy	Load-Balancing-Paketrouting	Routing von Antwortpaketen
Cluster	Das ist das Standardverhalten für das Weiterleiten von Paketen mit Load-Balancing: Wenn der Knoten, der Load-Balancing-Pakete empfangen hat, keinen Bereitstellungs-Pod hat, der bereit und nicht beendet ist, leitet dieser Knoten die Pakete an einen anderen Knoten weiter, der einen Bereitstellungs-Pod hat, der bereit und nicht beendet ist. Wenn der Knoten, der Load-Balancing-Pakete empfangen hat, einen Bereitstellungs-Pod enthält, der bereit und nicht beendet ist, kann der Knoten die Pakete an Folgendes weiterleiten: Ein lokaler Pod. Ein anderer Knoten mit einem bereitstellenden, einsatzbereiten, nicht beendeten Pod. Wenn in regionalen Clustern der Knoten, der Pakete mit Load-Balancing empfangen hat, Pakete an einen anderen Knoten weiterleitet, hat die zonale Affinität die folgende Wirkung: Wenn die zonale Affinität nicht aktiviert ist, kann sich der andere Knoten in einer beliebigen Zone befinden. Wenn die zonale Affinität aktiviert ist, versucht der Knoten, der Pakete mit Load-Balancing empfangen hat, diese an einen anderen Knoten in derselben Zone weiterzuleiten. Wenn das nicht möglich ist, kann sich der andere Knoten in einer beliebigen Zone befinden. Wenn es als letztes Mittel keine bereitstellenden, bereiten und nicht beendeten Pods für den Dienst auf allen Knoten im Cluster gibt, passiert Folgendes: Wenn „Proxy Terminating Endpoints“ aktiviert ist^1, leitet der Knoten, der Load-Balancing-Pakete empfangen hat, diese nach Möglichkeit an einen Bereitstellungs-Pod weiter, der beendet wird. Wenn „Proxy Terminating Endpoints“ deaktiviert ist oder keine Pods im gesamten Cluster vorhanden sind, schließt der Knoten, der Load-Balancing-Pakete empfangen hat, die Verbindung mit einem TCP-Reset.	Antwortpakete werden immer von einem Knoten mit Direct Server Return gesendet: Wenn der Knoten mit dem Bereitstellungs-Pod nicht der Knoten ist, der die entsprechenden Pakete mit Load-Balancing empfangen hat, sendet der Bereitstellungsknoten die Antwortpakete zurück an den empfangenden Knoten. Der empfangende Knoten sendet dann die Antwortpakete mithilfe von Direct Server Return. Wenn der Knoten mit dem Bereitstellungs-Pod der Knoten ist, der die Pakete mit Load-Balancing empfangen hat, sendet dieser Knoten die Antwortpakete mit Direct Server Return.
Local	Das ist das Standardverhalten für das Weiterleiten von Paketen mit Load-Balancing: Der Knoten, der Pakete mit Load-Balancing empfangen hat, hat in der Regel einen Bereitstellungs-Pod, der bereit ist und nicht beendet wird. Das ist erforderlich, um die Systemdiagnose des Load-Balancers zu bestehen. Der Knoten leitet Pakete mit Load-Balancing an einen lokalen Pod weiter. In regionalen Clustern ändert die zonale Affinität das Baseline-Verhalten für das Routing von Paketen mit Load-Balancing nicht. Wenn es auf dem Knoten, der Load-Balancing-Pakete empfangen hat, keine Bereitstellungs-Pods gibt, die bereit und nicht beendet werden, passiert Folgendes: Wenn „Proxy Terminating Endpoints“ aktiviert ist^1, leitet der Knoten, der Load-Balancing-Pakete empfangen hat, diese nach Möglichkeit an einen lokalen Bereitstellungs-Pod weiter, der beendet wird. Wenn „Proxy Terminating Endpoints“ deaktiviert ist oder der Knoten, der Load-Balancing-Pakete empfangen hat, keinen Bereitstellungs-Pod hat, schließt dieser Knoten die Verbindung mit einem TCP-Reset.	Der Knoten mit dem Bereitstellungs-Pod ist immer der Knoten, der die Pakete mit Load-Balancing empfangen hat. Dieser Knoten sendet die Antwortpakete mit Direct Server Return.

¹ Proxy Terminating Endpoints ist in diesen Konfigurationen aktiviert:

• GKE-Cluster, die die Legacy-Dataplane verwenden: GKE-Version 1.26 und höher
• GKE-Cluster, die GKE Dataplane V2 verwenden: GKE-Version 1.26.4-gke.500 und höher

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 Google Cloud Preisrechner schätzen.

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

• Interne Passthrough-Network Load Balancer verwenden das Kontingent für Backend-Dienste pro Projekt, das Kontingent für Systemdiagnosen pro Projekt und das Kontingent für Weiterleitungsregeln für interne Passthrough-Network Load Balancer pro Virtual Private Cloud-Netzwerk.
• Backend-Dienst-basierte externe Passthrough-Network Load Balancer verwenden das Kontingent für Backend-Dienste pro Projekt, das Kontingent für Systemdiagnosen pro Projekt und das Kontingent pro Projekt für Weiterleitungsregeln des externen Passthrough-Network Load Balancers.
• Zielpoolsbasierte externe Passthrough-Network Load Balancer verwenden das Zielpool-Kontingent pro Projekt, das Kontingent pro Projekt für Systemdiagnosen und das Kontingent pro Projekt für Weiterleitungsregeln des externen Passthrough-Network Load Balancers.

Nächste Schritte

• Weitere Informationen zu GKE-LoadBalancer-Dienstparametern
• Weitere Informationen zu Kubernetes-Diensten