Scaling manuel

Cette page explique comment mettre à l'échelle manuellement votre service. Il fournit également des instructions pour un cas d'utilisation courant : modifier le nombre d'instances en fonction d'un calendrier à l'aide de jobs Cloud Scheduler et de l'API Cloud Run Admin.

Présentation

Par défaut, Cloud Run effectue un scaling horizontal automatique jusqu'à un nombre maximal d'instances spécifié ou par défaut, en fonction du trafic et de l'utilisation du processeur. Toutefois, dans certains cas d'utilisation, vous pouvez souhaiter définir un nombre spécifique d'instances à l'aide du scaling manuel.

Le scaling manuel vous permet de définir un nombre spécifique d'instances, indépendamment du trafic ou de l'utilisation, et sans avoir à redéployer. Tout cela vous permet d'écrire votre propre logique de scaling à l'aide d'un système externe. Pour obtenir un exemple, consultez Scaling basé sur les planifications.

Paramètres de nombre minimal et maximal d'instances au niveau de la révision et scaling manuel

Si vous définissez le scaling manuel pour votre service, tous les paramètres d'instances minimales et maximales au niveau de la révision sont ignorés.

Répartition du trafic pour le scaling manuel

La liste suivante décrit comment les instances sont allouées lors de la répartition du trafic sous scaling manuel. Cela inclut le comportement des révisions avec balise de trafic uniquement.

  • Lors d'une répartition du trafic, des instances sont allouées à chaque révision de manière proportionnelle, en fonction de la répartition du trafic, comme pour la répartition du trafic avec un nombre minimal d'instances au niveau du service.

  • Si le nombre de révisions recevant du trafic dépasse le nombre d'instances manuelles, certaines révisions n'auront aucune instance. Le trafic envoyé à ces révisions recevra la même erreur que si les révisions étaient désactivées.

  • Pour toutes les révisions recevant du trafic dans une répartition du trafic, les instances minimales et maximales au niveau de la révision sont désactivées.

  • Si une révision est active uniquement en raison de tags de trafic :

    • Si le nombre minimal d'instances au niveau de la révision est défini, le nombre d'instances spécifié démarre, mais n'est pas comptabilisé dans le nombre total d'instances manuelles du service. La révision ne sera pas mise à l'échelle automatiquement.
    • Si le nombre minimal d'instances au niveau de la révision n'est pas défini, la révision est mise à l'échelle sur une instance au maximum, en réponse au trafic envoyé à l'URL du tag.

Comportement de la facturation avec le scaling manuel

Lorsque vous utilisez le scaling manuel, le comportement de facturation est semblable à celui de la fonctionnalité Nombre minimal d'instances.

En d'autres termes, avec le scaling manuel et la facturation basée sur les instances, les instances inactives mises à l'échelle manuellement sont facturées comme des instances actives.

Si vous utilisez le scaling manuel avec la facturation basée sur les requêtes, les instances inactives avec scaling manuel sont facturées en tant qu'instances minimales inactives. Pour en savoir plus sur la facturation, consultez la page des tarifs.

Rôles requis

Pour obtenir les autorisations nécessaires pour déployer des services Cloud Run, demandez à votre administrateur de vous accorder les rôles IAM suivants :

Pour obtenir la liste des rôles et des autorisations IAM associés à Cloud Run, consultez les sections Rôles IAM Cloud Run et Autorisations IAM Cloud Run. Si votre service Cloud Run communique avec les APIGoogle Cloud , telles que les bibliothèques clientes Cloud, consultez le guide de configuration de l'identité du service. Pour en savoir plus sur l'attribution de rôles, consultez les pages Autorisations de déploiement et Gérer les accès.

Configurer le scaling

Vous pouvez configurer le mode de scaling à l'aide de la console Google Cloud , de Google Cloud CLI, d'un fichier YAML ou de l'API lorsque vous créez ou mettez à jour un service :

Console

  1. Dans la console Google Cloud , accédez à Cloud Run :

    Accédez à Cloud Run

  2. Si vous configurez un nouveau service, sélectionnez Services dans le menu, puis cliquez sur Déployer un conteneur pour afficher le formulaire Créer un service. Si vous configurez un service existant, cliquez sur celui-ci pour afficher son panneau de détails, puis sur l'icône Stylo à côté de Scaling (Mise à l'échelle) en haut à droite.

  3. Recherchez le formulaire Scaling du service (pour un nouveau service) ou le formulaire Modifier le scaling pour un service existant.

    image

    Dans le champ Nombre d'instances, spécifiez le nombre d'instances de conteneur pour le service.

  4. Cliquez sur Créer pour un nouveau service ou sur Enregistrer pour un service existant.

gcloud

Pour spécifier le scaling d'un nouveau service, utilisez la commande deploy :

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

