Résoudre les problèmes d'extraction d'images

Cette page vous aide à résoudre les problèmes liés au processus d'extraction d'images dans Google Kubernetes Engine (GKE). Si vous utilisez le streaming d'image, consultez plutôt Dépanner le streaming d'image. Cette page se concentre sur les extractions d'images standards.

Cette page s'adresse aux développeurs d'applications qui souhaitent s'assurer que leurs applications sont déployées correctement, ainsi qu'aux administrateurs et opérateurs de plate-forme qui souhaitent comprendre la cause première des échecs d'extraction d'images et vérifier la configuration de la plate-forme. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Trusted Cloud by S3NS , consultez Rôles utilisateur et tâches courantes de GKE.

Le processus d'extraction d'images permet à Kubernetes, et donc à GKE, de récupérer des images de conteneurs à partir d'un registre. Lorsqu'un pull d'image échoue, vous pouvez constater un ralentissement de votre application, voire son dysfonctionnement.

Pour déterminer si les extractions d'images sont à l'origine du dysfonctionnement de votre application, cette page vous aide à diagnostiquer l'échec de l'extraction d'images en trouvant et en comprenant les messages d'erreur pertinents. Vous apprendrez ensuite à résoudre les causes courantes d'échec de l'extraction d'images :

• Paramètres d'authentification : votre cluster ne dispose pas des autorisations nécessaires pour accéder au registre d'images de conteneurs.
• Connectivité réseau : votre cluster ne peut pas se connecter au registre en raison de problèmes DNS, de règles de pare-feu ou d'un manque d'accès à Internet dans les clusters qui utilisent l'isolation réseau.
• Image introuvable dans le registre : le nom ou le tag de l'image spécifiés sont incorrects, l'image a été supprimée ou le registre n'est pas disponible.
• Limites de performances : une taille d'image importante, des E/S de disque lentes ou une congestion du réseau peuvent entraîner des extractions lentes ou des délais d'attente.
• Architecture d'image incompatible : l'image a été créée pour une architecture de processeur différente de celle de votre pool de nœuds GKE.
• Versions de schéma incompatibles : il est possible que vous utilisiez containerd 2.0 ou version ultérieure avec un schéma Docker v1, qui n'est pas compatible.

Si vous avez déjà vu un message d'événement spécifique, recherchez-le sur cette page et suivez les étapes de dépannage indiquées. Si vous n'avez pas reçu de message, suivez les instructions des sections ci-dessous dans l'ordre. Si le problème persiste, contactez Cloud Customer Care.

Comprendre les extractions d'images

Avant de commencer le dépannage, il est utile d'en savoir un peu plus sur le cycle de vie d'une image et sur les endroits où vous pouvez héberger vos images.

Cycle de vie des images

Lorsque vous créez un pod, le kubelet reçoit la définition du pod, qui inclut la spécification de l'image. Le kubelet a besoin de cette image pour pouvoir exécuter un conteneur basé sur l'image. Avant d'extraire l'image, le kubelet vérifie si elle est présente dans le moteur d'exécution du conteneur. Le kubelet vérifie également la stratégie d'extraction d'images du pod. Si l'image ne se trouve pas dans le cache de l'environnement d'exécution du conteneur ou si la stratégie d'extraction d'images l'exige, le kubelet demande à l'environnement d'exécution du conteneur (containerd) d'extraire l'image spécifiée du registre. Un échec d'extraction d'image empêche le démarrage du conteneur dans le pod.

Une fois l'image extraite, l'environnement d'exécution du conteneur décompresse l'image pour créer un système de fichiers de base en lecture seule pour le conteneur. Le moteur d'exécution du conteneur stocke cette image, qui reste présente tant que des conteneurs en cours d'exécution y font référence. Si aucun conteneur en cours d'exécution ne fait référence à une image, celle-ci devient éligible au ramasse-miettes et le kubelet la supprime à terme.

Options d'hébergement d'images

Nous vous recommandons d'utiliser l'une des options suivantes pour héberger vos images :

• Artifact Registry : Artifact Registry est le gestionnaire de packages entièrement géré de Google. Artifact Registry s'intègre étroitement à d'autres services Trusted Cloud by S3NSet offre un contrôle des accès précis. Pour en savoir plus, consultez Utiliser des images de conteneurs dans la documentation Artifact Registry.

