Globalen externen Application Load Balancer mit Cloud Run, App Engine oder Cloud Run Functions einrichten

Auf dieser Seite wird beschrieben, wie Sie einen externen Application Load Balancer erstellen, um Anfragen an serverlose Back-Ends weiterzuleiten. Der Begriff "serverlos" bezieht sich hier auf die folgenden serverlosen Computing-Produkte:

  • App Engine
  • Cloud Run-Funktionen
  • Cloud Run

Durch die Einbindung externer Application Load Balancer in API Gateway können Ihre serverlosen Back-Ends alle Features von Cloud Load Balancing nutzen. Informationen zum Konfigurieren eines externen Application Load Balancers zum Weiterleiten von Traffic an ein API Gateway finden Sie unter Erste Schritte mit einem externen Application Load Balancer für API Gateway. Die Unterstützung für externe Application Load Balancer für API Gateway befindet sich in der Vorschau.

Serverlose NEGs bieten Ihnen die Möglichkeit, serverlose Google Cloud-Anwendungen mit externen Application Load Balancern zu verwenden. Nachdem Sie einen Load-Balancer mit dem serverlosen NEG-Backend konfiguriert haben, werden Anfragen an den Load-Balancer zum serverlosen Backend der Anwendung geleitet.

Weitere Informationen zu serverlosen NEGs finden Sie in der Übersicht zu serverlosen NEGs.

Wenn Sie bereits Nutzer des klassischen Application Load Balancers sind und eine neue Bereitstellung mit dem globalen externen Application Load Balancer planen, lesen Sie den Abschnitt Migration – Übersicht.

Hinweise

  1. App Engine-, Cloud Run Functions- oder Cloud Run-Dienst bereitstellen.
  2. Installieren Sie die Google Cloud CLI, falls noch nicht geschehen.
  3. Konfigurieren Sie Berechtigungen.
  4. Fügen Sie eine SSL-Zertifikatsressource hinzu.

App Engine-, Cloud Run Functions- oder Cloud Run-Dienst bereitstellen

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

Für das Beispiel auf dieser Seite wurde die Python-Kurzanleitung für Cloud Run verwendet, um einen Cloud Run-Dienst in der Region us-central1 bereitzustellen. Auf der restlichen Seite wird beschrieben, wie Sie einen externen Application Load Balancer einrichten, der ein serverloses NEG-Backend verwendet, um Anfragen an diesen Dienst weiterzuleiten.

Wenn Sie noch keine serverlose Anwendung bereitgestellt haben oder eine serverlose NEG mit einer Beispielanwendung ausprobieren möchten, nutzen Sie eine der folgenden Kurzanleitungen. Sie können eine serverlose Anwendung in jeder Region erstellen, aber Sie müssen später zum Erstellen der serverlosen NEG und des Load-Balancers dieselbe Region verwenden.

Cloud Run

Wenn Sie eine einfache Hello World-Anwendung erstellen möchten, verpacken Sie sie in ein Container-Image und stellen Sie das Container-Image dann für Cloud Run bereit. Weitere Informationen finden Sie unter Kurzanleitung: Erstellen und bereitstellen.

Wenn Sie bereits einen Beispielcontainer nach Container Registry hochgeladen haben, finden Sie weitere Informationen unter Kurzanleitung: Vorgefertigten Beispielcontainer bereitstellen.

Cloud Run-Funktionen

Siehe Cloud Run Functions: Python-Kurzanleitung.

App Engine

Informationen finden Sie in den folgenden App Engine-Kurzanleitungen für Python 3:

Google Cloud CLI installieren

Installieren Sie die Google Cloud CLI. In der gcloud-Übersicht finden Sie Informationen zum Konzept und zur Installation des Tools.

Wenn Sie die gcloud CLI noch nicht ausgeführt haben, führen Sie zuerst gcloud init aus, um Ihr gcloud-Verzeichnis zu initialisieren.

Berechtigungen konfigurieren

Um dieser Anleitung zu folgen, müssen Sie in einem Projekt eine serverlose NEG und einen externen HTTP(S)-Load-Balancer erstellen. Sie sollten entweder Inhaber oder Bearbeiter des Projekts sein oder die folgenden IAM-Rollen für Compute Engine haben:

Aufgabe Erforderliche Rolle
Load-Balancer und Netzwerkkomponenten erstellen Netzwerkadministrator
NEGs erstellen und ändern Compute-Instanzadministrator
SSL-Zertifikate erstellen und ändern Sicherheitsadministrator

Externe IP-Adresse reservieren

Nachdem die Dienste nun ausgeführt werden, müssen Sie eine globale statische externe IP-Adresse einrichten, über die Ihre Kunden den Load-Balancer erreichen können.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Externe IP-Adressen auf.

    Zu externen IP-Adressen

  2. Klicken Sie auf Externe statische IP-Adresse reservieren.

  3. Geben Sie für Name example-ip ein.

  4. Wählen Sie für Netzwerkdienststufe die Option Premium aus.

  5. Setzen Sie die IP-Version auf IPv4.

  6. Wählen Sie unter Typ die Option Global aus.

  7. Klicken Sie auf Reservieren.

gcloud 

gcloud compute addresses create example-ip \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

Notieren Sie sich die reservierte IPv4-Adresse:

gcloud compute addresses describe example-ip \
    --format="get(address)" \
    --global

SSL-Zertifikatsressource erstellen

