Regionsübergreifendes Failover mit dem Cloud Run-Dienststatus automatisieren

In diesem Dokument wird beschrieben, wie Sie einen hochverfügbaren, multiregionalen Cloud Run-Dienst mit automatisierten Failover- und Failback-Funktionen konfigurieren und bereitstellen.

Der Cloud Run-Dienstzustand zeigt den aggregierten Zustand Ihres Dienstes in jeder Region mithilfe von serverlosen Netzwerk-Endpunktgruppen (NEGs) an.

Funktionsweise

Beim automatischen Failover werden eingehende Anfragen von einem globalen externen Application Load Balancer oder einem regionenübergreifenden internen Application Load Balancer über regionale serverlose NEGs an Ihre Cloud Run-Dienste weitergeleitet. Einzelne Containerinstanzen führen Bereitschaftsprüfungen aus, die von Cloud Run aggregiert werden, um den allgemeinen Systemzustand jedes regionalen Dienstes zu ermitteln.

Ein Cloud Run-Dienst in einer Region ist fehlerfrei und empfängt Traffic, wenn mindestens 60% seiner Instanzen die Bereitschaftsprüfungen bestehen. Wenn eine Region fehlerhaft wird, leitet der Load Balancer den Traffic automatisch an eine fehlerfreie Region weiter. Sobald sich die fehlerhafte Region erholt hat, stellt der Load Balancer den Traffic dorthin schrittweise wieder her.

Beschränkungen

Für den Cloud Run-Dienstzustand gelten die folgenden Einschränkungen:

  • Sie müssen mindestens eine Mindestinstanz auf Dienst- oder Überarbeitungsebene pro Region konfigurieren, um den Zustand zu berechnen. Sie können auch den Messwert Anzahl der Containerinstanzen in Cloud Monitoring verwenden, um die erforderlichen Mindestinstanzen für Ihre Regionen zu schätzen.
  • Für Failover sind mindestens zwei Dienste aus verschiedenen Regionen erforderlich. Andernfalls wird die Fehlermeldung no healthy upstream angezeigt, wenn ein Dienst fehlschlägt.
  • Sie können keine URL-Maske oder Tags in serverlosen NEGs konfigurieren.
  • Wenn ein Cloud Run-Dienst gelöscht wird, meldet Cloud Run dem Load Balancer keinen fehlerhaften Status.
  • Beim Starten einer neuen Instanz wird die erste Bereitschaftsprüfung nicht berücksichtigt. Daher kann eine Anfrage kurzzeitig an einen neu gestarteten Dienst weitergeleitet werden, bevor dieser fehlerhaft wird.
  • Der Zustand des Cloud Run-Dienstes wird für alle Instanzen berechnet. Versionen ohne Prüfungen und neu gestartete Instanzen, die ihre erste Bereitschaftsprüfung noch nicht abgeschlossen haben, werden als unbekannt behandelt. Während einer Umstellung des gesamten Traffics zwischen Überarbeitungen kann Service Health kurzzeitig UNKNOWN melden, während neue Instanzen gestartet werden und ihre erste Bereitschaftsprüfung abschließen. Der Load Balancer behandelt unbekannte Instanzen als fehlerfrei.
  • Die Berechnung des Dienstzustands kann zu ungenauen Ergebnissen führen, wenn Instanzen schnell abstürzen.

Best Practices

Sie können eine Kombination aus Bereitschaftsprüfungen, Aufteilung des Traffics und Mindestanzahl von Instanzen verwenden, um sichere, schrittweise Roll-outs durchzuführen. So können Sie den Zustand einer neuen Version in einer einzelnen „Canary“-Region prüfen, bevor Sie sie hochstufen. Dadurch wird sichergestellt, dass der Load Balancer Traffic nur an fehlerfreie regionale Backends sendet.

Wenn Sie Prüfungen für Ihre eigene Anwendung konfigurieren, fügen Sie Ihrem Dienstcode einen HTTP/1-Endpunkt (den Cloud Run-Standard, nicht HTTP/2) hinzu, um auf die Prüfung zu reagieren. Der Endpunktname (z. B. /startup, /health oder /are_you_ready) muss mit dem path in der Prüfungskonfiguration übereinstimmen. HTTP-Systemdiagnose-Endpunkte sind extern zugänglich und folgen den gleichen Prinzipien wie alle anderen extern zugänglichen HTTP-Dienstendpunkte.

