Résoudre les problèmes liés aux charges de travail déployées

Autopilot Standard

---

Cette page explique comment résoudre les erreurs liées aux charges de travail déployées dans Google Kubernetes Engine (GKE).

Pour obtenir des conseils plus généraux sur le dépannage de vos applications, consultez la section Dépannage des applications dans la documentation Kubernetes.

Toutes les erreurs: vérifier l'état du pod

En cas de problème avec les pods d'une charge de travail, Kubernetes met à jour l'état du pod avec un message d'erreur. Pour afficher ces erreurs, vérifiez l'état d'un pod à l'aide de la console Google Cloud ou de l'outil de ligne de commande kubectl.

Console

Procédez comme suit :

1. Dans la console Google Cloud, accédez à la page Charges de travail.

   Accéder à la page Charges de travail

2. Sélectionnez la charge de travail que vous souhaitez examiner. L'onglet Aperçu affiche l'état de la charge de travail.

3. Dans la section Pods gérés, cliquez sur un message d'état d'erreur.

kubectl

Pour afficher tous les pods exécutés dans votre cluster, utilisez la commande suivante :

kubectl get pods

Le résultat ressemble à ce qui suit :

NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

Les erreurs potentielles sont répertoriées dans la colonne Status.

Pour obtenir plus d'informations sur un pod spécifique, exécutez la commande suivante :

kubectl describe pod POD_NAME

Remplacez POD_NAME par le nom du pod que vous souhaitez examiner.

Dans la sortie, le champ Events affiche plus d'informations sur les erreurs.

Pour en savoir plus, consultez les journaux du conteneur:

kubectl logs POD_NAME

Ces journaux peuvent vous aider à identifier si une commande ou un code dans le conteneur a provoqué le plantage du pod.

Après avoir identifié l'erreur, consultez les sections suivantes pour essayer de résoudre le problème.

Erreur: CrashLoopBackOff

Un état CrashLoopBackOff ne signifie pas qu'il y a une erreur spécifique, mais indique qu'un conteneur plante de manière répétée après le redémarrage. Lorsqu'un conteneur plante ou se ferme peu de temps après son démarrage (CrashLoop), Kubernetes tente de le redémarrer. À chaque échec de redémarrage, le délai (BackOff) avant la tentative suivante augmente de manière exponentielle (10 s, 20 s, 40 s, etc.) jusqu'à un maximum de cinq minutes.

Les sections suivantes vous aideront à identifier la raison pour laquelle votre conteneur plante.

Utiliser le playbook interactif sur le plantage en boucle des pods

Commencez à résoudre les problèmes à l'origine d'un état CrashLoopBackOff à l'aide du playbook interactif de la console Google Cloud:

1. Accédez au playbook interactif sur le plantage en boucle des pods :

   Accéder au playbook

2. Dans la liste déroulante Cluster, sélectionnez le cluster que vous souhaitez dépanner. Si vous ne trouvez pas votre cluster, saisissez son nom dans le champ Filtre.

3. Dans la liste déroulante Espace de noms, sélectionnez l'espace de noms que vous souhaitez résoudre. Si vous ne trouvez pas votre espace de noms, saisissez-le dans le champ Filtre.

4. Parcourez chacune des sections pour identifier la cause du problème:

   1. Identifier les erreurs d'application
   2. Analyser les problèmes de mémoire saturée
   3. Examiner les perturbations de nœud
   4. Analyser les échecs des vérifications d'activité
   5. Corréler des événements de modification

5. Facultatif: Pour recevoir des notifications concernant les futures erreurs CrashLoopBackOff, sélectionnez Créer une alerte dans la section Conseils d'atténuation futurs.

Journaux d'inspection

Un conteneur peut planter pour plusieurs raisons. La consultation des journaux d'un pod peut aider à en identifier la cause.

Vous pouvez vérifier les journaux à l'aide de la console Google Cloud ou de l'outil de ligne de commande kubectl.

Console

Procédez comme suit :

1. Accédez à la page Charges de travail dans la console Google Cloud.

   Accéder à la page Charges de travail

2. Sélectionnez la charge de travail que vous souhaitez examiner. L'onglet Aperçu affiche l'état de la charge de travail.

3. Dans la section Pods gérés, cliquez sur le pod qui pose problème.

4. Dans le menu du pod, cliquez sur l'onglet Journaux.

kubectl

1. Affichez tous les pods exécutés dans votre cluster:

   kubectl get pods
   

