Résoudre les problèmes liés à Cloud Run

Cette page explique comment résoudre les erreurs que vous pouvez rencontrer lors de l'utilisation de Cloud Run. Personalized Service Health publie tous les incidents Cloud Run qui proviennent de l'infrastructure Google Cloud sous-jacente pour identifier les interruptions de service Google Cloud qui affectent vos projets. Vous devez également envisager de configurer des alertes pour les événements Personalized Service Health. Pour en savoir plus sur les incidents affectant tous les services Google Cloud , consultez le tableau de bord Google Cloud Service Health.

Recherchez des problèmes existants ou signalez de nouveaux problèmes dans les outils publics de suivi des problèmes.

Pour les autres messages d'erreur non listés sur cette page, consultez Problèmes connus dans Cloud Run. Si vous continuez à rencontrer des erreurs même après avoir suivi les étapes de ce guide, contactez l'assistance.

Consultez les sections suivantes pour savoir comment résoudre les problèmes dans Cloud Run :

Erreurs de déploiement

Cette section décrit les erreurs de déploiement courantes dans Cloud Run et les méthodes permettant de les résoudre.

Échec du démarrage du conteneur

L'erreur suivante se produit lors de votre tentative de déploiement :

Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.

Pour résoudre ce problème, procédez comme suit :

  1. Vérifiez que vous pouvez exécuter votre image de conteneur localement. Si votre image de conteneur ne peut pas s'exécuter localement, vous devez d'abord diagnostiquer et résoudre le problème localement.

  2. Vérifiez si votre conteneur écoute les requêtes sur le bon port. Votre conteneur doit écouter les requêtes entrantes sur le port défini par Cloud Run et indiqué dans la variable d'environnement PORT. Pour savoir comment spécifier le port,consultez Configurer des conteneurs pour les services.

  3. Vérifiez si votre conteneur écoute sur toutes les interfaces réseau, généralement référencées sous l'adresse 0.0.0.0. En particulier, votre conteneur ne doit pas écouter sur le port 127.0.0.1.

  4. Vérifiez que votre image de conteneur est compilée pour Linux 64 bits, comme requis par le contrat d'exécution du conteneur.

  5. Utilisez Cloud Logging pour rechercher les erreurs d'application dans les journaux stdout ou stderr. Vous pouvez également rechercher les plantages capturés dans Error Reporting.

    Vous devrez peut-être mettre à jour votre code ou vos paramètres de révision pour corriger les erreurs ou les plantages. Vous pouvez également résoudre les problèmes liés à votre service en local.

Erreur d'importation de conteneur

L'erreur suivante se produit lors de votre tentative de déploiement :

The service has encountered an error during container import. Please try again later. Resource readiness deadline exceeded.

Pour résoudre ce problème, procédez comme suit :

  1. Vérifiez que le système de fichiers du conteneur ne contient pas de caractères non-utf8.

  2. Certaines images Docker basées sur Windows utilisent des couches étrangères. Le plan de contrôle de Cloud Run n'est pas compatible avec les couches étrangères. Pour résoudre ce problème, essayez de définir l'option --allow-nondistributable-artifacts dans le daemon Docker :

La fonctionnalité n'est pas disponible

L'erreur suivante se produit lorsque vous appelez l'API Cloud Run Admin :

The feature is not supported in the declared launch stage

Cette erreur se produit lorsque vous appelez directement l'API Cloud Run Admin et utilisez une fonctionnalité bêta sans spécifier d'annotation ou de champ de l'étape de lancement.

Pour résoudre ce problème, ajoutez le champ de l'étape de lancement aux requêtes.

Consultez les exemples suivants pour ajouter des références à l'étape de lancement lorsque vous utilisez l'API REST v1 ou v2 :

  • Annotation de l'étape de lancement à une requête client avec JSON et l'API REST v1 :

      "annotations": {
    "run.googleapis.com/launch-stage": "BETA"
  }

  • Référence LaunchStage à une requête client avec JSON et l'API REST v2 :

    "launchStage": "BETA"

  • Annotation de l'étape de lancement à une requête de service avec YAML et l'API REST v1 :

    kind: Service
metadata:
annotations:
  run.googleapis.com/launch-stage: BETA

L'utilisateur root est introuvable

L'erreur suivante se produit lorsque les clés de chiffrement gérées par le client sont spécifiées à l'aide d'un paramètre --key :

ERROR: "User \"root\""not found in /etc/passwd

Pour résoudre ce problème, spécifiez USER 0 au lieu de USER root dans le Dockerfile.

Le compte de service Compute Engine par défaut est supprimé.

L'erreur suivante se produit lors du déploiement :

ERROR: (gcloud.run.deploy) User EMAIL_ADDRESS does not have permission to access namespace NAMESPACE_NAME (or it may not exist): Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-compute@developer.gserviceaccount.com (or it may not exist).

Ce problème se produit dans l'un des scénarios suivants :

  • Le compte de service Compute Engine par défaut n'existe pas dans le projet, et aucun compte de service n'est spécifié avec l'option --service-account au moment du déploiement.

  • Le développeur ou le compte principal déployant le service ne dispose pas des autorisations requises pour le compte de service Compute Engine par défaut à déployer.

Pour remédier à ce problème :

  1. Spécifiez un compte de service à l'aide de l'option --service-account :

    gcloud run services update SERVICE_NAME --service-account SERVICE_ACCOUNT

  2. Vérifiez que le compte de service que vous spécifiez dispose des autorisations requises pour le déploiement.

Pour vérifier si l'agent de service Compute Engine par défaut existe dans votre projet Google Cloud , procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Autorisations d'Identity and Access Management :

    Accéder aux autorisations

  2. Cochez la case Inclure les attributions de rôles fournies par Google.

  3. Dans la liste Comptes principaux, localisez l'ID de l'agent de service Compute Engine, qui suit le format PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Problèmes liés au compte de service Cloud Build

L'erreur suivante se produit lors des déploiements de sources lorsque le compte de service Cloud Build ne dispose pas des autorisations requises ou est désactivé :

ERROR: (gcloud.run.deploy) NOT_FOUND: Build failed. The service has encountered an internal error. Please try again later. This command is authenticated as EMAIL_ADDRESS which is the active account specified by the [core/account] property.

