Manuelle Skalierung

Auf dieser Seite wird beschrieben, wie Sie Ihren Dienst manuell skalieren. Außerdem finden Sie dort eine Anleitung für einen häufigen Anwendungsfall: Ändern der Anzahl der Instanzen basierend auf einem Zeitplan mithilfe von Cloud Scheduler-Jobs und der Cloud Run Admin API.

Übersicht

Standardmäßig wird Cloud Run je nach Traffic und CPU-Auslastung automatisch auf eine angegebene oder standardmäßige maximale Anzahl von Instanzen skaliert. Für einige Anwendungsfälle ist es jedoch möglicherweise sinnvoll, eine bestimmte Anzahl von Instanzen mithilfe des manuellen Scalings festzulegen.

Bei der manuellen Skalierung können Sie eine bestimmte Anzahl von Instanzen festlegen, unabhängig von Traffic oder Auslastung und ohne dass eine erneute Bereitstellung erforderlich ist. So haben Sie die Möglichkeit, Ihre eigene Skalierungslogik mit einem externen System zu schreiben. Ein Beispiel hierfür finden Sie unter Zeitplanbasierte Skalierung.

Einstellungen für die Mindest- und Höchstanzahl von Instanzen auf Überarbeitungsebene und manuelle Skalierung

Wenn Sie für Ihren Dienst die manuelle Skalierung festlegen, werden alle Einstellungen für die Mindestanzahl und die maximale Anzahl von Instanzen auf Überarbeitungsebene ignoriert.

Trafficaufteilungen für die manuelle Skalierung

In der folgenden Liste wird beschrieben, wie Instanzen zugewiesen werden, wenn Sie den Traffic bei der manuellen Skalierung aufteilen. Das gilt auch für das Verhalten bei Überarbeitungen mit Traffic-Tag.

• Bei einer Trafficaufteilung werden jeder Überarbeitung Instanzen proportional zur Trafficaufteilung zugewiesen, ähnlich wie bei der Trafficaufteilung mit Mindestanzahl von Instanzen auf Dienstebene.

• Wenn die Anzahl der Revisionen, die Traffic erhalten, die Anzahl der manuellen Instanzen überschreitet, haben einige Revisionen keine Instanzen. Traffic, der an diese Überarbeitungen gesendet wird, führt zum gleichen Fehler wie bei deaktivierten Überarbeitungen.

• Für alle Überarbeitungen, die in einer Trafficaufteilung Traffic empfangen, werden alle Mindest- und Höchstanzahlen von Instanzen auf Überarbeitungsebene deaktiviert.

• Wenn eine Überarbeitung nur aufgrund von Traffic-Tags aktiv ist:

  • Wenn die Mindestanzahl von Instanzen auf Versionsebene festgelegt ist, wird die angegebene Anzahl von Instanzen gestartet, sie wird jedoch nicht auf die Gesamtzahl der manuellen Instanzen des Dienstes angerechnet. Die Revision wird nicht automatisch skaliert.
  • Wenn die Mindestanzahl von Instanzen auf Überarbeitungsebene nicht festgelegt ist, wird die Überarbeitung als Reaktion auf Traffic, der an die Tag-URL gesendet wird, auf maximal eine Instanz hochskaliert.

Abrechnungsverhalten bei manueller Skalierung

Wenn Sie die manuelle Skalierung verwenden, ähnelt das Abrechnungsverhalten dem Verhalten bei Verwendung der Funktion Mindestanzahl von Instanzen.

Bei manueller Skalierung und instanzbasierter Abrechnung werden manuell skalierte inaktive Instanzen als aktive Instanzen abgerechnet.

Wenn Sie die manuelle Skalierung mit anfragebasierter Abrechnung verwenden, werden manuell skalierte inaktive Instanzen als inaktive Mindestanzahl von Instanzen abgerechnet. Vollständige Abrechnungsdetails finden Sie auf der Preisseite.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Bereitstellen von Cloud Run-Diensten benötigen:

