Übersicht über zonale Netzwerk-Endpunktgruppen

Eine Netzwerk-Endpunktgruppe (NEG) ist ein Konfigurationsobjekt, das eine Gruppe von Back-End-Endpunkten oder -Diensten angibt. Zonale NEGs sind zonale Ressourcen, die Kombinationen aus IP-Adressen oder IP-Adressen/Port-Kombinationen für Google Cloud-Ressourcen in einem einzelnen Subnetz darstellen.

Sie können in NEGs IP-Adressen und Ports in logischen Gruppen zusammenstellen, die anstelle ganzer VMs nur Softwaredienste abbilden. Das ist ein weiterer praktischer Nutzen von NEGs. Als Endpunkte können IP-Adressen für Mikrodienste dienen, die in GCP-VMs ausgeführt und von anderen Orchestrierungstools wie Apache Mesos oder Cloud Foundry verwaltet werden.

Informationen zu anderen NEG-Typen finden Sie unter:

Es gibt zwei Arten von zonalen NEGs, je nach Art der Netzwerkendpunkte, aus denen die NEG besteht. Beide Arten von zonalen NEG unterstützen unterschiedliche Anwendungsfälle und Load-Balancer.

Sie können zonale NEGs nicht als Back-End mit Netzwerk-Load-Balancing verwenden.

GCE_VM_IP-NEGs

Diese zonalen NEGs enthalten einen oder mehrere interne Netzwerkendpunkte, die in eine primäre IP-Adresse einer Compute Engine-VM aufgelöst werden. Mit dieser Art von zonaler NEG können Sie keinen Port angeben.

Diese Endpunkte können nur als Back-Ends in Back-End-Diensten für interne TCP/UDP-Load-Balancer verwendet werden.

Mit GCE_VM_IP-NEGs können Sie nur Endpunkte anhängen, die zur primären internen IP-Adresse einer VM im VPC-Netzwerk von NEG gehören. Primäre interne IP-Adressen einer NIC einer VM mit mehreren NICs können einer NEG hinzugefügt werden, solange die NEG dasselbe VPC-Netzwerk wie die NIC verwendet.

GCE-VM_IP_PORT-NEGs

Diese zonalen NEGs enthalten einen oder mehrere interne Netzwerkendpunkte, die in eine primäre interne IP-Adresse einer VM oder in eine IP-Adresse in einem ihrer Alias-IP-Bereiche aufgelöst werden. Beispielsweise verwendet GKE NEGs dieses Typs, wobei die Endpunkte eine IP-Adresse aus dem Alias-IP-Bereich des Knotens plus einem Port sind – eine Pod-IP-Adresse und ein Containerport. Jeder Netzwerkendpunkt wird mithilfe einer Kombination aus IP-Adresse und Port angegeben.

Diese NEGs können als Back-Ends in Back-End-Diensten für externe HTTP(S)-, internes HTTP-, TCP-Proxy- und SSL-Proxy-Load-Balancing verwendet werden. Sie können keine GCE_VM_IP_PORT-Endpunkte mit internen TCP/UDP-Load-Balancern oder Netzwerk-Load-Balancern verwenden. Da es möglich ist, IP-Adressen und Ports für die zonalen NEG-Back-Ends anzugeben, lässt sich der Traffic differenziert und zielgerichtet auf die Anwendungen und Container verteilen, die innerhalb von VM-Instanzen ausgeführt werden.

Wenn Sie für Container oder Anwendungen, die in einer VM ausgeführt werden, einen eindeutigen GCE_VM_IP_PORT-Netzwerkendpunkt erstellen möchten, müssen Sie entweder die primäre IP-Adresse der VM verwenden oder eine sekundäre IP-Adresse, die der VM mit der Funktion der Alias-IP-Adresse zugewiesen wird. Die im Container ausgeführte Software oder die in der VM ausgeführte Anwendung muss so konfiguriert sein, dass sie sich an die vom Netzwerkendpunkt verwendete IP-Adresse bindet.

GCE_VM_IP_PORT-NEGs sind besonders nützlich für GKE. Informationen zur Verwendung von NEGs mit GKE finden Sie unter Containernatives Load-Balancing verwenden.

Endpunktbeziehungen

Bei der Erstellung einer NEG wählen Sie eine Zone, ein Netzwerk und ein Subnetz aus. Jede Endpunkt-IP-Adresse muss sich im selben Subnetz befinden wie die zonale NEG.