Remplacez les éléments suivants :

  • SERVICE par le nom de votre service
  • INSTANCE_COUNT avec le nombre d'instances pour le service. Cela définit le service sur le scaling manuel. Spécifiez la valeur 0 pour désactiver le service. Spécifiez la valeur auto pour utiliser le comportement d'autoscaling par défaut de Cloud Run.
  • IMAGE_URL par une référence à l'image de conteneur, par exemple us-docker.pkg.dev/cloudrun/container/hello:latest. Si vous utilisez Artifact Registry, le dépôt REPO_NAME doit déjà être créé. L'URL se présente sous la forme suivante : LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.

Spécifiez le scaling pour un service existant à l'aide de la commande update suivante :

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

YAML

  1. Si vous créez un service, ignorez cette étape. Si vous mettez à jour un service existant, téléchargez sa configuration YAML :

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

  2. Modifiez les attributs scalingMode et manualInstanceCount :

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
  annotations:
  run.googleapis.com/launch-stage: BETA
  run.googleapis.com/scalingMode: MODE
  run.googleapis.com/manualInstanceCount: INSTANCE_COUNT

    Remplacez les éléments suivants :

    • SERVICE par le nom de votre service Cloud Run
    • MODE avec manual pour le scaling manuel ou automatic pour le comportement d'autoscaling Cloud Run par défaut.
    • INSTANCE_COUNT avec le nombre d'instances que vous mettez à l'échelle manuellement pour le service. Spécifiez une valeur de 0 pour désactiver le service.

  3. Créez ou mettez à jour le service à l'aide de la commande suivante :

    gcloud run services replace service.yaml

API REST

Pour mettre à jour le nombre minimal d'instances au niveau du service pour un service donné, envoyez une requête HTTP PATCH au point de terminaison service de l'API Cloud Run Admin.

Exemple, à l'aide de curl :

    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

Remplacez :

  • ACCESS_TOKEN par un jeton d'accès valide pour un compte disposant des autorisations IAM pour mettre à jour un service. Par exemple, si vous êtes connecté à gcloud, vous pouvez récupérer un jeton d'accès à l'aide de gcloud auth print-access-token. À partir d'une instance de conteneur Cloud Run, vous pouvez récupérer un jeton d'accès via le serveur de métadonnées d'instance de conteneur.
  • MANUAL_INSTANCE_COUNT avec le nombre d'instances pour le service. Cela définit le service sur le scaling manuel. Spécifiez la valeur 0 pour désactiver le service.
  • SERVICE par le nom du service ;
  • REGION par la région dans laquelle le service est déployé. Google Cloud
  • PROJECT_ID par l'ID du projet Google Cloud .

Terraform

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez la page Commandes Terraform de base.

Ajoutez les éléments suivants à une ressource google_cloud_run_v2_service dans votre configuration Terraform :
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"
  }
}

Remplacez :

  • SERVICE_NAME par le nom de votre service Cloud Run ;
  • REGION par la région Google Cloud . Exemple : europe-west1.
  • IMAGE_URL par une référence à l'image de conteneur, par exemple us-docker.pkg.dev/cloudrun/container/hello:latest. Si vous utilisez Artifact Registry, le dépôt REPO_NAME doit déjà être créé. L'URL se présente sous la forme suivante : LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
  • INSTANCE_COUNT avec le nombre d'instances que vous mettez à l'échelle manuellement pour le service. Ce nombre d'instances est réparti entre toutes les révisions avec un trafic spécifié en fonction du pourcentage de trafic qu'elles reçoivent.

Afficher la configuration du scaling pour votre service

Pour afficher les instances de configuration du scaling de votre service Cloud Run :

Console

  1. Dans la console Google Cloud , accédez à Cloud Run :

    Accédez à Cloud Run

  2. Cliquez sur le service qui vous intéresse pour ouvrir le panneau Informations sur le service.

  3. Le paramètre de scaling actuel est affiché en haut à droite du panneau d'informations sur le service, après le libellé Scaling, à côté de l'icône en forme de stylo.

gcloud

Utilisez la commande suivante pour afficher la configuration de scaling actuelle du service :

gcloud beta run services describe SERVICE

Remplacez SERVICE par le nom du service.

Recherchez le champ Scaling: Manual (Instances: ) en haut du texte renvoyé par describe.

YAML

Utilisez la commande suivante pour télécharger la configuration YAML du service :

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

La configuration de scaling est contenue dans les attributs scalingMode et manualInstanceCount.

Désactiver un service

Lorsque vous désactivez un service, toutes les requêtes en cours de traitement peuvent se terminer. Toutefois, les requêtes ultérieures envoyées à l'URL du service échoueront avec une erreur Service unavailable ou Service disabled.

Les requêtes adressées aux révisions de service qui ne sont actives qu'en raison de tags de trafic ne sont pas concernées, car ces révisions ne sont pas désactivées.

Pour désactiver un service, définissez le scaling sur zéro. Vous pouvez désactiver un service à l'aide de la console Google Cloud , de Google Cloud CLI, d'un fichier YAML ou de l'API :