Cloud Build a modifié le comportement par défaut concernant la façon dont Cloud Build utilise les comptes de service dans les nouveaux projets. Pour en savoir plus, consultez Modification du compte de service Cloud Build par défaut. En raison de cette modification, les nouveaux projets qui déploient du code source vers Cloud Run pour la première fois peuvent utiliser un compte de service Cloud Build par défaut disposant d'autorisations insuffisantes pour le déploiement à partir du code source.

Pour résoudre ce problème, procédez comme suit :

L'agent de service Cloud Run ne dispose pas de l'autorisation de lire l'image

L'erreur suivante se produit lorsque vous essayez d'effectuer un déploiement depuis un projet à l'aide d'une image stockée dans Artifact Registry, en utilisant le domaine gcr.io dans un autre projet :

Google Cloud Run Service Agent must have permission to read the image, gcr.io/PROJECT-ID/IMAGE-NAME. Ensure that the provided container image URL is correct and that above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that PROJECT-ID/IMAGE-NAME is not in project PROJECT-ID-2. Permission must be granted to the Google Cloud Run Service Agent from this project.

L'erreur suivante peut également s'afficher lorsque vous essayez d'effectuer un déploiement depuis un projet à l'aide d'une image stockée dans Artifact Registry dans un autre projet :

ERROR: (gcloud.run.deploy) PERMISSION_DENIED: User must have permission to read
the image, REGION.pkg.dev/PROJECT_ID/ARTIFACT_REGISTRY_REPO/IMAGE:latest. Ensure that the provided container image URL is correct
and that the above account has permission to access the image. If you just enabled
the Cloud Run API, the permissions might take a few minutes to propagate. Note
that the image is from project PROJECT_ID, which is not the same as
this project PROJECT_ID.

Pour résoudre ce problème, suivez les recommandations de dépannage ci-dessous :

  • Suivez les instructions pour déployer des images de conteneurs à partir d'autres projets Google Cloud afin de vous assurer que vos comptes principaux disposent des autorisations nécessaires.

  • Ce problème peut également se produire si le projet se trouve dans un périmètre VPC Service Controls avec une restriction sur l'API Cloud Storage qui interdit les requêtes de l'agent de service Cloud Run. Pour résoudre ce problème :

    1. Ouvrez l'explorateur de journaux dans la console Google Cloud . (N'utilisez pas la page Journaux de la page Cloud Run) :

      Accéder à l'explorateur de journaux

    2. Saisissez le texte suivant dans le champ "Requête" :

      protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
severity=ERROR
protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
protoPayload.authenticationInfo.principalEmail="service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com"

    3. Si vous voyez des entrées de journal après avoir utilisé cette requête, examinez-les pour déterminer si vous devez mettre à jour vos règles VPC Service Controls. Elles peuvent indiquer que vous devez ajouter service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com à une règle d'accès préexistante.

Autorisations manquantes pour les déploiements de sources

Les erreurs suivantes peuvent se produire lors du déploiement à partir de la source :

ERROR: (gcloud.run.deploy) EMAIL_ADDRESS does not have permission
to access namespaces instance PROJECT_ID (or it may not exist): Google
Cloud Run Service Agent does not have permission to get access tokens for
the service account SERVICE_ACCOUNT. Please give SERVICE_ACCOUNT
permission iam.serviceAccounts.getAccessToken on the service account.

Alternatively, if the service account is unspecified or in the same project you
are deploying in, ensure that the Service Agent is assigned the Google
Cloud Run Service Agent role roles/run.serviceAgent. This
command is authenticated as EMAIL_ADDRESS, which is the active account
specified by the [core/account] property.

Chaque service Cloud Run est associé à un compte de service qui lui sert d'identité lorsqu'il accède à d'autres ressources. Ce compte de service peut être le compte de service par défaut (PROJECT_NUMBER-compute@developer.gserviceaccount.com) ou un compte de service géré par l'utilisateur.

Dans les environnements où plusieurs services accèdent à des ressources différentes, vous pouvez utiliser des identités par service avec différents comptes de service gérés par l'utilisateur au lieu du compte de service par défaut.

Pour résoudre ce problème, accordez au compte déployeur le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) sur le compte de service utilisé comme identité de service. Ce rôle prédéfini contient l'autorisation iam.serviceAccounts.actAs, qui est requise pour associer un compte de service au service ou à la révision. L'autorisation iam.serviceAccounts.actAs est automatiquement accordée à un utilisateur qui crée un compte de service géré par l'utilisateur. Toutefois, pour que d'autres déployeurs puissent en disposer, elle doit leur être accordée par l'utilisateur qui crée le compte de service géré par l'utilisateur.

Pour en savoir plus sur les exigences d'accès pour les nouveaux comptes de service que vous créez, consultez Obtenir des recommandations pour créer des comptes de service dédiés.

L'utilisateur ne dispose pas des autorisations suffisantes pour déployer des sources

L'erreur suivante se produit lorsque le compte du déployeur ne dispose pas des autorisations requises sur votre projet :

ERROR: (gcloud.run.deploy) 403 Could not upload file EMAIL_ADDRESS does
not have storage.objects.create access to the Google Cloud Storage object. Permission storage.objects.create denied on resource (or it may not exist). This
command is authenticated as EMAIL_ADDRESS which is the active account.

Pour résoudre cette erreur, demandez à votre administrateur de vous accorder les rôles Identity and Access Management suivants :

Erreur lors du déploiement d'un service Cloud Run à partir d'autres projets Google Cloud

L'erreur suivante se produit lorsque vous déployez un service Cloud Run à partir d'un projet source vers un projet cible :

Failed to create service.
Operation failed due to missing permissions.

Google Cloud Run Service Agent does not have permission to get access
tokens for the service account SERVICE_ACCOUNT. Please give
SERVICE_ACCOUNT permission iam.serviceAccounts.getAccessToken
on the service account. Alternatively, if the service account is unspecified or
in the same project you are deploying in, ensure that the Service Agent is
assigned the Google Cloud Run Service Agent role roles/run.serviceAgent.

