Regionenübergreifenden internen Application Load Balancer mit Cloud Run einrichten

In diesem Dokument wird gezeigt, wie Sie einen regionenübergreifenden internen Application Load Balancer mit Cloud Run bereitstellen. Dazu verwenden Sie ein serverloses NEG-Backend für den Load-Balancer.

Serverlose NEGs bieten Ihnen die Möglichkeit, Cloud Run-Dienste mit Ihrem Load-Balancer zu verwenden. Nachdem Sie einen Load-Balancer mit dem serverlosen NEG-Backend konfiguriert haben, werden Anfragen an den Load-Balancer zum Cloud Run-Backend geleitet.

Das überregionale Load-Balancing sorgt für Redundanz. Wenn eine Region nicht erreichbar ist, wird der Traffic automatisch in eine andere Region umgeleitet. Abhängig vom Standort des Envoys wird der Proxy-Traffic so an Cloud Run-Dienste verteilt:

  • Wenn multiregionale Cloud Run-Dienste in derselben Region wie Envoy konfiguriert sind, wird die NEG bevorzugt, die sich in derselben Region wie Envoy befindet. Traffic wird nur dann an die Failover-Region gesendet, wenn die Ausreißererkennung aktiviert und die lokale NEG fehlerhaft ist.
  • Wenn multiregionale Cloud Run-Dienste nicht in derselben Region wie Envoy konfiguriert sind, wird der Traffic gleichmäßig auf alle NEGs verteilt. Die NEGs in der Nähe sind nicht bevorzugt.
  • Wenn Identity-Aware Proxy aktiviert ist, wird nur eine einzelne serverlose NEG unterstützt. Sie können jedoch zusätzliche Cloud Run-Dienste konfigurieren, aber der Load-Balancer sendet keinen Traffic an sie.

Hinweise

Bevor Sie diese Anleitung durcharbeiten, sollten Sie sich mit Folgendem vertraut machen:

Cloud Run-Dienst bereitstellen

Bei den Anleitungen auf dieser Seite wird davon ausgegangen, dass Sie bereits einen Cloud Run-Dienst ausführen.

Für das Beispiel auf dieser Seite können Sie jede der Cloud Run-Kurzanleitungen verwenden, um einen Cloud Run-Dienst bereitzustellen.

Beschränken Sie den eingehenden Traffic auf internal, um den Zugriff auf den Cloud Run-Dienst über das Internet zu verhindern. Traffic vom internen Anwendungs-Load-Balancer wird als interner Traffic betrachtet.

Durch die Platzierung des Cloud Run-Dienstes in mehreren Regionen werden Fehler in einer einzelnen Region vermieden. Führen Sie die folgenden Befehle aus, um den Cloud Run-Dienst in den Regionen REGION_A und REGION_B bereitzustellen:

gcloud

gcloud run deploy CLOUD_RUN_SERVICE_NAMEA \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_A \
   --image=IMAGE_URLA

gcloud run deploy CLOUD_RUN_SERVICE_NAMEB \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_B \
   --image=IMAGE_URLB

Notieren Sie sich den Namen des Dienstes, den Sie erstellen. Auf der restlichen Seite wird beschrieben, wie Sie einen Load-Balancer einrichten, der Anfragen an diesen Dienst weiterleitet.

SSL-Zertifikatsressource einrichten

Erstellen Sie eine Zertifikatmanager-SSL-Zertifikatsressource:

Wir empfehlen die Verwendung eines von Google verwalteten Zertifikats.

Berechtigungen

Damit Sie dieser Anleitung folgen können, müssen Sie in der Lage sein, Instanzen zu erstellen und ein Netzwerk in einem Projekt zu ändern. Sie müssen entweder Inhaber oder Bearbeiter des Projekts sein oder alle folgenden Compute Engine-IAM-Rollen haben.

Aufgabe Erforderliche Rolle
Netzwerke, Subnetze und Load-Balancer-Komponenten erstellen Compute-Netzwerkadministrator
Firewallregeln hinzufügen und löschen Compute-Sicherheitsadministrator
Instanzen erstellen Compute-Instanzadministrator

Weitere Informationen finden Sie in folgenden Leitfäden:

Einrichtung: Übersicht

Sie können den regionenübergreifenden internen Application Load Balancer wie im folgenden Diagramm beschrieben konfigurieren:

Regionenübergreifender interner Application Load Balancer mit Cloud Run-Bereitstellung.
Regionenübergreifender interner Application Load Balancer mit Cloud Run-Bereitstellung (zum Vergrößern klicken).

Wie im Diagramm dargestellt, wird in diesem Beispiel ein regionenübergreifender interner Anwendungs-Load-Balancer in einem VPC-Netzwerk mit einem Back-End-Dienst und zwei Cloud Run-Bereitstellungen inREGION_A undREGION_B Regionen erstellt.

