Nur-Proxy-Subnetze für Envoy-basierte Load-Balancer

Auf dieser Seite wird gezeigt, wie Sie Nur-Proxy-Subnetze verwenden, die von Envoy-basierten Load-Balancern verwendet werden. Ein Nur-Proxy-Subnetz bietet einen Pool von Proxys, die ausschließlich für Envoy-Proxys reserviert sind, die von Load-Balancern verwendet werden. Es kann nicht für andere Zwecke verwendet werden. Pro Region eines VPC-Netzwerks kann immer nur ein Nur-Proxy-Subnetz aktiv sein.

Die Proxys beenden eingehende Verbindungen und entscheiden dann anhand der URL-Zuordnung, der Sitzungsaffinität des Back-End-Dienstes, des Load-Balancing-Modus jeder Back-End-Instanzgruppe oder NEG und anderer Faktoren, wohin eine HTTP(S)-Anfrage gesendet wird.

  1. Ein Client stellt eine Verbindung zur IP-Adresse und zum Port der Weiterleitungsregel des Load-Balancers her.

  2. Jeder Proxy überwacht die IP-Adresse und den Port, die in der Weiterleitungsregel des entsprechenden Load-Balancers angegeben sind. Einer der Proxys empfängt und beendet die Netzwerkverbindung des Clients.

  3. Der Proxy stellt eine Verbindung zur entsprechenden Back-End-VM oder zum entsprechenden Back-End-Endpunkt einer Netzwerk-Endpunktgruppe her. Dies richtet sich nach der URL-Zuordnung und den Back-End-Diensten des Load-Balancers.

Jedem Proxy des Load-Balancers wird eine interne IP-Adresse zugewiesen. Pakete, die von einem Proxy an eine Back-End-VM oder einen Back-End-Endpunkt gesendet werden, haben eine Quell-IP-Adresse aus dem Nur-Proxy-Subnetz. Die Proxys für alle Load-Balancer in einer Region verwenden interne IP-Adressen aus einem einzigen Nur-Proxy-Subnetz in jener Region Ihres VPC-Netzwerks.

Nur-Proxy-Subnetze müssen unabhängig davon erstellt werden, ob Ihr Netzwerk im automatischen oder im benutzerdefinierten Modus arbeitet. Ein Nur-Proxy-Subnetz muss mindestens 64 IP-Adressen bereitstellen. Das entspricht einer Präfixlänge von maximal /26. Als Subnetzgröße wird /23 (512 Nur-Proxy-Adressen) empfohlen.

Die Proxyzuweisung erfolgt auf VPC-Ebene, nicht auf der Load-Balancer-Ebene. Sie müssen in jeder Region eines virtuellen Netzwerks (VPC), in dem Sie Envoy-basierte Load-Balancer verwenden, ein Nur-Proxy-Subnetz anlegen. Wenn Sie mehrere Load-Balancer in derselben Region und im selben VPC-Netzwerk bereitstellen, nutzen sie dasselbe Nur-Proxy-Subnetz für das Load-Balancing.

Das Nur-Proxy-Subnetz kann nicht für andere Zwecke verwendet werden. Die IP-Adresse für die Weiterleitungsregel des Load-Balancers stammt nicht aus dem Nur-Proxy-Subnetz. Auch die IP-Adressen der Back-End-VMs und -Endpunkte kommen nicht aus dem Nur-Proxy-Subnetz.

Unterstützte Load-Balancer

Die folgenden Load-Balancer erfordern Nur-Proxy-Subnetze:

Nur-Proxy-Subnetze in der Load-Balancer-Architektur

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die für einen regionalen externen HTTP(S)-Load-Balancer erforderlich sind.

Komponenten des regionalen externen HTTP(S)-Load-Balancers (zum Vergrößern klicken)
Komponenten des regionalen externen HTTP(S)-Load-Balancers (zum Vergrößern klicken)

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die für einen internen HTTP(S)-Load-Balancer erforderlich sind.

Nummerierte Komponenten des internen HTTP(S)-Load-Balancings (zum Vergrößern klicken)
Nummerierte Komponenten des internen HTTP(S)-Load-Balancers (zum Vergrößern klicken)