Pour résoudre ce problème, procédez comme suit :

  1. Attribuez le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) au compte de service que vous utilisez comme identité de service dans votre projet cible.

  2. Attribuez le rôle Créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator) au compte de service Cloud Run dans le projet cible. Ajoutez l'adresse e-mail de l'agent de service Cloud Run (service-PROJECT_NUMBER@SERVICE_DOMAIN.iam.gserviceaccount.com) en tant que compte principal du projet source.

  3. Désactivez la règle d'administration iam.disableCrossProjectServiceAccountUsage.

Pour obtenir des instructions détaillées, consultez Configurer l'identité du service pour les services.

Erreurs lors du déploiement de votre code source Python sur Cloud Run

Lorsque vous déployez un service Cloud Run à partir du code source avec le runtime Python, l'une des erreurs suivantes se produit :

  • Revision REVISION_NAME is not ready and cannot serve traffic.
The user provided container failed to start and listen on port defined by PORT=8080
environment variable within the allocated timeout. This can happen if the port is
misconfigured or if the timeout is too short. The healthcheck timeout can be extended.
  • Le déploiement réussit, mais des codes d'erreur HTTP 500 figurent dans les journaux.

Le buildpack Python définit le point d'entrée par défaut pour les déploiements de sources Cloud Run. Pour Python version 3.13 et ultérieures, le buildpack Python définit le point d'entrée en fonction de la configuration du service Web dans votre fichier requirements.txt. Si vous ne spécifiez pas de serveur Web ni de framework dans le fichier requirements.txt, ou si vous utilisez Python 3.12 ou une version antérieure, le buildpack Python définit le point d'entrée par défaut sur gunicorn -b :8080 main:app. Pour en savoir plus, consultez Créer une application Python.

Vous pouvez résoudre ce problème de plusieurs manières. Par exemple, vous pouvez spécifier l'un des serveurs Web suivants dans votre fichier requirements.txt :

  • gunicorn :

      # https://pypi.org/project/gunicorn/
  gunicorn==21.2.0

  • fastapi et uvicorn :

    
# https://pypi.org/project/fastapi
fastapi[standard]==0.116.1

# https://pypi.org/project/uvicorn
uvicorn==0.35.0

Vous pouvez également suivre l'une des procédures suivantes pour résoudre les erreurs de déploiement :

  • Spécifiez le point d'entrée en exécutant la commande de déploiement de la source suivante :

    gcloud run deploy SERVICE --source .  --set-build-env-vars GOOGLE_ENTRYPOINT="ENTRYPOINT"

    Remplacez les éléments suivants :

    • SERVICE : nom du service sur lequel vous souhaitez déployer.
    • ENTRYPOINT : point d'entrée par défaut que vous souhaitez utiliser pour votre code source.

  • Utilisez un fichier Procfile pour définir un point d'entrée.

Erreurs de diffusion

Cette section répertorie les problèmes que vous pouvez rencontrer lors de la diffusion et fournit des suggestions pour les résoudre.

HTTP 404 : Introuvable

Le problème suivant se produit lors de la diffusion :

`HTTP 404`:Not found

Vous pouvez rencontrer des erreurs HTTP 404 dans les cas suivants :

  1. Une URL de requête ou un code d'application incorrects renvoient des erreurs 404. Pour résoudre ce problème, procédez comme suit :

    1. Vérifiez que l'URL que vous avez demandée est correcte. Vous pouvez vérifier l'URL sur la page d'informations sur le service dans la console Google Cloud ou en exécutant la commande suivante :

      gcloud run services describe SERVICE_NAME | grep URL

    2. Inspectez les endroits où votre application renvoie des codes d'erreur 404. Si votre application renvoie 404, vous pouvez le trouver dans Cloud Logging. Vérifiez également que l'application ne renvoie pas de code d'erreur 404 lorsque vous l'exécutez localement.

    3. Assurez-vous que votre application ne commence pas à écouter sur le port configuré avant qu'il ne soit prêt à recevoir des requêtes.

  2. La requête n'atteint pas le conteneur, ce qui entraîne une erreur 404 dans les scénarios suivants :

    Dans ces deux scénarios, vous ne trouverez pas l'erreur 404 dans Cloud Logging, même si vous appliquez le filtre suivant :

    resource.type="cloud_run_revision"
log_name="projects/PROJECT_ID/logs/run.googleapis.com%2Frequests"
httpRequest.status=404

  3. Avec les mêmes paramètres d'entrée, la requête peut être bloquée par VPC Service Controls sur la base du contexte de l'appelant, qui inclut le projet et l'adresse IP. Pour rechercher un non-respect des règles VPC Service Controls :

    1. Ouvrez l'explorateur de journaux dans la console Google Cloud  :

      Accéder à l'explorateur de journaux

    2. Saisissez le texte suivant dans le champ "Requête" :

      resource.type="audited_resource"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy"
resource.labels.method="run.googleapis.com/HttpIngress"

    3. Si vous voyez des entrées de journal après avoir utilisé cette requête, examinez-les pour déterminer si vous devez ou non mettre à jour vos règles VPC Service Controls.

  4. Accédez au point de terminaison de votre service avec un équilibreur de charge à l'aide du runtime Python. Pour résoudre ce problème, vérifiez le masque d'URL de votre équilibreur de charge et assurez-vous que le chemin d'URL que vous spécifiez pour l'équilibreur de charge correspond au chemin d'accès dans votre code source Python.

Aucune instance de conteneur disponible

L'erreur suivante se produit lors de la diffusion :

HTTP 429
The request was aborted because there was no available instance.
The Cloud Run service might have reached its maximum container instance
limit or the service was otherwise not able to scale to incoming requests.
This might be caused by a sudden increase in traffic, a long container startup time or a long request processing time.

Pour résoudre ce problème, vérifiez la métrique Nombre d'instances de conteneur de votre service et envisagez d'augmenter cette limite si votre utilisation approche du maximum. Pour en savoir plus, consultez Définir le nombre maximal d'instances pour les services. Si vous avez besoin d'instances supplémentaires, demandez une augmentation de quota.

Cloud Run n'a pas pu gérer le débit du trafic

L'erreur suivante se produit lors de la diffusion ou lorsque le service n'a pas atteint sa limite maximale d'instances de conteneur :

HTTP 500
The request was aborted because there was no available instance