Die Einrichtung des regionenübergreifenden internen Application Load Balancers wird so beschrieben:

  1. Ein VPC-Netzwerk mit den folgenden Subnetzen:

    • Subnetz SUBNET_A und ein Nur-Proxy-Subnetz in REGION_A.
    • Subnetz SUBNET_B und ein Nur-Proxy-Subnetz in REGION_B.

    Sie müssen in jeder Region eines VPC-Netzwerks, in dem Sie regionenübergreifende interne Application Load Balancer verwenden, Nur-Proxy-Subnetze erstellen. Das Nur-Proxy-Subnetz der Region wird von allen regionenübergreifenden internen Application Load Balancern in der Region gemeinsam genutzt. Quelladressen von Paketen, die der Load-Balancer an die Back-Ends Ihres Dienstes sendet, werden vom Nur-Proxy-Subnetz zugewiesen. In diesem Beispiel hat das Nur-Proxy-Subnetz für die Region REGION_A den primären IP-Adressbereich 10.129.0.0/23 und für REGION_B den primären IP-Adressbereich 10.130.0.0/23. Dies ist die empfohlene Subnetzgröße.

  2. Eine Firewallregel, die Nur-Proxysubnetz-Traffic in Ihrem Netzwerk zulässt. Dies bedeutet, dass Sie eine Regel hinzufügen müssen, die Traffic von den TCP-Ports 80, 443 und 8080 über 10.129.0.0/23 und 10.130.0.0/23 zulässt (in diesem Beispiel der Bereich des Nur-Proxy-Subnetzes).

  3. Eine weitere Firewallregel für die Systemdiagnoseprüfungen.

  4. Eine Hochverfügbarkeitskonfiguration mit serverlosen Back-Ends für Cloud Run-Bereitstellungen in den Regionen REGION_A und REGION_B. Wenn die Back-Ends in einer Region zufällig ausfallen, wird der Traffic auf die andere Region umgeleitet.

  5. Ein globaler Backend-Dienst, der die Nutzung und die Integrität von Backends überwacht. Achten Sie darauf, dass für den Backend-Dienst die Ausreißererkennung aktiviert ist.

  6. Eine globale URL-Zuordnung, die die URL einer Anfrage parst und Anfragen anhand des Hosts und Pfades der Anfrage-URL an bestimmte Backend-Dienste weiterleitet.

  7. Ein globaler HTTP- oder HTTPS-Zielproxy, der eine Anfrage vom Nutzer empfängt und an die URL-Zuordnung weiterleitet. Konfigurieren Sie für HTTPS eine regionale SSL-Zertifikatsressource. Der Zielproxy verwendet das SSL-Zertifikat, um SSL-Traffic zu entschlüsseln, wenn Sie das HTTPS-Load-Balancing konfigurieren. Der Zielproxy kann Traffic über HTTP oder HTTPS an Ihre Instanzen weiterleiten.

  8. Globale Weiterleitungsregeln, die die interne IP-Adresse Ihres Load-Balancers haben, um jede eingehende Anfrage an den Zielproxy weiterzuleiten.

    Die mit der Weiterleitungsregel verknüpfte interne IP-Adresse kann aus jedem Subnetz im selben Netzwerk und in derselben Region stammen. Beachten Sie folgende Bedingungen:

    • Die IP-Adresse kann (nicht erforderlich) aus demselben Subnetz wie die Backend-Instanzgruppen stammen.
    • Die IP-Adresse darf nicht aus dem reservierten Nur-Proxy-Subnetz stammen, dessen Flag --purpose auf GLOBAL_MANAGED_PROXY gesetzt ist.
    • Wenn Sie dieselbe interne IP-Adresse mit mehreren Weiterleitungsregeln verwenden möchten, setzen Sie das Flag --purpose für die IP-Adresse auf SHARED_LOADBALANCER_VIP.

  9. Optional: Konfigurieren Sie DNS-Routingrichtlinien vom Typ GEO, um Clienttraffic an die Load-Balancer-VIP in der Region weiterzuleiten, die dem Client am nächsten ist.

Netzwerk und Subnetze konfigurieren

Konfigurieren Sie im VPC-Netzwerk ein Subnetz in jeder Region, in der Ihre Back-Ends konfiguriert sind. Konfigurieren Sie außerdem in jeder Region, in der Sie den Load-Balancer konfigurieren möchten, ein proxy-only-subnet.

In diesem Beispiel werden das folgende VPC-Netzwerk, die folgende Region und die folgenden Subnetze verwendet:

  • Netzwerk. Das Netzwerk ist ein VPC-Netzwerk im benutzerdefinierten Modus mit dem Namen NETWORK.

  • Subnetze für Back-Ends Ein Subnetz mit dem Namen SUBNET_A in der Region REGION_A verwendet 10.1.2.0/24 für seinen primären IP-Bereich. Das Subnetz mit dem Namen SUBNET_A in der Region REGION_B verwendet 10.1.3.0/24 für seinen primären IP-Bereich.

  • Subnetz für Proxys. Ein Subnetz mit dem Namen PROXY_SN_A in der Region REGION_A verwendet 10.129.0.0/23 für seinen primären IP-Bereich. Ein Subnetz mit dem Namen PROXY_SN_B in der Region REGION_B verwendet 10.130.0.0/23 für seinen primären IP-Bereich.

Auf mehrere regionenübergreifende interne Application Load Balancer kann von jeder Region innerhalb der VPC aus zugegriffen werden. Daher können Clients aus jeder Region global auf Ihre Load-Balancer-Back-Ends zugreifen.

Backend-Subnetze konfigurieren

Console

  1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

    Zur Seite VPC-Netzwerke

  2. Klicken Sie auf VPC-Netzwerk erstellen.

  3. Geben Sie einen Namen für das Netzwerk an.

  4. Wählen Sie im Abschnitt Subnetze als Modus für die Subnetzerstellung Benutzerdefiniert aus.

  5. Erstellen Sie ein Subnetz für die Back-Ends des Load-Balancers. Geben Sie im Bereich Neues Subnetz folgende Informationen ein:

    • Geben Sie einen Namen für das Subnetz an.
    • Wählen Sie eine Region aus: REGION_A
    • Geben Sie einen IP-Adressbereich ein: 10.1.2.0/24

  6. Klicken Sie auf Fertig.

  7. Klicken Sie auf Subnetz hinzufügen.

  8. Erstellen Sie ein Subnetz für die Back-Ends des Load-Balancers. Geben Sie im Bereich Neues Subnetz folgende Informationen ein:

    • Geben Sie einen Namen für das Subnetz an.
    • Wählen Sie eine Region aus: REGION_B
    • Geben Sie einen IP-Adressbereich ein: 10.1.3.0/24

  9. Klicken Sie auf Fertig.

  10. Klicken Sie auf Erstellen.

gcloud

  1. Erstellen Sie mit dem Befehl gcloud compute networks create das benutzerdefinierte VPC-Netzwerk:

    gcloud compute networks create NETWORK --subnet-mode=custom

  2. Erstellen Sie mit dem Befehl gcloud compute networks subnets create ein Subnetz im Netzwerk NETWORK in der Region REGION_A:

    gcloud compute networks subnets create SUBNET_A \
    --network=NETWORK \
    --range=10.1.2.0/24 \
    --region=REGION_A

  3. Erstellen Sie mit dem Befehl gcloud compute networks subnets create ein Subnetz im Netzwerk NETWORK in der Region REGION_B:

    gcloud compute networks subnets create SUBNET_B \
    --network=NETWORK \
    --range=10.1.3.0/24 \
    --region=REGION_B