Zum Erstellen eines HTTPS-Load-Balancers müssen Sie dem Frontend des Load-Balancers eine SSL-Zertifikatsressource hinzufügen. Erstellen Sie eine SSL-Zertifikatsressource mit einem von Google verwalteten SSL-Zertifikat oder mit einem selbst verwalteten SSL-Zertifikat.

  • Von Google verwaltete Zertifikate. Es empfiehlt sich, von Google verwaltete Zertifikate zu verwenden, da Google Cloud diese Zertifikate automatisch abruft, verwaltet und verlängert. Zum Erstellen eines von Google verwalteten Zertifikats benötigen Sie eine Domain und die zugehörigen DNS-Einträge, damit das Zertifikat bereitgestellt werden kann. Außerdem müssen Sie den DNS-A-Eintrag der Domain so aktualisieren, dass er auf die IP-Adresse des Load-Balancers (example-ip) verweist, die im vorherigen Schritt erstellt wurde. Eine ausführliche Anleitung finden Sie unter Von Google verwaltete Zertifikate verwenden.

  • Selbst signierte Zertifikate. Wenn Sie derzeit keine Domain einrichten möchten, können Sie ein selbst signiertes SSL-Zertifikat zu Testzwecken verwenden.

In diesem Beispiel wird davon ausgegangen, dass Sie bereits eine SSL-Zertifikatsressource erstellt haben.

Wenn Sie diesen Prozess testen möchten, ohne eine SSL-Zertifikatsressource oder eine Domain (für von Google verwaltete Zertifikate erforderlich) zu erstellen, folgen Sie der Anleitung auf dieser Seite, um stattdessen einen HTTP-Load-Balancer einzurichten.

Load-Balancer erstellen

Im folgenden Diagramm verwendet der Load-Balancer ein serverloses NEG-Backend, um Anfragen zu einem serverlosen Cloud Run-Dienst zu leiten. Für dieses Beispiel wurde die Python-Kurzanleitung für Cloud Run verwendet, um einen Cloud Run-Dienst bereitzustellen.

Architektur des externen Application Load Balancers für eine Cloud Run-Anwendung.
Architektur eines externen Application Load Balancers für eine Cloud Run-Anwendung (zum Vergrößern anklicken)

Da Systemdiagnosen für Backend-Dienste mit serverlosen NEG-Backends nicht unterstützt werden, müssen Sie keine Firewallregel erstellen, die Systemdiagnosen zulässt, wenn der Load-Balancer nur serverlose NEG-Backends hat.

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 Öffentlich (extern) aus und klicken Sie auf Weiter.
  5. Wählen Sie unter Globale oder Einzelregion-Bereitstellung die Option Am besten für globale Arbeitslasten aus und klicken Sie auf Weiter.
  6. Wählen Sie unter Generation des Load Balancers die Option Globaler externer Application Load Balancer aus und klicken Sie auf Weiter.
  7. Klicken Sie auf Konfigurieren.

Grundlegende Konfiguration

  1. Geben Sie serverless-lb als Name für den Load-Balancer ein.
  2. Lassen Sie das Fenster geöffnet, um fortzufahren.

Frontend-Konfiguration

  1. Klicken Sie auf Frontend-Konfiguration.
  2. Geben Sie für Name einen Namen ein.
  3. Zum Erstellen eines HTTPS-Load-Balancers benötigen Sie ein SSL-Zertifikat (gcloud compute ssl-certificates list).

    Wir empfehlen die Verwendung eines von Google verwalteten Zertifikats, wie bereits beschrieben.

    4. Füllen Sie die folgenden Felder aus, um einen externen Application Load Balancer zu konfigurieren.

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

    Attribut Wert (Wert eingeben bzw. Option auswählen)
    Protokoll HTTPS
    Netzwerkdienststufe Premium
    IP-Version IPv4
    IP-Adresse Beispiel-IP
    Port 443
    Optional: HTTP-Keepalive-Zeitlimit Geben Sie ein Zeitlimit zwischen 5 und 1.200 Sekunden ein. Der Standardwert beträgt 610 Sekunden.
    Zertifikat Wählen Sie ein vorhandenes Zertifikat aus oder erstellen Sie ein neues.

    Zum Erstellen eines HTTPS-Load-Balancers benötigen Sie eine SSL-Zertifikatsressource, die im HTTPS-Proxy verwendet wird. Sie können eine SSL-Zertifikatsressource entweder mit einem von Google verwalteten SSL-Zertifikat oder mit einem selbst verwalteten SSL-Zertifikat erstellen.
    Zum Erstellen eines von Google verwalteten Zertifikats benötigen Sie eine Domain. Der A-Eintrag der Domain muss der IP-Adresse des Load-Balancers zugeordnet werden (in diesem Beispiel example-ip). Es empfiehlt sich, von Google verwaltete Zertifikate zu verwenden, da Google Cloud diese Zertifikate automatisch abruft, verwaltet und verlängert. Wenn Sie keine Domain haben, können Sie ein selbst signiertes SSL-Zertifikat zu Testzwecken verwenden.
    Optional: HTTP-zu-HTTPS-Weiterleitung aktivieren Klicken Sie dieses Kästchen an, um HTTP-zu-HTTPS-Weiterleitungen zu aktivieren.

    Wenn Sie dieses Kästchen anklicken, wird ein zusätzlicher partieller HTTP-Load-Balancer erstellt, der dieselbe IP-Adresse wie Ihr HTTPS-Load-Balancer verwendet und die HTTP-Anfragen an das HTTPS-Frontend Ihres Load-Balancers weiterleitet.

    Dieses Kästchen kann nur angeklickt werden, wenn das HTTPS-Protokoll aktiviert und eine reservierte IP-Adresse verwendet wird.

    Wenn Sie diesen Prozess testen möchten, ohne eine SSL-Zertifikatsressource oder eine Domain (für von Google verwaltete Zertifikate erforderlich) einzurichten, können Sie einen HTTP-Load-Balancer einrichten.

    Wenn Sie einen HTTP-Load-Balancer erstellen möchten, prüfen Sie, ob die folgenden Optionen mit diesen Werten konfiguriert sind:

    Attribut Wert (Wert eingeben bzw. Option auswählen)
    Protokoll HTTP
    Netzwerkdienststufe Premium
    IP-Version IPv4
    IP-Adresse Beispiel-IP
    Port 80
    Optional: HTTP-Keepalive-Zeitlimit Geben Sie ein Zeitlimit zwischen 5 und 1.200 Sekunden ein. Der Standardwert beträgt 610 Sekunden.
  4. Klicken Sie auf Fertig.