• Registre auto-hébergé : un registre auto-hébergé vous offre plus de contrôle, mais vous devez également le gérer. Envisagez cette option si vous avez des besoins spécifiques en termes de conformité ou de sécurité qu'Artifact Registry ne peut pas satisfaire.

Diagnostiquer un échec d'extraction d'image

Pour diagnostiquer les échecs d'extraction d'images, effectuez les investigations détaillées dans les sections suivantes :

1. Afficher l'état et les événements du pod
2. Comprendre la signification des états
3. Utilisez les messages d'événement pour identifier la cause de l'échec de l'extraction d'image.
4. Affichez les journaux de l'explorateur de journaux.

Afficher l'état et les événements du pod

Pour vous aider à vérifier qu'un pull d'image a échoué, GKE enregistre les états suivants pour les pods :

• ImagePullBackOff
• ErrImagePull
• ImageInspectError
• InvalidImageName
• RegistryUnavailable
• SignatureValidationFailed

ImagePullBackOff et ErrImagePull sont les états les plus courants.

En plus de ces états, les événements Kubernetes vous aident à identifier la cause des échecs d'extraction d'images.

Pour confirmer que l'extraction de votre image échoue, recherchez les messages d'état, puis lisez les messages d'événement en sélectionnant l'une des options suivantes :

Comprendre la signification des états

Pour mieux comprendre la signification des différents états, consultez les descriptions suivantes :

• ImagePullBackOff : le kubelet n'a pas réussi à extraire l'image, mais il continuera à réessayer avec un délai croissant (ou délai avant nouvelle tentative) pouvant aller jusqu'à cinq minutes.
• ErrImagePull : erreur générale et irrécupérable lors du processus d'extraction de l'image.
• ImageInspectError : l'environnement d'exécution du conteneur a rencontré un problème lors de la tentative d'inspection de l'image du conteneur.
• InvalidImageName : le nom de l'image de conteneur spécifié dans la définition de votre pod n'est pas valide.
• RegistryUnavailable : le registre n'est pas accessible. Il s'agit généralement d'un problème de connectivité réseau.
• SignatureValidationFailed : la signature numérique de l'image du conteneur n'a pas pu être validée.

Utiliser les messages d'événement pour trouver la cause de l'échec de l'extraction d'image

Le tableau suivant répertorie les messages d'événement liés aux échecs d'extraction d'images et les étapes de dépannage à suivre si vous rencontrez l'un de ces messages.

Les messages liés aux échecs d'extraction d'images sont souvent précédés du préfixe suivant :

Failed to pull image "IMAGE_ADDRESS": rpc error: code = CODE = failed to pull and unpack image "IMAGE_ADDRESS": failed to resolve reference "IMAGE_ADDRESS":

Ce message inclut les valeurs suivantes :

• IMAGE_ADDRESS : adresse complète de l'image. Exemple : us-west1-docker.pkg.dev/my-project/my-repo/test:staging.
• CODE : code d'erreur associé au message du journal. Par exemple, NotFound ou Unknown.

Certaines causes d'échec d'extraction d'image n'ont pas de message d'événement associé. Si vous ne voyez aucun des messages d'événement du tableau ci-dessous, mais que vous rencontrez toujours des problèmes d'extraction d'images, nous vous recommandons de continuer à lire le reste de la page.

Afficher les journaux de l'explorateur de journaux

Pour examiner l'historique des événements d'extraction d'images ou corréler les échecs d'extraction d'images avec l'activité d'autres composants, consultez les journaux avec l'explorateur de journaux :

1. Dans la console Trusted Cloud , accédez à la page Explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans le volet "Requête", saisissez la requête suivante :

   log_id("events")
   resource.type="k8s_pod"
   resource.labels.cluster_name="CLUSTER_NAME"
   jsonPayload.message=~"Failed to pull image"
   

   Remplacez CLUSTER_NAME par le nom du cluster sur lequel s'exécute le pod présentant des erreurs d'extraction d'image.

3. Cliquez sur Exécuter la requête et examinez les résultats.

Examiner les paramètres d'authentification

Les sections suivantes vous aident à vérifier que votre environnement GKE dispose des paramètres d'authentification appropriés pour extraire des images du dépôt.

Pour vérifier si des problèmes d'authentification sont à l'origine d'un problème d'extraction d'image, effectuez les investigations décrites dans les sections suivantes :