Wie in den Diagrammen dargestellt, sind für die Bereitstellung eines Envoy-basierten Load-Balancers mindestens zwei Subnetze erforderlich:

  • Die Back-End-VMs und Back-End-Endpunkte des Load-Balancers verwenden ein einzelnes Subnetz mit dem primären IP-Adressbereich 10.1.2.0/24 (in diesem Beispiel). Dieses Subnetz ist nicht das Nur-Proxy-Subnetz. Sie können für Ihre Back-End-VMs und -Endpunkte mehrere Subnetze verwenden. Die Subnetze müssen sich dazu in derselben Region wie der Load-Balancer befinden. Bei internen HTTP(S)-Load-Balancern muss sich auch die IP-Adresse des Load-Balancers, der der Weiterleitungsregel zugeordnet ist, in diesem Subnetz befinden.
  • Das Nur-Proxy-Subnetz ist 10.129.0.0/23 (in diesem Beispiel).

Nur-Proxy-Subnetz erstellen

Das Erstellen eines Nur-Proxy-Subnetzes erfolgt im Wesentlichen wie beim Erstellen eines Subnetzes, mit dem einzigen Unterschied, dass einige Flags hinzugefügt werden.

Sie können ein vorhandenes Subnetz nicht als Nur-Proxy-Subnetz wiederverwenden. In jeder Region, die einen Envoy-basierten Load-Balancer hat, müssen Sie ein neues Subnetz erstellen. Das liegt zum Teil daran, dass mit dem Befehl subnets update das Feld --purpose eines Subnetzes nicht geändert werden kann. Beim Nur-Proxy-Subnetz muss --purpose auf REGIONAL_MANAGED_PROXY gesetzt werden.

Für interne HTTP(S)-Load-Balancer ist --purpose=REGIONAL_MANAGED_PROXY die bevorzugte Einstellung; --purpose=INTERNAL_HTTPS_LOAD_BALANCER funktioniert jedoch auch.

Damit Sie Weiterleitungsregeln für Ihre regionalen Load-Balancer erstellen können, müssen Sie vorher für die Proxys der Load-Balancer ein Nur-Proxy-Subnetz einrichten. Wenn Sie versuchen, einen Load-Balancer zu konfigurieren, ohne zuvor ein Nur-Proxy-Subnetz für die Region erstellt zu haben, schlägt das Erstellen des Load-Balancers fehl.

Console

  1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
    Zur Seite "VPC-Netzwerke"
  2. Klicken Sie auf den Namen des freigegebenen VPC-Netzwerks, dem Sie ein Nur-Proxy-Subnetz hinzufügen möchten.
  3. Klicken Sie auf Subnetz hinzufügen.
  4. Geben Sie einen Namen ein.
  5. Wählen Sie eine Region aus.
  6. Setzen Sie Zweck auf Regional verwalteter Proxy.
  7. Geben Sie einen IP-Adressbereich ein.
  8. Klicken Sie auf Hinzufügen.

gcloud

Ein Nur-Proxy-Subnetz wird mit dem Befehl gcloud compute networks subnets create erstellt.

gcloud compute networks subnets create SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE

Die Felder sind so definiert:

  • SUBNET_NAME ist der Name des Nur-Proxy-Subnetzes.
  • REGION ist die Region des Nur-Proxy-Subnetzes.
  • VPC_NETWORK_NAME ist der Name des VPC-Netzwerks, das das Subnetz enthält.
  • CIDR_RANGE ist der primäre IP-Adressbereich des Subnetzes. Die Subnetzmaske darf maximal 26 lang sein, damit mindestens 64 IP-Adressen für Proxys in der Region verfügbar sind. Als Länge der Subnetzmaske wird /23 empfohlen.

Ein vollständiges Konfigurationsbeispiel finden Sie unter Nur-Proxy-Subnetz konfigurieren.

Damit Verbindungen vom Nur-Proxy-Subnetz akzeptiert werden, müssen Sie eine Firewallregel für Ihre Back-Ends konfigurieren. Ein vollständiges Konfigurationsbeispiel einschließlich der Einrichtung der Firewallregel finden Sie hier:

Proxyverfügbarkeit

Manchmal haben Google Cloud-Regionen nicht genügend Proxykapazität für einen neuen Load-Balancer. In diesem Fall gibt die Google Cloud Console beim Erstellen des Load-Balancers eine Warnmeldung zur Proxyverfügbarkeit aus. Sie haben folgende Möglichkeiten, dieses Problem zu beheben:

  • Wählen Sie eine andere Region für den Load-Balancer aus. Diese Option kann sinnvoll sein, wenn Sie Back-Ends in einer anderen Region haben.
  • Wählen Sie ein VPC-Netzwerk aus, dem bereits ein Nur-Proxy-Subnetz zugewiesen ist.
  • Warten Sie, bis das Kapazitätsproblem behoben ist.

