LoadBalancer-Services

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 Passthrough-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:

Entscheidungsbaum für LoadBalancer-Dienst.
Abbildung: LoadBalancer-Dienst-Entscheidungsbaum

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 regionalen externen Passthrough-Network Load Balancern implementiert. Clients außerhalb Ihres VPC-Netzwerk und Google Cloud-VMs mit Internetzugriff können auf einen externen LoadBalancer-Dienst zugreifen.

    Verwenden Sie eine der folgenden Methoden, um einen externen LoadBalancer-Dienst zu erstellen:

    • In Clustern mit GKE 1.37 oder höher erstellt GKE automatisch einen Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer mit GCE_VM_IP-NEG-Backends. Sie müssen dem Dienstmanifest keine Annotationen oder Felder hinzufügen. Wenn Sie explizit einen Legacy-Load-Balancer auf Zielpoolbasis erstellen möchten, fügen Sie das Feld-Wert-Paar spec.loadBalancerClass: "networking.gke.io/l4-regional-external-legacy" hinzu.

    • Fügen Sie in Clustern mit GKE 1.33.1-gke.1779000 bis 1.36 dem Dienstmanifest spec.loadBalancerClass: "networking.gke.io/l4-regional-external" hinzu, bevor Sie das Manifest an den Cluster senden. Wir empfehlen, dieses Feld zu verwenden, da es immer einen Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer mit GCE_VM_IP-NEG-Backends erstellt. Das Feld spec.loadBalancerClass ist unveränderlich und kann nach dem Erstellen des Dienstes nicht mehr geändert werden.

    • In Clustern, auf denen eine unterstützte GKE-Version ausgeführt wird, können Sie dem Dienstmanifest die Annotation cloud.google.com/l4-rbs: "enabled" hinzufügen, bevor Sie das Manifest an den Cluster senden. Mit dieser Annotation wird auch ein Backend-Dienst-basierter regionaler externer Passthrough-Network-Load-Balancer erstellt. Der Load Balancer verwendet GCE_VM_IP-NEG-Backends, wenn das Manifest an einen Cluster gesendet wird, auf dem GKE 1.32.2-gke.1652000 oder höher ausgeführt wird. Andernfalls verwendet der Load Balancer Instanzgruppen-Back-Ends. Die GKE wertet diese Annotation nur aus, wenn das Dienstmanifest zum ersten Mal auf den Cluster angewendet wird.

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

    Als Best Practice sollten Sie vor dem Erstellen eines internen LoadBalancer-Dienstes prüfen, ob die GKE-Teileinstellung aktiviert ist. Die GKE-Teilmengenerstellung wird automatisch aktiviert, wenn auf Ihrem Cluster GKE 1.36 oder höher ausgeführt wird. Bei früheren GKE-Versionen sollten Sie die GKE-Teileinstellung explizit aktivieren.

    Verwenden Sie eine der folgenden Methoden, um einen internen LoadBalancer-Dienst zu erstellen:

    • Fügen Sie in Clustern mit GKE 1.33.1-gke.1779000 oder höher, in denen GKE-Subsetting aktiviert ist, dem Dienstmanifest spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" hinzu, bevor Sie das Manifest an den Cluster senden. Wir empfehlen, dieses Feld zu verwenden, da damit immer ein interner Passthrough-Network-Load-Balancer mit GCE_VM_IP-NEG-Back-Ends erstellt wird. Das Feld spec.loadBalancerClass ist unveränderlich und kann nach dem Erstellen des Dienstes nicht mehr geändert werden.

    • In Clustern, auf denen eine unterstützte GKE-Version ausgeführt wird, können Sie die Annotation networking.gke.io/load-balancer-type: "Internal" dem Dienstmanifest hinzufügen, bevor Sie das Manifest an den Cluster senden. Dadurch wird auch ein interner Passthrough-Network-Load-Balancer erstellt. Der Load Balancer verwendet GCE_VM_IP-NEG-Backends, wenn das Manifest an einen Cluster gesendet wird, für den die GKE-Teilmengeneinstellung aktiviert ist. Andernfalls verwendet der Load Balancer Instanzgruppen-Backends.