Backend-Konfiguration

  1. Klicken Sie auf Backend-Konfiguration.
  2. Klicken Sie in der Liste Backend-Dienste und Backend-Buckets auf Backend-Dienst erstellen.
  3. Geben Sie für Name einen Namen ein.
  4. Wählen Sie unter Backend-Typ die Option Endpunktgruppe in serverlosem Netzwerk aus.
  5. Lassen Sie das Protokoll unverändert. Dieser Parameter wird ignoriert.
  6. Wählen Sie im Bereich Backends für Neues Backend die Option Endpunktgruppe für ein serverloses Netzwerk erstellen aus.
  7. Geben Sie für Name einen Namen ein.
  8. Wählen Sie unter Region die Option us-central1 und dann Cloud Run aus.
  9. Wählen Sie Dienstname auswählen aus.
  10. Wählen Sie in der Liste Dienst den Cloud Run-Dienst aus, für den Sie einen Load Balancer erstellen möchten.
  11. Klicken Sie auf Erstellen.
  12. Klicken Sie im Bereich Neues Backend auf Fertig.
  13. Klicken Sie auf Erstellen.

Routingregeln

Routingregeln bestimmen, wie Ihr Traffic weitergeleitet wird. Um das Routing zu konfigurieren, richten Sie Hostregeln und Pfad-Matcher ein, die Konfigurationskomponenten der URL-Zuordnung eines externen Application Load Balancers sind.

  1. Klicken Sie auf Routingregeln.

  2. Behalten Sie die Standardhosts und -pfade bei. In diesem Beispiel werden alle Anfragen an den Backend-Dienst gesendet, der im vorherigen Schritt erstellt wurde.

Konfiguration prüfen

  1. Klicken Sie auf Prüfen und abschließen.
  2. Prüfen Sie alle Einstellungen.
  3. Optional: Klicken Sie auf Entsprechender Code, um die REST API-Anfrage aufzurufen, die zum Erstellen des Load-Balancers verwendet wird.
  4. Klicken Sie auf Erstellen.
  5. Warten Sie, bis der Load-Balancer erstellt ist.
  6. Klicken Sie auf den Namen des Load-Balancers (serverless-lb).
  7. Notieren Sie die IP-Adresse des Load-Balancers für die nächste Aufgabe. Sie wird als IP_ADDRESS bezeichnet.

gcloud

  1. Erstellen Sie eine serverlose NEG für Ihre serverlose Anwendung.

    So erstellen Sie eine serverlose NEG mit einem Cloud Run-Dienst: 

       gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \
       --region=us-central1 \
       --network-endpoint-type=serverless  \
       --cloud-run-service=CLOUD_RUN_SERVICE_NAME
    Weitere Optionen finden Sie im Referenzhandbuch gcloud unter gcloud compute network-endpoint-groups create.
  2. Erstellen Sie einen Back-End-Dienst. 
       gcloud compute backend-services create BACKEND_SERVICE_NAME \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --global
  3. Fügen Sie dem Back-End-Dienst das serverlose NEG als Back-End hinzu. 
       gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --global \
       --network-endpoint-group=SERVERLESS_NEG_NAME \
       --network-endpoint-group-region=us-central1
  4. Erstellen Sie eine URL-Zuordnung, um eingehende Anfragen an den Backend-Dienst weiterzuleiten: 
       gcloud compute url-maps create URL_MAP_NAME \
       --default-service BACKEND_SERVICE_NAME

    Diese beispielhafte URL-Zuordnung ist nur auf einen Backend-Dienst ausgerichtet, der eine einzelne serverlose Anwendung darstellt. Daher müssen keine Hostregeln oder Pfad-Matcher eingerichtet werden. Wenn Sie mehr als einen Backend-Dienst haben, können Sie Hostregeln verwenden, um Anfragen basierend auf dem Hostnamen zu verschiedenen Diensten zu leiten. Sie können auch Tools zum Abgleich von Pfaden einrichten, um Anfragen basierend auf dem Anfragepfad zu verschiedenen Diensten zu leiten.

  5. Zum Erstellen eines HTTPS-Load-Balancers benötigen Sie eine SSL-Zertifikatsressource, die im HTTPS-Proxy verwendet wird. Sie können eine SSL-Zertifikatsressource entweder mit einem von Google verwalteten SSL-Zertifikat oder mit einem selbst verwalteten SSL-Zertifikat erstellen. Es empfiehlt sich, von Google verwaltete Zertifikate zu verwenden, da Google Cloud diese Zertifikate automatisch abruft, verwaltet und verlängert.

    Zum Erstellen eines von Google verwalteten Zertifikats benötigen Sie eine Domain. Wenn Sie keine Domain haben, können Sie ein selbst signiertes SSL-Zertifikat zu Testzwecken verwenden.

    So erstellen Sie eine von Google verwaltete SSL-Zertifikatsressource: 
       gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
       --domains DOMAIN
    So erstellen Sie eine selbstverwaltete SSL-Zertifikatressource: 
       gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
       --certificate CRT_FILE_PATH \
       --private-key KEY_FILE_PATH

  6. Erstellen Sie einen HTTP(S)-Zielproxy, um Anfragen an Ihre URL-Zuordnung weiterzuleiten.

    Erstellen Sie einen HTTP-Zielproxy für einen HTTP-Load-Balancer:

       gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
      --url-map=URL_MAP_NAME

    Erstellen Sie einen HTTPS-Zielproxy für einen HTTPS-Load-Balancer. Der Proxy ist der Teil des Load-Balancers, der das SSL-Zertifikat für das HTTPS-Load-Balancing besitzt. Daher laden Sie in diesem Schritt auch Ihr Zertifikat.

       gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
       --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
       --ssl-certificates=SSL_CERTIFICATE_NAME \
       --url-map=URL_MAP_NAME

    Dabei gilt:

    • TARGET_HTTP_PROXY_NAME ist der Name des HTTP-Ziel-Proxys.
    • TARGET_HTTPS_PROXY_NAME ist der Name des HTTPS-Ziel-Proxys.
    • HTTP_KEEP_ALIVE_TIMEOUT_SEC ist ein optionales Feld zur Angabe des Client-HTTP-Keepalive-Zeitlimits. Das Zeitlimit muss zwischen 5 und 1200 Sekunden liegen. Der Standardwert beträgt 610 Sekunden.
    • SSL_CERTIFICATE_NAME ist der Name des SSL-Zertifikats.
    • URL_MAP_NAME ist der Name der URL-Zuordnung.
  7. Erstellen Sie eine Weiterleitungsregel, um eingehende Anfragen an den Proxy weiterzuleiten.

    Für einen HTTP-Load-Balancer:

       gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \
   --load-balancing-scheme=EXTERNAL_MANAGED \
   --network-tier=PREMIUM \
   --address=example-ip \
   --target-http-proxy=TARGET_HTTP_PROXY_NAME \
   --global \
   --ports=80

    Für einen HTTPS-Load-Balancer:

       gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --network-tier=PREMIUM \
       --address=example-ip \
       --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
       --global \
       --ports=443