2. Dans la sortie de la commande précédente, recherchez un pod avec l'erreur CrashLoopBackOff dans la colonne Status.

3. Obtenez les journaux du pod:

   kubectl logs POD_NAME
   

   Remplacez POD_NAME par le nom du pod qui pose problème.

   Vous pouvez également transmettre l'option -p pour obtenir les journaux de l'instance précédente du conteneur d'un pod, si elle existe.

Vérifier le code de sortie du conteneur qui plante

Pour mieux comprendre pourquoi votre conteneur a planté, recherchez le code de sortie:

1. Décrivez le pod :

   kubectl describe pod POD_NAME
   

   Remplacez POD_NAME par le nom du pod qui pose problème.

2. Vérifiez la valeur du champ containers: CONTAINER_NAME: last state: exit code :

   • Si le code de sortie est 1, le conteneur a planté car l'application a planté.
   • Si le code de sortie est 0, vérifiez la durée d'exécution de l'application. Les conteneurs se ferment à la fin du processus principal de l'application. Si l'exécution de l'application se termine très rapidement, il arrive que le conteneur continue à redémarrer. Si vous rencontrez cette erreur, une solution consiste à définir le champ restartPolicy sur OnFailure. Une fois cette modification effectuée, l'application ne redémarre que lorsque le code de sortie n'est pas égal à 0.

Se connecter à un conteneur en cours d'exécution

Pour exécuter des commandes bash à partir du conteneur afin de tester le réseau ou de vérifier si vous avez accès aux fichiers ou aux bases de données utilisés par votre application, ouvrez une interface système pour le pod:

kubectl exec -it POD_NAME -- /bin/bash

Si le pod comporte plusieurs conteneurs, ajoutez -c CONTAINER_NAME.

Erreurs: ImagePullBackOff et ErrImagePull

Un état ImagePullBackOff ou ErrImagePull indique que l'image utilisée par un conteneur ne peut pas être chargée à partir du registre d'images.

Vous pouvez examiner ce problème à l'aide de la console Google Cloud ou de l'outil de ligne de commande kubectl.

Console

Procédez comme suit :

1. Dans la console Google Cloud, accédez à la page Charges de travail.

   Accéder à la page Charges de travail

2. Sélectionnez la charge de travail que vous souhaitez examiner. L'onglet Aperçu affiche l'état de la charge de travail.

3. Dans la section Pods gérés, cliquez sur le pod qui pose problème.

4. Dans le menu du pod, cliquez sur l'onglet Événements.

kubectl

Pour obtenir plus d'informations sur l'image de conteneur d'un pod, exécutez la commande suivante :

kubectl describe pod POD_NAME

Problème: l'image est introuvable

Si votre image est introuvable, procédez comme suit:

1. Vérifiez que le nom de l'image est correct.
2. Vérifiez que le tag de l'image est correct. (Essayez :latest ou aucun tag pour extraire la dernière image).
3. 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.

4. Dans les clusters GKE Standard, essayez d'extraire l'image Docker manuellement:

   1. Utilisez SSH pour vous connecter à la VM.

      Par exemple, pour utiliser SSH pour vous connecter à une VM, exécutez la commande suivante:

      gcloud compute ssh VM_NAME --zone=ZONE_NAME
      

      Remplacez les éléments suivants :

      • VM_NAME : nom de la VM.
      • ZONE_NAME : une zone Compute Engine.

   2. Générez un fichier de configuration dans /home/[USER]/.docker/config.json:

      docker-credential-gcr configure-docker
      

      Assurez-vous que le fichier de configuration situé à l'adresse /home/[USER]/.docker/config.json inclut le registre de l'image dans le champ credHelpers. Par exemple, le fichier suivant inclut des informations d'authentification pour les images hébergées sur asia.gcr.io, eu.gcr.io, gcr.io, marketplace.gcr.io et us.gcr.io:

      {
      "auths": {},
      "credHelpers": {
        "asia.gcr.io": "gcr",
        "eu.gcr.io": "gcr",
        "gcr.io": "gcr",
        "marketplace.gcr.io": "gcr",
        "us.gcr.io": "gcr"
      }
      }
      

   3. Essayez d'extraire l'image:

      docker pull IMAGE_NAME
      

   Si le téléchargement manuel de l'image fonctionne, vous devrez probablement spécifier ImagePullSecrets sur un pod. Les pods ne peuvent référencer que des codes secrets d'extraction d'image dans leur propre espace de noms. Ce processus doit donc être effectué une fois par espace de noms.

