Vous pouvez configurer des vérifications de démarrage HTTP, TCP et gRPC, ainsi que des vérifications d'activité HTTP et gRPC pour les services Cloud Run nouveaux et existants. La configuration varie en fonction du type de vérification.
Notez qu'une vérification de démarrage TCP est automatiquement configurée pour un nouveau service Cloud Run. Pour en savoir plus, consultez la section Vérification de démarrage TCP par défaut.
Cas d'utilisation
Vous pouvez configurer deux types de tests de vérification d'état :
Les vérifications d'activité déterminent s'il faut redémarrer un conteneur.
- Dans ce cas, le redémarrage d'un conteneur peut augmenter la disponibilité du service en cas de bugs.
- Les vérifications d'activité sont destinées à redémarrer des instances individuelles qui ne peuvent pas être récupérées d'une autre manière. Elles doivent principalement être utilisées en cas de défaillance d'instance irrécupérable, par exemple pour détecter un interblocage où un service est en cours d'exécution, mais ne peut pas progresser. Vous pouvez exiger une vérification de l'activité pour chaque conteneur à l'aide de règles d'administration personnalisées.
Les vérifications de démarrage déterminent si le conteneur a démarré et est prêt à accepter le trafic.
- Lorsque vous configurez une vérification de démarrage, les vérifications d'activité sont désactivées jusqu'à ce que la vérification de démarrage détermine que le conteneur est démarré, afin d'éviter toute interférence avec le démarrage du service.
- Les vérifications de démarrage sont particulièrement utiles si vous utilisez des contrôles d'activité sur des conteneurs à démarrage lent, car elles les empêchent de s'arrêter prématurément avant que les conteneurs ne soient opérationnels.
Sachez que lorsqu'un service rencontre des échecs répétés de démarrage ou de vérification d'activité, Cloud Run limite les redémarrages d'instances pour éviter les boucles de plantage non contrôlées.
Vérification de démarrage TCP par défaut
Une vérification de démarrage TCP est automatiquement configurée pour un nouveau service Cloud Run avec des valeurs par défaut. La vérification par défaut est équivalente à la suivante :
startupProbe: tcpSocket: port: CONTAINER_PORT timeoutSeconds: 240 periodSeconds: 240 failureThreshold: 1
Remplacez CONTAINER_PORT par le port de conteneur défini pour votre service.
Vous pouvez modifier ces valeurs par défaut en suivant les instructions de la section Configuration de la vérification sur la présente page.
Facturation et allocation de processeurs
- Les processeurs sont alloués à chaque vérification.
- Toutes les vérifications sont facturées pour l'utilisation de la mémoire et des processeurs, mais il n'y a pas de frais basés sur les requêtes.
Exigences et comportement de vérification
Type de vérification | Conditions requises | Comportement |
---|---|---|
Démarrage TCP | Aucune | Par défaut, Cloud Run établit une connexion TCP pour ouvrir le socket TCP sur le port spécifié. Si Cloud Run ne parvient pas à établir une connexion, cela indique un échec. Si une vérification de démarrage n'aboutit pas dans le délai spécifié ( failureThreshold * periodSeconds ), qui ne peut pas dépasser 240 secondes, le conteneur est arrêté. Consultez également la section Valeurs TCP par défaut. |
Démarrage HTTP | Créez un point de terminaison de vérification d'état HTTP Utilisez HTTP/1 |
Après la configuration de la vérification, Cloud Run envoie une requête HTTP GET au point de terminaison de la vérification d'état du service (par exemple, /ready ). Toute réponse comprise entre 200 et 400 indique un succès, toute autre réponse indique un échec.Si une vérification de démarrage n'aboutit pas dans le délai spécifié ( failureThreshold * periodSeconds ), qui ne peut pas dépasser 240 secondes, le conteneur est arrêté.Si la vérification de démarrage HTTP réussit dans le délai spécifié et que vous avez configuré une vérification d'activité HTTP, celle-ci est démarrée. |
Activité HTTP | Créez un point de terminaison de vérification d'état HTTP Utilisez HTTP/1 |
La vérification d'activité ne démarre qu'une fois la vérification de démarrage réussie. Une fois que la vérification est configurée et qu'une vérification de démarrage réussit, Cloud Run envoie une requête HTTP GET au point de terminaison de vérification d'état du service (par exemple, /health ). Toute réponse comprise entre 200 et 400 indique un succès, toute autre réponse indique un échec.Si une vérification d'activité n'aboutit pas dans le délai spécifié ( failureThreshold * periodSeconds ), le conteneur est arrêté à l'aide d'un signal SIGKILL . Toute requête restante encore diffusée par le conteneur est interrompue par le code d'état HTTP 503 . Une fois le conteneur arrêté, l'autoscaling Cloud Run démarre une nouvelle instance de conteneur. |
Démarrage gRPC | Mettez en œuvre le protocole de vérification d'état gRPC dans votre service Cloud Run. | Si une vérification de démarrage échoue dans le délai spécifié (failureThreshold * periodSeconds ), qui ne peut pas dépasser 240 secondes, le conteneur est arrêté. |
Activité gRPC | Mettez en œuvre le protocole de vérification d'état gRPC dans votre service Cloud Run. | Si vous configurez une vérification de démarrage gRPC, la vérification d'activité ne commence qu'une fois la vérification de démarrage réussie. Une fois la vérification d'activité configurée et une vérification de démarrage réussie, Cloud Run envoie une requête de vérification d'état au service. Si une vérification d'activité échoue dans le délai spécifié ( failureThreshold * periodSeconds ), le conteneur est arrêté à l'aide d'un signal SIGKILL . Une fois le conteneur arrêté, l'autoscaling Cloud Run démarre une nouvelle instance de conteneur. |
Configurer des vérifications
Tout changement de configuration entraîne la création d'une révision. Les révisions ultérieures obtiennent aussi automatiquement le même paramètre de configuration, à moins que vous ne le mettiez explicitement à jour.
Vous pouvez configurer des vérifications HTTP, TCP et gRPC à l'aide de la console Google Cloud, de YAML ou de Terraform :
Console
Important : si vous configurez votre service Cloud Run pour les vérifications HTTP, vous devez également ajouter un point de terminaison de vérification d'état HTTP dans votre code de service pour répondre à la vérification. Si vous configurez une vérification gRPC, vous devez également mettre en œuvre le protocole de vérification d'état gRPC dans votre service Cloud Run.
Dans Google Cloud Console, accédez à la page Cloud Run.
Pour un nouveau service, développez Conteneur(s), volumes, mise en réseau et sécurité pour afficher les options de vérification d'état. Pour un service existant, cliquez sur le service que vous souhaitez configurer, puis sur Modifier et déployer pour afficher les options de vérification d'état.
Dans la section Conteneur(s) accédez à Vérifications d'état puis cliquez sur Ajouter une vérification d'état afin d'ouvrir le panneau de configuration Ajouter une vérification d'état.
Dans le menu Sélectionner le type de vérification d'état, sélectionnez le type de vérification d'état que vous souhaitez ajouter, par exemple démarrage ou activité.
Dans le menu Sélectionner un type de vérification, sélectionnez le type de vérification que vous souhaitez utiliser, par exemple HTTP ou gRPC. Le formulaire de configuration de vérification s'affiche.
Notez que la configuration de vérification varie selon le type de vérification. Configurez les paramètres de la vérification :
- Si vous utilisez des vérifications HTTP :
- Assurez-vous que votre service utilise HTTP/1 (valeur par défaut de Cloud Run) et non HTTP/2.
- Utilisez le champ Chemin d'accès pour spécifier le chemin d'accès relatif au point de terminaison (par exemple,
/
). - Cochez la case En-têtes HTTP pour spécifier des en-têtes personnalisés facultatifs. Spécifiez ensuite le nom de l'en-tête dans le champ Nom et la valeur de l'en-tête dans le champ Valeur. Cliquez sur Ajouter un en-tête HTTP pour spécifier d'autres en-têtes.
- Pour le champ Port, spécifiez le port de conteneur utilisé pour votre service.
- Dans le champ Délai initial, spécifiez le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 et 240 secondes. La valeur par défaut est de 0 seconde.
- Dans le champ Période, spécifiez la périodicité (en secondes) à laquelle effectuer la vérification. Par exemple,
2
pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 et 240 secondes. La valeur par défaut est de 10 secondes. - Pour Seuil d'échec, spécifiez le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
- Dans le champ Délai avant expiration, spécifiez le nombre de secondes d'attente avant expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour
periodSeconds
. Définissez une valeur comprise entre 1 et 240. La valeur par défaut est 1.
- Si vous utilisez des vérifications HTTP :
Cliquez sur Ajouter pour ajouter le nouveau seuil.
YAML
Important : si vous configurez votre service Cloud Run pour les vérifications HTTP, vous devez également ajouter un point de terminaison dans votre code de service pour répondre à la vérification. Si vous configurez une vérification gRPC, vous devez également mettre en œuvre le protocole de vérification d'état gRPC dans votre service Cloud Run.
Démarrage TCP
-
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
Configurez l'attribut
startupProbe
comme indiqué ci-dessous :apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: spec: containers: - image: IMAGE_URL startupProbe: tcpSocket: port: CONTAINER_PORT initialDelaySeconds: DELAY timeoutSeconds: TIMEOUT failureThreshold: THRESHOLD periodSeconds: PERIOD
Remplacer
- SERVICE par le nom de votre service 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
- (FACULTATIF) CONTAINER_PORT doit être défini sur le port de conteneur utilisé pour votre service.
- DELAY par le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 seconde et 240 secondes. La valeur par défaut est de 0 seconde.
- (FACULTATIF) TIMEOUT par le nombre de secondes d'attente jusqu'à l'expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour
periodSeconds
. Définissez une valeur comprise entre 1 et 240. La valeur par défaut est 1. - THRESHOLD par le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
- PERIOD par le délai (en secondes) auquel effectuer la vérification.
Par exemple,
2
pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 seconde et 240 secondes. La valeur par défaut est de 10 secondes.
-
Créez ou mettez à jour le service à l'aide de la commande suivante :
gcloud run services replace service.yaml
Démarrage HTTP
-
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
Assurez-vous que votre service utilise HTTP/1 (valeur par défaut de Cloud Run) et non HTTP/2.
Configurez l'attribut
startupProbe
comme indiqué ci-dessous :apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: spec: containers: - image: IMAGE_URL startupProbe: httpGet: path: PATH port: CONTAINER_PORT httpHeaders: - name: HEADER_NAME value: HEADER_VALUE initialDelaySeconds: DELAY timeoutSeconds: TIMEOUT failureThreshold: THRESHOLD periodSeconds: PERIOD
replace
- SERVICE par le nom de votre service 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
- PATH par le chemin relatif au point de terminaison HTTP, par exemple,
/ready
. - (FACULTATIF) CONTAINER_PORT doit être défini sur le port de conteneur utilisé pour votre service.
- (FACULTATIF)
httpHeaders
peut être utilisé pour fournir des en-têtes personnalisés multiples ou répétés à l'aide des champs HEADER_NAME et HEADER_VALUE, comme indiqué. - (FACULTATIF) DELAY par le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 seconde et 240 secondes. La valeur par défaut est de 0 seconde.
- (FACULTATIF) TIMEOUT par le nombre de secondes d'attente jusqu'à l'expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour
periodSeconds
. Définissez une valeur comprise entre 1 et 240. La valeur par défaut est 1. - (FACULTATIF) THRESHOLD par le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
- (FACULTATIF) PERIOD par le délai (en secondes) auquel effectuer la vérification.
Par exemple,
2
pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 et 240 secondes. La valeur par défaut est de 10 secondes.
-
Créez ou mettez à jour le service à l'aide de la commande suivante :
gcloud run services replace service.yaml
Activité HTTP
-
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
Assurez-vous que votre service utilise HTTP/1 (valeur par défaut de Cloud Run) et non HTTP/2.
Configurez l'attribut
livenessProbe
comme indiqué ci-dessous :apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: spec: containers: - image: IMAGE_URL livenessProbe: httpGet: path: PATH port: CONTAINER_PORT httpHeaders: - name: HEADER_NAME value: HEADER_VALUE initialDelaySeconds: DELAY timeoutSeconds: TIMEOUT failureThreshold: THRESHOLD periodSeconds: PERIOD
Remplacer
- SERVICE par le nom de votre service 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
- PATH par le chemin relatif au point de terminaison HTTP, par exemple,
/ready
. - (FACULTATIF) CONTAINER_PORT doit être défini sur le port de conteneur utilisé pour votre service.
- (FACULTATIF)
httpHeaders
peut être utilisé pour fournir des en-têtes personnalisés multiples ou répétés à l'aide des champs HEADER_NAME et HEADER_VALUE, comme indiqué. - (FACULTATIF) DELAY par le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 seconde et 240 secondes. La valeur par défaut est de 0 seconde.
- (FACULTATIF) TIMEOUT par le nombre de secondes d'attente jusqu'à l'expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour
periodSeconds
. Définissez une valeur comprise entre 1 et 3 600. La valeur par défaut est 1. - (FACULTATIF) THRESHOLD par le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
- (FACULTATIF) PERIOD par le délai (en secondes) auquel effectuer la vérification.
Par exemple,
2
pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 et 3 600 secondes. La valeur par défaut est de 10 secondes.
-
Créez ou mettez à jour le service à l'aide de la commande suivante :
gcloud run services replace service.yaml
Démarrage gRPC
-
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
Configurez l'attribut
startupProbe
comme indiqué ci-dessous :apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: spec: containers: - image: IMAGE_URL startupProbe: grpc: service: GRPC_SERVICE port: CONTAINER_PORT initialDelaySeconds: DELAY timeoutSeconds: TIMEOUT failureThreshold: THRESHOLD periodSeconds: PERIOD
Remplacer
- SERVICE par le nom de votre service 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
- (FACULTATIF) GRPC_SERVICE. Si défini, il est utilisé dans le champ de service de
grpc.health.v1.HealthCheckRequest
lorsque l'appel RPCgrpc.health.v1.Health.Check
est effectué. - (FACULTATIF) CONTAINER_PORT doit être défini sur le port de conteneur utilisé pour votre service.
- (FACULTATIF) DELAY par le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 et 240 secondes. La valeur par défaut est de 0 seconde.
- (Facultatif) TIMEOUT par le nombre de secondes d'attente jusqu'à l'expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour periodSeconds. Définissez une valeur comprise entre 1 et 240. La valeur par défaut est 1.
- (FACULTATIF) THRESHOLD par le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
- (FACULTATIF) PERIOD par le délai (en secondes) auquel effectuer la vérification.
Par exemple,
2
pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 et 240 secondes. La valeur par défaut est de 10 secondes.
-
Créez ou mettez à jour le service à l'aide de la commande suivante :
gcloud run services replace service.yaml
Activité gRPC
-
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
Configurez l'attribut
livenessProbe
comme indiqué ci-dessous :apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: spec: containers: - image: IMAGE_URL livenessProbe: grpc: port: CONTAINER_PORT service: GRPC_SERVICE initialDelaySeconds: DELAY timeoutSeconds: TIMEOUT failureThreshold: THRESHOLD periodSeconds: PERIOD
Remplacer
- SERVICE par le nom de votre service 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
- (FACULTATIF) CONTAINER_PORT doit être défini sur le port de conteneur utilisé pour votre service.
- (FACULTATIF) GRPC_SERVICE. Si défini, il est utilisé dans le champ de service de
grpc.health.v1.HealthCheckRequest
lorsque l'appel RPCgrpc.health.v1.Health.Check
est effectué. - (FACULTATIF) DELAY par le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 seconde et 240 secondes. La valeur par défaut est de 0 seconde.
- (FACULTATIF) TIMEOUT par le nombre de secondes d'attente jusqu'à l'expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour
periodSeconds
. Définissez une valeur comprise entre 1 et 3 600. La valeur par défaut est 1. - (FACULTATIF) THRESHOLD par le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
- (FACULTATIF) PERIOD par le délai (en secondes) auquel effectuer la vérification. Par exemple,
2
pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 et 3 600 secondes. La valeur par défaut est de 10 secondes.
-
Créez ou mettez à jour le service à l'aide de la commande suivante :
gcloud run services replace service.yaml
Terraform
Important : si vous configurez votre service Cloud Run pour les vérifications HTTP, vous devez également ajouter un point de terminaison dans votre code de service pour répondre à la vérification. Si vous configurez une vérification gRPC, vous devez également mettre en œuvre le protocole de vérification d'état gRPC dans votre service Cloud Run.
Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez la page Commandes Terraform de base.
Démarrage TCP
Configurez votre service Cloud Run avec l'attribut startup_probe
comme indiqué ci-dessous :
Démarrage HTTP
Assurez-vous que votre service utilise HTTP/1 (valeur par défaut de Cloud Run) et non HTTP/2.
Configurez votre service Cloud Run avec l'attribut startup_probe
comme indiqué ci-dessous :
Activité HTTP
Assurez-vous que votre service utilise HTTP/1 (valeur par défaut de Cloud Run) et non HTTP/2.
Configurez votre service Cloud Run avec l'attribut liveness_probe
comme indiqué ci-dessous :
Démarrage gRPC
Configurez votre service Cloud Run avec l'attribut startup_probe
comme indiqué ci-dessous :
Activité gRPC
Configurez votre service Cloud Run avec l'attribut liveness_probe
comme indiqué ci-dessous :
Créer des points de terminaison HTTP de vérification d'état
Si vous configurez votre service Cloud Run pour une vérification de démarrage HTTP ou une vérification d'activité, vous devez ajouter un point de terminaison dans votre code de service pour répondre à la vérification. Le point de terminaison peut porter n'importe quel nom, par exemple /startup
ou /ready
, mais il doit correspondre aux valeurs que vous spécifiez pour path
dans la configuration de la vérification. Par exemple, si vous spécifiez /ready
pour une vérification de démarrage HTTP, vous spécifiez path
dans votre configuration de vérification, comme indiqué ci-dessous :
startupProbe: httpGet: path: /ready
Les points de terminaison HTTP de vérification d'état sont accessibles en externe et suivent les mêmes principes que tous les autres points de terminaison de service HTTP exposés en externe.