Größe oder Adressbereich eines Nur-Proxy-Subnetzes ändern

Wenn Sie die Anzahl der Back-Ends in Ihrer Bereitstellung ändern, müssen Sie möglicherweise die Größe oder den Adressbereich Ihres Nur-Proxy-Subnetzes ändern.

Sie können ein Nur-Proxy-Subnetz nicht auf dieselbe Weise erweitern wie bei einem primären Adressbereich (mit dem Befehl expand-ip-range). Stattdessen müssen Sie ein Nur-Proxy-Subnetz als Sicherung erstellen, das Ihren Anforderungen entspricht, und es dann der aktiven Rolle zuweisen. Dies liegt daran, dass nur ein einzelnes Nur-Proxy-Subnetz pro Region und VPC-Netzwerk aktiv sein kann und Sie nur den primären IP-Adressbereich eines Subnetzes erweitern können.

Neue Verbindungen bleiben vom Hochstufen eines Nur-Proxy-Sicherungssubnetzes zum aktiven Nur-Proxy-Subnetz unberührt:

  • Das neu aktivierte Nur-Proxy-Subnetz wird für neue Verbindungen verwendet.
  • Das zuvor aktive und jetzt zum Sicherungssubnetz herabgestufte Nur-Proxy-Subnetz wird für neue Verbindungen nicht mehr verwendet.
  • Google Cloud beginnt, vorhandene Verbindungen von Proxys im zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetz auszugleichen.

Sie können pro Region und VPC-Netzwerk nur ein aktives Nur-Proxy-Subnetz und nur ein Nur-Proxy-Sicherungssubnetz erstellen.

Console

  1. Erstellen Sie ein Nur-Proxy-Sicherungssubnetz in derselben Region und geben Sie einen primären IP-Adressbereich an, der Ihren Anforderungen entspricht.

    1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
      Zur Seite "VPC-Netzwerke"
    2. Klicken Sie auf den Namen des freigegebenen VPC-Netzwerks, dem Sie ein Nur-Proxy-Subnetz hinzufügen möchten.
    3. Klicken Sie auf Subnetz hinzufügen.
    4. Geben Sie einen Namen ein.
    5. Wählen Sie eine Region aus.
    6. Setzen Sie Zweck auf Regional verwalteter Proxy.
    7. Wählen Sie als Rolle die Option Sicherung aus.
    8. Geben Sie einen IP-Adressbereich ein.
    9. Klicken Sie auf Hinzufügen.
  2. Erstellen oder ändern Sie für Ihre Back-End-VMs oder -Endpunkte Firewallregeln, die eingehenden Traffic zulassen. Die Regeln müssen den primären IP-Adressbereich des Nur-Proxy-Sicherungssubnetzes enthalten.

  3. Stufen Sie das Nur-Proxy-Subnetz, das als Back-up dient, zum aktiven Subnetz hoch. Diese Aktion stuft auch das zuvor aktive Nur-Proxy-Subnetz zur Back-up-Rolle herab:

    1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
      Zur Seite "VPC-Netzwerke"
    2. Klicken Sie auf den Namen des freigegebenen VPC-Netzwerks, das Sie ändern möchten.
    3. Suchen Sie unter Reservierte Nur-Proxy-Subnetze für das Load-Balancing das im vorherigen Schritt erstellte Sicherungssubnetz.
    4. Klicken Sie auf Activate (Aktivieren).
    5. Geben Sie ein optionales Drain-Zeitlimit an.
    6. Klicken Sie auf Subnetz aktivieren.
  4. Wenn das Zeitlimit für den Verbindungsausgleich abgelaufen ist oder sichergestellt ist, dass Verbindungen zu Ihren Back-End-VMs oder -Endpunkten nicht von Proxys im zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetz stammen, haben Sie folgende Möglichkeiten:

    • Ändern Sie die Firewallregeln für zulässigen eingehenden Traffic für Ihre Back-End-VMs oder -Endpunkte so, dass diese nicht den primären IP-Adressbereich des zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetzes enthalten.
    • Durch Löschen des zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetzes können Sie die IP-Adressen freigeben, die dieses Subnetz für seinen primären IP-Adressbereich verwendet hat.

