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

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

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'images, consultez plutôt la section Résoudre les problèmes liés au streaming d'images. 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 correctement déployées, ainsi qu'aux administrateurs et opérateurs de plate-forme qui souhaitent comprendre l'origine des échecs de récupération 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 Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Le processus d'extraction d'images permet à Kubernetes, et donc à GKE, de récupérer des images de conteneur à partir d'un registre. Lorsqu'une extraction d'image échoue, vous pouvez constater une lenteur dans votre application ou son incapacité à fonctionner.

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 recherchant et en comprenant les messages d'erreur pertinents. Vous apprendrez ensuite à résoudre les causes courantes d'échec de la récupération d'images suivantes:

• Paramètres d'authentification: votre cluster ne dispose pas des autorisations nécessaires pour accéder au registre des images de conteneur.
• 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é est incorrect, l'image a été supprimée ou le registre est indisponible.
• Limites de performances: une taille d'image importante, des E/S disque lentes ou une congestion du réseau peuvent entraîner des extractions lentes ou des délais avant expiration.
• Architecture d'image incompatible: l'image a été compilée pour une architecture de processeur différente de celle de votre pool de nœuds GKE.
• Versions de schéma incompatibles: vous utilisez peut-être containerd 2.0 ou une 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 vu de message, suivez les sections suivantes dans l'ordre. Si le problème persiste, contactez l'assistance Cloud Customer Care.

Comprendre les extractions d'images

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

Cycle de vie des images

Lorsque vous créez un pod, 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 de récupérer l'image, le kubelet vérifie l'environnement d'exécution du conteneur pour voir si l'image est présente. Kubelet vérifie également la stratégie d'extraction d'images du pod. Si l'image ne figure 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 de l'extraction d'image empêche le démarrage du conteneur dans le pod.

Une fois l'extraction de l'image réussie, 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. L'environnement d'exécution du conteneur stocke cette image, qui reste présente tant que les conteneurs en cours d'exécution la référencent. Si aucun conteneur en cours d'exécution ne fait référence à une image, celle-ci peut être soumise à la récupération des objets inutilisés et le kubelet finit par la supprimer.

Options d'hébergement d'images

Nous vous recommandons d'héberger vos images sur l'une des plates-formes suivantes:

• Artifact Registry: Artifact Registry est le gestionnaire de paquets entièrement géré de Google. Artifact Registry s'intègre étroitement aux autres services Google Cloudet offre un contrôle précis des accès. Pour en savoir plus, consultez la section 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 matière de conformité ou de sécurité que le dépôt d'artefacts ne peut pas répondre.

Diagnostiquer l'échec de l'extraction d'image

Pour diagnostiquer les échecs de récupération d'images, effectuez les investigations décrites dans les sections suivantes:

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

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

Pour vous aider à vérifier qu'une extraction 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 à trouver la cause des échecs d'extraction d'images.

Pour vérifier si l'extraction d'images é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 d'essayer avec un délai (ou temps de latence) croissant pouvant aller jusqu'à cinq minutes.
• ErrImagePull: erreur générale non récupérable lors du processus de récupération d'image.
• ImageInspectError: l'environnement d'exécution du conteneur a rencontré un problème lors de l'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 identifier la cause de l'échec de l'extraction d'image

Le tableau suivant répertorie les messages d'événement liés aux échecs de récupération 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 de journal. Par exemple, NotFound ou Unknown.

Certaines causes d'échecs d'extraction d'images n'ont pas de message d'événement associé. Si aucun des messages d'événement du tableau suivant ne s'affiche, mais que vous rencontrez toujours des problèmes de récupération d'images, nous vous recommandons de lire la suite de la page.

Afficher les journaux de l'explorateur de journaux

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

1. Dans Google Cloud Console, accédez à la page Explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans le volet de 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 de récupération 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 entraînent un problème de récupération d'image, effectuez les investigations décrites dans les sections suivantes:

1. Vérifiez l'accès à l'image.
2. Vérifiez la configuration de imagePullSecret et la spécification de déploiement.
3. Vérifier le champ d'application de l'accès du nœud pour le dépôt Artifact Registry privé
4. 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 du conteneur.

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

