Ü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. Die beiden Typen von zonalen NEGs unterstützen unterschiedliche Anwendungsfälle und Load-Balancer-Typen.

NEGs mit GCE_VM_IP-Endpunkten

Passthrough-Network Load Balancer unterstützen zonale NEGs mit GCE_VM_IP-Endpunkten. Diese zonalen NEGs enthalten einen oder mehrere Endpunkte, die mithilfe der primären internen IPv4-Adresse der Netzwerkschnittstelle einer Compute Engine-VM dargestellt werden.

Obwohl Google Cloud eine IP-Adresse verwendet, um den Endpunkt darzustellen, dient ein GCE_VM_IP-Endpunkt dazu, die Netzwerkschnittstelle selbst zu identifizieren. Die Netzwerkschnittstelle muss sich im Subnetz der NEG befinden.

Da ein GCE_VM_IP-Endpunkt eine Netzwerkschnittstelle identifiziert, können Sie keinen Port mit einem GCE_VM_IP-Endpunkt angeben.

Diese Typen von Endpunkten können nur als Backends in Backend-Diensten für interne Passthrough-Network-Load-Balancer und externe Passthrough-Network-Load-Balancer verwendet werden.

NEGs mit GCE_VM_IP_PORT-Endpunkten

Diese zonalen NEGs enthalten eine oder mehrere der folgenden Kombinationen aus IP-Adresse oder IP-Adresse und Zielport:

  • Die primäre interne IPv4-Adresse einer VM-Netzwerkschnittstelle
  • Die primäre interne IPv4-Adresse einer VM-Netzwerkschnittstelle plus eine Zielportnummer
  • Eine interne IPv4-Adresse aus dem Alias-IP-Adressbereich, der einer VM-Netzwerkschnittstelle zugewiesen ist
  • Eine interne IPv4-Adresse aus dem Alias-IP-Adressbereich, der einer VM-Netzwerkschnittstelle zugewiesen ist, sowie eine Zielportnummer

Die Netzwerkschnittstelle mit dem Endpunkt GCE_VM_IP_PORT muss sich im Subnetz der NEG befinden. Wenn Sie bei einem GCE_VM_IP_PORT-Endpunkt eine Portnummer weglassen, verwendet Google Cloud die Standardportnummer der NEG für den Endpunkt.

Da es möglich ist, IP-Adressen und Ports für diese 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. GKE verwendet GCE_VM_IP_PORT-Endpunkte für:

Sie können selbstverwaltete Load-Balancer erstellen, die zonale NEGs verwenden, deren GCE_VM_IP_PORT-Endpunkte von GKE verwaltet werden. Weitere Informationen finden Sie unter Containernatives Load-Balancing über eigenständige zonale NEGs.

Application Load Balancer und Proxy-Network Load Balancer unterstützen zonale NEGs mit GCE_VM_IP_PORT-Endpunkten.

Endpunktspezifikation

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

Zonale GCE_VM_IP_PORT-NEGs

Für zonale GCE_VM_IP_PORT-NEGs muss Folgendes zutreffen:

  • 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 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 an der Netzwerkschnittstelle oder eine Alias-IP-Adresse auf der Netzwerkschnittstelle 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 auf der Netzwerkschnittstelle oder eine Alias-IP-Adresse auf der Netzwerkschnittstelle sein. Der verwendete Port ist der Standardport der NEG.

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

Zonale GCE_VM_IP-NEGs

Für zonale GCE_VM_IP-NEGs muss Folgendes zutreffen:

  • 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 einer GCE_VM_IP-NEG muss eine eindeutige IP-Adresse sein. Auf eine eindeutige Endpunkt-IP-Adresse kann von mehr als einer NEG verwiesen werden.

  • Jede GCE_VM_IP-NEG ist immer einem Netzwerk und einem Subnetzwerk zugeordnet. Wenn Sie einen Endpunkt hinzufügen, können Sie eine IP-Adresse angeben oder nicht. Wenn eine IP-Adresse angegeben ist, muss sie auf die primäre interne IP-Adresse der angehängten VM-Instanz festgelegt werden, die dem Subnetzwerk der NEG entspricht. Die primäre interne IP-Adresse einer Netzwerkschnittstelle einer VM-Instanz mit mehreren NICs kann einer NEG hinzugefügt werden, solange sie mit dem NEG-Subnetzwerk übereinstimmt.

  • Jede NEG unterstützt maximal die maximale Anzahl von Endpunkten pro NEG. Die Endpunkte müssen auf alle eindeutigen VMs verteilt werden. Mehrere Endpunkte können sich nicht auf einer einzelnen VM befinden, da eine VM nicht mehr als eine Netzwerkschnittstelle haben kann, die demselben Subnetz zugeordnet ist.

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 Backend für mehr als einen Backend-Dienst verwenden.

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