Domain mit dem Load-Balancer verbinden

Notieren Sie sich nach der Erstellung des Load-Balancers die IP-Adresse, die diesem zugewiesen ist, z. B. 30.90.80.100. Wenn Sie Ihre Domain auf den Load-Balancer verweisen möchten, erstellen Sie mit Ihrem Domain-Registrierungsdienst einen A-Eintrag. Wenn Sie Ihrem SSL-Zertifikat mehrere Domains hinzugefügt haben, müssen Sie für jede Domain einen A-Eintrag hinzufügen, der auf die IP-Adresse des Load-Balancers verweist. So erstellen Sie beispielsweise A-Einträge für www.example.com und example.com:

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

Wenn Sie Cloud DNS als DNS-Anbieter verwenden, finden Sie weitere Informationen unter Einträge hinzufügen, ändern und löschen.

Load-Balancer testen

Nachdem Sie den Load-Balancer konfiguriert haben, können Sie Traffic an die IP-Adresse des Load-Balancers senden. Wenn Sie eine Domain konfiguriert haben, können Sie auch Traffic an den Domainnamen senden. Die DNS-Weitergabe kann jedoch einige Zeit in Anspruch nehmen. Sie sollten daher zuerst die IP-Adresse zu Testzwecken verwenden.

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

    Load-Balancing aufrufen

  2. Klicken Sie auf den Load-Balancer, den Sie gerade erstellt haben.

  3. Notieren Sie sich seine IP-Adresse.

  4. Bei einem HTTP-Load-Balancer können Sie Ihren Load-Balancer mit einem Webbrowser testen. Rufen Sie dafür http://IP_ADDRESS auf. Ersetzen Sie IP_ADDRESS durch die IP-Adresse des Load-Balancers. Sie sollten zur Startseite des helloworld-Dienstes geleitet werden.

  5. Bei einem HTTPS-Load-Balancer können Sie Ihren Load-Balancer mit einem Webbrowser testen. Rufen Sie dafür https://IP_ADDRESS auf. Ersetzen Sie IP_ADDRESS durch die IP-Adresse des Load-Balancers. Sie sollten zur Startseite des helloworld-Dienstes geleitet werden.
    Sollte das nicht funktionieren und Sie verwenden ein von Google verwaltetes Zertifikat, prüfen Sie, ob der Status der Zertifikatsressource AKTIV ist. Weitere Informationen finden Sie unter Von Google verwaltete SSL-Zertifikate verwenden.
    Wenn Sie ein selbst signiertes Zertifikat zu Testzwecken genutzt haben, zeigt Ihr Browser eine Warnung an. Sie müssen Ihren Browser ausdrücklich anweisen, ein selbst signiertes Zertifikat zu akzeptieren. Bestätigen Sie die Warnung, um die eigentliche Seite zu sehen.

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.

Multiregionales Load-Balancing einrichten

Im zuvor beschriebenen Beispiel wird als Backend nur ein Cloud Run-Dienst in der Region us-central1 verwendet. Da die serverlose NEG nur jeweils auf einen Endpunkt verweisen kann, wird das Load-Balancing nicht über mehrere Regionen hinweg ausgeführt. Der externe Application Load Balancer dient nur als Frontend und leitet den Traffic an den angegebenen Endpunkt der helloworld-Anwendung weiter. Unter Umständen ist es jedoch vorteilhafter, wenn Sie Ihre Cloud Run-Anwendung in mehreren Regionen bereitstellen, um die Latenz für Endnutzer zu verbessern.

Wenn einem Backend-Dienst mehrere serverlose NEGs zugeordnet sind, sorgt der Load-Balancer für ausgewogenen Traffic. Dazu werden Anfragen zur serverlosen NEG in der nächsten verfügbaren Region weitergeleitet. Backend-Dienste können jedoch pro Region nur eine serverlose NEG enthalten. Damit Ihr Cloud Run-Dienst in mehreren Regionen verfügbar ist, müssen Sie das regionenübergreifende Routing einrichten. Sie sollten ein einziges URL-Schema verwenden können, das überall auf der Welt funktioniert, aber Nutzeranfragen über die Region verarbeitet, die dem Nutzer am nächsten ist.