Für Cluster, auf denen GKE-Versionen vor 1.37 ausgeführt werden, erstellen LoadBalancer-Dienstmanifeste, die weder spec.loadBalancerClass noch die Annotationen cloud.google.com/l4-rbs: "enabled" oder networking.gke.io/load-balancer-type: "Internal" enthalten, einen zielpoolbasierten regionalen externen Passthrough-Network-Load-Balancer. Wir raten davon ab, zielpoolbasierte regionale externe Passthrough-Network Load Balancer zu verwenden.

HttpLoadBalancing-Voraussetzung

Wenn Sie LoadBalancer-Dienste erstellen möchten, die von Backend-Dienst-basierten regionalen externen Passthrough-Network Load Balancern oder internen Passthrough-Network Load Balancern unterstützt werden, muss das Add-on HttpLoadBalancing aktiviert sein, wenn Ihr Cluster eine GKE-Version vor 1.36 ausführt. Das Add-on HttpLoadBalancing ist standardmäßig aktiviert.

LoadBalancer-Dienste in GKE-Version 1.36 und höher sind nicht vom Add-on HttpLoadBalancing abhängig.

Effekt von externalTrafficPolicy

Mit dem Parameter externalTrafficPolicy wird Folgendes gesteuert:

  • 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 übermittelt hat
  • Ob die ursprüngliche Client-IP-Adresse beibehalten wird oder verloren geht

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 bereitstellenden, bereiten, nicht beendenden Pod gesendet werden, wobei die ursprüngliche Client-Quell-IP-Adresse 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.
  • 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 Latenzen kommen, da Pakete nach der Zustellung an einen Knoten vom Load Balancer an einen bereitstellenden Pod auf einem anderen Knoten weitergeleitet werden können. Diese Option ist nicht mit gewichtetem Load Balancing kompatibel.

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

Gewichtetes Load Balancing

Externe LoadBalancer-Dienste unterstützen gewichtetes Load Balancing. Dadurch können Knoten mit mehr bereitstellenden, bereiten, 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.

Trafficverteilung mit gewichtetem Load Balancing.
Abbildung: Trafficverteilung mit gewichtetem Load Balancing

Wie im Diagramm dargestellt, verteilen Dienste mit aktiviertem gewichtetem Load Balancing neue Verbindungen proportional zur Anzahl der bereiten Pods auf jedem Knoten.

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

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

  • Sie müssen einen externen LoadBalancer-Dienst erstellen, der zu einem Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer führt.

    • In Clustern mit GKE 1.37 oder höher erstellt GKE diesen Load-Balancer-Typ standardmäßig. Es sind keine zusätzlichen Felder oder Annotationen erforderlich.

    • Fügen Sie in Clustern mit GKE 1.33.1-gke.1779000 bis 1.36 dem Service-Manifest spec.loadBalancerClass: "networking.gke.io/l4-regional-external" hinzu, bevor Sie das Manifest an den Cluster senden. Dies ist die bevorzugte Methode.

    • Fügen Sie in Clustern, auf denen eine unterstützte GKE-Version ausgeführt wird, die Annotation cloud.google.com/l4-rbs: "enabled" dem Dienstmanifest hinzu, bevor Sie das Manifest an den Cluster senden.

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

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

Informationen zum Verwenden des gewichteten Load Balancings finden Sie unter Gewichtetes Load Balancing aktivieren.

Zonale Affinität

Interne LoadBalancer-Dienste unterstützen die zonale Affinität, mit der neue Verbindungen an Knoten mit Bereitstellungs-Pods in derselben Zone wie ein Client weitergeleitet werden können. Wenn es in der Zone keine fehlerfreien Pods gibt, leitet GKE den Traffic an eine andere Zone weiter. Wenn Sie den Traffic innerhalb einer Zone halten, können Sie den zonenübergreifenden Traffic minimieren, was die Kosten und die Latenz reduziert. Wenn Sie die zonale Affinität in einem GKE-Cluster aktivieren möchten, muss die GKE-Teilmengeneinstellung aktiviert sein.

