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

Cette page vous explique comment résoudre les problèmes liés aux messages d'erreur et ceux liés à l'utilisation de Cloud Run.

Vous pouvez également consulter les problèmes existants ou signaler de nouveaux problèmes dans les outils publics de suivi des problèmes.

Pour les autres messages d'erreur non répertoriés sur cette page, consultez la page Problèmes connus.

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 Google 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 Google 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 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, 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_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.

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 :

  • Si elle est 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 Cloud Run du service destinataire, au format https://service-xyz.run.app.
      • Le service Cloud Run doit exiger une authentification.
      • Le service Cloud Run peut être appelé par l'URL Cloud Run ou via une URL d'équilibreur de charge.
    • L'ID client d'un ID client OAuth 2.0 de type application Web, au format nnn-xyz.apps.googleusercontent.com.
    • Une audience personnalisée configurée et utilisant les valeurs exactes fournies. Par exemple, si l'audience personnalisée est service.example.com, la valeur de la revendication d'audience (aud) doit également être service.example.com. Si l'audience personnalisée est https://service.example.com, la valeur de la revendication d'audience doit également être https://service.example.com.

  • L'outil jwt.io permet de vérifier les revendications d'un jeton JWT.

  • Si le format d'un jeton d'authentification n'est pas valide, une erreur 401 se produit. 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 se produit.

  • 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 afin d'acheminer le trafic de sortie, et que vous obtenez non valides, veillez à ajouter les hôtes suivants aux exceptions de proxy HTTP :

    • 169.254.* ou 169.254.0.0/16
    • *.google.internal

    Cette erreur 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 le job ou le service Cloud Run et le proxy HTTP sont hébergés dans différentes charges de travail Google Cloud, même si les bibliothèques clientes Google Cloud sont en mesure d'obtenir des identifiants, les jetons sont générés pour le compte de service attribué à la charge de travail du proxy HTTP, qui peut ne pas disposer des autorisations requises pour effectuer les opérations de l'API Google Cloud prévues. Dans ce cas, les jetons sont récupérés à partir de la vue du serveur de métadonnées de la charge de travail du proxy HTTP, et non de celui de Cloud Run.

    • Si le proxy HTTP n'est pas hébergé dans Google Cloud et que les requêtes du serveur de métadonnées sont acheminées à l'aide du proxy, les requêtes de jeton échouent et les opérations des API Google Cloud ne sont pas authentifiées.

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

L'erreur suivante peut ou non se trouver dans Cloud Logging avec resource.type = "cloud_run_revision" :

The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header

L'erreur suivante est présente dans la réponse HTTP renvoyée au client :

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

Pour résoudre ce problème lorsque l'erreur Cloud Logging resource.type = "cloud_run_revision" est présente :

  • 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 les rôles "Administrateur Cloud Run" (roles/run.admin) et "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 n'incluent pas de jeton d'authentification, ou s'ils incluent 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.

Pour résoudre ce problème lorsque l'erreur Cloud Logging resource.type = "cloud_run_revision" n'est pas présente :

  • Un code d'état 403 peut être renvoyé lorsqu'un service est configuré avec l'entrée sur All, mais qu'il a été bloqué en raison de VPC Service Controls. Consultez la section suivante sur les erreurs 404 pour en savoir plus sur le dépannage des refus de VPC Service Controls.

HTTP 403 : erreur lors de l'accès au service à partir d'un navigateur Web

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

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

Lorsque vous appelez un service Cloud Run à partir d'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, choisissez l'une des solutions suivantes :

  • 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.

  • En guise de solution temporaire, vous pouvez accéder à votre service via un navigateur Web à l'aide du proxy Cloud Run dans Google Cloud CLI. Vous pouvez relayer un service en local à l'aide de la commande suivante :

    gcloud run services proxy SERVICE --project PROJECT-ID

    Après avoir exécuté cette commande, 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 des services privés.

  • Autorisez les appels non authentifiés à votre service. C'est utile pour les tests ou lorsque votre service est une API publique ou un site Web.

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 :

  1. Vérifiez que l'URL que vous demandez est correcte en consultant 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 logique d'application est susceptible de renvoyer des codes d'erreur 404. Si votre application renvoie le jeton 404, celui-ci est visible dans Cloud Logging.

  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.

  4. Vérifiez que l'application ne renvoie pas de code d'erreur 404 lorsque vous l'exécutez localement.

Un objet 404 est renvoyé lorsque les paramètres d'entrée d'un service Cloud Run sont définis sur "Interne" ou "Interne et Cloud Load Balancing" et qu'une requête n'est pas compatible avec la restriction réseau spécifiée. Cela peut également se produire si l'URL run.app par défaut du service Cloud Run est désactivée et qu'un client tente d'accéder au service en utilisant cette URL run.app. Dans chaque scénario, la requête n'atteint pas le conteneur et l'erreur 404 n'apparaît pas dans Cloud Logging avec le filtre suivant :

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

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, 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="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.