Zum Einrichten des Servings für mehrere Regionen müssen Sie die Premium-Netzwerkstufe verwenden, um sicherzustellen, dass alle regionalen Cloud Run-Bereitstellungen kompatibel und bereit sind, den Traffic aus jeder Region zu bedienen.

So richten Sie einen Load-Balancer für mehrere Regionen ein:

  1. Richten Sie zwei Cloud Run-Dienste in verschiedenen Regionen ein. Angenommen, Sie haben zwei Cloud Run-Dienste bereitgestellt: einen in einer Region in den USA und einen anderen in einer Region in Europa.
  2. Erstellen Sie einen externen Application Load Balancer mit folgender Einrichtung:
    1. Set up a global backend service with two serverless NEGs:
      1. Erstellen Sie die erste NEG in derselben Region, in der sich der in den USA bereitgestellte Cloud Run-Dienst befindet.
      2. Erstellen Sie die zweite NEG in derselben Region, in der sich der in Europa bereitgestellte Cloud Run-Dienst befindet.
    2. Richten Sie Ihre Frontend-Konfiguration mit der Premium-Netzwerkdienststufe ein.

Die sich daraus ergebende Einrichtung wird im folgenden Diagramm dargestellt.

Multiregionales Routing für serverlose Anwendungen.
Multiregionales Routing für serverlose Anwendungen

Dieser Abschnitt baut auf der oben beschriebenen Load Balancer-Einrichtung auf, in der Sie eine serverlose NEG in der Region us-central1 erstellt haben, die auf einen Cloud Run-Dienst in derselben Region verweist. Außerdem wird davon ausgegangen, dass Sie einen zweiten Cloud Run-Dienst in der Region europe-west1 erstellt haben. Die zweite serverlose NEG, die Sie erstellen, verweist auf diesen Cloud Run-Dienst in der Region europe-west1.

In diesem Beispiel führen Sie die folgenden Schritte aus:

  1. Erstellen Sie eine zweite serverlose NEG in der Region europe-west1.
  2. Hängen Sie die zweite serverlose NEG an den Backend-Dienst an.

So fügen Sie einem vorhandenen Backend-Dienst eine zweite serverlose NEG hinzu:

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 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 im Bereich Backends auf Backend hinzufügen.

  7. Wählen Sie in der Liste Serverlose Netzwerk-Endpunktgruppen die Option Serverlose Netzwerk-Endpunktgruppe erstellen aus.

  8. Geben Sie einen Namen für die serverlose NEG ein.

  9. Wählen Sie bei Region die Option europe-west1 aus.

  10. Wählen Sie unter Typ der Endpunktgruppe für ein serverloses Netzwerk den Wert Cloud Run aus und führen Sie dann die folgenden Schritte aus:

    1. Wählen Sie die Option Dienst auswählen aus.
    2. Wählen Sie in der Liste Dienst den Cloud Run-Dienst aus, für den Sie einen Load Balancer erstellen möchten.

  11. Klicken Sie auf Erstellen.

  12. Klicken Sie auf der Seite Neues Backend auf Fertig.

  13. Klicken Sie auf Speichern.

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

  15. Klicken Sie zum Aktualisieren des Load Balancers auf der Seite Globalen externen Application Load Balancer bearbeiten auf Aktualisieren.

gcloud

  1. Erstellen Sie eine zweite serverlose NEG in derselben Region, in der der Cloud Run-Dienst bereitgestellt wird.

    gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME_2 \
  --region=europe-west1 \
  --network-endpoint-type=SERVERLESS \
  --cloud-run-service=CLOUD_RUN_SERVICE_2

    Ersetzen Sie Folgendes:

    • SERVERLESS_NEG_NAME_2: der Name der zweiten serverlosen NEG
    • CLOUD_RUN_SERVICE_2: der Name des Cloud Run-Dienstes

  2. Fügen Sie dem Backend-Dienst die zweite serverlose NEG als Backend hinzu.

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --global \
  --network-endpoint-group=SERVERLESS_NEG_NAME_2 \
  --network-endpoint-group-region=europe-west1

    Ersetzen Sie Folgendes:

    • BACKEND_SERVICE_NAME: der Name des Backend-Dienstes
    • SERVERLESS_NEG_NAME_2: der Name der zweiten serverlosen NEG

Authentifiziertes Pub/Sub-Push-Abo mit einer Cloud Run-Bereitstellung für mehrere Regionen verwenden

Bei authentifizierten Push-Anfragen erwartet Cloud Run standardmäßig ein regionsspezifisches Zielgruppenfeld. Wenn die Push-Anfrage bei einer Cloud Run-Bereitstellung in mehreren Regionen an einen Cloud Run-Dienst in einer anderen Region weitergeleitet wird, schlägt die JWT-Token-Bestätigung aufgrund einer Zielgruppenabweichung fehl.

So umgehen Sie diese regionsspezifische Beschränkung:

  1. Konfigurieren Sie eine benutzerdefinierte Zielgruppe, die für Dienstbereitstellungen in verschiedenen Regionen identisch ist.
  2. Konfigurieren Sie die Pub/Sub-Push-Nachrichten so, dass sie die benutzerdefinierte Zielgruppe als Zielgruppe im JWT-Token verwenden.

Regionales Routing einrichten