Sie können eine Dienstüberarbeitung für einen vorhandenen Cloud Run-Dienst bereitstellen, der keine Bereitschaftsprüfung oder Cloud Run Service Health verwendet. Führen Sie diesen Vorgang für jede Region einzeln aus, um eine neue Überarbeitung sicher bereitzustellen:

  1. Stellen Sie die neue Version in einer einzelnen „Canary“-Region mit einer konfigurierten Bereitschaftsprüfung bereit.

  2. Senden Sie einen kleinen Teil des Traffics (z. B. 1%) an die neue Version.

  3. Verwenden Sie eine Mindestanzahl von Instanzen ungleich null auf Dienstebene und nicht auf Überarbeitungsebene.

  4. Prüfen Sie den Messwert für die Bereitschaftsprüfung (run.googleapis.com/container/instance_count_with_readiness), um sicherzustellen, dass neue Instanzen fehlerfrei sind.

  5. Erhöhen Sie den Traffic-Prozentsatz für die neue Version schrittweise. Überwachen Sie während der Hochskalierung den regionalen Cloud Run-Dienstzustand (run.googleapis.com/service_health_count), der vom Load Balancer verwendet wird. Der Cloud Run-Dienst meldet den Service Health UNKNOWN, bis genügend Traffic an die neue Version weitergeleitet wird.

  6. Sobald die Version 100% des Traffics empfängt und der regionale Cloud Run-Dienst stabil und fehlerfrei ist, wiederholen Sie diesen Vorgang für alle anderen Regionen.

Für Dienste, die bereits Cloud Run Service Health verwenden, können Sie einen zweistufigen Roll-out parallel in mehreren Regionen ausführen, um UNKNOWN-Meldungen zu vermeiden:

  1. Leiten Sie einen Teil des Traffics an die neue Version weiter. Warten Sie, bis neue Instanzen gestartet sind und die Bereitschaftsprüfungen bestehen.

  2. Leiten Sie 100% des Traffics an die neue Version weiter.

Anleitung: Automatisches Failover konfigurieren

In dieser Anleitung erfahren Sie, wie Sie eine Go-Beispielanwendung in zwei Regionen bereitstellen, einen globalen externen Application Load Balancer mit serverlosen NEGs einrichten und ein automatisiertes Failover testen.

In dieser Anleitung wird Folgendes beschrieben:

  1. Beispielanwendung vorbereiten
  2. Cloud Run-Dienste in zwei Regionen mit Bereitschaftsprüfungen bereitstellen
  3. Globalen externen Application Load Balancer einrichten
  4. Dienste über die serverlose NEG hinzufügen
  5. Failover testen

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.