Wenn Sie die 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 (0.0). Diese Konfiguration trägt dazu bei, dass der Traffic innerhalb der Zone verworfen wird, anstatt auf andere Zonen überzugehen. Der Load Balancer beschränkt die ursprüngliche Gruppe der infrage kommenden Knoten-Backends auf die infrage kommenden Knoten-Backends, die sich in derselben Zone wie der Client befinden, wenn alle der folgenden Bedingungen erfüllt sind:

  • Der Client ist mit zonaler Affinität kompatibel.

  • In der Zone des Clients befindet sich mindestens ein fehlerfreies, geeignetes Knoten-Backend.

In allen anderen Situationen verwendet der Load Balancer weiterhin die ursprüngliche Gruppe zulässiger Knoten-Backends, ohne eine zonale Affinitätsoptimierung anzuwenden.

Weitere Informationen dazu, wie sich die Konfiguration der zonalen Affinität auf das Verhalten des Load Balancers auswirkt, finden Sie in der Dokumentation zur 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.

Überlegungen zur Skalierung mit zonaler Affinität

Da die zonale Affinität nicht nativ in den HorizontalPodAutoscaler (HPA) integriert ist, können Skalierungsprobleme auftreten, wenn der Traffic innerhalb einer Zone die Kapazität der Pods in dieser Zone überschreitet. Der HPA skaliert Pods anhand von aggregierten Clustermesswerten und nicht anhand der Last pro Zone. Daher kann es sein, dass eine Zone mit hohem Traffic (zonale Überlastung) keine zusätzlichen Pods erhält. Dies kann zu einer Leistungsminderung oder zu Verbindungsabbrüchen für Clients in dieser Zone führen, selbst wenn der Cluster insgesamt nicht ausgelastet ist.

IP-Adressfamilien

Ein LoadBalancer-Dienst kann ein Single-Stack-Dienst (nur IPv4 oder nur IPv6) oder ein Dual-Stack-Dienst sein. Dies steuern Sie mit den Feldern spec.ipFamilyPolicy und spec.ipFamilies. Ein Single-Stack-Dienst hat eine Weiterleitungsregel und ein Dual-Stack-Dienst hat zwei: eine für IPv4 und eine für IPv6.

IPv6-LoadBalancer-Dienste haben die folgenden zusätzlichen Merkmale:

  • Sie verwenden immer GCE_VM_IP-NEG-Back-Ends.
  • Ihre IPv6-Adressen stammen aus einem Subnetzbereich in Ihrem VPC-Netzwerk (dessen IPv6-Zugriffstyp mit dem Typ des Load Balancers übereinstimmen muss) oder aus Bring Your Own IPv6-Adressen (BYOIPv6):
    • Interne IPv6-LoadBalancer-Dienste können interne Subnetze verwenden, die über ein öffentliches delegiertes BYOIPv6-Präfix bereitgestellt werden.
    • In GKE-Version 1.37.1-gke.2097000 und höher unterstützen externe Single-Stack-IPv6-LoadBalancer-Dienste die direkte Zuweisung externer BYOIPv6-Adressbereiche aus einem regionalen IPv6-Subpräfix eines öffentlichen delegierten Präfixes. Sie können diese Zuweisung entweder mit der Annotation networking.gke.io/ip-collection-v6 oder durch Angabe eines statischen externen BYOIPv6-Adressbereichs konfigurieren.
  • Externe IPv6-LoadBalancer-Dienste erfordern einen Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer.

Weitere Informationen finden Sie unter IPv6-LoadBalancer-Dienste und Eigene IPv6-Adressen verwenden (BYOIPv6).

Besondere Überlegungen für interne LoadBalancer-Dienste

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

GKE-Teilmengeneinstellung