1. Vérifiez l'accès à l'image.
2. Vérifiez la configuration imagePullSecret et la spécification de déploiement.
3. Vérifiez que le compte de service du nœud est actif.
4. Vérifier le champ d'application de l'accès du nœud au dépôt Artifact Registry privé
5. Vérifiez les paramètres de VPC Service Controls pour accéder à Artifact Registry.

Vérifier l'accès à l'image

Si vous rencontrez une erreur d'extraction d'image 403 Forbidden, vérifiez que les composants requis peuvent accéder à l'image de conteneur.

La méthode permettant de valider et d'appliquer les rôles nécessaires pour accorder l'accès requis diffère selon le type de dépôt dans lequel vos images sont stockées. Pour valider et accorder l'accès, sélectionnez l'une des options suivantes :

Vérifier la configuration imagePullSecret et la spécification de déploiement

Si vous utilisez un imagePullSecret, assurez-vous d'avoir créé un secret contenant les identifiants d'authentification pour extraire les images et que tous les déploiements spécifient le secret que vous avez défini. Pour en savoir plus, consultez Spécifier des secrets imagePullSecrets sur un pod dans la documentation Kubernetes.

Vérifier l'état actif du compte de service du nœud

Si vous rencontrez une erreur d'extraction d'image 401 Unauthorized, vérifiez que le compte de service du nœud est actif. Même si les autorisations sont correctement configurées, cette erreur se produira si le compte est désactivé. Pour vérifier l'état actif du compte de service du nœud, sélectionnez l'une des options suivantes :

Si le compte de service est désactivé, activez-le.

Vérifier le champ d'application de l'accès du nœud au dépôt Artifact Registry privé

Si vous stockez votre image de conteneur dans un dépôt Artifact Registry privé, il est possible que votre nœud ne dispose pas du niveau d'accès approprié. Dans ce cas, vous remarquerez peut-être une erreur d'extraction d'image 401 Unauthorized.

Pour vérifier le niveau d'accès et l'accorder si nécessaire, procédez comme suit :

1. Identifiez le nœud exécutant le pod:

   kubectl describe pod POD_NAME | grep "Node:"
   

   Remplacez POD_NAME par le nom du pod qui rencontre un échec d'extraction d'image.

2. Vérifiez que le nœud que vous avez identifié à l'étape précédente dispose du champ d'application de stockage approprié :

   gcloud compute instances describe NODE_NAME \
       --zone="COMPUTE_ZONE" \
       --format="flattened(serviceAccounts[].scopes)"
   

   Remplacez les éléments suivants :

   • NODE_NAME : nom du nœud que vous avez identifié à l'étape précédente.
   • COMPUTE_ZONE : zone Compute Engine à laquelle appartient le nœud.

   La sortie doit contenir au moins l'un des niveaux d'accès suivants :

   • serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/devstorage.read_only
   • serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/cloud-platform

   Si le nœud ne contient pas l'un de ces champs d'application, l'extraction de l'image échoue.

3. Recréez le pool de nœuds auquel le nœud appartient avec un champ d'application suffisant. Étant donné que vous ne pouvez pas modifier les nœuds existants, vous devez les recréer avec le champ d'application approprié.

   Nous vous recommandons de créer le pool de nœuds avec le champ d'application gke-default. Ce champ d'application donne accès aux champs d'application suivants :

   • https://www.googleapis.com/auth/devstorage.read_only
   • https://www.googleapis.com/auth/logging.write
   • https://www.googleapis.com/auth/monitoring
   • https://www.googleapis.com/auth/service.management.readonly
   • https://www.googleapis.com/auth/servicecontrol
   • https://www.googleapis.com/auth/trace.append

   Si le champ d'application gke-default ne convient pas, accordez au pool de nœuds le champ d'application devstorage.read_only, qui permet d'accéder aux données en lecture seule.

   gke-default

   Créez un pool de nœuds avec le champ d'application gke-default :

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --scopes="gke-default"
   

   Remplacez les éléments suivants :

   • NODE_POOL_NAME : nom du nouveau pool de nœuds.
   • CLUSTER_NAME : nom de votre cluster existant.
   • CONTROL_PLANE_LOCATION : emplacement Compute Engine du plan de contrôle de votre cluster. Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux.

   devstorage.read_only

   Créez un pool de nœuds avec le champ d'application devstorage.read_only :

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --scopes="https://www.googleapis.com/auth/devstorage.read_only"
   

   Remplacez les éléments suivants :

   • NODE_POOL_NAME : nom du nouveau pool de nœuds.
   • CLUSTER_NAME : nom de votre cluster existant.
   • CONTROL_PLANE_LOCATION : emplacement Compute Engine du plan de contrôle de votre cluster. Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux.