• Cloud Run-Entwickler (roles/run.developer) im Cloud Run-Dienst
• Dienstkontonutzer (roles/iam.serviceAccountUser) für die Dienstidentität
• Artifact Registry Reader (roles/artifactregistry.reader) für das Artifact Registry-Repository des bereitgestellten Container-Images (falls zutreffend)

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.

Skalierung konfigurieren

Sie können den Skalierungsmodus über die Google Cloud Console, die Google Cloud CLI, eine YAML-Datei oder die API konfigurieren, wenn Sie einen Dienst erstellen oder aktualisieren:

gcloud beta run deploy SERVICE \
    --scaling=INSTANCE_COUNT \
    --image IMAGE_URL

gcloud beta run services update SERVICE \
   --scaling=INSTANCE_COUNT

    curl -H "Content-Type: application/json" \
    -H "Authorization: Bearer ACCESS_TOKEN" \
    -X PATCH \
    -d '{"launchStage":"BETA","scaling":{"manualInstanceCount":MANUAL_INSTANCE_COUNT }}' \
    https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE?update_mask=launchStage,scaling.manualInstanceCount

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE_NAME"
  location = "REGION"
  launch_stage = "BETA"

  template {
    containers {
      image = "IMAGE_URL"
    }
  }
  scaling {
    scaling_mode = "MANUAL"
    manual_instance_count = "INSTANCE_COUNT"
  }
}

Skalierungskonfiguration für Ihren Dienst ansehen

So rufen Sie die Instanzen der Skalierungskonfiguration für Ihren Cloud Run-Dienst auf:

gcloud beta run services describe SERVICE

gcloud run services describe SERVICE --format export > service.yaml

Dienst deaktivieren

Wenn Sie einen Dienst deaktivieren, werden alle Anfragen, die gerade verarbeitet werden, abgeschlossen. Alle weiteren Anfragen an die Dienst-URL schlagen jedoch mit einem Service unavailable- oder Service disabled-Fehler fehl.

Anfragen an Dienstversionen, die nur aufgrund von Traffic-Tags aktiv sind, sind nicht betroffen, da diese Versionen nicht deaktiviert werden.

Um einen Dienst zu deaktivieren, legen Sie die Skalierung auf null fest. Sie können einen Dienst über die Google Cloud Console, die Google Cloud CLI, eine YAML-Datei oder die API deaktivieren:

gcloud beta run services update SERVICE --scaling=0

    curl -H "Content-Type: application/json" \
    -H "Authorization: Bearer ACCESS_TOKEN" \
    -X PATCH \
    -d '{"launchStage":"BETA","scaling":{"manualInstanceCount":0 }}' \
    https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE?update_mask=launchStage,scaling.manualInstanceCount

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE_NAME"
  location = "REGION"
  launch_stage = "BETA"

  template {
    containers {
      image = "IMAGE_URL"
    }
  }
  scaling {
    scaling_mode = "MANUAL"
    manual_instance_count = "0"
  }
}

Beispiel für die zeitplanbasierte Skalierung

Ein häufiger Anwendungsfall für die manuelle Skalierung ist die Änderung der Anzahl der Instanzen basierend auf einem vordefinierten Zeitplan. In diesem Beispiel verwenden wir Cloud Scheduler, um zwei Jobs zu planen, die jeweils die Cloud Run Admin API aufrufen, um die Anzahl der Instanzen zu skalieren. Im ersten Job wird der Dienst so konfiguriert, dass er während der Geschäftszeiten (9:00 bis 17:00 Uhr, Mo–Fr) manuell auf 10 Instanzen skaliert wird. Im zweiten Job wird der Dienst so konfiguriert, dass er außerhalb der Geschäftszeiten auf null Instanzen herunterskaliert wird.