Console

  1. Dans la console Google Cloud , accédez à Cloud Run :

    Accédez à Cloud Run

  2. Cliquez sur le service que vous souhaitez désactiver pour afficher son panneau de détails, puis sur l'icône Stylo à côté de Scaling (Mise à l'échelle) en haut à droite.

  3. Recherchez le formulaire Modifier le scaling et sélectionnez Scaling manuel.

    image

    Dans le champ Nombre d'instances, saisissez la valeur 0 (zéro).

  4. Cliquez sur Enregistrer.

gcloud

Pour désactiver un service, utilisez la commande suivante pour définir la mise à l'échelle sur zéro :

gcloud beta run services update SERVICE --scaling=0

Remplacez SERVICE par le nom du service.

YAML

  1. Téléchargez la configuration YAML de votre service :

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

  2. Définissez l'attribut manualInstanceCount sur zéro (0) :

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
  annotations:
  run.googleapis.com/launch-stage: BETA
  run.googleapis.com/scalingMode: manual
  run.googleapis.com/manualInstanceCount: `0`

    Remplacez SERVICE par le nom de votre service Cloud Run.

  3. Créez ou mettez à jour le service à l'aide de la commande suivante :

    gcloud run services replace service.yaml

API REST

Pour désactiver un service, envoyez une requête HTTP PATCH au point de terminaison service de l'API Cloud Run Admin.

Exemple, à l'aide de curl :

    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

Remplacez :

  • ACCESS_TOKEN par un jeton d'accès valide pour un compte disposant des autorisations IAM pour mettre à jour un service. Par exemple, si vous êtes connecté à gcloud, vous pouvez récupérer un jeton d'accès à l'aide de gcloud auth print-access-token. À partir d'une instance de conteneur Cloud Run, vous pouvez récupérer un jeton d'accès via le serveur de métadonnées d'instance de conteneur.
  • SERVICE par le nom du service ;
  • REGION par la région dans laquelle le service est déployé. Google Cloud
  • PROJECT_ID par l'ID du projet Google Cloud .

Terraform

Pour désactiver un service, définissez l'attribut manual_instance_count sur zéro (0) :

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"
  }
}

Remplacez :

  • SERVICE_NAME par le nom de votre service Cloud Run ;
  • REGION par la région Google Cloud . Exemple : europe-west1.
  • IMAGE_URL par une référence à l'image de conteneur, par exemple us-docker.pkg.dev/cloudrun/container/hello:latest. Si vous utilisez Artifact Registry, le dépôt REPO_NAME doit déjà être créé. L'URL se présente sous la forme suivante : LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG

Exemple de scaling basé sur les planifications

Un cas d'utilisation courant du scaling manuel consiste à modifier le nombre d'instances en fonction d'un calendrier prédéfini. Dans cet exemple, nous utilisons Cloud Scheduler pour planifier deux jobs, chacun d'eux appelant l'API Cloud Run Admin pour mettre à l'échelle le nombre d'instances. La première tâche définit le service pour qu'il soit mis à l'effectuer un scaling horizontal manuellement à 10 instances pendant les heures ouvrées (de 9h à 17h, du lundi au vendredi). Le deuxième job définit le service pour qu'il soit mis à l'échelle sur zéro instance pendant les heures creuses.

Notez que définir le nombre d'instances sur zéro, comme indiqué dans l'exemple, désactive le service, mais pas les tâches Cloud Scheduler. Ces tâches continuent de s'exécuter et réinitialiseront (et réactiveront) le service à 10 instances comme prévu.

Dans cet exemple, nous utilisons le guide de démarrage rapide de Cloud Run pour plus de simplicité, mais vous pouvez utiliser le service de votre choix.

Pour configurer le scaling manuel basé sur la programmation :

  1. Déployez votre service à l'aide de la commande suivante :

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

    Remplacez les variables suivantes :

    • REGION par la région dans laquelle le service Cloud Run est déployé.
    • SERVICE par le nom du service Cloud Run.

  2. Configurez votre service pour le scaling manuel à 10 instances à l'aide de la commande suivante :

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

  3. Créez un job Cloud Scheduler qui met manuellement à l'échelle les instances de service jusqu'à 10 instances pendant les heures de bureau :

    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

    Cette commande crée un job Cloud Scheduler qui effectue un appel HTTP à l'API Cloud Run Admin, en définissant le nombre d'instances sur 10. L'exemple utilise le compte de service Compute Engine par défaut PROJECT_NUMBER-compute@developer.gserviceaccount.com pour les jobs Cloud Scheduler. Vous pouvez utiliser n'importe quel compte de service autorisé à mettre à jour les services Cloud Run.

  4. Créez un job Cloud Scheduler qui met manuellement à l'échelle les instances de service sur zéro instance pendant les heures creuses, ce qui désactive le service :

    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

    Cette commande crée un job Cloud Scheduler qui effectue un appel HTTP à l'API Cloud Run Admin, en définissant le nombre d'instances de scaling manuel sur zéro. Cela désactive effectivement le service, mais pas les jobs Cloud Scheduler, qui continueront de s'exécuter et de réinitialiser (et de réactiver) le service à 10 instances comme prévu.