Wenn Sie ein Netzwerk im automatischen Modus auswählen, müssen Sie kein Subnetz eingeben. Dennoch wird der zonalen NEG ein Subnetz zugewiesen. Wenn Sie für die NEG ein Netzwerk im automatischen Modus, aber kein Subnetz auswählen, wird das automatisch erstellte Subnetz aus der Region verwendet, zu der die von Ihnen für die NEG ausgewählte Zone gehört.

Der Typ der erstellten NEG wird beim Erstellen der NEG angegeben (entweder GCE_VM_IP oder GCE_VM_IP_PORT). Damit wird festgelegt, welche Arten von Endpunkten die NEG unterstützt.

Für die zonalen NEGs GCE_VM_IP und GCE_VM_IP_PORT gilt:

  • Sie müssen für jeden VM-Endpunkt den Namen angeben.

  • Jede Endpunkt-VM muss sich in derselben Zone befinden wie die NEG.

  • Jeder Endpunkt in der NEG muss eine eindeutige Kombination aus IP-Adresse und Port sein. Auf eine eindeutige Kombination aus IP-Adressen und Ports kann von mehr als einer NEG verwiesen werden.

  • Jede Endpunkt-VM muss eine Netzwerkschnittstelle (NIC) im selben VPC-Netzwerk wie die NEG haben. Endpunkt-IP-Adressen müssen mit demselben Subnetz verknüpft sein, das in der NEG angegeben ist.

  • Jede NEG unterstützt maximal die maximale Anzahl von Endpunkten pro NEG. Die Endpunkte können auf so viele einzelne VMs oder alle auf einer VM verteilt werden.

Bei GCE_VM_IP_PORT-NEGs können Sie beim Hinzufügen eines Endpunkts eine IP-Adresse und einen Port, nur eine IP-Adresse oder keine der beiden angeben:

  • Wenn Sie eine IP-Adresse und einen Port angeben, kann die IP-Adresse entweder die primäre interne IP-Adresse der VM-NIC oder eine Alias-IP-Adresse auf der NIC sein. Sie können selbst einen Port auswählen.

  • Wenn Sie nur eine IP-Adresse angeben, kann die IP-Adresse entweder die primäre interne IP-Adresse der VM-NIC oder eine Alias-IP-Adresse auf der NIC sein. Der verwendete Port ist der Standardport der NEG.

  • Wenn Sie beides weglassen, wählt Google Cloud die primäre interne IP-Adresse der NIC aus und verwendet den Standardport der NEG.

Load-Balancing mit zonalen NEGs

Zonale NEGs können als Back-Ends für Back-End-Dienste in einem Load-Balancer verwendet werden. Wenn Sie eine zonale NEG als Back-End für einen Back-End-Dienst verwenden, müssen auch alle anderen Back-Ends in diesem Back-End-Dienst zonale NEGs desselben Typs sein (entweder alle GCE_VM_IP oder GCE_VM_IP_PORT). Sie können Instanzgruppen und zonale NEGs nicht als Back-Ends im selben Back-End-Dienst verwenden.

Sie können denselben Netzwerkendpunkt mehreren zonalen NEGs hinzufügen. Sie können dieselbe zonale NEG als Back-End für mehr als einen Back-End-Dienst verwenden.

Zonale GCE_VM_IP_PORT-NEGs können entweder den RATE-Balancing-Modus oder den CONNECTIONBalancing-Modus verwenden, je nach Protokoll des Back-End-Dienstes. Unterstützte Load-Balancer müssen eine Zielkapazität definieren.

Zonale GCE_VM_IP-NEGs müssen den CONNECTION-Balancing-Modus verwenden. Sie können keine Zielkapazität definieren, da interne TCP/UDP-Load-Balancer die Zielkapazitätseinstellung nicht unterstützen.

Zonale NEG-Back-Ends können nicht den Balancing-Modus UTILIZATION verwenden.

Internes TCP/UDP-Load-Balancing

Zonale NEGs mit GCE_VM_IP-Endpunkten können nur als Back-End-Dienste für interne TCP/UDP-Load-Balancer verwendet werden.

Für NEGs mit GCE_VM_IP-Endpunkten gelten folgende primäre Anwendungsfälle:

Vereinfachte VM-Verwaltung für interne TCP/UDP-Load-Balancer

Wie bei Instanzgruppen können Sie dieselbe NEG als Back-End für mehrere interne TCP/UDP-Load-Balancer verwenden. Im Unterschied zu Instanzgruppen kann ein VM-Endpunkt zu mehreren NEGs gehören und jede dieser NEGs kann als Back-End für einen oder mehrere interne TCP/UDP-Load-Balancer verwendet werden.

Interne TCP/UDP-Load-Balancer mit überlappenden zonalen GCE-VM-IP-NEGs
Interne TCP/UDP-Load-Balancer mit überlappenden zonalen NEGs