Erreur : Autorisation refusée

Si vous rencontrez une erreur "Autorisation refusée" ou "Aucun accès en extraction", vérifiez que vous êtes connecté et/ou que vous avez accès à l'image. Essayez l'une des méthodes suivantes en fonction du registre dans lequel vous hébergez vos images.

Attention : Container Registry est obsolète et son abandon est planifié. Les organisations n'ayant pas utilisé Container Registry avant le 8 janvier 2024 disposeront par défaut des nouveaux dépôts gcr.io hébergés sur Artifact Registry. Depuis le 15 mai 2024, les projets Google Cloud qui n'utilisaient pas Container Registry précédemment n'accepteront que l'hébergement et la gestion des images dans Artifact Registry pour le domaine gcr.io.

L'arrêt de Container Registry est prévu pour le 18 mars 2025. Pour en savoir plus sur cet arrêt, consultez la page Abandon de Container Registry.

Artifact Registry

Si votre image se trouve dans Artifact Registry, le compte de service de votre pool de nœuds doit disposer d'un accès en lecture au dépôt contenant l'image.

Attribuez le rôle artifactregistry.reader au compte de service :

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --location=REPOSITORY_LOCATION \
    --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
    --role="roles/artifactregistry.reader"

Remplacez les éléments suivants :

• REPOSITORY_NAME : nom de votre dépôt Artifact Registry
• REPOSITORY_LOCATION : région de votre dépôt Artifact Registry
• SERVICE_ACCOUNT_EMAIL : adresse e-mail du compte de service IAM associé à votre pool de nœuds.

Container Registry

Si votre image se trouve dans Container Registry, le compte de service de votre pool de nœuds doit disposer d'un accès en lecture au bucket Cloud Storage contenant l'image.

Attribuez le rôle roles/storage.objectViewer au compte de service afin qu'il puisse lire le contenu du bucket:

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
    --role=roles/storage.objectViewer

Remplacez les éléments suivants :

• SERVICE_ACCOUNT_EMAIL : adresse e-mail du compte de service associé à votre pool de nœuds. Vous pouvez répertorier tous les comptes de service de votre projet à l'aide de gcloud iam service-accounts list.
• BUCKET_NAME: nom du bucket Cloud Storage contenant vos images. Vous pouvez répertorier tous les buckets de votre projet à l'aide de la commande gcloud storage ls.

Si votre administrateur de registre a configuré des dépôts gcr.io dans Artifact Registry pour stocker des images pour le domaine gcr.io au lieu de Container Registry, vous devez accorder un accès en lecture à Artifact Registry plutôt que Container Registry.

Registre privé

Si votre image se trouve dans un registre privé, vous devrez peut-être disposer de clés pour y accéder. Pour en savoir plus, consultez la section Utiliser des registres privés de la documentation Kubernetes.

Erreur 401 Opération non autorisée: impossible d'extraire des images du dépôt de registre de conteneurs privé

Une erreur semblable à la suivante peut se produire lorsque vous extrayez une image d'un dépôt Container Registry privé:

gcr.io/PROJECT_ID/IMAGE:TAG: rpc error: code = Unknown desc = failed to pull and
unpack image gcr.io/PROJECT_ID/IMAGE:TAG: failed to resolve reference
gcr.io/PROJECT_ID/IMAGE]:TAG: unexpected status code [manifests 1.0]: 401 Unauthorized

Warning  Failed     3m39s (x4 over 5m12s)  kubelet            Error: ErrImagePull
Warning  Failed     3m9s (x6 over 5m12s)   kubelet            Error: ImagePullBackOff
Normal   BackOff    2s (x18 over 5m12s)    kubelet            Back-off pulling image

Pour résoudre ce problème, procédez comme suit :

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

   kubectl describe pod POD_NAME | grep "Node:"
   

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

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

   Le niveau d'accès du nœud doit contenir au moins l'un des éléments 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, recréez le pool de nœuds.

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

   • Recommandé: 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"
     

   • Créez un pool de nœuds avec uniquement un champ d'application de stockage:

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

Erreur: Pod non programmable

Un état PodUnschedulable indique que votre pod ne peut pas être planifié en raison de ressources insuffisantes ou d'une erreur de configuration.

Si vous avez configuré des métriques du plan de contrôle, vous trouverez plus d'informations sur ces erreurs dans les sections métriques du programmeur et métriques du serveur d'API.

