Übersicht über zonale Netzwerk-Endpunktgruppen

Sie können zonale Netzwerk-Endpunktgruppen (NEGs) als Back-End für einen Back-End-Dienst verwenden. Diese Konfiguration dient hauptsächlich dazu, Container auf Ihren VMs bereitzustellen, in denen Sie Dienste ausführen können. Außerdem können Sie Traffic detailliert auf Anwendungen verteilen, die in den VMs ausgeführt werden.

In diesem Dokument wird die Verwendung zonaler Netzwerk-Endpunktgruppen mit den folgenden Load-Balancer-Typen beschrieben:

Mit den folgenden Load-Balancer-Typen können zonale NEGs nicht als Back-End verwendet werden:

Informationen zu Internet-NEGs finden Sie unter Übersicht über Endpunktgruppen für das Internet.

Informationen zu serverlosen NEGs finden Sie unter Übersicht über Endpunktgruppen für serverlose Netzwerke.

Übersicht

Zonale Netzwerk-Endpunktgruppen (NEGs) sind zonale Ressourcen, die Kombinationen aus IP-Adressen und Ports für Google Cloud-Ressourcen innerhalb eines einzelnen Subnetzes darstellen. Eine Kombination aus IP-Adresse und Port wird als Netzwerkendpunkt bezeichnet.

Zonale Netzwerk-Endpunktgruppen können als Back-Ends in Back-End-Diensten für HTTP(S)-, internes HTTP-, TCP-Proxy- und SSL-Proxy-Load-Balancing verwendet werden. Für interne TCP/UDP-Load-Balancer können NEGs nicht als Back-End verwendet werden. 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.

Endpunktbeziehungen

Bei der Erstellung einer Netzwerk-Endpunktgruppe 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.

Netzwerk-Endpunktgruppen unterstützen derzeit nur den Typ GCE_VM_IP_PORT. Dies bedeutet, dass für einzelne Endpunkte IP-Adressen erforderlich sind, die mit Google Cloud-VMs verknüpft sind. Beim Hinzufügen von Endpunkten zu einer zonalen NEG gilt Folgendes:

  • Geben Sie den Namen der VM-Instanz an. Die VM-Instanz muss sich in derselben Zone befinden wie die NEG und die Netzwerkschnittstelle im VPC-Netzwerk muss sich in einem Subnetz der Region befinden, zu der diese Zone gehört.

  • Eine NEG kann bis zu 10.000 Endpunkte enthalten, die alle zur selben VM gehören können. Die Endpunkte werden erstellt, wenn sie in eine vorhandene NEG eingefügt werden und dabei auf die VM verwiesen wird. Endpunkte, die in verschiedenen NEGs erstellt werden, können auf dieselbe VM verweisen.

    • Zusätzlich zur VM-Instanz können Sie eine IP-Adresse oder eine Kombination aus IP-Adresse und Port angeben. Jede IP-Adresse, die Sie angeben, muss entweder die primäre interne IP-Adresse der VM oder eine Alias-IP-Adresse für die VM im selben Subnetz wie die zonale NEG sein.

    • Wenn Sie beim Hinzufügen eines Endpunkts keine IP-Adresse angeben, wird die primäre interne IP-Adresse der VM im VPC-Netzwerk verwendet.

    • Wenn Sie beim Hinzufügen eines Endpunkts keinen Port angeben, müssen Sie für die zonale NEG einen Standardport definiert haben. Endpunkte verwenden den Standardport, sofern kein spezifischer Port angegeben ist. Das bedeutet, Sie müssen entweder einen Standardport angeben, wenn Sie ein zonales NEG erstellen, oder für jeden hinzugefügten Endpunkt einen Port angeben.

    • Jeder Endpunkt in einer zonalen NEG muss eine eindeutige Kombination aus IP-Adresse und Port sein. Wenn Sie keinen Port für die IP-Adresse auswählen, wird die IP-Adresse mit dem Standardport kombiniert.

Endpunkte, Container und Services

Wenn Sie für Container oder Anwendungen, die in einer VM ausgeführt werden, einen eindeutigen 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.

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

Außerdem können Sie 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.

Load-Balancing