GKE-Teilmengeneinstellung

GKE verwendet GCP_VM_IP zonale NEGs und Teilmengeneinstellung zur Verbesserung der Skalierbarkeit interner TCP/UDP-Load-Balancer:

Ohne Teilmengeneinstellung erstellt GKE eine nicht verwaltete Instanzgruppe pro Zone, die aus den Knoten des Clusters aus allen Knotenpools in dieser Zone besteht. Diese zonalen Instanzgruppen werden als Back-Ends für einen oder mehrere interne LoadBalancer-Dienste verwendet (und für externe Ingress-Instanzen, die keine NEGs selbst verwenden).

Mit der Teilmengeneinstellung erstellt GKEGCE_VM_IP zonale NEGs für jeden internen LoadBalancer-Dienst. Derselbe Endpunkt kann Mitglied von mehreren zonalen NEGs sein. Im Gegensatz zu Instanzgruppen kann Google Cloud das Load-Balancing auf mehrere zonale NEGs ausführen, die denselben Endpunkt enthalten.

Durch Teilmengeneinstellung wird der Traffic effizienter auf interne LoadBalancer-Dienste in Clustern mit mehr als 250 Knoten verteilt. Beispiel: Ein GKE-Cluster mit 300 Knoten könnte einen internen LoadBalancer-Dienst mit 25 Knoten in einer NEG haben, da es 25 Bereitstellungs-Pods für diesen Dienst gibt. Nicht alle 300 Knoten müssen zu einem Instanzgruppen-Back-End für diesen Dienst hinzugefügt werden.

Beachten Sie, dass auch Kontingente für NEGs, Weiterleitungsregeln, Back-End-Dienste und andere Google Cloud-Netzwerkressourcen gelten.

Externes HTTP(S)-, internes HTTP(S)-, TCP-Proxy- und SSL-Proxy-Load-Balancing

Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten können als Back-Ends für Back-End-Dienste in den folgenden Arten von Load-Balancern verwendet werden: externes HTTP(S), internes HTTP(S), TCP-Proxy und SSL-Proxy-Load-Balancing.

Der primäre Anwendungsfall für zonale GCE_VM_IP_PORT-NEGs ist containernatives Load-Balancing, damit Sie den Traffic direkt auf Container verteilen können, die auf VMs ausgeführt werden, z. B. auf Pod-IP-Adressen. in GKE-Clustern.

Das folgende Beispiel zeigt, wie Load-Balancer Traffic auf Mikrodienste verteilen, die in Containern auf Ihren VMs ausgeführt werden. Die VMs sind so konfiguriert, dass sie Alias-IP-Bereiche aus ihren Subnetzen verwenden, und diese Bereiche sind die Adressen, die von den Containern verwendet werden.

Load-Balancing zonaler Netzwerk-Endpunktgruppen mit Containern (zum Vergrößern klicken)
Load-Balancing zonaler Netzwerk-Endpunktgruppen mit Containern (zum Vergrößern klicken)

Die folgenden Abbildungen zeigen Konfigurationskomponenten für HTTP(S)-Load-Balancer, TCP/SSL-Proxy-Load-Balancer und interne HTTP(S)-Load-Balancer, deren Back-Ends zonale NEGs sind:

  • Premium-Stufe – Jeder HTTP(S)-, SSL-Proxy- und TCP-Proxy-Load-Balancer hat eine eigene globale externe Weiterleitungsregel, die Traffic an das entsprechende Zielproxy-Objekt weiterleitet.

  • Standardstufe – Jeder HTTP(S)-, SSL-Proxy- und TCP-Proxy-Load-Balancer hat eine eigene regionale externe Weiterleitungsregel, die Traffic an das entsprechende Zielproxy-Objekt weiterleitet.

  • Jeder interne HTTP(S)-Load-Balancer hat eine eigene regionale, intern verwaltete Weiterleitungsregel, die Traffic an das entsprechende Zielproxy-Objekt weiterleitet.

  • Für Ziel-HTTP(S)-Proxys wird der verwendete Back-End-Dienst ermittelt, indem Name und Pfad des Anfragehosts in der URL-Zuordnung geprüft werden. Im Fall von externen HTTP(S)- und internen HTTP(S)-Load-Balancern kann die URL-Zuordnung auf mehrere Back-End-Dienste verweisen.

  • Für Ziel-TCP- oder Ziel-SSL-Proxys kann nur ein Back-End-Dienst definiert werden.

  • Der Back-End-Dienst leitet Traffic an seine Back-End-NEGs weiter. Für jede Anfrage wählt der Load-Balancer einen Netzwerkendpunkt aus einer der zonalen NEGs aus und sendet den Traffic dorthin.