Die GKE-Teilmengeneinstellung für interne LoadBalancer-Dienste ist standardmäßig für GKE-Cluster mit Version 1.36 und höher aktiviert. Bei diesen Versionen bleibt die GKE-Teilmengenbildung aktiv, auch wenn das Flag --enable-l4-ilb-subsetting auf Clusterebene in Ihrer Clusterkonfiguration oder in IaC-Tools (Infrastruktur als Code) wie Terraform auf false gesetzt ist.

Diese clusterweite Konfigurationsoption verbessert die Skalierbarkeit interner Passthrough-Network Load Balancer, da Knotenendpunkte effizienter in GCE_VM_IP-Netzwerk-Endpunktgruppen (NEGs) gruppiert werden. Die NEGs werden als Backends 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.

GKE-Teileinstellung für zwei Dienste in einem zonalen Cluster.

Bei Clustern mit Versionen vor 1.36 können Sie die GKE-Teilmengeneinstellung manuell aktivieren, wenn Sie einen Cluster erstellen oder einen vorhandenen Cluster aktualisieren. Nachdem die GKE-Teilmengeneinstellung aktiviert wurde, kann sie nicht mehr deaktiviert werden.

Für die GKE-Teileinstellung ist Folgendes erforderlich:

  • GKE-Version 1.18.19-gke.1400 oder höher.
  • Wenn Ihr Cluster eine Version vor 1.36 hat, muss das Add-on HttpLoadBalancing aktiviert sein. Dieses Add-on ist standardmäßig aktiviert. Der Cluster kann dann Load Balancer verwalten, die Backend-Dienste verwenden. Wenn Ihr Cluster die Version 1.36 oder höher hat, ist das Add-on HttpLoadBalancing keine Voraussetzung für die GKE-Teilmengenerstellung.

Knotenanzahl

Bei einem Cluster mit deaktivierter GKE-Teileinstellung kann es zu Problemen mit internen LoadBalancer-Diensten kommen, wenn der Cluster insgesamt mehr als 250 Knoten (unter allen Knotenpools) hat. Dies 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 beiden 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 insgesamt mehr als 250 Knoten.

Die Anzahl der Knoten, die mit der GKE-Teilmengeneinstellung unterstützt werden, hängt vom Wert des Felds externalTrafficPolicy für den internen LoadBalancer-Dienst ab:

  • externalTrafficPolicy: Local: unterstützt bis zu 250 Knoten mit Bereitstellungs-Pods für einen bestimmten Dienst.

  • externalTrafficPolicy: Cluster: Es gibt keine Beschränkung für die Anzahl der Knoten mit Bereitstellungs-Pods. Dieses Verhalten tritt auf, weil GKE für jeden Dienst maximal 25 Knotenendpunkte in GCE_VM_IP-NEGs konfiguriert. Weitere Informationen finden Sie unter Knotenmitgliedschaft in GCE_VM_IP-NEG-Backends.

Traffic-Verteilung

Standardmäßig erstellen interne und externe LoadBalancer-Dienste Passthrough-Network Load Balancer, bei denen die Sitzungsaffinität auf NONE festgelegt ist. 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 identifizieren und auszuwählen.

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

Auswirkung von gewichtetem Load Balancing

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

Der Load Balancer verwendet die Gewichtungsinformationen so:

  • Die Gruppe der infrage kommenden Knoten-Back-Ends des Load Balancers besteht aus allen fehlerfreien Knoten mit einer Gewichtung ungleich null.

  • Der Load Balancer berücksichtigt die Gewichtung, wenn er eines der infrage kommenden Knoten-Backends auswählt. Wenn der Dienst externalTrafficPolicy: Local verwendet (erforderlich, damit das gewichtete Load Balancing wirksam ist), wird ein geeignetes Knoten-Backend mit mehr bereitstellenden, bereiten, nicht-terminierenden Pods eher ausgewählt als ein geeignetes Knoten-Backend mit weniger Pods.

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

In der folgenden Tabelle sind die Methoden zur Knotengruppierung für verschiedene LoadBalancer-Dienstkonfigurationen aufgeführt:

Dienst- und Clusterdetails Daraus resultierender Google Cloud -Load-Balancer Methode der Knotengruppierung
Interner LoadBalancer-Dienst
GKE-Version 1.33.1-gke.1779000 oder höher in einem Cluster mit aktiviertem GKE-Subsetting1. Dienstmanifest, das mit spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" an den Cluster gesendet wurde. Ein interner Passthrough-Network Load Balancer, dessen Backend-Dienst GCE_VM_IP-NEG-Backends (Network Endpoint Group) verwendet

Knoten-VMs werden in zonalen 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.

Alle unterstützten GKE-Versionen in einem Cluster mit aktivierter GKE-Teileinstellung1. Dienstmanifest, das mit der Annotation networking.gke.io/load-balancer-type: "Internal" an den Cluster gesendet wurde.
GKE-Versionen vor 1.36 in einem Cluster mit deaktivierter GKE-Teilmengeneinstellung1. Dienstmanifest, das mit der Annotation networking.gke.io/load-balancer-type: "Internal" an den Cluster gesendet wurde. Ein interner 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.
Externe LoadBalancer-Dienste
GKE-Version 1.37 oder höher. Das Dienstmanifest wurde an den Cluster gesendet, aber das Feld-Wert-Paar spec.loadBalancerClass: "networking.gke.io/l4-regional-external-legacy" ist nicht enthalten. Ein Backend-Dienst-basierter regionaler externer Passthrough-Network Load Balancer mit GCE_VM_IP-NEG-Backends (Network Endpoint Group)

Knoten-VMs werden in zonalen 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.

GKE-Version 1.33.1-gke.1779000 bis 1.36. Dienstmanifest, das mit dem Feld/Wert-Paar spec.loadBalancerClass: "networking.gke.io/l4-regional-external" an den Cluster gesendet wurde.
GKE-Version 1.32.2-gke.1652000 bis 1.36. Dienstmanifest, das mit der Annotation cloud.google.com/l4-rbs: "enabled" an den Cluster gesendet wurde2.
GKE-Version vor 1.32.2-gke.16520003. Dienstmanifest, das mit der Annotation cloud.google.com/l4-rbs: "enabled" an den Cluster gesendet wurde2. Ein Backend-Dienst-basierter regionaler externer Passthrough-Network-Load-Balancer mit zonalen nicht verwalteten Instanzgruppen-Backends

Alle Knoten-VMs werden in zonal nicht verwaltete Instanzgruppen platziert, die GKE als Backends für den Backend-Dienst des regionalen externen Passthrough-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.

GKE-Versionen vor 1.37. Dienstmanifest, das ohne alle der folgenden Elemente an den Cluster gesendet wurde:

  • spec.loadBalancerClass
  • networking.gke.io/load-balancer-type Anmerkung
  • cloud.google.com/l4-rbs Anmerkung


ODER

GKE-Version 1.37 oder höher. Dienstmanifest, das mit dem Feld/Wert-Paar spec.loadBalancerClass: "networking.gke.io/l4-regional-external-legacy" an den Cluster gesendet wurde.

 Zielpoolbasierter regionaler externer Passthrough-Network Load Balancer, dessen Zielpool alle Knoten des Clusters enthält

Der Zielpool ist eine ältere API, die nicht auf NEGs oder 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 GKE-Teileinstellungen werden in GKE-Version 1.36 und höher automatisch aktiviert. Die GKE-Teilmengeneinstellung kann nicht deaktiviert werden, nachdem Sie sie aktiviert haben.

2Die Annotation cloud.google.com/l4-rbs: "enabled" wird nur berücksichtigt, wenn das Dienstmanifest an den Cluster gesendet wird. Wenn Sie diese Annotation einem vorhandenen Dienstmanifest hinzufügen, wird ein zielpoolbasierter regionaler externer Passthrough-Network-Load-Balancer nicht in einen Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer konvertiert.