Vérifier les paramètres de VPC Service Controls pour accéder à Artifact Registry

Si vous utilisez VPC Service Controls, assurez-vous que les périmètres de service autorisent l'accès à Artifact Registry. Pour en savoir plus, consultez Protéger les dépôts dans un périmètre de service dans la documentation Artifact Registry.

Examiner la connectivité réseau

Lors de l'extraction d'une image, la connectivité réseau peut empêcher le processus de se terminer.

Pour vérifier si des problèmes de connectivité réseau sont à l'origine d'un problème d'extraction d'image, effectuez les investigations décrites dans les sections suivantes :

1. Examinez la résolution DNS.
2. Examinez la configuration de votre pare-feu.
3. Examinez la connectivité Internet des points de terminaison de registre externes.
4. Vérifiez si la connexion aux API Google expire.

Examiner la résolution DNS

Si une erreur d'extraction d'image server misbehaving s'affiche, la résolution DNS peut être à l'origine de l'échec de l'extraction d'image.

Pour examiner les problèmes de résolution DNS, essayez les solutions suivantes :

1. Résolvez les problèmes liés au serveur de métadonnées. Le serveur de métadonnées du nœud résout toutes les requêtes DNS. Tout problème lié à ce serveur peut perturber la résolution de noms, ce qui empêche la connexion au dépôt et l'extraction de l'image.
2. Si vous utilisez Cloud DNS pour la résolution DNS, assurez-vous que vos zones privées gérées Cloud DNS, vos zones de transfert, vos zones d'appairage et vos règles de réponse sont correctement configurées. Des erreurs de configuration dans ces domaines peuvent perturber la résolution DNS. Pour en savoir plus sur Cloud DNS, consultez Utiliser Cloud DNS pour GKE. Pour obtenir des conseils sur la résolution des problèmes liés à Cloud DNS dans GKE, consultez Résoudre les problèmes liés à Cloud DNS dans GKE.
3. Si vous utilisez kube-dns pour la résolution DNS, assurez-vous qu'il fonctionne correctement. Pour obtenir des conseils sur le dépannage de kube-dns, consultez Résoudre les problèmes liés à kube-dns dans GKE.
4. Si les nœuds du cluster ne disposent pas d'adresses IP externes (ce qui est courant si vous utilisez l'isolation réseau), activez l'accès privé à Google sur le sous-réseau utilisé par le cluster et assurez-vous de respecter les exigences réseau. Si vous utilisez Cloud NAT,Trusted Cloud by S3NS active automatiquement l'accès privé à Google.

Examiner la configuration de votre pare-feu

Lorsqu'un problème lié à votre pare-feu empêche l'extraction de votre image, le message d'erreur suivant peut s'afficher :

Failed to start Download and install k8s binaries and configurations

Diagnostiquer les problèmes liés à votre pare-feu

Si vous utilisez un cluster standard et que vous souhaitez vérifier si un problème lié à votre pare-feu est à l'origine de problèmes d'extraction d'images, procédez comme suit :

1. Utilisez SSH pour vous connecter au nœud qui rencontre des problèmes :

   gcloud compute ssh NODE_NAME --zone=ZONE_NAME
   

   Remplacez les éléments suivants :

   • NODE_NAME : nom du nœud.
   • ZONE_NAME : zone Compute Engine dans laquelle le nœud a été créé.

2. Envoyez les journaux les plus récents des services kube-node-installation.service et kube-node-configuration.service vers des fichiers texte nommés kube-node-installation_status.txt et kube-node-configuration_status.txt :

   systemctl status kube-node-installation.service > kube-node-installation_status.txt
   systemctl status kube-node-configuration.service > kube-node-configuration_status.txt
   

   Si ces journaux n'incluent pas d'informations sur l'échec de l'extraction de votre image, générez une copie complète des journaux :

   sudo journalctl -u kube-node-installation.service > kube-node-installation_logs.txt
   sudo journalctl -u kube-node-configuration.service > kube-node-configuration_logs.txt
   

3. Examinez le contenu des fichiers kube-node-installation_status.txt et kube-node-configuration_status.txt. Si i/o timeout s'affiche dans le résultat, le problème est probablement lié à votre pare-feu.