Zonale Netzwerk-Endpunktgruppen im Load-Balancing (zum Vergrößern klicken)
Zonale Netzwerk-Endpunktgruppen im Load-Balancing (zum Vergrößern klicken)

Anwendungsfall: containernatives Load-Balancing

Containernatives Load-Balancing ermöglicht Load-Balancern, Pods direkt anzusteuern und Entscheidungen zur Lastverteilung auf Pod- statt auf VM-Ebene zu treffen. Es gibt zwei Möglichkeiten, das containernative Load-Balancing zu konfigurieren: Sie können entweder von GKE Ingress verwaltete NEGs verwenden oder eigenständige NEGs.

Kubernetes Ingress mit NEGs (empfohlen)

Wenn NEGs mit Ingress verwendet werden, erleichtert der Ingress-Controller das Erstellen aller Aspekte des L7-Load-Balancers. Dazu gehören u. a. das Erstellen der virtuellen IP-Adresse, Weiterleitungsregeln, Systemdiagnosen und Firewallregeln. Informationen zu dieser Konfiguration finden Sie unter Containernatives Load-Balancing über Ingress.

Ingress ist die empfohlene Methode für den Einsatz von NEGs mit containernativem Load-Balancing, da es viele Features bietet, die das Verwalten von NEGs vereinfachen. Eigenständige NEGs sind dann eine Option, wenn von Ingress verwaltete NEGs nicht für Ihren Anwendungsfall geeignet sind.

Eine Anleitung zum Einrichten eines Load-Balancers über Ingress finden Sie unter Containernatives Load-Balancing über Ingress.

Eigenständige NEGs

Wenn zonale NEGs mit Load-Balancern bereitgestellt werden, die nicht von Ingress stammen, werden sie als eigenständige NEGs betrachtet. Eigenständige zonale NEGs werden über den NEG-Controller bereitgestellt und verwaltet. Weiterleitungsregeln, Systemdiagnosen und andere Load-Balancing-Objekte werden manuell bereitgestellt.

Beispiele für die Verwendung von eigenständigen zonalen NEGs mit GKE finden Sie unter:

Beschränkungen

  • Sie können keine zonalen NEGs mit Legacy-Netzwerken verwenden.
  • Back-End-Dienste, die NEGs als Back-Ends verwenden, können nicht gleichzeitig auch Instanzgruppen als Back-Ends verwenden.

Einschränkungen für zonale GCE_VM_IP-NEGs:

  • Zonale NEGs mit GCE_VM_IP-Endpunkten werden nur mit internen TCP/UDP-Load-Balancern unterstützt.
  • Das Attribut default-port wird für zonale GCE_VM_IP-NEGs nicht unterstützt.
  • Sie können die Cloud Console nicht zum Erstellen oder Verwalten von GCE_VM_IP-NEGs verwenden. Verwenden Sie entweder gcloud oder die REST API.

Kontingente

  • Informationen zu NEG-Kontingenten, z. B. NEGs pro Projekt, NEGs pro Back-End-Dienst und Endpunkte pro NEG, finden Sie auf der Seite Kontingente für Load-Balancing.

Fehlerbehebung

Traffic erreicht die Endpunkte nicht

Nach der Konfiguration des Dienstes sind neue Endpunkte in der Regel erreichbar, sobald sie der NEG zugeordnet wurden, vorausgesetzt, sie reagieren auf Systemdiagnosen.

Wenn der Traffic die Endpunkte nicht erreicht, führt dies zu einem 502-Fehlercode bei HTTP(S)- oder zu abgelehnten Verbindungen bei TCP/SSL-Load-Balancern. Prüfen Sie in diesem Fall Folgendes:

  • Prüfen Sie, ob die Firewallregeln eingehenden TCP-Traffic an Ihre Endpunkte in den Bereichen 130.211.0.0/22 und 35.191.0.0/16 zulassen.
  • Prüfen Sie, ob die Endpunkte fehlerfrei sind. Verwenden Sie dazu gcloud, wie unten gezeigt, oder rufen Sie in der Back-End-Dienstressource die API getHealth oder in der zonalen NEG die API listEndpoints auf, wobei Sie den Parameter showHealth auf SHOW einstellen. Mit dem folgenden gcloud-Befehl werden Systemstatusinformationen nach Netzwerkendpunkt angezeigt:
gcloud compute network-endpoint-groups list-network-endpoints NAME \
    --zone=ZONE

Nächste Schritte