Ein häufiger Grund für die Bereitstellung von Anwendungen in mehreren Regionen besteht darin, die Anforderungen an die Datenlokalität zu erfüllen. So können Sie beispielsweise sicherstellen, dass Anfragen von europäischen Nutzern immer in einer Region in Europa bearbeitet werden. Zum Einrichten benötigen Sie ein URL-Schema mit separaten URLs für Nutzer aus der EU und aus Nicht-EU-Ländern und müssen EU-Nutzer zu den URLs in der EU leiten.

In einem solchen Szenario würden Sie die URL-Zuordnung verwenden, um Anfragen von bestimmten URLs zu den entsprechenden Regionen zu leiten. Bei einer solchen Konfiguration werden Anfragen für eine Region niemals an eine andere Region gesendet. Dies sorgt für eine Isolierung der Regionen. Wenn dagegen eine Region ausfällt, werden Anfragen nicht zu einer anderen Region geleitet. Diese Konfiguration erhöht also nicht die Verfügbarkeit Ihres Dienstes.

Zum Einrichten des regionalen Routings müssen Sie die Premium-Netzwerkstufe verwenden, damit Sie verschiedene Regionen in einer Weiterleitungsregel kombinieren können.

So richten Sie einen Load-Balancer mit regionalem Routing ein:

  1. Richten Sie zwei Cloud Run-Dienste in verschiedenen Regionen ein. Angenommen, Sie haben zwei Cloud Run-Dienste bereitgestellt: "hello-world-eu" in einer Region in Europa und "hello-world-us" in einer Region in den USA.
  2. Erstellen Sie einen externen Application Load Balancer mit folgender Einrichtung:
    1. Richten Sie einen Backend-Dienst mit einer serverlosen NEG in Europa ein. Die serverlose NEG muss in derselben Region erstellt werden, wie der Cloud Run-Dienst bereitgestellt in Europa.
    2. Richten Sie einen zweiten Back-End-Dienst mit einer anderen serverlosen NEG in den USA ein. Diese serverlose NEG muss in derselben Region in den USA erstellt werden, in der sich der (vollständig verwaltete) Cloud Run-Dienst befindet.
    3. Richten Sie Ihre URL-Zuordnung mit den entsprechenden Host- und Pfadregeln ein, sodass eine Gruppe von URLs zum europäischen Back-End-Dienst leitet. Alle Anfragen werden dagegen zum Back-End-Dienst in den USA geleitet.
    4. Richten Sie Ihre Frontend-Konfiguration mit der Premium-Netzwerkstufe ein.

Der Rest der Konfiguration kann wie zuvor beschrieben sein. Die resultierende Konfiguration sollte etwa so aussehen:

Regionales Routing für serverlose Anwendungen ohne Failover.
Regionales Routing für serverlose Anwendungen ohne Failover

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.
    1. 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>.
    2. Cloud Run Functions: Ersetzen Sie den Namen der Funktion durch den Platzhalter <function>. In diesem Beispiel lautet die URL-Maske example.com/<function>.
    3. App Engine: Ersetzen Sie den Namen des Dienstes durch den Platzhalter <service>. Wenn dem Dienst eine Version zugeordnet ist, ersetzen Sie die Version durch den Platzhalter <version>. In diesem Beispiel lautet die URL-Maske example.com/<service>.
    4. API Gateway: Ersetzen Sie den Gateway-Namen durch den Platzhalter <gateway>. In diesem Beispiel lautet die URL-Maske example.com/<gateway>.

  3. Optional: Wenn sich der Dienstname (oder die Funktion, die Version oder das Tag) 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>, /<gateway> oder /<function> reduziert werden.

    Wenn sich der Dienstname 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:

Cloud Run

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

Dienst, Tag-Name Benutzerdefinierte Domain-URL 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>

Cloud Run-Funktionen

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

Funktionsname Benutzerdefinierte Domain-URL URL-Maske
login https://example.com/login /<Funktion>
login https://example.com/home/login /home/<Funktion>
login https://login.example.com <Funktion>.example.com
login https://login.home.example.com <Funktion>.home.example.com

App Engine

In dieser Tabelle wird davon ausgegangen, dass Sie eine benutzerdefinierte Domain namens example.com haben und alle Ihre App Engine-Dienste dieser Domain zugeordnet sind.

Dienstname, Version Benutzerdefinierte Domain-URL URL-Maske
Dienst: login https://login.example.com/web <Dienst>.example.com
Dienst: login https://example.com/home/login/web example.com/home/<Dienst> oder /home/<Dienst>
Dienst: login; Version: test https://test.example.com/login/web <Version>.example.com/<Dienst>
Dienst: login; Version: test https://example.com/login/test example.com/<Dienst>/<Version>

API Gateway

In dieser Tabelle wird davon ausgegangen, dass Sie eine benutzerdefinierte Domain namens example.com haben und alle Ihre API Gateway-Dienste dieser Domain zugeordnet sind.

Name des Gateways Benutzerdefinierte Domain-URL für API Gateway (Vorschau) URL-Maske
Anmeldung https://example.com/login /<Gateway>
Anmeldung https://example.com/home/login /home/<Gateway>
Anmeldung https://login.example.com <Gateway>.example.com
Anmeldung https://login.home.example.com <Gateway>.home.example.com

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 Backend-Dienstes eine URL-Maske ein, statt einen bestimmten Dienst auszuwählen.

Wenn Sie bereits einen Load-Balancer haben, können Sie die Back-End-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 eine URL-Maske verweist:

  1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
    Zur Seite „Load-Balancing“
  2. Klicken Sie auf den Namen des Load-Balancers, dessen Back-End-Dienst 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. Wählen Sie unter Region die Option us-central1 aus.
    3. Wählen Sie unter Typ der Endpunktgruppe für ein serverloses Netzwerk die Plattform aus, auf der Ihre serverlosen Anwendungen (oder Dienste oder Funktionen) erstellt wurden.
      1. Wählen Sie URL-Maske verwenden aus.
      2. Geben Sie eine URL-Maske ein. Eine Anleitung zum Erstellen einer URL-Maske finden Sie unter URL-Maske erstellen.
      3. Klicken Sie auf Erstellen.
  8. Klicken Sie im Bereich Neues Backend auf Fertig.
  9. Klicken Sie auf Aktualisieren.

