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

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Cette page explique comment résoudre les problèmes liés à Cloud Run.

Erreurs de déploiement

Cette section répertorie les problèmes que vous pouvez rencontrer lors du déploiement et fournit des suggestions pour 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, éliminez les causes potentielles suivantes :

  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 port prévu, comme indiqué dans le contrat d'exécution du conteneur. 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 la page Configurer des conteneurs.

  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.

  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 interne, délai de disponibilité des ressources dépassé

L'erreur suivante se produit lorsque vous tentez de déployer ou d'appeler une autre API Google Cloud :

The server has encountered an internal error. Please try again later. Resource readiness deadline exceeded.

Ce problème peut se produire lorsque l'agent de service Cloud Run n'existe pas ou lorsqu'il ne dispose pas du rôle "Agent de service Cloud Run (roles/run.serviceAgent)".

Pour vérifier que l'agent de service Cloud Run existe dans votre projet Cloud et qu'il dispose du rôle nécessaire, procédez comme suit :

  1. Ouvrez la console Google Cloud.

    Accéder à la page "IAM et administration"

  2. Dans l'angle supérieur droit de la page Autorisations, 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 Cloud Run, qui utilise l'ID
    service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com.

  4. Vérifiez que l'agent de service dispose du rôle Agent de service Cloud Run. Si l'agent de service ne dispose pas du rôle, attribuez-lui le rôle.

Erreur : utilisateur racine introuvable dans /etc/passwd

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

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

Le problème 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".

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 de votre tentative de 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'une des situations suivantes :

Pour remédier à ce problème, procédez comme suit :

  1. Spécifiez un compte de service à l'aide de l'option --service-account gcloud.
  2. Vérifiez que le compte de service que vous spécifiez dispose des autorisations requises pour le déploiement.

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

  1. Ouvrez la console Google Cloud.

    Accéder à la page "IAM et administration"

  2. Dans l'angle supérieur droit de la page Autorisations, 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 utilise l'ID
    PROJECT_NUMBER-compute@developer.gserviceaccount.com.

L'agent de service Cloud Run n'est pas autorisé à lire l'image.

L'erreur suivante se produit lorsque vous essayez d'effectuer un déploiement depuis PROJECT-ID à l'aide d'une image stockée dans Container Registry dans PROJECT-ID-2 :

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.

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-SC 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, procédez comme suit :

    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_ID@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-SC. Elles peuvent indiquer que vous devez ajouter service-PROJECT_ID@serverless-robot-prod.iam.gserviceaccount.com à une règle d'accès préexistante.

Erreurs 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, éliminez les causes potentielles suivantes :

  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. Bien que Container Registry ne génère pas d'erreur lorsque des couches étrangères sont présentes, le plan de contrôle de Cloud Run ne les accepte pas. Pour résoudre ce problème, vous pouvez essayer de définir l'option --allow-nondistributable-artifacts dans le daemon Docker :

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 401 : Le client n'est pas authentifié correctement

L'erreur suivante se produit lors de la diffusion :

The request was not authorized to invoke this service

Pour remédier à ce problème, procédez comme suit :

  • Si la requête a été invoquée par un compte de service : la revendication d'audience (aud) du jeton d'ID signé par Google doit être définie sur l'une des valeurs suivantes :
    • L'URL du service destinataire.
    • L'ID client d'un ID client OAuth 2.0 de type application Web (avec le format nnn-xyz.apps.googleusercontent.com).
      • L'ID client doit être créé avant le déploiement de la révision Cloud Run.
      • Cette option est parfaitement adaptée à un GCLB sauvegardé par plusieurs services Cloud Run dans différentes régions.
  • jwt.io est un bon outil pour vérifier les revendications d'un jeton JWT.
  • Si le format d'un jeton d'authentification n'est pas valide, une erreur 401 est générée. Si le format du jeton est valide et que le membre IAM utilisé pour générer le jeton ne dispose pas de l'autorisation run.routes.invoke, une erreur 403 est générée.

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

L'une des erreurs suivantes se produit lors de la diffusion :

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