API

Stellen Sie eine POST-Anfrage an die Methode networks.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

Stellen Sie eine POST-Anfrage an die Methode subnetworks.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

Stellen Sie eine POST-Anfrage an die Methode subnetworks.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

Nur-Proxy-Subnetz konfigurieren

Ein Nur-Proxy-Subnetz stellt eine Reihe von IP-Adressen bereit, die Google Cloud zum Ausführen von Envoy-Proxys in Ihrem Namen verwendet. Die Proxys beenden Verbindungen vom Client und erstellen neue Verbindungen zu den Back-Ends.

Dieses Nur-Proxy-Subnetz wird von allen Envoy-basierten regionalen Load-Balancern in derselben Region des VPC-Netzwerks verwendet. Pro Zweck, Region und Netzwerk kann jeweils nur ein Nur-Proxy-Subnetz aktiv sein.

Console

Wenn Sie die Google Cloud Console verwenden, können Sie das Nur-Proxy-Subnetz später auf der Seite Load Balancing erstellen.

Führen Sie die folgenden Schritte aus, wenn Sie jetzt das Nur-Proxy-Subnetz erstellen möchten:

  1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

    Zur Seite VPC-Netzwerke

  2. Klicken Sie auf den Namen des VPC-Netzwerks.
  3. Klicken Sie auf dem Tab Subnetze auf Subnetz hinzufügen.
  4. Geben Sie einen Namen für das Nur-Proxy-Subnetz an.
  5. Wählen Sie in der Liste Region REGION_A aus.
  6. Wählen Sie in der Liste Zweck die Option Regionenübergreifender verwalteter Proxy aus.
  7. Geben Sie im Feld IP-Adressbereich den Wert 10.129.0.0/23 ein.
  8. Klicken Sie auf Hinzufügen.

Erstellen Sie das Nur-Proxy-Subnetz in REGION_B.

  1. Klicken Sie auf Subnetz hinzufügen.
  2. Geben Sie einen Namen für das Nur-Proxy-Subnetz an.
  3. Wählen Sie in der Liste Region REGION_B aus.
  4. Wählen Sie in der Liste Zweck die Option Regionenübergreifender verwalteter Proxy aus.
  5. Geben Sie im Feld IP-Adressbereich den Wert 10.130.0.0/23 ein.
  6. Klicken Sie auf Hinzufügen.

gcloud

Erstellen Sie das Nur-Proxy-Subnetz mit dem Befehl gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23
    
    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23

API

Erstellen Sie das Nur-Proxy-Subnetz mit der Methode subnetworks.insert und ersetzen Sie PROJECT_ID dabei durch Ihre Projekt-ID.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": "PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

Serverlose NEGs erstellen

  1. Erstellen Sie eine serverlose NEG für Ihren Cloud Run-Dienst:

    gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-a \
   --region=REGION_A \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEA

    gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-b \
   --region=REGION_B \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEB

Load-Balancer konfigurieren

Traffic, der vom Load-Balancer zu den serverlosen NEG-Back-Ends geht, verwendet spezielle Routen außerhalb der VPC, die keinen Firewallregeln unterliegen. Wenn Ihr Load-Balancer nur serverlose NEG-Backends hat, müssen Sie keine Firewallregeln erstellen, um Traffic vom Nur-Proxy-Subnetz zum serverlosen Backend zuzulassen.

Console

Konfiguration starten

  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

    Load-Balancing aufrufen

  2. Klicken Sie auf Load-Balancer erstellen.
  3. Wählen Sie unter Typ des Load Balancers die Option Application Load Balancer (HTTP/HTTPS) aus und klicken Sie auf Weiter.
  4. Wählen Sie für Öffentlich oder intern die Option Intern aus und klicken Sie auf Weiter.
  5. Wählen Sie für Regionenübergreifende oder Einzelregions-Bereitstellung die Option Best für regionenübergreifende Arbeitslasten aus und klicken Sie auf Weiter.
  6. Klicken Sie auf Konfigurieren.

Grundlegende Konfiguration

  1. Geben Sie einen Namen für den Load Balancer an.
  2. Wählen Sie für Netzwerk die Option NETWORK aus.

Frontend mit zwei Weiterleitungsregeln konfigurieren

Bei HTTP:

  1. Klicken Sie auf Front-End-Konfiguration.
    1. Geben Sie einen Namen für die Weiterleitungsregel an.
    2. Wählen Sie in der Liste Subnetzwerkregion die Option REGION_A aus.

      Nur-Proxy-Subnetz reservieren

    3. Wählen Sie in der Liste Subnetzwerk die Option SUBNET_A aus.
    4. Klicken Sie in der Liste IP-Adresse auf IP-Adresse erstellen. Die Seite Statische interne IP-Adresse reservieren wird geöffnet.
      • Geben Sie einen Namen für die statische IP-Adresse an.
      • Wählen Sie im Abschnitt Statische IP-Adresse die Option Selbst auswählen aus.
      • Geben Sie im Abschnitt Benutzerdefinierte IP-Adresse 10.1.2.99 ein.
      • Wählen Sie Reservieren aus.
  2. Klicken Sie auf Fertig.
  3. Klicken Sie auf Front-End-IP und -Port hinzufügen, um die zweite Weiterleitungsregel hinzuzufügen.
    1. Geben Sie einen Namen für die Weiterleitungsregel an.
    2. Wählen Sie in der Liste Subnetzwerkregion die Option REGION_B aus.

      Nur-Proxy-Subnetz reservieren

    3. Wählen Sie in der Liste Subnetzwerk die Option SUBNET_B aus.
    4. Klicken Sie in der Liste IP-Adresse auf IP-Adresse erstellen. Die Seite Statische interne IP-Adresse reservieren wird geöffnet.
      • Geben Sie einen Namen für die statische IP-Adresse an.
      • Wählen Sie im Abschnitt Statische IP-Adresse die Option Selbst auswählen aus.
      • Geben Sie im Abschnitt Benutzerdefinierte IP-Adresse 10.1.3.99 ein.
      • Wählen Sie Reservieren aus.
  4. Klicken Sie auf Fertig.