Wenn Sie die Instanzen wie im Beispiel auf null setzen, wird der Dienst deaktiviert, nicht aber die Cloud Scheduler-Jobs. Diese Jobs werden weiterhin ausgeführt und setzen den Dienst wie geplant auf 10 Instanzen zurück (und aktivieren ihn wieder).

In diesem Beispiel verwenden wir zur Vereinfachung die Cloud Run-Kurzanleitung. Sie können aber auch einen Dienst Ihrer Wahl verwenden.

So richten Sie die zeitplanbasierte manuelle Skalierung ein:

1. Stellen Sie Ihren Dienst mit dem folgenden Befehl bereit:

   gcloud beta run deploy SERVICE \
      --image=us-docker.pkg.dev/cloudrun/container/hello \
      --region=REGION \
      --project PROJECT_ID

   Ersetzen Sie die folgenden Variablen:

   • REGION durch die Region, in der der Cloud Run-Dienst bereitgestellt wird.
   • SERVICE durch den Namen des Cloud Run-Dienstes.

2. Konfigurieren Sie Ihren Dienst mit dem folgenden Befehl für die manuelle Skalierung auf 10 Instanzen:

   gcloud beta run services update SERVICE \
      --region=REGION \
      --scaling=10

3. Einen Cloud Scheduler-Job erstellen, der die Dienstinstanzen während der Geschäftszeiten manuell auf 10 Instanzen skaliert:

   gcloud scheduler jobs create http hello-start-instances \
     --location=REGION \
     --schedule="0 9 * * MON-FRI" \
     --time-zone=America/Los_Angeles \
     --uri=https://run.googleapis.com/v2/projects/PROJECT_ID/
     locations/REGION/services/hello?update_mask=launchStage,scaling.manualInstanceCount \
     --headers=Content-Type=application/json,X-HTTP-Method-Override=PATCH \
     --http-method=PUT \
     --message-body='{"launchStage":"BETA","scaling":{"manualInstanceCount":10}}' \
     --oauth-service-account-email=PROJECT_NUMBER-compute@developer.gserviceaccount.com

   Mit diesem Befehl wird ein Cloud Scheduler-Job erstellt, der einen HTTP-Aufruf an die Cloud Run Admin API ausführt und die Anzahl der Instanzen auf 10 festlegt. Im Beispiel wird das Compute Engine-StandarddienstkontoPROJECT_NUMBER-compute@developer.gserviceaccount.com für die Cloud Scheduler-Jobs verwendet. Sie können ein beliebiges Dienstkonto verwenden, das die Berechtigungen zum Aktualisieren von Cloud Run-Diensten hat.

4. Einen Cloud Scheduler-Job erstellen, der die Dienstinstanzen außerhalb der Geschäftszeiten manuell auf null skaliert und den Dienst deaktiviert:

   gcloud scheduler jobs create http hello-stop-instances \
     --location=REGION \
     --schedule="0 17 * * MON-FRI" \
     --time-zone=America/Los_Angeles \
     --uri=https://run.googleapis.com/v2/projects/PROJECT_ID/
     locations/REGION/services/hello?update_mask=launchStage,scaling.manualInstanceCount \
     --headers=Content-Type=application/json,X-HTTP-Method-Override=PATCH \
     --http-method=PUT \
     --message-body='{"launchStage":"BETA","scaling":{"manualInstanceCount":0}}' \
     --oauth-service-account-email=PROJECT_NUMBER-compute@developer.gserviceaccount.com

   Mit diesem Befehl wird ein Cloud Scheduler-Job erstellt, der einen HTTP-Aufruf an die Cloud Run Admin API ausführt und die manuellen Skalierungsinstanzen auf null setzt. Dadurch wird der Dienst deaktiviert, aber nicht die Cloud Scheduler-Jobs. Diese werden weiterhin ausgeführt und setzen den Dienst wie geplant auf 10 Instanzen zurück (und aktivieren ihn wieder).