Zonale NEGs können als Back-Ends für Back-End-Dienste in den folgenden Load-Balancer-Typen verwendet werden:

  • ein externer HTTP(S)-Load-Balancer
  • ein internen HTTP(S)-Load-Balancer
  • ein SSL-Proxy-Load-Balancer
  • ein TCP-Proxy-Load-Balancer

Der primäre Anwendungsfall für zonale NEGs ist containernatives Load-Balancing. Damit können Sie den Traffic auf Mikrodienste verteilen, die in Containern auf Ihren VMs ausgeführt werden.

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)

Back-End-Dienste

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 sein. Sie können Instanzgruppen und zonale NEGs nicht als Back-Ends im selben Back-End-Dienst verwenden.

Sie können denselben Netzwerkendpunkt (Kombination aus IP-Adresse und Port) mehreren zonalen NEGs hinzufügen. Sie können dieselbe zonale NEG als Back-End für mehr als einen Back-End-Dienst verwenden.

Back-End-Dienste mit NEGs als Back-End können nur die Balancing-Modi RATE oder CONNECTION verwenden. Der Balancing-Modus UTILIZATION kann nicht für Back-End-Dienste verwendet werden, die NEGs als Back-Ends einsetzen.

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

Sie können zonale Netzwerk-Endpunktgruppen in Load-Balancern mit den Netzwerkdienststufen Standard oder Premium verwenden.

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)

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.

In der folgenden Liste wird der allgemeine Prozess beschrieben, der zum Einrichten des Load-Balancings mit eigenständigen NEGs erforderlich ist:

  1. Konfigurieren Sie Container oder Dienste auf den VMs. Wenn auf jeder VM mehrere Container ausgeführt werden sollen oder Sie IP-Adressen für die Container benötigen, konfigurieren Sie Alias-IP-Adressen für die VMs. Bei der Konfiguration von Diensten müssen mindestens zwei Dienste auf derselben VM ausgeführt werden, damit zumindest die Portnummern unterschiedlich sind.
  2. Erstellen Sie zonale Netzwerk-Endpunktgruppen.
  3. Fügen Sie den zonalen Netzwerk-Endpunktgruppen Netzwerkendpunkte hinzu.
  4. Erstellen Sie eine Systemdiagnose.
  5. Erstellen Sie einen Back-End-Dienst.
  6. Erstellen Sie für HTTP(S)-Load-Balancing eine URL-Zuordnung und verbinden Sie den Back-End-Dienst damit.
  7. Erstellen Sie den geeigneten Typ des Zielproxys, z. B. einen HTTP-, HTTPS-, SSL- oder TCP-Proxy. Verknüpfen Sie den Zielproxy mit der URL-Zuordnung (bei HTTP(S)-Load-Balancing) oder mit dem Back-End-Dienst (bei TCP-Proxy- und SSL-Proxy-Load-Balancing).
  8. Erstellen Sie eine Weiterleitungsregel und verknüpfen Sie sie mit dem Zielproxy.

So hängen Sie einen Load-Balancer an eigenständige zonale NEGs an:

Beschränkungen

  • Sie können keine zonalen NEGs mit Legacy-Netzwerken verwenden.
  • Die IP-Adresse für einen Netzwerkendpunkt muss eine primäre oder Alias-IP-Adresse sein, die zur angegebenen VM-Instanz gehört.

Beschränkungen

  • Zonale NEGs können nur als Back-Ends für Load-Balancer verwendet werden. Die folgenden Load-Balancer-Typen unterstützen zonale NEGs: HTTP(S), Internes HTTP(S), TCP-Proxy und SSL-Proxy.
  • Zonale NEGs für HTTP(s)-Load-Balancing unterstützen nur den RATE-Balancing-Modus. CONNECTION wird für TCP/SSL-Load-Balancing unterstützt. Nutzungsbasiertes Load-Balancing wird nicht unterstützt.
  • Back-End-Dienste, die NEGs als Back-Ends verwenden, können nicht gleichzeitig auch Instanzgruppen als Back-Ends verwenden.
  • Derzeit können nur interne IP-Adressen (RFC 1918) zu einer zonalen NEG hinzugefügt werden.
  • 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

Weitere Informationen