Pour remédier à ce problème :

  • Si le service est configuré pour être appelé par n'importe quel utilisateur, mettez à jour les paramètres IAM pour le rendre public.
  • Si le service ne doit être appelé que par certaines identités, assurez-vous de l'appeler avec le jeton d'autorisation approprié.
    • S'il est appelé par un développeur ou appelé par un utilisateur final, assurez-vous que le développeur ou l'utilisateur dispose de l'autorisation run.routes.invoke disponible via le rôle "Administrateur Cloud Run" (roles/run.admin) ou "Demandeur Cloud Run (roles/run.invoker)".
    • S'il est appelé par un compte de service, assurez-vous que le compte de service est membre du service Cloud Run et qu'il dispose du rôle "Demandeur Cloud Run (roles/run.invoker)".
    • Si les appels ne disposent pas d'un jeton d'authentification, ou s'ils disposent d'un jeton d'authentification dont le format est valide, mais qu'il manque l'autorisation run.routes.invoke du membre IAM utilisé pour générer le jeton, une erreur 403 est générée.
  • Si le projet se trouve dans un périmètre VPC-SC, vérifiez que les règles VPC-SC ne refusent pas le trafic run.googleapis.com/HttpIngress provenant de l'adresse IP ou de l'identité de l'appelant. Pour le vérifier, exécutez la commande suivante :

    1. Ouvrez l'explorateur de journaux dans la console Google Cloud (et non la page Journaux de Cloud Run) :

      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 mettre à jour vos règles VPC-SC.

HTTP 404 : Introuvable

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

Vous rencontrez une erreur HTTP 404.

Pour remédier à ce problème, procédez comme suit :

  1. Vérifiez que l'application ne renvoie pas l'erreur 404 lorsque vous l'exécutez localement.
  2. Vérifiez que l'URL que vous demandez est correcte en consultant la page d'informations sur le service dans la console Cloud ou en exécutant la commande suivante :

    gcloud run services describe SERVICE_NAME | grep URL
    
  3. Inspectez où votre logique d'application peut renvoyer explicitement des erreurs 404

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

HTTP 429 : 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 du conteneur" de votre service et envisagez d'augmenter cette limite si votre utilisation approche du maximum. Consultez les paramètres de nombre maximal d'instances et demandez une augmentation de quota si vous avez besoin d'instances supplémentaires.

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

L'erreur suivante se produit lors de la diffusion :

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

La cause de cette erreur peut être l'une des suivantes :

Pour résoudre ce problème, corrigez les problèmes répertoriés précédemment.

En plus de résoudre ces problèmes, vous pouvez les contourner en mettant en œuvre un intervalle exponentiel entre les tentatives et de nouvelles tentatives pour les requêtes que le client ne doit pas supprimer.

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

HTTP 500/HTTP 503 : les instances de conteneur dépassent les limites de mémoire

L'erreur 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.

Notez que, 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.

HTTP 503 : réponse incorrecte ou problème de connexion à l'instance de conteneur

L'une des erreurs suivantes se produit lors de la diffusion :

HTTP 503
The request failed because either the HTTP response was malformed or connection to the instance had an error.
[CRITICAL] WORKER TIMEOUT

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

  • Utilisez Cloud Logging pour rechercher les erreurs de mémoire saturée dans les journaux. Si vous voyez des messages d'erreur indiquant que les instances de conteneur dépassent les limites de mémoire, suivez les recommandations permettant de résoudre ce problème.

  • 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, vous devrez peut-être mettre à jour le paramètre de délai avant expiration de la requête pour votre framework de langage :

  • Dans certains cas, un code d'erreur 503 peut être le résultat indirect d'un goulot d'étranglement sur le réseau en aval, parfois 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 n'a pas dépassé 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.

  • La définition d'une configuration de simultanéité de service Cloud Run inférieure peut atténuer les erreurs 503 en fonction de l'application sous-jacente.

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

Les erreurs suivantes se produisent lors de la diffusion :

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

Ce problème survient lorsque vos instances de conteneur utilisent beaucoup de ressources processeur pour traiter les requêtes. Par conséquent, les instances de conteneur ne peuvent pas traiter toutes les requêtes et certaines requêtes renvoient donc un code d'erreur 503.

Pour résoudre ce problème, essayez une ou plusieurs des solutions suivantes :

HTTP 504 : erreur d'expiration du délai de la passerelle

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

Si votre service traite des requêtes de longue durée, vous pouvez augmenter le délai avant expiration des requêtes. Si votre service ne renvoie pas de réponse dans le délai spécifié, la requête se termine et le service renvoie une erreur HTTP 504, comme indiqué dans le contrat d'exécution du conteneur.

Connexion réinitialisée par l’homologue

Les erreurs suivantes se produisent lors de la diffusion :

Connection reset by peer

Cette erreur se produit lorsqu'une application dispose d'une connexion TCP établie avec un pair sur le réseau et que ce pair ferme la connexion de manière inattendue.