Utiliser le playbook interactif des pods non programmables

Vous pouvez résoudre les erreurs PodUnschedulable à l'aide du playbook interactif de la console Google Cloud:

1. Accédez au playbook interactif des pods non programmables:

   Accéder au playbook

2. Dans la liste déroulante Cluster, sélectionnez le cluster que vous souhaitez dépanner. Si vous ne trouvez pas votre cluster, saisissez son nom dans le champ Filtre.

3. Dans la liste déroulante Espace de noms, sélectionnez l'espace de noms que vous souhaitez résoudre. Si vous ne trouvez pas votre espace de noms, saisissez-le dans le champ Filtre.

4. Pour vous aider à identifier la cause, examinez chacune des sections du playbook:

   1. Analyser les ressources de processeur et de mémoire
   2. Analyser le nombre maximal de pods par nœud
   3. Analyser le comportement de l'autoscaler
   4. Analyser les autres modes de défaillance
   5. Corréler des événements de modification

5. Facultatif: Pour recevoir des notifications concernant les futures erreurs PodUnschedulable, sélectionnez Créer une alerte dans la section Conseils d'atténuation futurs.

Erreur: ressources insuffisantes

Vous pouvez rencontrer une erreur indiquant un manque de ressources processeur, de mémoire ou autre. Par exemple: No nodes are available that match all of the predicates: Insufficient cpu (2) indique que sur deux nœuds, le processeur disponible est insuffisant pour répondre aux requêtes d'un pod.

Si les demandes de ressources de pod dépassent celles d'un seul nœud d'un pool de nœuds éligibles, GKE ne programme pas le pod et ne déclenche pas non plus le scaling à la hausse pour ajouter un nœud. Pour que GKE planifie le pod, vous devez soit demander moins de ressources pour le pod, soit créer un pool de nœuds disposant de suffisamment de ressources.

Vous pouvez également activer le provisionnement automatique des nœuds afin que GKE puisse créer automatiquement des pools de nœuds avec des nœuds sur lesquels les pods non planifiés peuvent s'exécuter.

Le nombre de requêtes par défaut sur le processeur est de 100 millions ou 10 % d'un processeur (ou un cœur). Si vous souhaitez demander plus ou moins de ressources, indiquez la valeur dans la spécification de pod sous spec: containers: resources: requests.

Remarque : Votre cluster exécute des conteneurs système dans l'espace de noms kube-system. Ces conteneurs utilisent également des ressources de cluster.

Erreur: MatchNodeSelector

MatchNodeSelector indique qu’aucun nœud ne correspond au sélecteur de libellés du pod.

Pour vous en assurer, vérifiez les libellés indiqués dans le champ nodeSelector de la spécification de pod, sous spec: nodeSelector.

Pour savoir comment les nœuds de votre cluster sont libellés, exécutez la commande suivante :

kubectl get nodes --show-labels

Pour associer un libellé à un nœud, exécutez la commande suivante :

kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

Remplacez les éléments suivants :

• NODE_NAME: nœud auquel vous souhaitez ajouter un libellé.
• LABEL_KEY : clé de libellé.
• LABEL_VALUE : valeur du libellé.

Pour en savoir plus, consultez la section Attribuer des pods à des nœuds dans la documentation Kubernetes.

Erreur: PodToleratesNodeTaints

PodToleratesNodeTaints indique que le pod ne peut pas être planifié sur un nœud, car le pod ne présente pas de tolérances correspondant aux propriétés de rejet existantes.

Pour vous en assurer, exécutez la commande suivante :

kubectl describe nodes NODE_NAME

Dans le résultat, examinez le champ Taints, qui répertorie les paires valeur/clé et les effets de planification.

Si l'effet indiqué est NoSchedule, alors aucun pod ne peut être planifié sur ce nœud sans la tolérance correspondante.

Pour résoudre ce problème, vous pouvez supprimer la propriété de rejet. Par exemple, pour supprimer le rejet NoSchedule, exécutez la commande suivante :

kubectl taint nodes NODE_NAME key:NoSchedule-

Erreur: PodFitsHostPorts

PodFitsHostPorts indique qu'un port qu'un nœud tente d'utiliser est déjà en cours d'utilisation.

Pour résoudre ce problème, vérifiez la valeur hostPort de la spécification de pod sous spec: containers: ports: hostPort. Vous devrez peut-être remplacer cette valeur par un autre port.