Bei HTTPS:

Wenn Sie HTTPS zwischen dem Client und dem Load-Balancer verwenden, benötigen Sie eine oder mehrere SSL-Zertifikatsressourcen, um den Proxy zu konfigurieren. Informationen zum Erstellen eines all-regions von Google verwalteten Zertifikats finden Sie in der folgenden Dokumentation:

Nachdem Sie das von Google verwaltete Zertifikat erstellt haben, hängen Sie das Zertifikat direkt an den Zielproxy an. Zertifikatzuordnungen werden nicht von regionsübergreifenden internen Application Load Balancern unterstützt.

Informationen zum Erstellen eines selbstverwalteten all-regions-Zertifikats finden Sie in der folgenden Dokumentation: Regionales selbstverwaltetes Zertifikat bereitstellen.

  1. Klicken Sie auf Front-End-Konfiguration.
    1. Geben Sie einen Namen für die Weiterleitungsregel an.
    2. Wählen Sie im Feld Protokoll die Option HTTPS (includes HTTP/2) aus.
    3. Achten Sie darauf, dass der Port auf 443 festgelegt ist.
    4. Wählen Sie in der Liste Subnetzwerkregion die Option REGION_A aus.

      Nur-Proxy-Subnetz reservieren

    5. Wählen Sie in der Liste Subnetzwerk die Option SUBNET_A aus.
    6. Klicken Sie in der Liste IP-Adresse auf IP-Adresse erstellen. Die Seite Statische interne IP-Adresse reservieren wird geöffnet.
      • Geben Sie einen Namen für die statische IP-Adresse an.
      • Wählen Sie im Abschnitt Statische IP-Adresse die Option Selbst auswählen aus.
      • Geben Sie im Abschnitt Benutzerdefinierte IP-Adresse 10.1.3.99 ein.
      • Wählen Sie Reservieren aus.
    7. Wählen Sie im Abschnitt Zertifikat hinzufügen das Zertifikat aus.
    8. Optional: So fügen Sie zusätzlich zum primären SSL-Zertifikat Zertifikate hinzu:
      1. Klicken Sie auf Zertifikat hinzufügen.
      2. Wählen Sie das Zertifikat aus der Liste aus.
    9. Wählen Sie aus der Liste SSL-Richtlinie eine SSL-Richtlinie aus. Wenn Sie keine SSL-Richtlinien erstellt haben, wird eine Google Cloud-SSL-Standardrichtlinie angewendet.
    10. Klicken Sie auf Fertig.

    Fügen Sie die zweite Frontend-Konfiguration hinzu:

    1. Geben Sie einen Namen für die Front-End-Konfiguration an.
    2. Wählen Sie im Feld Protokoll die Option HTTPS (includes HTTP/2) aus.
    3. Achten Sie darauf, dass der Port auf 443 festgelegt ist.
    4. Wählen Sie in der Liste Subnetzwerkregion die Option REGION_B aus.

      Nur-Proxy-Subnetz reservieren

    5. Wählen Sie in der Liste Subnetzwerk die Option SUBNET_B aus.
    6. Klicken Sie in der Liste IP-Adresse auf IP-Adresse erstellen. Die Seite Statische interne IP-Adresse reservieren wird geöffnet.
      • Geben Sie einen Namen für die statische IP-Adresse an.
      • Wählen Sie im Abschnitt Statische IP-Adresse die Option Selbst auswählen aus.
      • Geben Sie im Abschnitt Benutzerdefinierte IP-Adresse 10.1.3.99 ein.
      • Wählen Sie Reservieren aus.
    7. Wählen Sie im Abschnitt Zertifikat hinzufügen das Zertifikat aus.
    8. Optional: So fügen Sie zusätzlich zum primären SSL-Zertifikat Zertifikate hinzu:
      1. Klicken Sie auf Zertifikat hinzufügen.
      2. Wählen Sie das Zertifikat aus der Liste aus.
    9. Wählen Sie aus der Liste SSL-Richtlinie eine SSL-Richtlinie aus. Wenn Sie keine SSL-Richtlinien erstellt haben, wird eine Google Cloud-SSL-Standardrichtlinie angewendet.
    10. Klicken Sie auf Fertig.
    Backend-Dienst konfigurieren
    1. Klicken Sie auf Backend-Konfiguration.
    2. Klicken Sie in der Liste Backend-Dienste erstellen oder auswählen auf Backend-Dienst erstellen.
    3. Geben Sie einen Namen für den Backend-Dienst an.
    4. Wählen Sie für Protokoll die Option HTTP aus.
    5. Geben Sie als Benannter Port http ein.
    6. Wählen Sie in der Liste Backend-Typ die Option Endpunktgruppe in serverlosem Netzwerk aus.
    7. Im Abschnitt Neues Back-End:
      • Wählen Sie in der Liste Endpunktgruppe in serverlosem Netzwerk die Option gl7ilb-serverless-neg-a aus.
      • Klicken Sie auf Fertig.
      • Klicken Sie auf Backend hinzufügen, um ein weiteres Backend hinzuzufügen.
      • Wählen Sie in der Liste Endpunktgruppe in serverlosem Netzwerk die Option gl7ilb-serverless-neg-b aus.
      • Klicken Sie auf Fertig.

    Routingregeln konfigurieren

    1. Klicken Sie auf Routingregeln.
    2. Wählen Sie unter Modus die Option Einfache Host- und Pfadregel aus.
    3. Achten Sie darauf, dass für alle nicht übereinstimmenden Hosts und alle nicht übereinstimmenden Pfade nur ein Backend-Dienst vorhanden ist.

    Konfiguration prüfen

    1. Klicken Sie auf Prüfen und abschließen.
    2. Prüfen Sie die Konfigurationseinstellungen des Load-Balancers.
    3. Klicken Sie auf Erstellen.