Résoudre les problèmes de configuration de votre pare-feu

Pour résoudre les problèmes liés à votre pare-feu, essayez les solutions suivantes :

1. Identifiez et corrigez les règles de pare-feu qui bloquent le trafic réseau. Par exemple, vous pouvez avoir une règle qui bloque le trafic vers le registre qui stocke votre image.

   1. Accédez aux journaux de flux VPC :

      1. Dans la console Trusted Cloud , accédez à la page Explorateur de journaux.

         Accéder à l'explorateur de journaux

      2. Dans le volet "Requête", saisissez la requête suivante :

         resource.type="gce_subnetwork"
         logName="projects/PROJECT_ID/logs/[compute.googleapis.com%2Fvpc_flows](http://compute.googleapis.com%2Fvpc_flows)"
         resource.labels.subnetwork_name="SUBNET_NAME",
         

         Remplacez les éléments suivants :

         • PROJECT_ID : ID de votre projet Trusted Cloud .
         • SUBNET_NAME : nom de votre sous-réseau.

         Pour en savoir plus, consultez Accéder aux journaux de flux à l'aide de requêtes dans la documentation VPC.

   2. Si vous identifiez des règles de pare-feu qui bloquent le trafic requis, mettez-les à jour.

2. Si les nœuds du cluster ne disposent pas d'adresses IP externes (ce qui est courant si vous utilisez l'isolation réseau), activez l'accès privé à Google sur le sous-réseau utilisé par le cluster et assurez-vous de respecter les exigences réseau. Si vous utilisez Cloud NAT,Trusted Cloud by S3NS active automatiquement l'accès privé à Google.

Examiner la connectivité Internet des points de terminaison de registre externes

Si la configuration de votre réseau dirige le trafic vers un point de terminaison de registre externe, il est possible que ce point de terminaison ne soit pas connecté à Internet. Lorsque le point de terminaison n'a pas accès, l'extraction d'image peut échouer et une erreur d'extraction d'image i/o timeout s'affiche.

Pour vérifier la connectivité réseau entre le point de terminaison du registre externe et le registre, utilisez ping ou traceroute :

ping REGISTRY_ENDPOINT

Ou

traceroute REGISTRY_ENDPOINT

Remplacez REGISTRY_ENDPOINT par le point de terminaison du registre. Cette valeur peut être un nom d'hôte ou une adresse IP.

Si vous constatez une erreur de connectivité, examinez les routes VPC :

1. Dans la console Trusted Cloud , accédez à Routes.

   Accéder à la page Routes

2. Examinez la colonne Priorité et assurez-vous que la route de priorité la plus élevée pointe vers une source ayant accès au registre. Les routes associées à des valeurs inférieures sont prioritaires.

Vérifiez si la connexion aux API Google expire.

Si vous utilisez l'isolation réseau, vous pouvez rencontrer une erreur de délai d'expiration de la connexion aux API et services Google, ce qui entraîne une erreur d'extraction d'image i/o timeout.

Cette erreur se produit, car vos nœuds n'ont pas pu accéder à l'une des API suivantes lorsqu'ils ont essayé d'extraire des images du registre :

• containerregistry.googleapis.com
• artifactregistry.googleapis.com

Pour vous assurer de pouvoir vous connecter aux API requises, essayez les solutions suivantes :

1. Activez l'accès privé à Google. Les nœuds sans adresse IP externe ont besoin de l'accès privé à Google pour accéder aux adresses IP externes des API et services Google.
2. Utilisez un domaine compatible.

3. Examinez vos règles de pare-feu :

   1. Dans la console Trusted Cloud , accédez à "Règles de pare-feu".

      Accéder aux stratégies de pare-feu

   2. Vérifiez si vous avez des règles qui bloquent le trafic TCP sortant sur le port 443 vers 199.36.153.4/30, 199.36.153.8/30 ou toute plage d'adresses IP utilisée par le domaine de votre choix pour les API et services Google. Les plages d'adresses IP 199.36.153.4/30 et 199.36.153.8/30 sont utilisées respectivement pour l'accès privé à Google et l'accès privé restreint à Google. Le trafic TCP sur le port 443 vers ces plages permet d'accéder aux API et services Google.

      Si vous trouvez l'une de ces règles, créez une règle de pare-feu de sortie pour autoriser ce trafic.