3GKE aktualisiert Backend-Dienst-basierte regionale externe Passthrough-Network Load Balancer mit Instanzgruppen-Backends nicht automatisch auf Backend-Dienst-basierte regionale externe Passthrough-Network Load Balancer mit GCE_VM_IP-NEG-Backends. 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 GKE einen internen Passthrough-Network-Load-Balancer oder einen Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer mit GCE_VM_IP-NEG-Backends erstellt, werden die NEGs so erstellt und verwaltet:

  • Die GKE erstellt 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 GCE_VM_IP-NEGs des Dienstes als Endpunkte hinzugefügt werden.

  • Bei einem IPv6-LoadBalancer-Dienst füllt GKE die GCE_VM_IP-NEG mit den IPv6-Adressen der Knotennetzwerkschnittstellen.

Die Steuerungsebene des Clusters verwaltet Knotenendpunkte in GCE_VM_IP-NEGs gemäß dem Wert der externalTrafficPolicy des Dienstes und der Anzahl der Knoten im Cluster, wie in den folgenden Tabellen zusammengefasst.

Knoten im internen Passthrough-Network Load Balancer

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. 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 regionalem externem Passthrough-Network Load Balancer

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 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 3.000 Knoten mit Bereitstellungs-Pods. Mehr als 3.000 Knoten können im Cluster vorhanden sein,aber GKE unterstützt nur das Erstellen von bis zu 3.000 Endpunkten, wenn Backend-Dienst-basierte regionale 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 sind Back-Ends für die folgenden von GKE erstellten Load Balancer:

  • Ein interner Passthrough-Network-Load-Balancer, der für einen internen LoadBalancer-Dienst erstellt wurde, dessen Manifest die Annotation networking.gke.io/load-balancer-type: "Internal" enthält, die an einen Cluster mit einer GKE-Version vor 1.36 gesendet wurde, wobei die GKE-Teilmengeneinstellung deaktiviert ist.
  • Ein Backend-Dienst-basierter regionaler externer Passthrough-Network-Load-Balancer, der für einen externen LoadBalancer-Dienst erstellt wurde, dessen Manifest die Annotation cloud.google.com/l4-rbs: "enabled" enthält und an einen Cluster gesendet wurde, auf dem eine GKE-Version vor 1.32.2-gke.1652000 ausgeführt wird.
  • Ein externer Application Load Balancer, der für einen externen GKE-Ingress erstellt wurde, den GKE-Ingress-Controller verwendet, aber kein containernatives Load Balancing nutzt.

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 regionalen externen Passthrough-Network Load Balancer und externen Application Load Balancer erstellen und verwalten, die für GKE-Ingress-Ressourcen erstellt wurden, 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, NEG-Back-Ends zu verwenden:

  • LoadBalancer-Dienste erstellen, die GCE_VM_IP-NEGs verwenden. Weitere Informationen finden Sie unter Knotengruppierung.
  • 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

Alle GKE-LoadBalancer-Dienste implementieren eine Load-Balancer-Systemdiagnose. Das Systemdiagnosesystem des Load Balancers wird außerhalb des Clusters ausgeführt und unterscheidet sich von einer Pod-Bereitschafts-, Aktivitäts- oder Startprüfung.