gcloud

  1. Erstellen Sie ein Nur-Proxy-Sicherungssubnetz in derselben Region und geben Sie mit dem Befehl gcloud compute networks subnets create mit dem Flag --role=BACKUP einen primären IP-Bereich an, der Ihren Anforderungen entspricht.

    gcloud compute networks subnets create BACKUP_PROXY_SUBNET \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=BACKUP \
       --region=REGION \
       --network=VPC_NETWORK_NAME \
       --range=CIDR_RANGE
    
  2. Erstellen oder ändern Sie für Ihre Back-End-VMs oder -Endpunkte Firewallregeln, die eingehenden Traffic zulassen. Die Regeln müssen den primären IP-Adressbereich des Nur-Proxy-Sicherungssubnetzes enthalten.

  3. Mit dem folgenden gcloud-Befehl wird ein Nur-Proxy-Sicherungssubnetz zum aktiven Subnetz hochgestuft und das zuvor aktive Nur-Proxy-Subnetz zum Sicherungssubnetz herabgestuft:

    gcloud compute networks subnets update BACKUP_PROXY_SUBNET \
       --region=REGION \
       --role=ACTIVE \
       --drain-timeout=CONNECTION_DRAINING_TIMEOUT
    

    Dabei gilt:

    • BACKUP_PROXY_SUBNET: der Name des neu erstellten Nur-Proxy-Sicherungssubnetzes
    • REGION: Region des neu erstellten Nur-Proxy-Sicherungssubnetzs
    • CONNECTION_DRAINING_TIMEOUT: die Zeit in Sekunden, die Google Cloud zum Migrieren vorhandener Verbindungen von Proxys im zuvor aktiven Nur-Proxy-Subnetz zur Verfügung hat.
  4. Wenn das Zeitlimit für den Verbindungsausgleich abgelaufen ist oder sichergestellt ist, dass Verbindungen zu Ihren Back-End-VMs oder -Endpunkten nicht von Proxys im zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetz stammen, haben Sie folgende Möglichkeiten:

    • Ändern Sie die Firewallregeln für zulässigen eingehenden Traffic für Ihre Back-End-VMs oder -Endpunkte so, dass diese nicht den primären IP-Adressbereich des zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetzes enthalten.
    • Durch Löschen des zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetzes können Sie die IP-Adressen freigeben, die dieses Subnetz für seinen primären IP-Adressbereich verwendet hat.

Beispiel: Nur-Proxy-Subnetz ändern

Dieser Abschnitt enthält eine Beispielkonfiguration, die die Schritte zum Ändern des Nur-Proxy-Subnetzes in einer Region zeigt.

  1. Erstellen Sie ein Nur-Proxy-Sicherungssubnetz für die Region.

    gcloud compute networks subnets create new-l7ilb-backend-subnet-us-west1 \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=BACKUP \
       --region=us-west1 \
       --network=default \
       --range=10.130.0.0/23
    
  2. Aktualisieren Sie die Back-End-Firewall, um Verbindungen vom neuen Subnetz zuzulassen.

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.129.0.0/23,10.130.0.0/23
    
  3. Legen Sie das neue Subnetz als ACTIVE Nur-Proxy-Subnetz in der Region fest und warten Sie, bis der Verbindungsausgleich des alten Subnetzes abgeschlossen ist.

    gcloud compute networks subnets update new-l7ilb-ip-range-us-west1 \
       --drain-timeout 1h --role ACTIVE
    

    Wenn Sie einen sofortigen Verbindungsausgleich für einen IP-Adressbereich ausführen möchten, legen Sie für --drain-timeout den Wert 0s fest. Dadurch werden unmittelbar alle Verbindungen zu den Proxys beendet, denen Adressen im Subnetz zugewiesen wurden, für das ein Verbindungsausgleich ausgeführt wird.

  4. Kontrollieren Sie den Status des Verbindungsausgleichs mit dem Befehl list oder describe. Das Subnetz hat während des Verbindungsausgleichs den Status DRAINING.

    gcloud compute networks subnets list
    

    Warten Sie, bis der Verbindungsausgleich abgeschlossen ist. Anschließend erhält das alte Nur-Proxy-Subnetz den Status READY.

  5. Ändern Sie die Back-End-Firewallregel, um nur Verbindungen aus dem neuen Subnetz zuzulassen.

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.130.0.0/23
    
  6. Löschen Sie das alte Subnetz.

    gcloud compute networks subnets delete l7ilb-ip-range-us-west1 \
       --region us-west1
    

