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

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

Pour les autres problèmes non listés ci-dessous, vérifiez s'il s'agit d'un problème connu.

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_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 Service Controls. 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 :

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

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

L'erreur suivante se produit lors de la diffusion :

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

HTTP 403 : le trafic entrant du client est refusé

L'erreur suivante se produit lors de la diffusion :

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

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

  • Le projet qui appelle le service se trouve dans un périmètre VPC Service Controls et n'est pas autorisé à appeler des services en dehors de ce périmètre.

  • Le projet propriétaire du service se trouve dans un périmètre VPC Service Controls et les règles de VPC Service Controls refusent le trafic run.googleapis.com/HttpIngress émanant de l'adresse IP ou de l'identité de l'appelant. Pour vérifier si c'est le cas, 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 ou non mettre à jour vos règles VPC Service Controls.

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. Si le projet se trouve dans un périmètre VPC Service Controls, vérifiez si ses paramètres d'entrée entraînent un cas de non-respect des règles, comme décrit dans la section précédente, Le trafic entrant du client est refusé.

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

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

  4. Inspectez les endroits où votre logique d'application est susceptible de renvoyer des codes d'erreur 404.

  5. 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. 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 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 :

  • Vérifiez Cloud Logging : 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.

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