4. Si vous utilisez Artifact Registry, assurez-vous que votre environnement répond aux exigences pour l'utilisation d'Artifact Registry avec l'isolation réseau.

5. Vérifiez que des routes VPC sont configurées pour les adresses IP virtuelles (VIP) (199.36.153.4/30 ou 199.36.153.8/30) :

   1. Dans la console Trusted Cloud , accédez à "Réseaux VPC".

      Accéder aux réseaux VPC

   2. Dans la colonne Nom, cliquez sur default.

   3. Sur la page "Détails du réseau VPC", cliquez sur l'onglet Routes.

   4. Examinez le tableau des routes.

      Si votre réseau VPC contient une route par défaut (destination 0.0.0.0/0 ou ::0/0) et que le saut suivant de cette route est la passerelle Internet par défaut (Réseau par défaut), utilisez cette route pour que les adresses IP virtuelles accèdent aux API et services Google.

      Si vous avez remplacé une route par défaut par une route personnalisée dont le saut suivant n'est pas la passerelle Internet par défaut, respectez les exigences de routage pour les API et services Google en utilisant le routage personnalisé.

Déterminez pourquoi le kubelet ne trouve pas votre image.

Lorsque le kubelet ne trouve pas votre image, une erreur image not found peut s'afficher et des échecs d'extraction d'image peuvent se produire.

Pour aider le kubelet à trouver votre image, essayez les solutions suivantes :

1. Examinez le fichier manifeste de votre pod et assurez-vous que le nom et le tag de votre image sont correctement orthographiés. Toute faute d'orthographe ou erreur de mise en forme entraîne l'échec de l'extraction de l'image.
2. Vérifiez que l'image existe toujours dans le registre dans lequel vous l'avez stockée. Si le chemin d'accès au registre de l'image est complet, vérifiez qu'il existe dans le registre Docker que vous utilisez. Si vous ne fournissez que le nom de l'image, vérifiez le registre Docker Hub.
3. Si votre cluster utilise l'isolation du réseau, essayez les solutions suivantes :
   1. Activez l'accès privé à Google.
   2. Vérifiez que votre périmètre de service est correctement configuré.

Déterminer pourquoi les extractions d'images sont lentes ou arrivent à expiration

Si vous utilisez une image très volumineuse pour votre charge de travail GKE, l'extraction de l'image peut expirer et entraîner une erreur context cancelled. Bien que la taille des images ne soit pas limitée, l'erreur context cancelled indique souvent que la taille de l'image est la cause du problème.

Vous pouvez également remarquer que certaines extractions d'images ne génèrent pas d'erreur, mais prennent beaucoup plus de temps que d'habitude. Si vous souhaitez obtenir une référence pour vos temps d'extraction d'images habituels, consultez l'entrée de journal Successfully pulled image. Par exemple, le message de journal suivant indique que l'extraction de l'image a pris 30,313387996 secondes :

Successfully pulled image "IMAGE_ADDRESS" in 30.313387996s.

Les délais d'attente et les extractions d'images lentes ont souvent les mêmes causes. Pour résoudre ces problèmes, essayez les solutions suivantes :

1. Vérifiez si le service est indisponible. Si vous n'avez remarqué ce problème qu'au cours d'une période spécifique, vérifiez s'il y a eu des Trusted Cloud by S3NS interruptions de service.
2. Vérifiez les performances du disque. Des E/S disque lentes peuvent augmenter les temps d'extraction des images. Envisagez de passer à des disques persistants avec SSD (pd-ssd) ou d'utiliser des disques plus volumineux pour améliorer les performances. Pour obtenir d'autres conseils, consultez Résoudre les problèmes de performances de disque.
3. Réduisez la taille de l'image. Par exemple, vous pouvez déplacer certaines données des images de conteneur vers des volumes persistants.
4. Profitez de la mise en cache des images pour réduire le temps de démarrage des pods. GKE met en cache les images sur les nœuds. Lors de l'extraction d'une image, l'environnement d'exécution du conteneur ne télécharge que les calques qui ne sont pas déjà présents dans le cache. Pour maximiser l'efficacité de ce mécanisme de mise en cache et minimiser les temps d'extraction d'images, structurez votre fichier Dockerfile de manière à placer les parties de l'image qui changent fréquemment (comme le code de votre application) vers la fin du fichier et utilisez des images de base plus petites.
5. Activez le streaming d'images. Cette fonctionnalité peut accélérer le démarrage des pods et le téléchargement des images. Pour en savoir plus, consultez Utiliser le streaming d'image pour extraire des images de conteneur.
6. Assurez-vous que le compte de service par défaut dispose des autorisations nécessaires. La modification des rôles attribués au compte de service par défaut peut perturber les charges de travail, y compris l'extraction d'images. Pour obtenir d'autres conseils, consultez Identifier les clusters avec des comptes de service de nœud auxquels il manque des autorisations critiques.
7. Examinez les configurations de proxy. Si un proxy existe entre votre cluster GKE et un dépôt non géré par Google, cela peut entraîner une latence.
8. Vérifiez les logiciels tiers. Certains logiciels tiers peuvent interférer avec les extractions d'images. Déterminez si des outils récemment installés peuvent être à l'origine de conflits.