Neuen Nutzern von Google Cloud steht möglicherweise eine kostenlose Testversion zur Verfügung.

  1. Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

  6. Aktivieren Sie die APIs für Artifact Registry, Cloud Build, Cloud Run Admin API, Network Services API und Compute Engine, falls sie noch nicht aktiviert sind.

    Erforderliche Rollen zum Aktivieren von APIs

    Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Inhaberrolle (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen

    APIs aktivieren

  7. Installieren und initialisieren Sie die gcloud CLI.
  8. Aktualisieren Sie die Komponenten: 
    gcloud components update
  9. Legen Sie die in dieser Anleitung verwendeten Konfigurationsvariablen fest: 
    PROJECT_ID= gcloud config set core/project PROJECT_ID
PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
SERVICE=health-example
REGION_A=us-west1
REGION_B=europe-west1
     Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID in Google Cloud .

Erforderliche Rollen festlegen

Wenn Sie die Bereitstellung aus der Quelle mit Build durchführen möchten, müssen Sie oder Ihr Administrator dem Cloud Build-Dienstkonto die folgenden IAM-Rollen zuweisen.

Klicken, um die erforderlichen Rollen für das Cloud Build-Dienstkonto aufzurufen

Cloud Build verwendet automatisch das Compute Engine-Standarddienstkonto als Cloud Build-Standarddienstkonto, um Ihren Quellcode und Ihre Cloud Run-Ressource zu erstellen, sofern Sie dieses Verhalten nicht überschreiben. Damit Cloud Build Ihre Quellen erstellen kann, bitten Sie Ihren Administrator, dem Compute Engine-Standarddienstkonto in Ihrem Projekt die Rolle Cloud Run Builder (roles/run.builder) zuzuweisen:

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/run.builder

Ersetzen Sie PROJECT_NUMBER durch Ihre Google Cloud-Projektnummer und PROJECT_ID durch Ihre Google Cloud-Projekt-ID. Eine detaillierte Anleitung zum Ermitteln der Projekt-ID und der Projektnummer finden Sie unter Projekte erstellen und verwalten.

Es dauert einige Minuten, bis die Zuweisung der Rolle „Cloud Run-Builder“ für das Compute Engine-Standarddienstkonto übertragen wurde.

Bitten Sie Ihren Administrator, der Dienstidentität die Rolle Storage-Administrator (roles/storage.admin) zuzuweisen, um die Berechtigungen zu erhalten, die Ihre Dienstidentität benötigt, um auf die Datei und den Cloud Storage-Bucket zuzugreifen. Weitere Informationen zu Cloud Storage-Rollen und -Berechtigungen finden Sie unter IAM für Cloud Storage.

Eine Liste der IAM-Rollen und -Berechtigungen im Zusammenhang mit Cloud Run finden Sie unter IAM-Rollen für Cloud Run und IAM-Berechtigungen für Cloud Run. Wenn Ihr Cloud Run-Dienst mitGoogle Cloud -APIs wie Cloud-Clientbibliotheken verknüpft ist, lesen Sie die Konfigurationsanleitung für Dienstidentitäten. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Bereitstellungsberechtigungen und Zugriff verwalten.

Beispielanwendung vorbereiten

So rufen Sie das gewünschte Codebeispiel ab:

  1. Klonen Sie das Beispiel-Repository auf Ihren lokalen Computer:

    git clone https://github.com/GoogleCloudPlatform/golang-samples

  2. Wechseln Sie in das Verzeichnis, das den Cloud Run-Beispielcode enthält:

    cd golang-samples/run/service-health

Cloud Run-Dienst in zwei Regionen mit Bereitschaftsprüfungen bereitstellen

Für Failover sind mindestens zwei Dienste aus verschiedenen Regionen erforderlich. Führen Sie die folgenden Befehle aus, um Ihre Dienste aus dem Quellcode in zwei verschiedenen Regionen mit Bereitschaftsprüfungen bereitzustellen. Wenn Sie Terraform verwenden möchten, lesen Sie den Abschnitt Multiregionalen Dienst bereitstellen und fügen Sie die Konfiguration der Bereitschaftsprüfung hinzu.

  1. Stellen Sie den Dienst health-example in us-west1 und europe-west1 aus dem Quellverzeichnis bereit. Sie benötigen mindestens eine Instanz, um Service Health mit Bereitschaftsprüfungen zu konfigurieren:

    gcloud run deploy $SERVICE \
--source=. \
--regions=$REGION_A,$REGION_B \
--min=10 \
--readiness-probe httpGet.path="/are_you_ready"

  2. Beantworten Sie die Aufforderungen, die erforderlichen APIs zu installieren, indem Sie nach Aufforderung y antworten. Dies ist nur einmal für ein Projekt erforderlich. Antworten Sie auf andere Aufforderungen, indem Sie die Plattform und Region angeben, sofern Sie diese nicht wie im Abschnitt Vorbereitung beschrieben eingerichtet haben.

Globalen externen Application Load Balancer einrichten

So richten Sie einen globalen externen Application Load Balancer ein, um Traffic zwischen us-west1 und europe-west1 weiterzuleiten: Wenn Sie Ihren Load Balancer lieber mit Terraform bereitstellen möchten, lesen Sie den Abschnitt Globalen externen Application Load Balancer erstellen.

  1. Erstellen Sie einen Backend-Dienst.

    gcloud compute backend-services create $SERVICE-bs \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --global

  2. Richten Sie eine globale statische externe IP-Adresse ein, um den Load Balancer zu erreichen:

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

  3. Erstellen Sie eine URL-Zuordnung, um eingehende Anfragen an den Backend-Dienst weiterzuleiten:

    gcloud compute url-maps create $SERVICE-lb \
  --default-service $SERVICE-bs

  4. Erstellen Sie einen Ziel-HTTP-Proxy, um Anfragen an Ihre URL-Zuordnung weiterzuleiten:

    gcloud compute target-http-proxies create $SERVICE-hp \
--url-map=$SERVICE-lb

  5. Erstellen Sie eine Weiterleitungsregel, um eingehende Anfragen an den Proxy weiterzuleiten:

    gcloud compute forwarding-rules create $SERVICE-fr \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --network-tier=PREMIUM \
  --address=$SERVICE-ip \
  --target-http-proxy=$SERVICE-hp \
  --global \
  --ports=80

Dienste über eine serverlose NEG hinzufügen

So fügen Sie die Dienste, die Sie in us-west1 und europe-west1 bereitgestellt haben, mithilfe der serverlosen NEG hinzu: Wenn Sie Ihre serverlosen NEGs lieber mit Terraform bereitstellen möchten, finden Sie weitere Informationen unter Regionale Netzwerk-Endpunktgruppen konfigurieren.

  1. Erstellen Sie eine serverlose Netzwerk-Endpunktgruppe (NEG) für Ihren Cloud Run-Dienst in us-west1 und europe-west1:

    gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_A \
    --region $REGION_A \
    --network-endpoint-type=serverless \
    --cloud-run-service=$SERVICE

    gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_B \
    --region $REGION_B \
    --network-endpoint-type=serverless \
    --cloud-run-service=$SERVICE

  2. Fügen Sie die serverlose NEG als Backend zu den Backend-Diensten in us-west1 und europe-west1 hinzu:

    gcloud compute backend-services add-backend $SERVICE-bs \
    --global \
    --network-endpoint-group=$SERVICE-neg-$REGION_A \
    --network-endpoint-group-region=$REGION_A

    gcloud compute backend-services add-backend $SERVICE-bs \
    --global \
    --network-endpoint-group=$SERVICE-neg-$REGION_B \
    --network-endpoint-group-region=$REGION_B

Weitere Konfigurationsoptionen finden Sie unter Globalen externen Application Load Balancer mit Cloud Run einrichten.

Regionalen Systemzustand melden

Führen Sie die folgenden Schritte aus, um die regionale Cloud Run Service Health zu aggregieren und einen fehlerfreien oder fehlerhaften Status an den Load Balancer zu melden:

  1. Stellen Sie eine Cloud Run-Dienstrevision in mehreren Regionen mit einer oder mehreren Mindestinstanzen bereit. Führen Sie den folgenden Befehl aus, um die Bereitschaftsprüfung zu verwenden, die Sie im vorherigen Schritt konfiguriert haben:

    gcloud run deploy SERVICE_NAME \
--regions=REGION_A,REGION_B \
--min=MIN_INSTANCES

    Ersetzen Sie Folgendes:

    • SERVICE_NAME ist der Name des Diensts.
    • REGION_A, REGION_B: verschiedene Regionen für Ihre Dienstrevision. Legen Sie beispielsweise REGION_A auf us-central1 und REGION_B auf europe-west1 fest.
    • MIN_INSTANCES: die Anzahl von Containerinstanzen, die einsatzbereit gehalten werden und zum Empfangen von Anfragen bereit sein sollen. Sie müssen den Mindestwert auf 1 oder mehr festlegen.

  2. Konfigurieren Sie eine gRPC- oder HTTP-Bereitschaftsprüfung, die auf jeder Containerinstanz eingerichtet ist.

  3. Konfigurieren Sie einen globalen externen Application Load Balancer oder einen regionenübergreifenden internen Application Load Balancer, um Traffic von fehlerhaften Regionen wegzuleiten.

  4. Richten Sie serverlose NEGs für jeden Cloud Run-Dienst in jeder Region ein.

  5. Konfigurieren Sie einen Backend-Dienst, um eine Verbindung zu serverlosen NEGs herzustellen.

Beispiel-Cloud Run-Anwendung mit Bereitschaftsprüfungen in zwei Regionen bereitstellen

Failover testen und prüfen

So testen Sie das Failover, um die Zuverlässigkeit und Ausfallsicherheit Ihrer Cloud Run-Dienste zu gewährleisten:

  1. Führen Sie den folgenden Befehl aus, um die IP-Adresse des Load Balancers abzurufen:

    LBIP=$(gcloud compute addresses describe $SERVICE-ip --global --format='value(address)')

  2. Optional: Senden Sie eine Anfrage an Ihren Load Balancer, wenn Ihre Dienste eine Authentifizierung erfordern:

    curl  -H "Authorization: Bearer $(gcloud auth print-identity-token)" $LBIP

  3. Rufen Sie den Wert der LBIP-Variablen mit dem Befehl echo $LBIP ab. Dadurch wird die IP-Adresse des Load Balancers ausgegeben. Beispiel: 11.22.33.44.

  4. Wenn Sie einen Failover testen möchten, rufen Sie die URL http://LOAD_BALANCER_IP auf, wobei LOAD_BALANCER_IP der Wert ist, den Sie im vorherigen Schritt erhalten haben. Klicken Sie im Bereich Bereitstellungsregionen auf den Schalter für Ihre Region. Dadurch werden die fehlerfreie Region und die Instanz, die Traffic verarbeitet, festgelegt:

    Regionenübergreifendes Failover mit Cloud Run Service Health automatisieren

Systemdiagnosen überwachen

Nachdem Sie Cloud Run Service Health eingerichtet haben, erfassen serverlose NEGs den Cloud Monitoring-Messwert für den Dienstzustand. Sie können den Systemzustand der vorhandenen regionalen Dienste aufrufen.

Wenn ein Dienst in einer Region fehlerhaft ist, leitet der Load Balancer den Traffic von der fehlerhaften Region in eine fehlerfreie Region um. Der Traffic wird wiederhergestellt, sobald die Region wieder fehlerfrei ist.

Authentifizierte Pub/Sub-Push-Abos mit multiregionaler Bereitstellung verwenden

Ein Pub/Sub-Dienst sendet standardmäßig Nachrichten an Push-Endpunkte in derselben Google Cloud -Region, in der der Pub/Sub-Dienst die Nachrichten speichert. Eine Problemumgehung für dieses Verhalten finden Sie unter Authentifiziertes Pub/Sub-Push-Abo mit einer multiregionalen Cloud Run-Bereitstellung verwenden.

Alternative: Manuelles Failover konfigurieren

Wenn Sie den Traffic manuell so konfigurieren müssen, dass er ohne Prüfungen auf eine fehlerfreie Region umgeleitet wird, ändern Sie die URL-Zuordnung des globalen externen Application Load Balancers.

  1. Wenn Sie die URL-Zuordnung des globalen externen Application Load Balancers aktualisieren möchten, entfernen Sie die NEG mit dem Flag --global aus dem Backend-Dienst:

    gcloud compute backend-services remove-backend BACKEND_NAME \
--network-endpoint-group=NEG_NAME \
--network-endpoint-group-region=REGION \
--global

    Ersetzen Sie Folgendes:

    • BACKEND_NAME ist der Name des Backend-Dienstes.
    • NEG_NAME: Der Name der Netzwerk-Endpunktgruppenressource, z. B. myservice-neg-uscentral1.
    • REGION: Die Region, in der die NEG erstellt wurde und aus der Sie Ihren Dienst entfernen möchten. Beispiel: us-central1,asia-east1

  2. Rufen Sie https://<domain-name> auf, um zu prüfen, ob eine fehlerfreie Region jetzt Traffic verarbeitet.

Löschen Sie alle Ressourcen, die Sie mit dieser Anleitung bereitgestellt haben, um zusätzliche Kosten für Ihr Google Cloud -Konto zu vermeiden.

Projekt löschen

Wenn Sie ein neues Projekt für diese Anleitung erstellt haben, löschen Sie das Projekt. Wenn Sie ein vorhandenes Projekt verwendet haben und es beibehalten möchten, ohne die Änderungen in dieser Anleitung hinzuzufügen, löschen Sie die für die Anleitung erstellten Ressourcen.

Am einfachsten vermeiden Sie weitere Kosten, wenn Sie das zum Ausführen der Anleitung erstellte Projekt löschen.

So löschen Sie das Projekt:

  1. Wechseln Sie in der Google Cloud -Console zur Seite Ressourcen verwalten.

    Zur Seite „Ressourcen verwalten“

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Anleitungsressourcen löschen

  1. Löschen Sie den Cloud Run-Dienst, den Sie in dieser Anleitung bereitgestellt haben. Für Cloud Run-Dienste fallen erst Kosten an, wenn sie Anfragen empfangen.

    Führen Sie den folgenden Befehl aus, um den Cloud Run-Dienst zu löschen:

    gcloud run services delete SERVICE-NAME

    Ersetzen Sie SERVICE-NAME durch den Namen Ihres Dienstes.

    Sie können Cloud Run-Dienste auch über die Google Cloud Console löschen.

  2. Entfernen Sie die Konfiguration der Standardregion gcloud, die Sie während der Einrichtung für die Anleitung hinzugefügt haben:

     gcloud config unset run/region

  3. Entfernen Sie die Projektkonfiguration:

     gcloud config unset project

Nächste Schritte