Pour résoudre ce problème, procédez comme suit :

  1. Examinez les causes possibles suivantes :

    • Une augmentation soudaine et importante du trafic
    • Un long temps de démarrage à froid
    • Un long temps de traitement des requêtes ou une augmentation soudaine du temps de traitement des requêtes
    • Le service atteint sa limite maximale d'instances de conteneur (HTTP 429)
    • Des facteurs temporaires attribuables au service Cloud Run

  2. Mettez en œuvre un intervalle exponentiel entre les tentatives et de nouvelles tentatives pour les requêtes que le client ne doit pas supprimer. Une augmentation courte et soudaine du trafic ou du temps de traitement des requêtes peut n'être visible dans Cloud Monitoring que si vous effectuez un zoom avant sur 10 secondes.

  3. Lorsque le problème est lié à une période d'augmentation temporaire du nombre d'erreurs attribuables uniquement à Cloud Run, veuillez contacter l'assistance.

L'instance Cloud Run ne démarre pas

L'erreur suivante se produit lors de la diffusion :

HTTP 500
The request failed because the instance could not start successfully.

Cette erreur se produit lorsque le conteneur ne parvient pas à démarrer et à devenir opérationnel dans le délai que vous avez configuré. Bien que cela puisse avoir plusieurs causes, l'une des raisons courantes est l'incapacité du conteneur à accéder à un secret requis depuis Secret Manager.

Pour résoudre ce problème, procédez comme suit :

  1. Vérifiez les autorisations IAM : assurez-vous que votre compte de service Cloud Run dispose du rôle Accesseur de secrets Secret Manager (roles/secretmanager.secretAccessor) pour le secret auquel vous essayez d'accéder.

  2. Vérifiez le chemin d'accès au secret : assurez-vous de spécifier le nom et la version du secret dans la configuration de votre application.

  3. Inspectez la configuration réseau : si vous utilisez un périmètre VPC Service Controls ou des règles de pare-feu, assurez-vous d'autoriser le trafic de sortie vers secretmanager.googleapis.com.

  4. Générez des journaux efficaces : ajoutez logging au processus de démarrage de votre application, en particulier autour de la récupération des secrets, pour diagnostiquer des échecs spécifiques.

L'opération n'est pas implémentée

L'erreur suivante se produit lorsque vous spécifiez une REGION incorrecte lors de l'appel de votre tâche Cloud Run, par exemple lorsque vous déployez une tâche dans la région asia-southeast1 et que vous l'appelez à l'aide de southeast1-asia ou asia-southeast :

HTTP 501
Operation is not implemented, or supported, or enabled.

Pour obtenir la liste des régions disponibles, consultez la page Emplacements Cloud Run.

Identifiants par défaut introuvables

L'erreur suivante se produit lorsque votre application n'est pas correctement authentifiée en raison de fichiers manquants, de chemins d'accès aux identifiants non valides ou d'attributions de variables d'environnement incorrectes :

HTTP 503: System.InvalidOperationException System.InvalidOperationException your Default
credentials were not found.

Pour remédier à ce problème :

  1. Installez et initialisez gcloud CLI.

  2. Configurez les identifiants par défaut de l'application (ADC) avec les identifiants associés à votre compte Google. Configurez les identifiants par défaut de l'application à l'aide des commandes suivantes :

      gcloud auth application-default login

    Un écran de connexion s'affiche. Une fois que vous êtes connecté, vos identifiants sont stockés dans le fichier d'identifiants local utilisé par ADC.

  3. Utilisez la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS pour fournir l'emplacement d'un fichier d'identifiants JSON dans votre projet Google Cloud .

    Pour en savoir plus, consultez Configurer le service Identifiants par défaut de l'application.

Les instances de conteneur dépassent les limites de mémoire

L'erreur HTTP 500 ou HTTP 503 suivante se produit lors de la diffusion dans Cloud Logging :

While handling this request, the container instance was found to be using too much memory and was terminated. This is likely to cause a new container instance to be used for the next request to this revision. If you see this message frequently, you may have a memory leak in your code or may need more memory. Consider creating a new revision with more memory.

Pour remédier à ce problème :

  1. Déterminez si vos instances de conteneur dépassent la mémoire disponible. Recherchez les erreurs connexes dans les journaux varlog/system.
  2. Si les instances dépassent la mémoire disponible, vous devez augmenter la limite de mémoire.

