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

Cette page explique comment résoudre les erreurs liées à vos 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.

kubectl get pods

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

kubectl describe pod POD_NAME

kubectl logs POD_NAME

Une fois que vous avez identifié l'erreur, utilisez les sections suivantes pour essayer de résoudre le problème.

Erreur : CrashLoopBackOff

Un état CrashLoopBackOff ne signifie pas qu'une erreur spécifique s'est produite. Il indique plutôt 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 redémarrage échoué, le délai (BackOff) avant la prochaine tentative augmente de manière exponentielle (10 s, 20 s, 40 s, etc.), jusqu'à un maximum de cinq minutes.

Les sections suivantes vous aident à identifier pourquoi votre conteneur peut planter.

Utiliser le playbook interactif sur les pods bloqués dans une boucle de plantage

Commencez à résoudre le problème à l'origine de l'é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 résoudre. Si vous ne trouvez pas votre cluster, saisissez son nom dans le champ filter_list 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 filter_list Filtre.

4. Parcourez chacune des sections pour vous aider à identifier la cause:

   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 consulter les journaux à l'aide de la console Google Cloud ou de l'outil de ligne de commande kubectl.

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 un shell sur 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.

Pour savoir comment résoudre ces problèmes, consultez la section Résoudre les problèmes de récupération d'images.

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 dans 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 résoudre. Si vous ne trouvez pas votre cluster, saisissez son nom dans le champ filter_list 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 filter_list Filtre.

4. Pour vous aider à identifier la cause, parcourez 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), qui 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.

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 Affecter 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 il 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

L'erreur PodFitsHostPorts signifie qu'un nœud tente d'utiliser un port déjà occupé.

Pour résoudre le problème, envisagez de suivre les bonnes pratiques Kubernetes et d'utiliser un NodePort au lieu d'un hostPort.

Si vous devez utiliser un hostPort, vérifiez les fichiers manifestes des pods et assurez-vous que toutes les valeurs définies pour hostPort sont uniques pour tous les pods du même nœud.

Erreur : Disponibilité minimale non présente

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.

kubectl get nodes

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 section Abandons de fonctionnalités et d'API.

Erreur: aucun port libre pour les ports de pod demandés

Si une erreur semblable à la suivante s'affiche, il est probable que plusieurs pods se trouvent sur le même nœud avec la même valeur définie dans le champ hostPort:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.

Lier un pod à un hostPort limite les emplacements où GKE peut planifier le pod, car chaque combinaison hostIP, hostPort et protocol doit être unique.

Pour résoudre le problème, envisagez de suivre les bonnes pratiques Kubernetes et d'utiliser un NodePort au lieu d'un hostPort.

Si vous devez utiliser un hostPort, vérifiez les fichiers manifestes des pods et assurez-vous que toutes les valeurs définies pour hostPort sont uniques pour tous les pods du même nœud.

Étapes suivantes

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

  • En ouvrant une demande d'assistance en contactant l'assistance client Cloud.
  • Obtenir de l'aide de la communauté en posant des questions sur StackOverflow et en utilisant la balise google-kubernetes-engine pour rechercher des problèmes similaires. Vous pouvez également rejoindre le canal Slack #kubernetes-engine pour obtenir plus d'aide de la communauté.
  • Signaler des bugs ou des demandes de fonctionnalités à l'aide de l'outil public de suivi des problèmes