gcloud

  1. Definieren Sie den Backend-Dienst mit dem Befehl gcloud compute backend-services create.

    gcloud compute backend-services create gil7-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --global

  2. Fügen Sie dem Backend-Dienst mit dem Befehl gcloud compute backend-services add-backend Backends hinzu.

    gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-a \
  --network-endpoint-group-region=REGION_A \
  --global

    gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-b \
  --network-endpoint-group-region=REGION_B \
  --global

  3. Erstellen Sie die URL-Zuordnung mit dem Befehl gcloud compute url-maps create.

    gcloud compute url-maps create gil7-map \
  --default-service=gil7-backend-service \
  --global

  4. Erstellen Sie den Zielproxy.

    Bei HTTP:

    Erstellen Sie den Zielproxy mit dem Befehl gcloud compute target-http-proxies create.

    gcloud compute target-http-proxies create gil7-http-proxy \
  --url-map=gil7-map \
  --global

    Bei HTTPS:

    Informationen zum Erstellen eines von Google verwalteten Zertifikats finden Sie in der folgenden Dokumentation:

    Nachdem Sie das von Google verwaltete Zertifikat erstellt haben, hängen Sie das Zertifikat direkt an den Zielproxy an. Zertifikatzuordnungen werden nicht von regionsübergreifenden internen Application Load Balancern unterstützt.

    Informationen zum Erstellen eines selbstverwalteten Zertifikats finden Sie in der folgenden Dokumentation:

    Weisen Sie Ihre Dateipfade den entsprechenden Variablennamen zu.

    export LB_CERT=PATH_TO_PEM_FORMATTED_FILE

    export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE

    Erstellen Sie mit dem Befehl gcloud certificate-manager certificates create ein SSL-Zertifikat für alle Regionen.

    gcloud certificate-manager certificates create gilb-certificate \
  --private-key-file=$LB_CERT \
  --certificate-file=$LB_PRIVATE_KEY \
  –-scope=all-regions

    Verwenden Sie das regionale SSL-Zertifikat, um mit dem Befehl gcloud compute target-https-proxies create einen Zielproxy zu erstellen.

    gcloud compute target-https-proxies create gil7-https-proxy \
  --url-map=gil7-map \
  --certificate-manager-certificates=gilb-certificate

  5. Erstellen Sie zwei Weiterleitungsregeln: eine mit einer VIP (10.1.2.99) in der Region REGION_B und eine mit einer VIP (10.1.3.99) in der Region REGION_A. “

    Bei benutzerdefinierten Netzwerken müssen Sie in der Weiterleitungsregel auf das Subnetz verweisen. Beachten Sie, dass dies das Subnetz der VM-Instanz (virtuelle Maschine) und nicht das Proxy-Subnetz ist.

    Bei HTTP:

    Verwenden Sie den Befehl gcloud compute forwarding-rules create mit den richtigen Flags.

    gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

    gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

    Bei HTTPS:

    Erstellen Sie die Weiterleitungsregel mit dem Befehl gcloud compute forwarding-rules create und den richtigen Flags.

    gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --address=10.1.3.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

    gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --address=10.1.2.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

API

Erstellen Sie den globalen Backend-Dienst durch Senden einer POST-Anfrage an die Methode backendServices.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

{
"name": "gil7-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7ilb_serverless_negwest",
    "balancingMode": "UTILIZATION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7ilb_serverless_negeast",
  }
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Erstellen Sie die URL-Zuordnung durch Senden einer POST-Anfrage an die Methode urlMaps.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/global/backendServices/gil7-backend-service"
}

Bei HTTP:

Erstellen Sie den Ziel-HTTP-Proxy durch Senden einer POST-Anfrage an die Methode targetHttpProxies.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map"
}

Erstellen Sie die Firewallregel durch Senden einer POST-Anfrage an die Methode globalforwardingRules.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Bei HTTPS:

Lesen Sie die Zertifikat- und privaten Schlüsseldateien und erstellen Sie dann das SSL-Zertifikat. Im folgenden Beispiel wird gezeigt, wie das mit Python funktioniert.

Erstellen Sie den Ziel-HTTPS-Proxy durch Senden einer POST-Anfrage an die Methode targetHttpsProxies.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"sslCertificates": /projects/PROJECT_ID/global/sslCertificates/SSL_CERT_NAME
}

Erstellen Sie die Firewallregel durch Senden einer POST-Anfrage an die Methode globalForwardingRules.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Load-Balancer testen

Da der Load-Balancing-Dienst nun ausgeführt wird, können Sie Traffic an die Weiterleitungsregel senden. Dieser wird dann an verschiedene Instanzen verteilt.

Firewallregel konfigurieren

In diesem Beispiel wird die Firewallregel fw-allow-ssh für die Test-Client-VM benötigt: fw-allow-ssh ist eine Regel für eingehenden Traffic, die für die Test-Client-VM gilt und eingehende SSH-Verbindungen an TCP-Port 22 von jeder Adresse aus ermöglicht. Sie können einen restriktiveren IP-Quelladressbereich für diese Regel auswählen. Geben Sie dazu beispielsweise nur die IP-Adressbereiche des Systems an, von dem aus Sie SSH-Sitzungen initiieren. In diesem Beispiel wird das Ziel-Tag allow-ssh verwendet.

gcloud

  1. Erstellen Sie die Firewallregel fw-allow-ssh, um SSH-Verbindungen zu VMs mit dem Netzwerk-Tag allow-ssh zu ermöglichen. Wenn Sie source-ranges weglassen, bezieht Google Cloud die Regel auf jede Quelle.

    gcloud compute firewall-rules create fw-allow-ssh \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