Pour remédier à 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, essayez d'utiliser le paramètre d'allocation de processeurs "Le processeur est toujours alloué".

  • 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 ces seuils, 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 moyen direct de configurer l'option keepalive dans Cloud Run au niveau du service, mais vous pouvez activer l'option keepalive pour chaque connexion de socket en fournissant les options de socket appropriées lors de l'ouverture d'une nouvelle connexion de socket TCP, en fonction de la bibliothèque cliente que vous utilisez pour cette connexion dans votre application.

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

Les erreurs suivantes se produisent lors de la diffusion :

SIGNATURE_REMOVED_BY_GOOGLE

Cette erreur peut se produire lors du développement et du test dans les cas suivants :

  1. Un utilisateur se connecte à l'aide de la CLI Google Cloud ou de Cloud Shell.
  2. L'utilisateur génère un jeton d'ID à l'aide des commandes gcloud.
  3. L'utilisateur essaie d'utiliser le jeton d'ID pour appeler un service Cloud Run non public.

Cela est volontaire. 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 la section Tester l'authentification dans votre service.

Problème causé par une limite du bac à sable de conteneur

Les erreurs suivantes se produisent lors de la diffusion dans le bac à sable de conteneur :

Container Sandbox: Unsupported syscall setsockopt(0x3,0x1,0x6,0xc0000753d0,0x4,0x0)

Si votre conteneur s'exécute localement, mais échoue dans Cloud Run, le bac à sable de conteneur Cloud Run en est peut-être responsable.

Pour remédier à ce problème, procédez comme suit :

  1. Ouvrez l'explorateur de journaux dans la console Google Cloud (et non la page Journaux de Cloud Run) :

    Accéder à l'explorateur de journaux

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

    resource.type="cloud_run_revision"
    logName="projects/PROJECT_ID/logs/run.googleapis.com%2Fvarlog%2Fsystem"
    
  3. Si vous trouvez un journal Container Sandbox avec un niveau de gravité DEBUG et que vous pensez qu'il est responsable de l'échec de votre conteneur, contactez l'assistance et fournissez le message du journal dans votre demande d'assistance.

    L'assistance Google Cloud peut vous demander de tracer les appels système effectués par votre service pour diagnostiquer les appels système de niveau inférieur qui ne sont pas affichés dans les journaux Cloud Logging.

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

Il s'agit simplement d'un avertissement qui n'a aucune incidence sur votre service. Cet avertissement apparaît, car 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. Vous pouvez éventuellement passer à l'environnement d'exécution de deuxième génération si vous ne souhaitez pas afficher ces avertissements dans vos journaux.

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

L'une des erreurs suivantes se produit lors de la diffusion :

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

Pour remédier à ce problème :

Pour modifier la valeur de la variable d'environnement et résoudre le problème, définissez ENV SPARK_LOCAL_IP="127.0.0.1" dans votre fichier Dockerfile. Dans Cloud Run, si la variable SPARK_LOCAL_IP n'est pas définie, elle sera définie par défaut sur son équivalent IPv6 plutôt que sur le localhost. Notez qu'il n'est pas possible de définir RUN export SPARK_LOCAL_IP="127.0.0.1" au moment de l'exécution et que Spark fonctionnera comme si cette option n'était pas définie.

Mapper les domaines personnalisés

Le domaine personnalisé est bloqué dans l'état de provisionnement des certificats.

L'une des erreurs suivantes se produit lorsque vous essayez de mapper 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 :

  • 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.
  • 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 Google Admin Toolbox Dig.

    Les enregistrements DNS dans votre bureau d'enregistrement de noms de domaine doivent correspondre à ceux que la console Google Cloud vous invite à ajouter.

  • Confirmez que la racine du domaine est validée dans votre compte à l'aide de l'une des méthodes suivantes :

    • Suivez les instructions pour ajouter des propriétaires de domaine validés et vérifiez que votre compte est répertorié en tant que Propriétaire confirmé.
    • Accédez à l'URL suivante :

      https://www.google.com/webmasters/verification/details?domain=ROOT_DOMAIN
      
  • 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
    

API Admin

La fonctionnalité n'est pas compatible dans l'étape de lancement déclarée.

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 de l'étape de lancement.

Pour résoudre ce problème, annotez la ressource avec la valeur run.googleapis.com/launch-stage de BETA dans la requête si une fonctionnalité bêta est utilisée.

L'exemple suivant ajoute une annotation de l'étape de lancement à une requête de service :

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

Résoudre les problèmes liés au système de fichiers réseau

Apprenez-en plus sur l'utilisation des systèmes de fichiers réseau.

Impossible d'accéder aux fichiers via NFS

Error Solution recommandée
mount.nfs: Protocol not supported Certaines images de base, par exemple debian et adoptopenjdk/openjdk11, ne contiennent pas de 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, vérifiez 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.