gcloud: Cloud Run

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

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

gcloud: Cloud Run Functions

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

gcloud compute network-endpoint-groups create helloworld-neg-mask \
 --region=us-central1 \
 --network-endpoint-type=serverless \
 --cloud-function-url-mask="example.com/<service>"

gcloud: App Engine

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

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --app-engine-url-mask="example.com/<service>"

gcloud: API Gateway

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

gcloud beta compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway \
  --serverless-deployment-url-mask="example.com/<gateway>"

Informationen dazu, wie der Load-Balancer mit Problemen bei nicht übereinstimmenden URL-Masken umgeht, finden Sie unter Probleme mit serverlosen NEGs beheben.

Vom externen Application Load Balancer bereitzustellende benutzerdefinierte Domain verschieben

Wenn Ihre serverlosen Computing-Anwendungen benutzerdefinierten Domains zugeordnet werden, sollten Sie Ihre DNS-Einträge aktualisieren, damit der Traffic, der an die vorhandenen benutzerdefinierten Domain-URLs von Cloud Run, Cloud Run Functions, API Gateway oder App Engine gesendet wird, stattdessen über den Load-Balancer geleitet wird.

Wenn Sie beispielsweise eine benutzerdefinierte Domain namens example.com haben und alle Ihre Cloud Run-Dienste dieser Domain zugeordnet sind, sollten Sie den DNS-Eintrag für example.com so aktualisieren, sodass er auf die IP-Adresse des Load-Balancers verweist.

Bevor Sie die DNS-Einträge aktualisieren, können Sie Ihre Konfiguration lokal testen. Erzwingen Sie dazu die lokale DNS-Auflösung der benutzerdefinierten Domain in die IP-Adresse des Load-Balancers. Passen Sie für lokale Tests entweder die Datei /etc/hosts/ auf Ihrem lokalen Computer an, damit example.com auf die IP-Adresse des Load-Balancers verweist, oder verwenden Sie das Flag curl --resolve, damit curl für die Anfrage die IP-Adresse des Load-Balancers verwendet.

Wenn der DNS-Eintrag für example.com in die IP-Adresse des HTTPS-Load-Balancers aufgelöst wird, werden an example.com gesendete Anfragen über den Load Balancer weitergeleitet. Der Load-Balancer leitet sie je nach URL-Zuordnung an den entsprechenden Back-End-Dienst weiter. Wenn der Backend-Dienst mit einer URL-Maske konfiguriert ist, verwendet die serverlose NEG außerdem die Maske, um die Anfrage zum entsprechenden Cloud Run-, Cloud Run Functions-, API Gateway- oder App Engine-Dienst zu leiten.

Cloud CDN aktivieren

Wenn Sie Cloud CDN für Ihren Cloud Run-Dienst aktivieren, können Sie die Inhaltsübermittlung optimieren, indem Sie Inhalte im Cache in der Nähe Ihrer Nutzer speichern.

Sie können Cloud CDN mit dem Befehl gcloud compute backend-services update in Backend-Diensten aktivieren, die von globalen externen Application Load Balancern verwendet werden.

gcloud compute backend-services update helloworld-backend-service 

    --enable-cdn 

    --global

Cloud CDN wird für Backend-Dienste mit Cloud Run-, Cloud Run Functions-, API Gateway- und App Engine-Backends unterstützt.

IAP für den externen Application Load Balancer aktivieren

Hinweis: IAP ist allerdings nicht mit Cloud CDN kompatibel.

Sie können IAP so konfigurieren, dass es aktiviert oder deaktiviert (Standard) wird. Wenn diese Option aktiviert ist, müssen Werte für oauth2-client-id und oauth2-client-secret angegeben werden.

Aktualisieren Sie zum Aktivieren von IAP den Back-End-Dienst so, dass das Flag --iap=enabled mit oauth2-client-id und oauth2-client-secret enthalten ist.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \
    --global

Optional können Sie IAP für eine Compute Engine-Ressource aktivieren. Verwenden Sie dazu die Google Cloud Console, die gcloud CLI oder die API.

Google Cloud Armor aktivieren

Google Cloud Armor ist ein Sicherheitsprodukt, das Schutz vor DDoS-Angriffen (Distributed Denial of Service) für alle GCLB-Proxy-Load-Balancer bietet. Google Cloud Armor stellt außerdem konfigurierbare Sicherheitsrichtlinien für Dienste bereit, auf die über einen externen Application Load Balancer zugegriffen wird. Informationen zu Google Cloud Armor-Sicherheitsrichtlinien für externe Application Load Balancer finden Sie in der Übersicht über Google Cloud Armor-Sicherheitsrichtlinien.

Wenn Sie Cloud Run Functions verwenden, können Sie mithilfe der Einstellung internal-and-gclb für eingehenden Traffic dafür sorgen, dass Anfragen geblockt werden, die an Standard-URLs gesendet werden.

Wenn Sie Cloud Run verwenden, können Sie sicherstellen, dass Anfragen, die an Standard-URLs oder andere über Cloud Run eingerichtete benutzerdefinierte Domains gesendet werden, geblockt werden durch das beschränken des eingehenden Traffics auf "internes und Cloud-Load-Balancing".

Wenn Sie App Engine verwenden, können Sie mithilfe von Steuerelementen für eingehenden Traffic festlegen, dass Ihre Anwendung nur Anfragen empfängt, die vom Load Balancer (und gegebenenfalls von der VPC) gesendet werden.