VM-Instanz zum Testen der Konnektivität erstellen

  1. Client-VM erstellen

    gcloud compute instances create l7-ilb-client-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_A \
    --zone=ZONE_A \
    --tags=allow-ssh

    gcloud compute instances create l7-ilb-client-b \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --zone=ZONE_B \
    --tags=allow-ssh

  2. Mit SSH eine Verbindung zu jeder Clientinstanz herstellen

    gcloud compute ssh l7-ilb-client-a \
   --zone=ZONE_A

    gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

  3. Prüfen Sie, ob die IP-Adresse ihren Hostnamen bereitstellt.

    • Prüfen Sie, ob die Client-VM beide IP-Adressen erreichen kann. Der Befehl ist erfolgreich und gibt den Namen der Back-End-VM zurück, von der die Anfrage verarbeitet wurde:

      curl 10.1.2.99

      curl 10.1.3.99

      Ersetzen Sie für HTTPS-Tests curl durch:

      curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443

      curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443

      Das Flag -k bewirkt, dass curl die Zertifikatsvalidierung überspringt.

    • Optional: Verwenden Sie den konfigurierten DNS-Eintrag, um die IP-Adresse aufzulösen.

      curl service.example.com

100 Anfragen ausführen und prüfen, ob ein Load-Balancing stattfindet

Bei HTTP:

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.3.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