Load-Balancer-Systemdiagnosepakete werden entweder von der Software kube-proxy (auf Clustern, die GKE Dataplane V2 nicht verwenden) oder von der Software cilium-agent (auf Clustern mit 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.

Die 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, einschließlich 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

Die Systemdiagnose des Load Balancers betrachtet einen Knoten als fehlerfrei, wenn mindestens ein bereiter, nicht beendeter Bereitstellungs-Pod auf dem Knoten 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 der 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 Systemdiagnoseport aus dem Knotenportbereich zu, sofern Sie keinen benutzerdefinierten Systemdiagnoseport angeben.

Wenn gewichtetes Load Balancing aktiviert ist, verwendet der Load Balancer sowohl Systemdiagnose- als auch Gewichtungsinformationen, um die Gruppe der infrage kommenden Knoten-Backends zu identifizieren. 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-Backends verfeinern. Weitere Informationen finden Sie unter Zonale Affinität.

Systemdiagnose für NEG im Vergleich zu MIG

Der von Ihrem LoadBalancer-Dienst verwendete Backend-Typ bestimmt, wie Google Cloud Load-Balancer-Systemdiagnosen konfiguriert und ausführt:

  • GKE-Teilmengeneinstellung (NEG-Backends): Wenn Ihr Dienst GCE_VM_IP-Netzwerk-Endpunktgruppen (NEGs) verwendet, z. B. wenn die GKE-Teilmengeneinstellung aktiviert ist, konfiguriert GKE zonale Systemdiagnosen. Bei zonalen NEGs richten sich Systemdiagnoseprüfungen direkt an den Port des Dienstes.
  • Instanzgruppenkonfigurationen (MIG-Backends): Wenn Ihr Dienst nicht verwaltete Instanzgruppen (MIGs) als Backends verwendet, konfiguriert GKE globale Systemdiagnosen. Bei Instanzgruppen richten sich die Systemdiagnoseprüfungen an den zugewiesenen nodePort des Dienstes.

Fehlerbehebung bei Systemdiagnosen

Wenn Ihre Load-Balancer-Backends als fehlerhaft gemeldet werden (z. B. 0/X healthy in der Google Cloud Console), untersuchen Sie die folgenden häufigen Ursachen:

  • Fehlende Firewallregeln: Google Cloud -Load-Balancer erfordern Firewallregeln für eingehenden Traffic, damit Systemdiagnoseprüfungen von den IP-Adressbereichen der Google-Systemdiagnose (z. B. 130.211.0.0/22 und 35.191.0.0/16) Ihre Clusterknoten erreichen können. Wenn diese Firewallregeln gelöscht oder geändert werden, schlagen Systemdiagnosen fehl.
  • Nicht übereinstimmender Zielport für die Prüfung: Alle benutzerdefinierten Netzwerksicherheitsregeln oder Firewallkonfigurationen auf Knotenebene müssen den richtigen Zielport für die Systemdiagnose berücksichtigen. Bei NEG-Backends richten sich die Prüfungen direkt an den Port des Dienstes, bei Backends mit verwalteten Instanzgruppen (MIG) jedoch an den nodePort. Eine Abweichung bei der erwarteten Portkonfiguration führt dazu, dass Prüfungen fehlschlagen.
  • externalTrafficPolicy: Local-Verhalten: Wenn Ihr Dienst mit der Einstellung externalTrafficPolicy: Local konfiguriert ist, schlägt die Systemdiagnose des Load Balancers für Knoten, die keinen bereiten, bereitstellenden Pod für diesen Dienst hosten, absichtlich fehl. Wenn alle Pods für den Dienst im gesamten Cluster nicht bereit sind oder beendet werden, werden alle Backend-Knoten als fehlerhaft (0/X healthy) gemeldet.

Prüfbereiche für Systemdiagnosen für IPv6-LoadBalancer-Dienste

Systemdiagnoseprüfungen für IPv6-LoadBalancer-Dienste stammen aus anderen Quellbereichen als IPv4-Prüfungen. GKE erstellt Firewallregeln zum Zulassen von eingehendem Traffic für die folgenden IPv6-Quellbereiche:

  • 2600:2d00:1:b029::/64 für interne Passthrough-Network Load Balancer.
  • 2600:1901:8001::/48 für regionale externe Passthrough-Network-Load-Balancer.

Wenn Sie Ihre eigenen Firewallregeln verwalten, müssen Sie eingehenden Traffic aus diesen Bereichen zu Ihren Clusterknoten zulassen. Andernfalls schlagen Systemdiagnosen für IPv6-LoadBalancer-Dienste fehl.

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 GKE Dataplane V2 nicht 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 Destination Network Address Translation (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

In der folgenden Tabelle wird die Beziehung zwischen externalTrafficPolicy und der Frage dargestellt, 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 GKE Dataplane V2 nicht verwenden, ändert jeder Knoten, der Pakete mit Load Balancing empfangen hat, immer die Quell-IP-Adresse dieser Pakete, sodass sie mit der IP-Adresse des Knotens übereinstimmt, unabhängig davon, ob der Knoten die Pakete an einen lokalen Pod oder einen Pod auf einem anderen Knoten weiterleitet.

In GKE-Clustern, die GKE Dataplane V2 verwenden, ändert jeder Knoten, der Pakete mit Load Balancing empfangen hat, die Quell-IP-Adresse dieser Pakete so, dass sie mit der IP-Adresse des Knotens übereinstimmt, 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 die Quell-IP-Adresse dieser Pakete nicht.

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

externalTrafficPolicy Paketrouting mit Load Balancing Routing von Antwortpaketen
Cluster

Im Folgenden wird das Standardverhalten für das Routing von Paketen mit Load Balancing beschrieben:

  • Wenn der Knoten, der die Pakete mit Load-Balancing empfangen hat, keinen bereitstellenden, bereiten, nicht-terminierenden Pod hat, leitet dieser Knoten die Pakete an einen anderen Knoten weiter, der einen bereitstellenden, bereiten, nicht-terminierenden Pod hat.
  • Wenn der Knoten, der die per Load Balancing verteilten Pakete empfangen hat, einen bereitstellenden, bereiten, nicht-terminierenden Pod hat, kann der Knoten die Pakete an einen der folgenden weiterleiten:
    • Ein lokaler Pod.
    • Ein anderer Knoten, der einen bereitstellenden, bereiten, nicht-terminierenden Pod hat.

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 folgenden Auswirkungen:

  • 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 die Load-Balancing-Pakete 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 auf allen Knoten im Cluster keine bereitstellenden, bereiten und nicht beendenden Pods für den Dienst gibt, geschieht Folgendes:

  • Wenn „Proxy Terminating Endpoints“ aktiviert ist1, leitet der Knoten, der die Pakete mit Load Balancing empfangen hat, diese nach Möglichkeit an einen bereitstellenden, aber beendenden Pod weiter.
  • Wenn „Proxy Terminating Endpoints“ deaktiviert ist oder im gesamten Cluster keine Pods vorhanden sind, schließt der Knoten, der die 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 Load-Balancing-Pakete empfangen hat, sendet der Bereitstellungsknoten die Antwortpakete an den empfangenden Knoten zurück. Anschließend sendet der empfangende Knoten die Antwortpakete mithilfe von Direct Server Return.
  • Wenn der Knoten mit dem Bereitstellungs-Pod der Knoten ist, der die Load-Balancing-Pakete empfangen hat, sendet dieser Knoten die Antwortpakete mithilfe von Direct Server Return.
Local

Das folgende Verhalten ist das Standardverhalten für das Routing von Paketen mit Load Balancing: Der Knoten, der Pakete mit Load Balancing empfangen hat, hat im Allgemeinen einen bereitstellenden, bereiten, nicht beendenden Pod (da ein solcher Pod erforderlich ist, 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 nicht das grundlegende Verhalten für das Routing von Paketen mit Load Balancing.

Wenn auf dem Knoten, der die Load-Balancing-Pakete empfangen hat, keine bereitstellenden, bereiten, nicht-terminierenden Pods für den Dienst vorhanden sind, geschieht Folgendes:

  • Wenn „Proxy Terminating Endpoints“ aktiviert ist1, leitet der Knoten, der Pakete mit Load-Balancing empfangen hat, diese an einen lokalen Bereitstellungs-Pod weiter, der jedoch nach Möglichkeit beendet wird.
  • Wenn „Proxy Terminating Endpoints“ deaktiviert ist oder der Knoten, der Pakete mit Load-Balancing 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 Load-Balancing-Pakete empfangen hat. Dieser Knoten sendet die Antwortpakete mithilfe von Direct Server Return.

1 Proxy-Terminierungsendpunkte sind in diesen Konfigurationen aktiviert:

  • GKE-Cluster, die GKE Dataplane V2 nicht 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

Kontingente

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

Nächste Schritte