Vérifier la configuration de 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 des images et que tous les déploiements spécifient le secret que vous avez défini. Pour en savoir plus, consultez la section Spécifier imagePullSecrets sur un pod dans la documentation Kubernetes.

Vérifier le champ d'application de l'accès du nœud pour le 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 champ d'application approprié. Dans ce cas, vous pouvez remarquer une erreur de récupération 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 une erreur de récupération 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 le nœud appartient.

   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. 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 permet d'accéder 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 n'est pas adapté, accordez au pool de nœuds le champ d'application devstorage.read_only, qui n'autorise l'accès qu'aux données en lecture.

   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 \
       --zone=COMPUTE_ZONE \
       --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.
   • COMPUTE_ZONE: zone Compute Engine à laquelle le nouveau pool de nœuds doit appartenir.

   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 \
       --zone=COMPUTE_ZONE \
       --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.
   • COMPUTE_ZONE: zone Compute Engine à laquelle le nouveau pool de nœuds doit appartenir.

Vérifier les paramètres 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 la section Protéger les dépôts dans un périmètre de service dans la documentation d'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 de récupération 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 de récupération d'image server misbehaving s'affiche, la résolution DNS peut être à l'origine de l'échec de la récupération d'image.

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

1. Résoudre 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 nom, empêchant la connexion au dépôt et entraînant l'échec de l'extraction d'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. Les erreurs de configuration dans ces domaines peuvent perturber la résolution DNS. Pour en savoir plus sur Cloud DNS, consultez la page Utiliser Cloud DNS pour GKE. Pour obtenir des conseils sur la résolution des problèmes liés à Cloud DNS dans GKE, consultez la page 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 la page Résoudre les problèmes de 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 conditions requises pour le réseau. Si vous utilisez Cloud NAT,Google Cloud active automatiquement l'accès privé à Google.

Examiner la configuration de votre pare-feu

Lorsqu'un problème avec votre pare-feu entraîne l'échec de l'extraction de l'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 avec votre pare-feu entraîne des problèmes de récupération 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 dans 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 le moment où l'extraction de votre image a échoué, 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 la sortie, 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éder aux journaux de flux VPC:

      1. Dans Google Cloud Console, accédez à la page Explorateur de journaux.

         Accéder à l'explorateur de journaux

      2. Dans le volet de 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 Google Cloud
         • SUBNET_NAME : nom de votre sous-réseau.

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

   2. Si vous trouvez 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 conditions requises pour le réseau. Si vous utilisez Cloud NAT,Google Cloud active automatiquement l'accès privé à Google.

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

Si votre configuration réseau dirige le trafic via un point de terminaison de registre externe, ce point de terminaison peut manquer de connectivité Internet. Lorsque le point de terminaison n'a pas accès à l'image, l'extraction de l'image peut échouer et une erreur d'extraction d'image i/o timeout s'affiche.

Pour vérifier la connectivité réseau du point de terminaison du registre externe au 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 Google Cloud, accédez à la page Routes.

   Accéder à la page Routes

2. Examinez la colonne Priorité et assurez-vous que le chemin d'accès de priorité la plus élevée mène à une source ayant accès au Registre. Les routes associées à des valeurs inférieures sont prioritaires.

Vérifier si la connexion aux API Google expire

Si vous utilisez l'isolation réseau, vous risquez de rencontrer une erreur où la connexion aux API et services Google expire, ce qui entraîne une erreur de récupération d'image i/o timeout.

Cette erreur se produit parce que vos nœuds n'ont pas pu atteindre 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 adresses IP externes 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 Google Cloud, accédez à "Règles d'administration".

      Accéder à la page "Stratégies de pare-feu"

   2. Vérifiez si vous avez des règles qui bloquent le trafic TCP sortant sur le port 443 à 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 limité à Google. Le trafic TCP sur le port 443 vers ces plages est destiné à 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 requises pour utiliser Artifact Registry avec l'isolation réseau.

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

   1. Dans la console Google 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 la table 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 (Network default), utilisez cette route pour que les adresses IP virtuelles puissent accéder 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, répondez aux exigences de routage pour les API et services Google en utilisant le routage personnalisé.