Une erreur 404 peut également s'afficher lorsque vous accédez à votre point de terminaison de service avec un équilibreur de charge à l'aide de l'environnement d'exécution 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 indiqué dans votre code source Python.

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. Elle peut également se produire 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

La cause de cette erreur peut être l'une des 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

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.

Notez qu'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.

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 501 : L'opération n'est pas mise en œuvre

L'erreur suivante se produit lors de la diffusion :

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

Ce problème se produit lorsque vous spécifiez une REGION incorrecte lors de l'appel de votre tâche Cloud Run. Par exemple, cette erreur peut se produire lorsque vous déployez un job dans la région asia-southeast1 et que vous appelez votre job à l'aide de southeast1-asia ou asia-southeast. Pour obtenir la liste des régions disponibles, consultez la page Emplacements Cloud Run.

HTTP 503 : les identifiants par défaut sont introuvables

L'erreur suivante se produit lors de la diffusion :

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

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

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 la page Configurer les identifiants par défaut de l'application.

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.

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

  • Utilisez Cloud Logging pour rechercher les erreurs de mémoire insuffisante 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.

  • Délais d'expiration au niveau de l'application : 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 :

  • Goulot d'étranglement sur le réseau en aval : dans certains cas, un code d'erreur 503 peut résulter indirectement 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 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.

  • Limite de requêtes entrantes vers un seul conteneur : il existe un problème connu où des taux de requêtes élevés par conteneur entraînent cette erreur 503. 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, essayez l'une des solutions suivantes :

    1. Activez le protocole HTTP/2 pour votre service et apportez les modifications nécessaires pour assurer la compatibilité HTTP/2.

    2. Évitez d'envoyer plus de 800 requêtes/seconde à une seule instance de conteneur en diminuant la simultanéité configurée. Utilisez l'équation suivante pour obtenir une estimation du taux de requêtes par instance de conteneur : requests/sec/container_instance ~= concurrency * (1sec / median_request_latency)

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.

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

  • 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 configurer votre application 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.
    • Vous pouvez utiliser 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, l'instance n'est pas arrêtée. Selon la manière dont l'application gère les erreurs de mémoire insuffisante au niveau de l'application, les requêtes peuvent se bloquer jusqu'à ce que le délai avant expiration de requête configuré soit atteint.

    • Si vous souhaitez que l'instance de conteneur s'arrête dans le scénario ci-dessus, 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.
    • Vous pouvez utiliser une vérification d'activité pour arrêter une instance qui renvoie des erreurs persistantes.

Connexion réinitialisée par l’homologue

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

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

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.

  • 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 configurer votre application 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 lorsqu'ils réutilisent une connexion déjà fermée. Si vous avez l'intention d'acheminer le trafic de sortie via un proxy HTTP, veillez à tenir compte de ce scénario en mettant en œuvre la validation de la connexion, les nouvelles tentatives et l'intervalle exponentiel entre les tentatives. Pour les pools de connexions, configurez des valeurs maximales pour l'âge des connexions, les connexions inactives et le délai d'inactivité des connexions.

Délais d'inactivité de la connexion

Des erreurs de latence ou l'une des erreurs suivantes se produisent en cas d'expiration du délai de connexion lors de l'envoi d'une requête à un hôte distant :

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

Ce type d'erreur se produit lorsqu'une application tente de créer une nouvelle connexion TCP avec un hôte distant et que l'établissement de la connexion prend trop de temps.

  • Si vous acheminez tout le trafic de sortie via un réseau VPC, à l'aide de connecteurs VPC ou de sortie VPC directe, vérifiez les points suivants :

    • Vous avez défini toutes les règles de pare-feu nécessaires pour autoriser le trafic entrant pour les connecteurs VPC.

    • Vos règles de pare-feu VPC autorisent 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.

    • Vous disposez 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.

  • Si vous utilisez un proxy HTTP pour acheminer tout le trafic de sortie de vos services ou jobs Cloud Run, assurez-vous que les hôtes distants sont 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 souhaitez acheminer le trafic de sortie HTTP via un proxy, assurez-vous de prendre en compte ce scénario en implémentant des nouvelles tentatives, un délai d'attente 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, veillez à ajouter 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

Les méthodes courantes pour configurer des exceptions de proxy HTTP pour la mise en réseau de sortie sont les suivantes :

  • 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. http.nonProxyHosts s'applique donc à la fois à HTTP et à HTTPS.
    • La propriété système http.nonProxyHosts n'est pas compatible avec la notation CIDR. Vous devez donc utiliser des expressions de correspondance de modèle.

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.

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 :

  • 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 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. Vous trouverez ci-dessous des exemples pour l'API REST v1 et l'API REST v2 :

L'exemple suivant ajoute une annotation de l'étape de lancement à une requête client avec JSON et l'API REST v1 :

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

L'exemple suivant ajoute une référence LaunchStage à une requête client avec JSON et l'API REST v2 :

  "launchStage": "BETA"

L'exemple suivant ajoute une 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

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.

La solution consiste à utiliser WebSockets ou HTTP/2.0, qui propagent les déconnexions des clients.

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

Erreur 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.