Nur-Proxy-Subnetz löschen

Wenn Sie ein Nur-Proxy-Subnetz löschen, wird sein primärer IP-Adressbereich freigegeben und kann für einen anderen Zweck verwendet werden. Für Google Cloud gelten bei Eingang einer Anfrage zum Löschen eines Nur-Proxy-Subnetzes die folgenden Regeln:

  • Ein aktives Nur-Proxy-Subnetz kann nicht gelöscht werden, wenn sich in derselben Region und im selben VPC-Netzwerk ein oder mehrere regionale Load-Balancer befinden.

  • Ein aktives Nur-Proxy-Subnetz kann nicht gelöscht werden, wenn in derselben Region und im selben VPC-Netzwerk ein Nur-Proxy-Sicherungssubnetz vorhanden ist.

    Wenn Sie versuchen, ein aktives Nur-Proxy-Subnetz zu löschen, bevor Sie die Sicherung löschen, wird die folgende Fehlermeldung angezeigt: "Ungültige Ressourcennutzung: Aktives Subnetzwerk kann nicht gelöscht werden, da ein Sicherungssubnetz vorhanden ist."

In der Praxis haben diese Regeln folgende Auswirkungen:

  • Wenn in einer bestimmten Region und in einem bestimmten VPC-Netzwerk kein regionaler Load-Balancer definiert ist, können Sie die Nur-Proxy-Subnetze in dieser Region löschen. Wenn ein Nur-Proxy-Sicherungssubnetz vorhanden ist, müssen Sie dieses vor dem aktiven Nur-Proxy-Subnetz löschen.

  • Wenn in einer bestimmten Region und in einem bestimmten VPC-Netzwerk mindestens ein regionaler Load-Balancer festgelegt ist, können Sie das aktive Nur-Proxy-Subnetz nicht löschen. Sie haben aber die Möglichkeit, ein Nur-Proxy-Sicherungssubnetz zum aktiven Subnetz hochzustufen. Dadurch wird das zuvor aktive Nur-Proxy-Subnetz automatisch zum Sicherungssubnetz herabgestuft. Nachdem die Verbindungen geändert wurden, können Sie das (zuvor aktive) Nur-Proxy-Subnetz löschen.

Weitere Informationen finden Sie in der VPC-Netzwerkdokumentation unter Subnetze löschen.

Beschränkungen

Für Nur-Proxy-Subnetze gelten die folgenden Einschränkungen:

  • Sie können nicht sowohl ein INTERNAL_HTTPS_LOAD_BALANCER als auch ein REGIONAL_MANAGED_PROXY Subnetz im selben Netzwerk und in derselben Region haben, genauso wie Sie nicht zwei REGIONAL_MANAGED_PROXY Proxys oder zwei INTERNAL_HTTPS_LOAD_BALANCER Proxys haben können.

  • Sie können pro Region und VPC-Netzwerk nur ein aktives Nur-Proxy-Subnetz und nur ein Nur-Proxy-Sicherungssubnetz erstellen.

  • Sie können nur dann ein Nur-Proxy-Sicherungssubnetz in einer Region und in einem Netzwerk erstellen, wenn Sie darin zuvor ein Nur-Proxy-Subnetz angelegt haben.

  • Sie können ein Nur-Proxy-Sicherungssubnetz zu einem aktiven Nur-Proxy-Subnetz hochstufen. In diesem Fall wird von Google Cloud das zuvor aktive Nur-Proxy-Subnetz automatisch zum Nur-Proxy-Sicherungssubnetz herabgestuft. Sie können ein Nur-Proxy-Subnetz nicht explizit als Nur-Proxy-Sicherungssubnetz festlegen.

  • Während des Zeitraums des Verbindungsausgleichs eines Nur-Proxy-Subnetzes (--drain-timeout) können Sie ein Nur-Proxy-Sicherungssubnetz nicht zu einem aktiven Nur-Proxy-Subnetz hochstufen.

  • Von Google Cloud wird keine Warnung ausgegeben, wenn das Nur-Proxy-Subnetz keine IP-Adressen mehr hat.

  • Nur-Proxy-Subnetze unterstützen keine VPC-Flusslogs.

Nächste Schritte