Déterminer 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 l'extraction de l'image peut échouer.

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 de votre image et de votre balise d'image sont orthographiés correctement. Toute erreur d'orthographe ou de mise en forme entraîne l'échec de l'extraction d'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 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 l'extraction d'images est lente ou expire

Si vous utilisez une image très volumineuse pour votre charge de travail GKE, l'extraction de l'image peut expirer et provoquer une erreur context cancelled. Bien que les images n'aient pas de limite de taille définie, l'erreur context cancelled indique souvent que la taille de l'image est la cause.

Vous remarquerez peut-être également que les extractions d'images ne sont pas bloquées, mais qu'elles prennent beaucoup plus de temps que d'habitude. Si vous souhaitez obtenir une référence des temps d'extraction d'images réguliers, 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 avant expiration et les extractions d'images lentes partagent de nombreuses causes. Pour résoudre ces problèmes, essayez les solutions suivantes:

1. Vérifiez si des pannes sont en cours. Si vous n'avez remarqué ce problème que pendant une période spécifique, vérifiez s'il y a eu des Google Cloud pannes.
2. Vérifiez les performances des disques. Des E/S disque lentes peuvent augmenter les temps d'extraction des images. Envisagez de passer aux disques persistants avec SSD (pd-ssd) ou d'utiliser des disques plus volumineux pour améliorer les performances. Pour obtenir des conseils supplémentaires, consultez la section Résoudre les problèmes de performances de disque.
3. Réduire la taille de l'image. Par exemple, vous pouvez peut-être déplacer certaines données des images de conteneur vers des volumes persistants.
4. Profitez de la mise en cache des images pour accélérer le démarrage des pods. GKE met en cache les images sur les nœuds. Lors d'une extraction d'image, l'environnement d'exécution du conteneur ne télécharge que les couches qui ne sont pas déjà présentes dans le cache. Pour maximiser l'efficacité de ce mécanisme de mise en cache et réduire les temps d'extraction d'images, structurez votre 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 du pod et le téléchargement des images. Pour en savoir plus, consultez la section 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. Modifier les rôles attribués au compte de service par défaut peut perturber les charges de travail, y compris les extractions d'images. Pour obtenir des conseils supplémentaires, consultez la section Identifier les clusters dont les comptes de service de nœuds ne disposent pas d'autorisations critiques.
7. Examinez les configurations de proxy. Si un proxy existe entre votre cluster GKE et un dépôt géré par un tiers, il peut entraîner une latence.
8. Vérifiez les logiciels tiers. Certains logiciels tiers peuvent interférer avec l'extraction d'images. Vérifiez si des outils récemment installés peuvent provoquer des conflits.

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

Si l'image que vous essayez de récupérer a été créée pour une architecture informatique différente de celle utilisée par vos pools de nœuds, la récupération de l'image échoue.

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

1. Pour vérifier l'architecture utilisée par votre image, consultez le fichier manifeste de votre image. 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 LOCATION
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME: nom du cluster sur lequel s'exécute le pod présentant des erreurs de récupération d'image.
   • LOCATION: région ou zone Compute Engine dans laquelle le nœud a été créé. Par exemple, us-central1-a ou us-central1.

   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 que les deux valeurs sont compatibles. Par exemple, si l'image a une architecture amd64, elle est compatible avec un pool de nœuds qui utilise e2-standard-2 comme type de machine. Toutefois, si le pool de nœuds utilisait t2a-standard-1 (un type de machine basé sur Arm), ce type de machine entraînerait une défaillance.

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é des versions de schéma d'image

L'utilisation de containerd 2.0 avec une image de schéma Docker v1 entraîne l'échec de l'extraction d'images, car containerd 2.0 a supprimé la prise en charge de l'extraction d'images Docker de schéma 1 dans GKE 1.33. Lorsque ce problème est à l'origine de l'échec de la récupération d'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 à partir d'images Docker de schéma 1.

Étape suivante

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.