Zonale GCE_VM_IP-NEGs müssen den Balancing-Modus CONNECTION verwenden. Darüber hinaus unterstützen interne Passthrough-Network Load Balancer und externe Passthrough-Network Load Balancer die Einstellung für die Zielkapazität nicht.

Passthrough-Network-Load-Balancer

Zonale NEGs mit GCE_VM_IP-Endpunkten können nur für interne Passthrough-Network-Load-Balancer und externe Passthrough-Network-Load-Balancer als Backends für Backend-Dienste verwendet werden.

In den folgenden Abschnitten finden Sie die primären Anwendungsfälle für NEGs mit GCE_VM_IP-Endpunkten.

Flexible Endpunktgruppierung

Wie bei Instanzgruppen können Sie dieselbe NEG als Backend für mehrere Passthrough-Network-Load-Balancer verwenden. Im Unterschied zu Instanzgruppen kann ein NEG-Endpunkt zu mehreren NEGs gehören und jede dieser NEGs kann als Backend für einen oder mehrere Passthrough-Network-Load-Balancer verwendet werden. Im Vergleich zu Instanzgruppen sind Sie nicht durch die Tatsache eingeschränkt, dass eine VM-Instanz nur Teil einer einzelnen Instanzgruppe sein kann.

Die folgende Abbildung zeigt ein Beispiel für die Architektur eines internen Passthrough-Network Load Balancers mit einer freigegebenen VM.

Interne Passthrough-Network Load Balancer mit überlappenden zonalen GCE-VM-IP-NEGs.
Interne Passthrough-Network Load Balancer mit überlappenden zonalen NEGs (zum Vergrößern klicken).

Nicht-nic0-Schnittstellen als Back-End-Endpunkte

Zonale NEGs mit GCE_VM_IP-Endpunkten ermöglichen das Load-Balancing zu Nicht-nic0-Netzwerkschnittstellen von VMs. Dies kann bei der Einbindung in Appliance-VMs von Drittanbietern nützlich sein, die in der Regel nic0 für Verwaltungsvorgänge reservieren. Mit GCE_VM_IP-NEGs kann jede Nicht-nic0-Netzwerkschnittstelle derselben VM an ein NEG-Backend eines Passthrough-Network Load Balancers angehängt werden.

GKE-Teilmengeneinstellung

GKE verwendet zonale GCE_VM_IP-NEGs und die Teilmengeneinstellung zur Verbesserung der Skalierbarkeit interner Passthrough-Network-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, Backend-Dienste und andere Google Cloud-Netzwerkressourcen gelten.

Weitere Informationen finden Sie unter Teilmengeneinstellung für internen Passthrough-Network-Load-Balancer verwenden.

Anwendungs-Load-Balancer und Proxy-Netzwerk-Load-Balancer

Die folgenden Abbildungen zeigen Konfigurationskomponenten für Load-Balancer, deren Back-Ends zonale NEGs mit GCE_VM_IP_PORT-Endpunkten sind:

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

Weitere Informationen zu den Architekturanforderungen dieser Load Balancer finden Sie unter:

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.

Containernatives Load-Balancing ermöglicht Load-Balancern, Pods direkt anzusteuern und Entscheidungen zur Lastverteilung auf Pod- statt auf VM-Ebene zu treffen.

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.
Load-Balancing zonaler Netzwerk-Endpunktgruppen mit Containern (zum Vergrößern klicken).

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 HTTP(S)-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. Alternativ können Sie einen Proxy-Load-Balancer manuell erstellen. Allerdings muss GKE die NEG-Endpunktmitgliedschaft verwalten, wie im nächsten Punkt beschrieben (Eigenständige NEGs).

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

  • Eigenständige NEGs

    Eigenständige NEGs bieten Ihrem GKE-Cluster die Möglichkeit, zonale NEGs mit GCE_VM_IP_PORT-Endpunkten zu erstellen, die Pod-IP-Adressen und Container-Ports darstellen, und geben Ihnen gleichzeitig die Flexibilität, die Load Balancer-Komponenten außerhalb von GKE zu konfigurieren.

    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.
  • Backend-Dienste, die NEGs als Backends verwenden, können nicht gleichzeitig auch Instanzgruppen als Backends verwenden.

Einschränkungen für zonale GCE_VM_IP-NEGs:

  • Zonale NEGs mit GCE_VM_IP-Endpunkten werden nur bei internen Passthrough-Network-Load-Balancern und externen Passthrough-Network-Load-Balancern unterstützt.
  • Das Attribut default-port wird für zonale GCE_VM_IP-NEGs nicht unterstützt.

Kontingente

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

Nächste Schritte