Ohne die richtigen Einstellungen für eingehenden Traffic können Nutzer die Standard-URL Ihrer serverlosen Anwendung verwenden, um Load-Balancer, Google Cloud Armor-Sicherheitsrichtlinien, SSL-Zertifikate und private Schlüssel zu umgehen, die durch den Load-Balancer übergeben werden.

Optional: Konfigurieren Sie eine Standard-Backend-Sicherheitsrichtlinie. Die Standardsicherheitsrichtlinie drosselt den Traffic über einen vom Nutzer konfigurierten Schwellenwert. Weitere Informationen zu Standardsicherheitsrichtlinien finden Sie in der Übersicht zur Ratenbegrenzung.

  1. Wenn Sie die standardmäßige Google Cloud Armor-Sicherheitsrichtlinie deaktivieren möchten, wählen Sie im Menü der Backend-Sicherheitsrichtlinie None aus.
  2. Wählen Sie im Abschnitt Sicherheit die Option Standardsicherheitsrichtlinie aus.
  3. Akzeptieren Sie im Feld Richtlinienname den automatisch generierten Namen oder geben Sie einen Namen für Ihre Sicherheitsrichtlinie ein.
  4. Akzeptieren Sie im Feld Anzahl der Anfragen die Standardanzahl der Anfragen oder geben Sie eine Ganzzahl zwischen 1 und 10,000 ein.
  5. Wählen Sie im Feld Intervall ein Intervall aus.
  6. Wählen Sie im Feld Für Schlüssel erzwingen einen der folgenden Werte aus: Alle, IP-Adresse oder X-Forwarded-For IP-Adresse. Weitere Informationen zu diesen Optionen finden Sie unter Clients für die Ratenbegrenzung identifizieren.

Logging und Monitoring aktivieren

Sie können Logs für den Backend-Dienst eines externen Application Load Balancers aktivieren, deaktivieren und aufrufen. Bei Verwendung der Google Cloud Console ist Logging standardmäßig für Backend-Dienste mit serverlosen NEG-Backends aktiviert. Sie können gcloud verwenden, um das Logging für jeden Backend-Dienst nach Bedarf zu deaktivieren. Eine Anleitung finden Sie unter Logging.

Der Load Balancer exportiert auch Monitoring-Daten nach Cloud Monitoring. Monitoring-Messwerte können dazu verwendet werden, die Konfiguration, Auslastung und Leistung eines Load-Balancers zu beurteilen. Messwerte können auch verwendet werden, um Probleme zu beheben und die Ressourcennutzung und Nutzerfreundlichkeit zu verbessern. Eine Anleitung dazu finden Sie unter Monitoring.

HTTP-Keepalive-Zeitlimit des Clients aktualisieren

Der in den vorherigen Schritten erstellte Load Balancer wurde mit einem Standardwert für das Client-HTTP-Keepalive-Zeitlimit konfiguriert.

Folgen Sie der nachstehenden Anleitung, um das HTTP-Keepalive-Zeitlimit des Clients zu aktualisieren.

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, den Sie ändern möchten.
  3. Klicken Sie auf Bearbeiten.
  4. Klicken Sie auf Frontend-Konfiguration.
  5. Maximieren Sie Erweiterte Funktionen. Geben Sie für HTTP-Keepalive-Zeitlimit ein Zeitlimit ein.
  6. Klicken Sie auf Aktualisieren.
  7. Klicken Sie zum Prüfen Ihrer Änderungen auf Prüfen und abschließen und dann auf Aktualisieren.

gcloud

Aktualisieren Sie bei einem HTTP-Load-Balancer den Ziel-HTTP-Proxy mit dem Befehl gcloud compute target-http-proxies update:

    gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global

Aktualisieren Sie bei einem HTTPS-Load-Balancer den Ziel-HTTPS-Proxy mit dem Befehl gcloud compute target-https-proxies update:

    gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global

Ersetzen Sie Folgendes:

  • TARGET_HTTP_PROXY_NAME ist der Name des HTTP-Ziel-Proxys.
  • TARGET_HTTPS_PROXY_NAME ist der Name des HTTPS-Ziel-Proxys.
  • HTTP_KEEP_ALIVE_TIMEOUT_SEC ist das HTTP-Keepalive-Zeitlimit von 5 bis 600 Sekunden.

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 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. 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 Globalen externen 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 im Abschnitt outlierDetection 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 Backend-Dienst verknüpft ist. Bevor Sie eine NEG löschen, muss sie vom Back-End-Dienst getrennt sein.

Console

  1. Wechseln Sie zum Tab Back-End-Dienste im erweiterten Load-Balancing-Menü, damit der zu löschende serverlose NEG derzeit von keinem Back-End-Dienst verwendet wird.
    Zum Tab „Back-End-Dienste“
  2. Wenn die serverlose NEG aktuell verwendet wird:
    1. Klicken Sie mithilfe der serverlosen NEG auf den Namen des Back-End-Dienstes.
    2. Klicken Sie auf Bearbeiten .
    3. Klicken Sie in der Liste der Back-Ends auf , um das serverlose NEG-Back-End aus dem Back-End-Dienst zu entfernen.
    4. Klicken Sie auf Speichern.
  3. Rufen Sie in der Google Cloud Console die Seite Netzwerk-Endpunktgruppe auf.
    Zur Seite „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 Back-End-Dienst zu entfernen, müssen Sie die Region angeben, in der die NEG erstellt wurde. Sie müssen auch das Flag --global angeben, da helloworld-backend-service eine globale Ressource ist.

gcloud compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

So löschen Sie die serverlose NEG:

gcloud compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1

Nächste Schritte