Bei HTTPS:

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

  {
    RESULTS=
    for i in {1..100}
    do
        RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

Failover testen

  1. Prüfen Sie das Failover auf Back-Ends in der Region REGION_A, wenn Back-Ends in der REGION_B fehlerhaft oder nicht erreichbar sind. Wir simulieren dies, indem wir alle Back-Ends aus REGION_B entfernen:

    gcloud compute backend-services remove-backend gil7-backend-service \
   --network-endpoint-group=gl7ilb-serverless-neg-b \
   --network-endpoint-group-zone=ZONE_B

  2. Stellen Sie eine SSH-Verbindung zu einer Client-VM in REGION_B her.

    gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

  3. Senden Sie Anfragen an die IP-Adresse mit Load-Balancing in der Region REGION_B. Die Befehlsausgabe zeigt Antworten von Back-End-VMs in REGION_A an:

    {
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.3.99: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Zusätzliche Konfigurationsoptionen

In diesem Abschnitt wird die Konfiguration des Beispiels um alternative und zusätzliche Optionen erweitert. Alle Aufgaben sind optional. Sie können sie in beliebiger Reihenfolge ausführen.

URL-Maske verwenden

Beim Erstellen einer serverlosen NEG können Sie, statt einen bestimmten Cloud Run-Dienst auszuwählen, eine URL-Maske verwenden, um auf mehrere Dienste zu verweisen, die in derselben Domain bereitgestellt werden. Eine URL-Maske ist eine Vorlage für Ihr URL-Schema. Die serverlose NEG verwendet diese Vorlage, um den Dienstnamen aus der URL der eingehenden Anfrage zu extrahieren und die Anfrage dem entsprechenden Dienst zuzuordnen.

URL-Masken sind besonders nützlich, wenn Ihr Dienst einer benutzerdefinierten Domain zugeordnet ist und nicht der Standardadresse, die Google Cloud für den bereitgestellten Dienst angibt. Eine URL-Maske bietet die Möglichkeit, mehrere Dienste und Versionen mit einer einzigen Regel anzusprechen, selbst wenn Ihre Anwendung ein benutzerdefiniertes URL-Muster verwendet.

Falls Sie es noch nicht getan haben, lesen Sie den Abschnitt zu URL-Masken in der Übersicht zu serverlosen NEGs.

URL-Maske erstellen

Wenn Sie eine URL-Maske für Ihren Load-Balancer erstellen möchten, beginnen Sie mit der URL Ihres Dienstes. In diesem Beispiel wird eine serverlose Beispielanwendung verwendet, die unter https://example.com/login ausgeführt wird. Dies ist die URL, unter der der login-Dienst der Anwendung bereitgestellt wird.

  1. Entfernen Sie http oder https aus der URL. Es verbleibt example.com/login.
  2. Ersetzen Sie den Dienstnamen durch einen Platzhalter für die URL-Maske.
    • Cloud Run: Ersetzen Sie den Namen des Cloud Run-Dienstes durch den Platzhalter <service>. Wenn dem Cloud Run-Dienst ein Tag zugeordnet ist, ersetzen Sie den Namen des Tags durch den Platzhalter <tag>. In diesem Beispiel lautet die URL-Maske example.com/<service>.

  3. Optional: Wenn sich der Dienstname aus dem Pfadabschnitt der URL extrahieren lässt, kann die Domain weggelassen werden. Der Pfadteil der URL-Maske wird durch den ersten Schrägstrich (/) abgetrennt. Wenn in der URL-Maske kein / vorhanden ist, wird die Maske nur für den Host verwendet. Daher kann die URL-Maske in diesem Beispiel auf /<service> reduziert werden.

    Wenn sich <service> aus dem Hostteil der URL extrahieren lässt, können Sie den Pfad in der URL-Maske vollständig weglassen.

    Sie können auch alle Host- oder Subdomain-Komponenten weglassen, die vor dem ersten Platzhalter stehen, sowie alle Pfadkomponenten, die nach dem letzten Platzhalter stehen. In solchen Fällen erfasst der Platzhalter die erforderlichen Informationen für die Komponente.

Hier einige weitere Beispiele zur Veranschaulichung dieser Regeln:

In dieser Tabelle wird davon ausgegangen, dass Sie eine benutzerdefinierte Domain namens example.com haben und alle Ihre Cloud Run-Dienste dieser Domain zugeordnet werden.

Dienst, Tag-Name Benutzerdefinierte Domain-URL in Cloud Run URL-Maske
Dienst: login https://login-home.example.com/web <Dienst>-home.example.com
Dienst: login https://example.com/login/web example.com/<Dienst> oder /<Dienst>
Dienst: login; Tag: test https://test.login.example.com/web <Tag>.<Dienst>.example.com
Dienst: login; Tag: test https://example.com/home/login/test example.com/home/<Dienst>/<Tag> oder /home/<Dienst>/<Tag>
Dienst: login; Tag: test https://test.example.com/home/login/web <Tag>.example.com/home/<Dienst>

Serverlose NEG mit URL-Maske erstellen

Console

Für einen neuen Load-Balancer können Sie den gleichen gesamten End-to-End-Prozess verwenden, wie weiter oben in diesem Thema beschrieben. Geben Sie bei der Konfiguration des Back-End-Dienstes eine URL-Maske ein, statt einen bestimmten Dienst auszuwählen.

Wenn Sie bereits einen Load-Balancer haben, können Sie die Backend-Konfiguration bearbeiten und die serverlose NEG auf eine URL-Maske statt auf einen bestimmten Dienst verweisen lassen.

So fügen Sie einem vorhandenen Backend-Dienst eine serverlose NEG hinzu, die auf einer URL-Maske basiert:

  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.
    Load-Balancing aufrufen
  2. Klicken Sie auf den Namen des Load-Balancers mit dem Backend-Dienst, den Sie bearbeiten möchten.
  3. Klicken Sie auf der Seite Details zum Load Balancer auf Bearbeiten .
  4. Klicken Sie auf der Seite Globalen externen Application Load Balancer bearbeiten auf Backend-Konfiguration.
  5. Klicken Sie auf der Seite Backend-Konfiguration für den Backend-Dienst, den Sie ändern möchten, auf Bearbeiten.
  6. Klicken Sie auf Back-End hinzufügen.
  7. Wählen Sie Serverlose Netzwerk-Endpunktgruppe erstellen aus.
    1. Geben Sie im Feld Name helloworld-serverless-neg ein.
    2. Unter Region wird die Region des Load-Balancers angezeigt.
    3. Unter Typ der Endpunktgruppe für ein serverloses Netzwerk ist Cloud Run der einzige unterstützte Typ für Netzwerk-Endpunktgruppen.
      1. Wählen Sie URL-Maske verwenden aus.
      2. Geben Sie eine URL-Maske ein. Weitere Informationen zum Erstellen einer URL-Maske finden Sie unter URL-Maske erstellen.
      3. Klicken Sie auf Erstellen.

  8. Klicken Sie im neuen Backend auf Fertig.
  9. Klicken Sie auf Aktualisieren.

gcloud

So erstellen Sie eine serverlose NEG mit der URL-Beispielmaske example.com/<service>:

gcloud compute network-endpoint-groups create SERVERLESS_NEG_MASK_NAME \
    --region=REGION \
    --network-endpoint-type=serverless \
    --cloud-run-url-mask="example.com/<service>"

Dieselbe IP-Adresse für mehrere interne Weiterleitungsregeln verwenden

Damit mehrere interne Weiterleitungsregeln dieselbe interne IP-Adresse haben, müssen Sie die IP-Adresse reservieren und das Flag --purpose auf SHARED_LOADBALANCER_VIP setzen.

gcloud 

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP
Wenn Sie HTTP-Traffic an HTTPS weiterleiten müssen, können Sie zwei Weiterleitungsregeln erstellen, die eine gemeinsame IP-Adresse nutzen. Weitere Informationen finden Sie unter HTTP-zu-HTTPS-Weiterleitung für interne Application Load Balancer einrichten.

DNS-Routingrichtlinien konfigurieren

Wenn sich Ihre Clients in mehreren Regionen befinden, möchten Sie möglicherweise den regionenübergreifenden internen Application Load Balancer mithilfe von VIPs in diesen Regionen zugänglich machen. In dieser multiregionalen Einrichtung werden die Latenz und die Kosten für den Netzwerktransport minimiert. Darüber hinaus können Sie eine DNS-basierte globale Load-Balancing-Lösung einrichten, die gegen regionale Ausfälle sicher ist. Weitere Informationen finden Sie unter DNS-Routingrichtlinien und Systemdiagnosen verwalten.

gcloud

Zum Erstellen eines DNS-Eintrags mit einer 30-Sekunden-TTL verwenden Sie den Befehl gcloud dns record-sets create.

gcloud dns record-sets create DNS_ENTRY --ttl="30" \
  --type="A" --zone="service-zone" \
  --routing-policy-type="GEO" \
  --routing-policy-data="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \
  --enable-health-checking

Ersetzen Sie Folgendes:

  • DNS_ENTRY: DNS- oder Domainname des Datensatzes

    Beispiel: service.example.com

  • REGION_A und REGION_B: die Regionen, in denen Sie den Load-Balancer konfiguriert haben

API

Erstellen Sie den DNS-Eintrag durch eine POST-Anfrage an die Methode ResourceRecordSets.create. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets
{
  "name": "DNS_ENTRY",
  "type": "A",
  "ttl": 30,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "REGION_A",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "gil7-forwarding-rule-a",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION_B",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "gil7-forwarding-rule-b",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}

Ausreißererkennung aktivieren

Sie können die Ausreißererkennung für globale Backend-Dienste aktivieren, um fehlerhafte serverlose NEGs zu identifizieren und die Anzahl der Anfragen zu reduzieren, die an die fehlerhaften serverlosen NEGs gesendet werden.

Die Ausreißererkennung wird für den Backend-Dienst mithilfe einer der folgenden Methoden aktiviert:

  • Die Methode consecutiveErrors (outlierDetection.consecutiveErrors), bei der ein HTTP-Statuscode der 5xx-Serie als Fehler gilt.
  • Die Methode consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), bei der nur die HTTP-Statuscodes 502, 503 und 504 als Fehler gelten.

Führen Sie die folgenden Schritte aus, um die Ausreißererkennung für einen vorhandenen Backend-Dienst zu aktivieren. Beachten Sie, dass auch nach der Aktivierung der Ausreißererkennung einige Anfragen an den fehlerhaften Dienst gesendet werden können und einen 5xx-Statuscode an die Clients zurückgeben. Zur weiteren Reduzierung der Fehlerrate können Sie aggressivere Werte für die Ausreißererkennungsparameter konfigurieren. Weitere Informationen finden Sie im Feld outlierDetection.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

    Load-Balancing aufrufen

  2. Klicken Sie auf den Namen des Load-Balancers, dessen Backend-Dienst Sie bearbeiten möchten.

  3. Klicken Sie auf der Seite Details zum Load-Balancer auf Bearbeiten.

  4. Klicken Sie auf der Seite Regionenübergreifenden internen Application Load Balancer bearbeiten auf Backend-Konfiguration.

  5. Klicken Sie auf der Seite Backend-Konfiguration für den Backend-Dienst, den Sie ändern möchten, auf Bearbeiten.

  6. Scrollen Sie nach unten und maximieren Sie den Abschnitt Erweiterte Konfigurationen.

  7. Wählen Sie im Abschnitt Ausreißererkennung das Kästchen Aktivieren aus.

  8. Klicken Sie auf Bearbeiten, um die Ausreißererkennung zu konfigurieren.

    Prüfen Sie, ob die folgenden Optionen mit diesen Werten konfiguriert sind:

    Attribut Wert
    Aufeinanderfolgende Fehler 5
    Intervall 1000
    Basisausschlusszeit 30.000
    Maximale Prozentzahl an Ausschlüssen 50
    Aufeinanderfolgende Fehler werden erzwungen 100

    In diesem Beispiel wird die Ausreißererkennungsanalyse jede Sekunde ausgeführt. Wenn die Anzahl der aufeinanderfolgenden HTTP-Statuscodes 5xx, die von einem Envoy-Proxy empfangen werden, mindestens fünf ist, wird der Backend-Endpunkt für 30 Sekunden aus dem Load-Balancing-Pool dieses Envoy-Proxys ausgeschlossen. Wenn der Erzwingungsprozentsatz auf 100 % eingestellt ist, erzwingt der Backend-Dienst den Ausschluss fehlerhafter Endpunkte aus den Load-Balancing-Pools dieser spezifischen Envoy-Proxys jedes Mal, wenn die Ausreißererkennungsanalyse läuft. Wenn die Ausschlussbedingungen erfüllt sind, können bis zu 50 % der Backend-Endpunkte aus dem Load-Balancing-Pool ausgeschlossen werden.

  9. Klicken Sie auf Speichern.

  10. Klicken Sie zum Aktualisieren des Backend-Dienstes auf Aktualisieren.

  11. Klicken Sie zum Aktualisieren des Load Balancers auf der Seite Regionenübergreifenden internen Application Load Balancer bearbeiten auf Aktualisieren.

gcloud

  1. Exportieren Sie den Backend-Dienst in eine YAML-Datei.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME.yaml --global

    Ersetzen Sie BACKEND_SERVICE_NAME durch den Namen des Backend-Dienstes.

  2. Bearbeiten Sie die YAML-Konfiguration des Backend-Dienstes, um die Felder für die Ausreißererkennung hinzuzufügen, wie in der folgenden YAML-Konfiguration hervorgehoben.

    In diesem Beispiel wird die Ausreißererkennungsanalyse jede Sekunde ausgeführt. Wenn die Anzahl der aufeinanderfolgenden HTTP-Statuscodes 5xx, die von einem Envoy-Proxy empfangen werden, mindestens fünf ist, wird der Backend-Endpunkt für 30 Sekunden aus dem Load-Balancing-Pool dieses Envoy-Proxys ausgeschlossen. Wenn der Erzwingungsprozentsatz auf 100 % eingestellt ist, erzwingt der Backend-Dienst den Ausschluss fehlerhafter Endpunkte aus den Load-Balancing-Pools dieser spezifischen Envoy-Proxys jedes Mal, wenn die Ausreißererkennungsanalyse läuft. Wenn die Ausschlussbedingungen erfüllt sind, können bis zu 50 % der Backend-Endpunkte aus dem Load-Balancing-Pool ausgeschlossen werden. 

    name: BACKEND_SERVICE_NAME
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
outlierDetection:
  baseEjectionTime:
    nanos: 0
    seconds: 30
  consecutiveErrors: 5
  enforcingConsecutiveErrors: 100
  interval:
    nanos: 0
    seconds: 1
  maxEjectionPercent: 50
port: 80
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
sessionAffinity: NONE
timeoutSec: 30
...

    Ersetzen Sie Folgendes:

    • BACKEND_SERVICE_NAME: der Name des Backend-Dienstes
    • PROJECT_ID: die Projekt-ID
    • REGION_A und REGION_B: die Regionen, in denen der Load-Balancer konfiguriert wurde.
    • SERVERLESS_NEG_NAME: der Name der ersten serverlosen NEG
    • SERVERLESS_NEG_NAME_2: der Name der zweiten serverlosen NEG

  3. Aktualisieren Sie den Backend-Dienst. Importieren Sie dazu die neueste Konfiguration.

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
  --source=BACKEND_SERVICE_NAME.yaml --global

    Die Ausreißererkennung ist jetzt für den Backend-Dienst aktiviert.

Serverlose NEG löschen

Eine Netzwerk-Endpunktgruppe kann nicht gelöscht werden, wenn sie mit einem Back-End-Dienst verknüpft ist. Bevor Sie eine NEG löschen, muss sie vom Back-End-Dienst getrennt sein.

Console

  1. Wechseln Sie zum Tab Backend-Dienste im Load-Balancing-Komponentenmenü, damit der zu löschende serverlose NEG derzeit von keinem Backend-Dienst verwendet wird.
    Zu „Backend-Dienste“
  2. Wenn die serverlose NEG verwendet wird, gehen Sie so vor:
    1. Klicken Sie auf den Namen des Backend-Dienstes, der die serverlose NEG verwendet.
    2. Klicken Sie auf Bearbeiten.
    3. Klicken Sie in der Liste der Backends auf , um das serverlose NEG-Backend aus dem Backend-Dienst zu entfernen.
    4. Klicken Sie auf Speichern.

  3. Rufen Sie in der Google Cloud Console die Seite Netzwerk-Endpunktgruppe auf.
    Zu „Netzwerk-Endpunktgruppe“
  4. Aktivieren Sie das Kästchen für die serverlose NEG, die Sie löschen möchten.
  5. Klicken Sie auf Löschen.
  6. Klicken Sie zur Bestätigung noch einmal auf Löschen.

gcloud

Um eine serverlose NEG aus einem Backend-Dienst zu entfernen, müssen Sie die Region angeben, in der die NEG erstellt wurde.

gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=SERVERLESS_NEG_NAME \
    --network-endpoint-group-region=REGION \
    --region=REGION

So löschen Sie die serverlose NEG:

gcloud compute network-endpoint-groups delete SERVERLESS_NEG_NAME \
    --region=REGION

Nächste Schritte