Erreur: Aucune disponibilité minimale

Si un nœud dispose de ressources suffisantes mais que vous obtenez toujours le message Does not have minimum availability, vérifiez l'état du pod. Si l'état est SchedulingDisabled ou Cordoned, le nœud ne peut pas planifier de nouveaux pods. Vous pouvez vérifier l'état d'un nœud à l'aide de la console Google Cloud ou de l'outil de ligne de commande kubectl.

Console

Procédez comme suit :

1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

   Accéder à Google Kubernetes Engine

2. Sélectionnez le cluster que vous souhaitez examiner. L'onglet Nœuds affiche les nœuds et leur état.

Pour activer la planification sur le nœud, procédez comme suit :

1. Dans la liste, cliquez sur le nœud que vous souhaitez examiner.

2. Dans la section Détails du nœud, cliquez sur Reprendre l'ordonnancement.

kubectl

Pour obtenir l'état de vos nœuds, exécutez la commande suivante :

kubectl get nodes

Pour activer la planification sur le nœud, exécutez cette commande :

kubectl uncordon NODE_NAME

Erreur : Nombre maximal de pods par nœud atteint

Si la limite Nombre maximal de pods par nœud est atteinte par tous les nœuds du cluster, les pods sont bloqués dans l'état non programmable. Sous l'onglet Événements du pod, un message contenant l'expression Too many pods s'affiche.

Pour résoudre ce problème, procédez comme suit :

1. Vérifiez la configuration Maximum pods per node à partir de l'onglet "Nœuds" dans les détails du cluster GKE dans la console Google Cloud.

2. Obtenez la liste des nœuds:

   kubectl get nodes
   

3. Pour chaque nœud, vérifiez le nombre de pods en cours d'exécution sur le nœud:

   kubectl get pods -o wide | grep NODE_NAME | wc -l
   

4. Si la limite est atteinte, ajoutez un pool de nœuds ou ajoutez des nœuds supplémentaires au pool de nœuds existant.

Problème : Taille maximale du pool de nœuds atteinte avec l'autoscaler de cluster activé

Si le pool de nœuds a atteint sa Taille maximale Selon sa configuration d'autoscaler de cluster, GKE ne déclenche pas de scaling à la hausse pour le pod qui serait autrement programmé avec ce pool de nœuds. Si vous souhaitez que le pod soit planifié sur ce pool de nœuds, modifiez la configuration de l'autoscaler de cluster.

Problème : Taille maximale du pool de nœuds atteinte avec l'autoscaler de cluster désactivé

Si le pool de nœuds a atteint son nombre maximal de nœuds et que l'autoscaler de cluster est désactivé, GKE ne peut pas planifier le pod avec le pool de nœuds. Augmentez la taille de votre pool de nœuds ou activez l'autoscaler de cluster pour que GKE redimensionne automatiquement votre cluster.

Erreur: PersistentVolumeClaims non liés

Unbound PersistentVolumeClaims indique que le pod fait référence à un objet PersistantVolumeClaim non lié. Cette erreur peut se produire en cas d'échec du provisionnement du PersistentVolume. Vous pouvez vérifier si le provisionnement a échoué en récupérant les événements associés au PersistentVolumeClaim et en examinant s'ils signalent un échec.

Pour obtenir la liste des événements, exécutez la commande suivante :

kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

Remplacez les éléments suivants :

• STATEFULSET_NAME : nom de l'objet StatefulSet.
• PVC_NAME : nom de l'objet PersistentVolumeClaim.

Cette erreur peut également être causée par une erreur de configuration lors du provisionnement manuel préalable d'un PersistentVolume et de sa liaison à un PersistentVolumeClaim.

Pour résoudre cette erreur, essayez de préprovisionner le volume à nouveau.

Erreur: quota insuffisant

Vérifiez que votre projet dispose d'un quota Compute Engine suffisant pour que GKE puisse effectuer le scaling à la hausse de votre cluster. Si GKE tente d'ajouter un nœud à votre cluster pour planifier le pod et que le scaling à la hausse dépasse le quota disponible de votre projet, vous recevez le message d'erreur scale.up.error.quota.exceeded.

Pour en savoir plus, consultez la section Erreurs liées au scaling à la hausse.

Problème: API obsolètes

Assurez-vous de ne pas utiliser d'API obsolètes qui sont supprimées dans la version mineure de votre cluster. Pour en savoir plus, consultez la page Abandons de GKE.

Étape suivante

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