Dans Cloud Run, les fichiers écrits dans le système de fichiers local sont comptabilisés dans la mémoire disponible. Cela inclut également les fichiers journaux écrits dans des emplacements autres que /var/log/* et /dev/log.

Impossible de traiter certaines requêtes en raison d'un paramètre de simultanéité élevée

L'erreur suivante se produit lorsque vos instances de conteneur utilisent une charge de processeur élevée pour traiter les requêtes et ne peuvent donc pas traiter toutes les requêtes :

HTTP 503
The Cloud Run service probably has reached its maximum container instance limit. Consider increasing this limit.

Pour résoudre ce problème, procédez comme suit :

  1. Augmentez le nombre maximal d'instances de conteneur pour votre service.

  2. Réduisez la simultanéité du service. Pour en savoir plus, consultez Définir le nombre maximal de requêtes simultanées par instance.

Erreurs Cloud Logging liées à l'abandon de requêtes en file d'attente

L'une des erreurs suivantes se produit lorsque Cloud Run ne parvient pas à évoluer assez rapidement pour gérer le trafic :

  • The request was aborted because there was no available instance:
severity=WARNING ( Response code: 429 ) Cloud Run cannot
scale due to the max-instances limit you set
during configuration.

  • severity=ERROR ( Response code: 500 ) Cloud Run intrinsically
cannot manage the rate of traffic.

Pour résoudre ce problème, procédez comme suit :

  1. Résolvez les causes racines qui peuvent entraîner des échecs de scaling, par exemple :

    • Une augmentation soudaine et importante du trafic
    • Un long temps de démarrage à froid
    • Un long temps de traitement des requêtes
    • Un taux d'erreur de code source élevé.
    • Vous avez atteint la limite maximale d'instances et le système ne peut plus évoluer.
    • Des facteurs temporaires attribuables au service Cloud Run

    Pour en savoir plus sur la résolution des problèmes de scaling et l'optimisation des performances, consultez Conseils de développement généraux.

  2. Pour les services ou fonctions basés sur un déclencheur HTTP, faites en sorte que le client mette en œuvre un intervalle exponentiel entre les tentatives et que les nouvelles tentatives pour les requêtes ne soient pas supprimées. Si vous déclenchez des services à partir de Workflows, vous pouvez utiliser la syntaxe try/retry pour ce faire.

  3. Pour les services ou fonctions en arrière-plan ou basés sur des événements, Cloud Run est compatible avec la distribution de type "au moins une fois". Même si vous n'activez pas explicitement les nouvelles tentatives, Cloud Run redistribue automatiquement l'événement et relance l'exécution. Pour en savoir plus, consultez la section Effectuer de nouvelles tentatives d'exécution des fonctions basées sur des événements.

  4. Pour les problèmes liés aux démarrages à froid, configurez un nombre minimal d'instances afin de réduire le nombre de démarrages à froid, ce qui aura un impact plus important sur la facturation.

  5. Lorsque le problème est lié à une période d'augmentation temporaire du nombre d'erreurs attribuables uniquement à Cloud Run, ou si vous avez besoin d'aide pour résoudre votre problème, contactez l'assistance.

Signature du jeton d'identité masquée par Google

L'erreur suivante se produit lors des phases de développement et de test :

SIGNATURE_REMOVED_BY_GOOGLE

Cette erreur peut se produire dans les scénarios suivants :

  • L'utilisateur se connecte à l'aide de la CLI Google Cloud ou de Cloud Shell.

  • L'utilisateur génère un jeton d'ID à l'aide des commandes gcloud.

  • L'utilisateur essaie d'utiliser le jeton d'ID pour appeler un service Cloud Run non public.

Il s'agit du comportement par défaut attendu. Google supprime la signature du jeton pour des raisons de sécurité, afin d'empêcher tout service Cloud Run non public de relire les jetons d'ID générés de cette manière.

Pour résoudre ce problème, appelez votre service privé avec un nouveau jeton d'ID. Pour en savoir plus, consultez Tester votre service privé.

Avertissement OpenBLAS dans les journaux

Si vous utilisez des bibliothèques basées sur OpenBLAS, telles que NumPy, avec l'environnement d'exécution de première génération, l'avertissement suivant peut s'afficher au sein de vos journaux :

OpenBLAS WARNING - could not determine the L2 cache size on this system,
assuming 256k`

L'avertissement OpenBLAS s'affiche lorsque le bac à sable de conteneur utilisé par l'environnement d'exécution de première génération n'expose pas de fonctionnalités matérielles de bas niveau. Cet avertissement n'a aucune incidence sur votre service. Pour éviter les entrées de journal d'avertissement OpenBLAS, passez à l'environnement d'exécution de deuxième génération.

Spark échoue lors de l'obtention de l'adresse IP de la machine à laquelle s'associer

Lorsque Spark échoue lors de l'obtention de l'adresse IP de la machine à laquelle s'associer, l'une des erreurs suivantes se produit :

assertion failed: Expected hostname (not IP) but got <IPv6 ADDRESS>
 
assertion failed: Expected hostname or IPv6 IP enclosed in [] but got <IPv6 ADDRESS>

Pour résoudre ce problème, définissez la variable d'environnement SPARK_LOCAL_IP sur 127.0.0.1 dans votre fichier Dockerfile (par exemple, ENV SPARK_LOCAL_IP="127.0.0.1"). Si vous ne définissez pas la variable d'environnement SPARK_LOCAL_IP, elle est définie par défaut sur son équivalent IPv6 plutôt que sur le localhost. De plus, Spark ne reconnaît pas la variable d'environnement définie sur RUN export SPARK_LOCAL_IP="127.0.0.1".

Impossible d'accéder aux fichiers via NFS

Erreur Solution recommandée
mount.nfs: Protocol not supported Certaines images de base, telles que debian et adoptopenjdk/openjdk11, ne contiennent pas la dépendance nfs-kernel-server.
mount.nfs: Connection timed out Si la connexion expire, assurez-vous que vous fournissez l'adresse IP correcte de l'instance Filestore.
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE Si l'accès a été refusé par le serveur, assurez-vous que le nom du partage de fichiers est correct.

Impossible d'accéder aux fichiers à l'aide de Cloud Storage FUSE

Consultez le guide de dépannage de Cloud Storage FUSE.

Latence élevée lorsque l'utilisation du processeur est faible

Votre service peut rencontrer des latences de requête élevées ou ne pas parvenir à effectuer un scaling à la hausse sous charge, même si Cloud Monitoring indique que l'utilisation moyenne du processeur est bien inférieure à l'objectif de scaling typique de 60 %.

Cause possible :

Cela peut se produire si votre application est monothread pour les tâches liées au processeur, mais qu'elle est déployée sur une instance avec plusieurs vCPU. Il est possible que votre application utilise un cœur de processeur virtuel au maximum, tandis que les autres cœurs restent principalement inactifs. L'autoscaler Cloud Run utilise l'utilisation moyenne du processeur sur tous les processeurs virtuels. Cette moyenne peut être faible dans ces cas, ce qui empêche le scaling basé sur le processeur.

Solutions :

  • Pour les applications monothread :
    • Privilégiez la configuration de votre service avec un processeur virtuel si ses besoins en mémoire peuvent être satisfaits (consultez Limites de mémoire et minimums de processeur). Cela permet aux métriques d'utilisation du processeur de refléter précisément la charge.
    • Si plusieurs processeurs virtuels sont nécessaires en raison de besoins élevés en mémoire qui dépassent les limites d'un processeur virtuel, l'autoscaling basé sur le processeur sera probablement moins efficace. Dans ce scénario, réduisez le paramètre de simultanéité maximale pour encourager le scaling plus tôt en fonction du débit de requêtes. Consultez la section Configuration de la simultanéité.
  • Pour les configurations à plusieurs processeurs virtuels : assurez-vous que votre application est conçue pour utiliser efficacement tous les processeurs virtuels alloués (par exemple, en utilisant plusieurs processus ou threads de nœud de calcul).

Erreurs de connectivité et de sécurité

Cette section décrit les erreurs de connectivité et de sécurité courantes dans Cloud Run, ainsi que les méthodes permettant de les résoudre.

Le client n'est pas authentifié correctement

L'erreur suivante se produit lors de la diffusion :

HTTP 401: The request was not authorized to invoke this service

Pour remédier à ce problème :

  1. Si un compte de service appelle votre service Cloud Run, définissez la revendication d'audience (aud) du jeton d'ID signé par Google sur la valeur suivante :

    • Si vous définissez aud sur l'URL du service destinataire au format https://SERVICE.run.app ou https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION, votre service doit exiger une authentification. Appelez votre service Cloud Run à l'aide de l'URL Cloud Run ou d'une URL d'équilibreur de charge. Pour obtenir des exemples d'envoi de requêtes authentifiées, consultez Appeler avec une requête HTTPS.

    • Si vous définissez aud sur l'ID client d'un ID client OAuth 2.0 de type application Web, au format nnn-xyz.apps.googleusercontent.com, vous pouvez appeler votre service Cloud Run via un équilibreur de charge HTTPS sécurisé par IAP. Nous recommandons cette approche pour un équilibreur de charge d'application sauvegardé par plusieurs services Cloud Run dans différentes régions.

    • Si vous définissez aud sur une audience personnalisée configurée, utilisez les valeurs exactes fournies. Par exemple, si l'audience personnalisée est https://service.example.com, la valeur de la revendication d'audience doit également être https://service.example.com.

  2. Assurez-vous que vos requêtes incluent un en-tête Authorization: Bearer ID_TOKEN ou un en-tête X-Serverless-Authorization: Bearer ID_TOKEN pour l'autorisation personnalisée, et qu'il s'agit d'un jeton d'ID, et non d'un jeton d'accès ou d'actualisation. Une erreur 401 peut se produire dans les scénarios suivants en raison d'un format d'autorisation incorrect :

    • Le jeton d'autorisation utilise un format non valide.

    • L'en-tête d'autorisation n'est pas un jeton Web JSON (JWT) avec une signature valide.

    • L'en-tête d'autorisation contient plusieurs jetons JWT.

    • La requête contient plusieurs en-têtes d'autorisation.

    Pour vérifier les revendications d'un jeton JWT, utilisez l'outil jwt.io.

  3. Si vous obtenez des jetons non valides lorsque vous utilisez le serveur de métadonnées pour extraire les jetons d'identification et d'accès afin d'authentifier les requêtes auprès du service Cloud Run ou de l'identité du job avec un proxy HTTP pour acheminer le trafic de sortie, ajoutez les hôtes suivants aux exceptions de proxy HTTP :

    • 169.254.* ou 169.254.0.0/16

    • *.google.internal

  4. Une erreur 401 se produit généralement lorsque les bibliothèques clientes Cloud utilisent le serveur de métadonnées pour récupérer les identifiants par défaut de l'application afin d'authentifier les appels REST ou gRPC. Si vous ne définissez pas les exceptions de proxy HTTP, cela entraîne les résultats de comportement suivants :

    • Si différentes charges de travail Google Cloud hébergent un service ou un job Cloud Run et le proxy HTTP, même si les bibliothèques clientes Cloud récupèrent les identifiants, le compte de service attribué à la charge de travail du proxy HTTP génère les jetons. Il est possible que les jetons ne disposent pas des autorisations requises pour effectuer les opérations Google Cloud API prévues. En effet, le compte de service récupère les jetons à partir de la vue du serveur de métadonnées de la charge de travail du proxy HTTP, et non du service ou de la tâche Cloud Run.

    • Si le proxy HTTP n'est pas hébergé dans Google Cloudet que vous acheminez les requêtes du serveur de métadonnées à l'aide du proxy, les requêtes de jeton échouent et les opérations des APIGoogle Cloud ne s'authentifient pas.

  5. Redéployez votre service pour autoriser l'accès public si votre organisation le permet. Cette approche est utile pour les tests.

Le client n'est pas autorisé à appeler le service

L'une des erreurs suivantes se produit lors de l'appel de votre service :

HTTP 403: The request was not authenticated. Either allow public access or set the proper Authorization header
 
HTTP 403: Forbidden: Your client does not have permission to get URL from this server.

Une erreur 403 peut se produire lorsque le membre IAM utilisé pour générer le jeton d'autorisation ne dispose pas de l'autorisation run.routes.invoke. Accordez cette autorisation à l'utilisateur qui génère le jeton.

De plus, si une entrée d'erreur au format resource.type = "cloud_run_revision" est présente dans Cloud Logging, suivez ces étapes pour résoudre l'erreur :

  1. Pour que votre service puisse être appelé par n'importe quel utilisateur, mettez à jour les paramètres IAM et rendez le service public.

  2. Pour que votre service ne puisse être appelé que par certaines identités, appelez-le avec le jeton d'autorisation approprié :

    • Si un développeur ou un utilisateur final appelle votre service, accordez l'autorisation run.routes.invoke. Vous pouvez accorder cette autorisation à l'aide des rôles Administrateur Cloud Run (roles/run.admin) et Demandeur Cloud Run (roles/run.invoker).

    • Si un compte de service appelle votre service, assurez-vous que le compte de service est membre du service Cloud Run et accordez-lui le rôle Demandeur Cloud Run (roles/run.invoker).

    • Si les appels n'incluent pas de jeton d'authentification, l'erreur 403 peut se produire. Si les appels avec un jeton d'authentification valide génèrent toujours l'erreur 403, accordez l'autorisation run.routes.invoke au membre IAM qui génère le jeton.

Si vous rencontrez une erreur 403 et que vous ne trouvez pas l'entrée de journal resource.type = "cloud_run_revision", cela peut être dû à VPC Service Controls qui bloque un service Cloud Run dont les paramètres d'entrée sont configurés sur All. Pour en savoir plus sur le dépannage des refus de VPC Service Controls, consultez Erreurs 404.

Erreur lors de l'accès au service depuis un navigateur Web

Le problème suivant se produit lorsque vous accédez à un service Cloud Run depuis un navigateur Web :

403 Forbidden
Your client does not have permission to get URL from this server.

Lorsque vous appelez un service Cloud Run depuis un navigateur Web, celui-ci envoie une requête GET au service. Toutefois, la requête ne contient pas le jeton d'autorisation de l'utilisateur appelant. Pour résoudre ce problème, procédez comme suit :

  1. Utilisez Identity-Aware Proxy (IAP) avec Cloud Run. IAP vous permet d'établir une couche d'autorisation centrale pour les applications accessibles via HTTPS. Avec IAP, vous pouvez utiliser un modèle de contrôle des accès au niveau de l'application au lieu des pare-feu au niveau du réseau. Pour en savoir plus sur la configuration de Cloud Run avec IAP, consultez Activer Identity-Aware Proxy pour Cloud Run.

  2. Pour contourner temporairement ce problème, accédez à votre service via un navigateur Web à l'aide du proxy Cloud Run dans Google Cloud CLI. Pour transférer un service localement, exécutez la commande suivante :

    gcloud run services proxy SERVICE --project PROJECT-ID

    Cloud Run envoie le service privé par proxy vers http://localhost:8080 (ou vers le port que vous spécifiez avec --port), en fournissant le jeton du compte actif ou un autre jeton que vous spécifiez. Il s'agit de la méthode recommandée pour tester en privé un site Web ou une API dans votre navigateur. Pour en savoir plus, consultez Tester les services privés.

  3. Autorisez l'accès public à votre service. C'est utile pour les tests ou lorsque votre service est une API publique ou un site Web.

Connexion réinitialisée par l’homologue

L'une des erreurs suivantes se produit lorsqu'un pair sur le réseau ferme de manière inattendue la connexion TCP établie par l'application :

Connection reset by peer
 
asyncpg.exceptions.ConnectionDoesNotExistError: connection was closed in the middle of operation
 
grpc.StatusRuntimeException: UNAVAILABLE: io exception
 
psycopg.OperationalError: the connection is closed
 
ECONNRESET

Pour résoudre ce problème, procédez comme suit :

  • Si vous tentez d'exécuter des tâches en arrière-plan avec la limitation du processeur, utilisez le paramètre de facturation basée sur les instances.

  • Assurez-vous de respecter les délais d'expiration des requêtes sortantes. Si votre application maintient une connexion à l'état inactif au-delà de ce seuil, la passerelle doit récupérer la connexion.

  • Par défaut, l'option de socket TCP keepalive est désactivée pour Cloud Run. Il n'existe pas de méthode directe pour configurer l'option keepalive au niveau du service. Pour activer l'option keepalive pour chaque connexion de socket, fournissez les options de socket requises lorsque vous ouvrez une nouvelle connexion de socket TCP, en fonction de la bibliothèque cliente que vous utilisez pour cette connexion dans votre application.

  • Les connexions sortantes sont parfois réinitialisées en raison de mises à jour de l'infrastructure. Si votre application réutilise des connexions à longue durée de vie, nous vous recommandons de la configurer de manière à rétablir les connexions afin d'éviter la réutilisation d'une connexion interrompue.

  • Si vous utilisez un proxy HTTP pour acheminer le trafic sortant de vos services ou jobs Cloud Run et que le proxy applique une durée de connexion maximale, le proxy peut supprimer sans notification les connexions TCP de longue durée, telles que celles établies à l'aide du regroupement de connexions. Cela entraîne l'échec des clients HTTP lors de la réutilisation d'une connexion déjà fermée. Si vous prévoyez d'acheminer le trafic de sortie via un proxy HTTP, vous devez implémenter la validation de la connexion, les tentatives et l'intervalle exponentiel entre les tentatives. Pour les pools de connexions, configurez les valeurs maximales pour l'âge de la connexion, les connexions inactives et le délai d'inactivité de la connexion.

Délai d'inactivité de la connexion

Les erreurs suivantes se produisent lorsqu'une application tente de créer une connexion TCP avec un hôte distant et que la connexion met trop de temps à s'établir :

java.io.IOException: Connection timed out
 
ConnectionError: HTTPSConnectionPool
 
dial tcp REMOTE_HOST:REMOTE_PORT: i/o timeout / context error
 
Error: 4 DEADLINE_EXCEEDED: Deadline exceeded

Pour résoudre les problèmes de délai de connexion dépassé, procédez comme suit :

  1. Si vous acheminez tout le trafic de sortie via un réseau VPC, à l'aide de connecteurs VPC ou de sortie VPC directe, procédez comme suit :

    • Définissez toutes les règles de pare-feu nécessaires pour autoriser le trafic entrant pour les connecteurs VPC.

    • Les règles de pare-feu VPC doivent autoriser le trafic entrant provenant des connecteurs VPC ou du sous-réseau de sortie VPC direct à atteindre l'hôte ou le sous-réseau de destination.

    • Assurez-vous de disposer de toutes les routes requises pour permettre un routage correct du trafic vers les hôtes de destination et inversement. Cela est important lors du routage du trafic de sortie via l'appairage de réseaux VPC ou la connectivité cloud hybride, car les paquets traversent plusieurs réseaux avant d'atteindre l'hôte distant.

  2. Si vous utilisez un proxy HTTP pour acheminer tout le trafic de sortie de vos services ou jobs Cloud Run, les hôtes distants doivent être accessibles à l'aide du proxy.

    Le trafic acheminé via un proxy HTTP peut être retardé en fonction de l'utilisation des ressources du proxy. Si vous acheminez le trafic de sortie HTTP à l'aide d'un proxy, implémentez des nouvelles tentatives, un délai exponentiel ou des disjoncteurs.

Configurer des exceptions de proxy HTTP

Lorsque vous utilisez un proxy HTTP pour acheminer le trafic sortant de vos services ou jobs Cloud Run, ajoutez des exceptions pour les API Cloud et d'autres hôtes et sous-réseaux sans proxy afin d'empêcher la latence, les délais avant expiration de la connexion, les réinitialisations de connexion et les erreurs d'authentification.

Les hôtes et sous-réseaux sans proxy doivent inclure, au minimum, les éléments suivants :

  • 127.0.0.1
  • 169.254.* ou 169.254.0.0/16
  • localhost
  • *.google.internal
  • *.googleapis.com

Les hôtes sans proxy peuvent éventuellement inclure les éléments suivants :

  • *.appspot.com
  • *.run.app
  • *.cloudfunctions.net
  • *.gateway.dev
  • *.googleusercontent.com
  • *.pkg.dev
  • *.gcr.io

Pour définir des exceptions de proxy HTTP pour la mise en réseau de sortie, configurez les éléments suivants :

  • Variables d'environnement : NO_PROXY ou no_proxy.

  • Option de machine virtuelle Java http.nonProxyHosts :

    • La propriété système https.nonProxyHosts n'est pas définie. Cette propriété système s'applique à la fois à HTTP et à HTTPS.

    • La propriété système http.nonProxyHosts n'est pas compatible avec la notation CIDR. Vous devez utiliser des expressions de correspondance de modèle.

Réponse incorrecte ou problème de connexion à l'instance de conteneur

L'erreur suivante se produit en cas de problème de connexion à une instance de conteneur :

HTTP 503
The request failed because either the HTTP response was malformed or connection to the instance had an error.

Pour résoudre ce problème, procédez comme suit :

  1.  Consultez Cloud Logging pour rechercher les erreurs suivantes :

    • Erreurs de mémoire insuffisante. Si les journaux contiennent des messages d'erreur indiquant que les instances de conteneur dépassent les limites de mémoire, consultez les recommandations de la section Les instances de conteneur dépassent les limites de mémoire.

    • Échecs de la vérification d'activité avec l'erreur suivante dans les journaux :

      LIVENESS HTTP probe failed 1 time consecutively for container CONTAINER_NAME on port 8080. The instance has been shut down.

      Si votre instance ne répond pas correctement à la vérification dans le délai imparti, procédez comme suit :

  2. Si les requêtes se terminent par un code d'erreur 503 avant d'atteindre le délai avant expiration de la requête défini dans Cloud Run, mettez à jour le paramètre de délai avant expiration de la requête pour votre framework de langage :

  3. Dans certains cas, un code d'erreur 503 peut se produire en raison d'un goulot d'étranglement sur le réseau en aval, par exemple lors des tests de charge. Par exemple, si votre service achemine le trafic via un connecteur d'accès au VPC sans serveur, assurez-vous que le connecteur ne dépasse pas son seuil de débit en procédant comme suit :

    1. Ouvrez l'accès au VPC sans serveur dans la console Google Cloud  :

      Accéder à l'accès au VPC sans serveur

    2. Recherchez les barres rouges dans l'histogramme du graphique de débit. Si une barre rouge s'affiche, envisagez d'augmenter le nombre maximal d'instances ou le type d'instance utilisé par le connecteur. Vous pouvez également compresser le trafic envoyé via un connecteur d'accès au VPC sans serveur.

  4. Si une instance de conteneur reçoit plus de 800 requêtes par seconde, les sockets TCP disponibles peuvent être épuisés. Pour résoudre ce problème, activez HTTP/2 pour votre service et apportez les modifications nécessaires pour assurer la compatibilité HTTP/2.

Erreur d'expiration du délai de la passerelle

L'erreur suivante se produit lorsque votre service ne renvoie pas de réponse dans un délai spécifié et que la requête se termine :

HTTP 504
The request has been terminated because it has reached the maximum request timeout.

Pour en savoir plus sur cette erreur, consultez le contrat d'exécution du conteneur.

Pour résoudre ce problème, procédez comme suit :

  • Si votre service traite des requêtes de longue durée, augmentez le délai avant expiration des requêtes.

  • Instrumentez la journalisation et le traçage pour comprendre où votre application perd du temps avant de dépasser le délai avant expiration de requête configuré.

  • Les connexions sortantes sont parfois réinitialisées en raison de mises à jour de l'infrastructure. Si votre application réutilise des connexions à longue durée de vie, nous vous recommandons de la configurer de manière à rétablir les connexions afin d'éviter la réutilisation d'une connexion interrompue.

    Selon la logique de votre application ou son processus de gestion des erreurs, une erreur 504 peut indiquer que votre application tente de réutiliser une connexion interrompue et que la requête se bloque jusqu'à ce que le délai avant expiration de requête configuré soit atteint. Utilisez une vérification d'activité pour arrêter une instance qui renvoie des erreurs persistantes.

  • Les erreurs de mémoire insuffisante qui se produisent dans le code de l'application, par exemple java.lang.OutOfMemoryError, n'arrêtent pas nécessairement une instance de conteneur. Si l'utilisation de mémoire ne dépasse pas la limite de mémoire du conteneur, Cloud Run n'arrête pas l'instance. Selon la manière dont l'application gère les erreurs de mémoire insuffisante au niveau de l'application, les requêtes peuvent ne pas aboutir tant que le délai avant expiration de requête configuré n'est pas atteint.

    Pour arrêter l'instance de conteneur, procédez comme suit :

    • Configurez la limite de mémoire au niveau de l'application de sorte qu'elle soit supérieure à votre limite de mémoire de conteneur.

    • Utilisez une vérification d'activité pour arrêter une instance qui renvoie des erreurs persistantes.

Domaine personnalisé bloqué lors du provisionnement du certificat

L'une des erreurs suivantes se produit lorsque vous mappez un domaine personnalisé :

The domain is available over HTTP.  Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin and to accept HTTP traffic.
 
Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin.

Pour remédier à ce problème :

  1. Patientez pendant au moins 24 heures. Le provisionnement du certificat SSL prend généralement environ 15 minutes, mais un délai maximal de 24 heures est parfois nécessaire.

  2. Vérifiez que vous avez correctement mis à jour vos enregistrements DNS auprès de votre bureau d'enregistrement de noms de domaine à l'aide de l'outil Dig de Google Admin Toolbox. Les enregistrements DNS dans votre bureau d'enregistrement de noms de domaine doivent correspondre à ceux que la consoleGoogle Cloud vous invite à ajouter.

  3. Validez la racine du domaine dans votre compte à l'aide de l'une des méthodes suivantes :

  4. Vérifiez que le certificat du domaine n'a pas expiré. Pour connaître les limites d'expiration, utilisez la commande suivante :

    echo | openssl s_client -servername 'ROOT_DOMAIN' -connect 'ROOT_DOMAIN:443' 2>/dev/null | openssl x509 -startdate -enddate -noout

La déconnexion du client ne se propage pas dans Cloud Run

Lorsque vous utilisez HTTP/1.1 sur Cloud Run, les événements de déconnexion du client ne sont pas transmis au conteneur Cloud Run.

Pour résoudre ce problème, utilisez Websockets ou HTTP/2.0, qui propagent les déconnexions des clients.