Cette page a été traduite par l'API Cloud Translation.

Scaling manuel

Cette page explique comment faire évoluer manuellement votre service. Il fournit également des instructions pour un cas d'utilisation courant, à savoir la modification du nombre d'instances en fonction d'une planification à l'aide de jobs Cloud Scheduler et de l'API Cloud Run Admin.

Présentation

Par défaut, Cloud Run s'adapte automatiquement à 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 souhaiterez peut-être pouvoir définir un nombre spécifique d'instances à l'aide de l'ajustement manuel.

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

Basculer entre le scaling automatique et manuel

Le changement de mode de scaling a un impact sur le nombre d'instances, ainsi que sur les paramètres du nombre minimal et maximal d'instances au niveau du service, comme indiqué dans le tableau suivant :

Sens du bouton de scaling	Nombre d'instances	Nombre minimal et maximal d'instances
Passer de l'automatisation à la gestion manuelle	Si le nombre d'instances n'est pas spécifié dans la commande qui change de mode, le paramètre Nombre minimal d'instances au niveau du service est hérité.	Après le basculement, le nombre minimal et maximal d'instances au niveau du service n'est plus défini.
Passer de la gestion manuelle à la gestion automatique	Le nombre d'instances défini manuellement n'est pas défini	Vous devez spécifier les deux instances minimales et maximales au niveau du service, ou aucune d'entre elles. (Si vous n'en spécifiez qu'un seul, une erreur s'affiche.) Si vous ne spécifiez aucun de ces éléments dans la commande qui bascule les modes, les instances minimales et maximales au niveau du service héritent du nombre d'instances manuel.

Paramètres du 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'instance minimale et maximale 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 avec le scaling manuel. Cela inclut le comportement des révisions basées uniquement sur les tags de trafic.

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é vers ces révisions générera 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, toutes 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é est démarré, mais n'est pas comptabilisé dans le nombre total d'instances manuelles du service. La révision ne sera pas automatiquement mise à l'échelle.
- Si le nombre minimal d'instances au niveau de la révision n'est pas défini, la révision est adaptée à un maximum de une instance en réponse au trafic envoyé à l'URL du tag.

Comportement de facturation avec le scaling manuel

Lorsque vous utilisez le scaling manuel, le comportement de facturation est semblable à celui que vous obtenez lorsque vous utilisez la fonctionnalité Instances minimales.

Autrement dit, avec le scaling manuel et la facturation basée sur les instances, les instances inutilisées à l'échelle manuelle sont facturées comme des instances actives.

Si vous utilisez le scaling manuel avec la facturation basée sur les requêtes, les instances inutilisées à échelle manuelle sont facturées en tant que instances minimales inutilisées. 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 :

Développeur Cloud Run (roles/run.developer) sur le service Cloud Run
Utilisateur du compte de service (roles/iam.serviceAccountUser) sur l'identité du service
Lecteur Artifact Registry (roles/artifactregistry.reader) sur le dépôt Artifact Registry de l'image de conteneur déployée (le cas échéant)

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 des APIGoogle Cloud , telles que des 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 mise à l'échelle à l'aide de la console Google Cloud, de Google Cloud CLI, d'un fichier YAML ou d'une API lorsque vous créez ou modifiez un service:

Console

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

Accédez à Cloud Run
Si vous configurez un nouveau service, cliquez sur Déployer un conteneur et sélectionnez Service 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 Échelle en haut à droite.
Recherchez le formulaire Scaling des services (pour un nouveau service) ou le formulaire Modifier l'ajustement pour un service existant.

Dans le champ Nombre d'instances, spécifiez le nombre d'instances de conteneur pour le service.
Cliquez sur Créer pour un nouveau service ou sur Enregistrer pour un service existant.

gcloud

Pour spécifier la mise à l'échelle 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. Le service est alors défini 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

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
```
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 par défaut de Cloud Run.
- INSTANCE_COUNT avec le nombre d'instances que vous mettez à l'échelle manuellement pour le service. Spécifiez la valeur 0 pour désactiver le service.
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. Le service est alors défini 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' Google Cloud ID du projet.

Afficher la configuration de scaling de votre service

Pour afficher les instances de configuration de mise à l'échelle de votre service Cloud Run:

Console

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

Accédez à Cloud Run
Cliquez sur le service qui vous intéresse pour ouvrir le panneau Informations sur le service.
Le paramètre de mise à l'échelle actuel est affiché en haut à droite du panneau d'informations sur le service, après l'étiquette Scaling (Mise à l'échelle), à côté de l'icône Stylo.

gcloud

Utilisez la commande suivante pour afficher la configuration de mise à l'échelle 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 sont autorisées à être traitées. Toutefois, toutes les autres requêtes envoyées à l'URL du service échoueront avec une erreur Service unavailable ou Service disabled.

Les requêtes envoyées aux révisions de service qui ne sont actives que grâce à des tags de trafic ne sont pas affecté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 la CLI Google Cloud, d'un fichier YAML ou de l'API:

Console

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

Accédez à Cloud Run
Cliquez sur le service que vous souhaitez désactiver pour afficher son panneau d'informations, puis sur l'icône Stylo à côté de Échelle en haut à droite du panneau d'informations.
Recherchez le formulaire Modifier le scaling, puis sélectionnez Scaling manuel.

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

gcloud

Pour désactiver un service, définissez la mise à l'échelle sur zéro à l'aide de la commande suivante:

gcloud beta run services update SERVICE --scaling=0

Remplacez SERVICE par le nom du service.

YAML

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

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

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.

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' Google Cloud ID du projet.

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 tâches, chacune d'elles appelant l'API Cloud Run Admin pour faire évoluer le nombre d'instances. La première tâche définit le service pour qu'il effectue une mise à l'échelle manuelle à 10 instances pendant les heures ouvrées (9h à 17h, du lundi au vendredi). La deuxième tâche définit le service pour qu'il ne comporte aucune instance en dehors des heures de travail.

Notez que définir les 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 simplifier les choses, mais vous pouvez utiliser le service de votre choix.

Pour configurer le scaling manuel basé sur un calendrier:

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.
Configurez votre service pour le scaling manuel sur 10 instances à l'aide de la commande suivante:
```
gcloud beta run services update SERVICE \
   --region=REGION \
   --scaling=10
```
Créez une tâche Cloud Scheduler qui étale manuellement les instances de service sur 10 instances pendant les heures ouvrées:
```
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 disposant des autorisations nécessaires pour mettre à jour les services Cloud Run.

Remarque :Cet exemple utilise l'en-tête X-HTTP-Method-Override=PATCH, car la CLI Cloud Scheduler n'est pas compatible avec le paramètre http-method=PATCH. Si vous configurez le job Cloud Scheduler à l'aide de la console Google Cloud, vous pouvez définir la méthode HTTP sur PATCH et exclure l'en-tête.

Créez une tâche Cloud Scheduler qui réduit manuellement le nombre d'instances du service à zéro en dehors des heures ouvrées, 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 les instances de mise à l'échelle manuelle sur zéro. Cela désactive effectivement le service, mais pas les tâches Cloud Scheduler, qui continueront de s'exécuter et de réinitialiser (et réactiver) le service à 10 instances comme prévu.