Vérifier que le fichier manifeste de l'image utilise la bonne architecture

Si l'image que vous essayez d'extraire a été créée pour une architecture informatique différente de celle utilisée par vos pools de nœuds, l'extraction de l'image échoue.

Pour vérifier si le fichier manifeste de votre image utilise la bonne architecture, procédez comme suit :

1. Pour vérifier l'architecture utilisée par votre image, consultez son fichier manifeste. Par exemple, pour afficher une image Docker, exécutez la commande suivante :

   docker manifest inspect --verbose IMAGE_NAME
   

   Remplacez IMAGE_NAME par le nom de l'image que vous souhaitez afficher.

   Le résultat ressemble à ce qui suit :

   ...
   "Platform": {
             "architecture": "amd64",
             "os": "linux"
     }
   ...
   

   Dans cet exemple, l'architecture compatible est amd64.

2. Vérifiez le type de machine utilisé par vos pools de nœuds :

   gcloud container node-pools list --cluster CLUSTER_NAME --location CONTROL_PLANE_LOCATION
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME : nom du cluster sur lequel s'exécute le pod présentant des erreurs d'extraction d'image.
   • CONTROL_PLANE_LOCATION : emplacement Compute Engine du plan de contrôle de votre cluster. Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux.

   Le résultat ressemble à ce qui suit :

   NAME: example-node-pool
   MACHINE_TYPE: e2-standard-2
   DISK_SIZE_GB: 100
   NODE_VERSION: 1.30.8-gke.1162000
   

   Dans cet exemple, le type de machine est e2-standard-2.

3. Comparez les valeurs des champs architecture et MACHINE_TYPE, et assurez-vous qu'elles sont compatibles. Par exemple, si l'image possède une architecture amd64, elle sera compatible avec un pool de nœuds qui utilise e2-standard-2 comme type de machine. Toutefois, si le pool de nœuds utilisé est t2a-standard-1 (un type de machine basé sur Arm), ce type de machine entraînerait un échec.

4. Si l'architecture de l'image n'est pas compatible avec le type de machine du pool de nœuds, recompilez l'image pour cibler l'architecture requise.

Vérifier la compatibilité de la version du schéma d'image

L'utilisation de containerd 2.0 avec une image de schéma Docker v1 entraîne l'échec des extractions d'images, car containerd 2.0 a supprimé la compatibilité avec l'extraction d'images Docker de schéma 1 dans GKE 1.33. Lorsque ce problème est à l'origine de l'échec de l'extraction de votre image, le message d'erreur suivant peut s'afficher :

Failed to get converter for "IMAGE_ADDRESS": Pulling Schema 1 images have been deprecated and disabled by default since containerd v2.0. As a workaround you may set an environment variable `CONTAINERD_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE=1`, but this will be completely removed in containerd v2.1.

Pour résoudre ce problème, identifiez et migrez ces images en suivant les instructions de la section Migrer depuis des images Docker de schéma 1.

Étapes suivantes

• Si vous ne trouvez pas de solution à votre problème dans la documentation, consultez Obtenir de l'aide pour obtenir une assistance supplémentaire, y compris des conseils sur les sujets suivants :

  • Ouvrez une demande d'assistance en contactant le service client Google Cloud.
  • Obtenir de l'aide de la communauté en posant des questions sur Stack Overflow et en utilisant le tag google-kubernetes-engine pour rechercher des problèmes similaires. Vous pouvez également rejoindre le canal Slack #kubernetes-engine pour obtenir de l'aide auprès de la communauté.
  • Signaler des bugs ou demander des fonctionnalités à l'aide de l'outil public de suivi des problèmes.