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

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 la résolution des problèmes liés à vos applications, consultez la section Résoudre les problèmes liés aux 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 Google Cloud console 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 l'erreur identifiée, utilisez les sections suivantes pour tenter de résoudre le problème.

Erreur : CrashLoopBackOff

L'état CrashLoopBackOff ne signifie pas qu'il existe une erreur spécifique, mais indique qu'un conteneur plante de manière répétée après avoir redémarré.

Pour en savoir plus, consultez la section Résoudre les problèmes liés aux événements CrashLoopBackOff.

Erreurs : ImagePullBackOff et ErrImagePull

L'é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 obtenir des conseils sur la résolution des problèmes liés à ces états, consultez la section Résoudre les problèmes liés aux extractions d'images.

Erreur : OutOfPods

L'état OutOfPods indique qu'un nœud ne peut pas exécuter de pod, car il a atteint sa capacité maximale de pods.

Symptômes

Un message semblable au suivant peut s'afficher dans les événements du pod :

Node didn't have enough resource: pods, requested: 1, used: 32, capacity: 32

Cause

Cette erreur se produit lorsqu'une requête est envoyée pour planifier un pod sur un nœud qui a déjà atteint sa capacité maximale. Cette situation peut se produire lors du démarrage du nœud, par exemple lorsque le composant kube-scheduler attribue des pods à un nouveau nœud avant que l'agent kubelet n'ait signalé la présence de pods statiques tels que le composant kube-proxy, qui nécessitent leur propre capacité de pods.

Solution

Pour résoudre ce problème, essayez l'une des solutions suivantes :

• Augmentez le nombre maximal de pods par nœud. Si vos nœuds atteignent systématiquement leur limite de pods, augmentez le paramètre --max-pods-per-node pour vos pools de nœuds. L'augmentation du nombre de pods peut nécessiter des nœuds plus volumineux pour gérer les demandes de ressources accrues.

• Activez l'autoscaler de cluster et le provisionnement automatique des nœuds. Si vous manquez fréquemment de capacité de pods, l'activation de l' autoscaler de cluster et du provisionnement automatique des nœuds peut vous aider à vous assurer que votre cluster dispose de suffisamment de nœuds pour répondre à la demande de vos charges de travail.

• Modifiez le profil d'autoscaling. Si vous utilisez déjà l'autoscaler de cluster, essayez de remplacer le profil d'autoscaling par le profil optimize-utilization au lieu du profil balanced. Le profil optimize-utilization peut augmenter la probabilité d'erreurs OutOfPods, car il tente de placer les pods sur les nœuds les plus utilisés.

Erreur : Pod non programmable

L'é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 de plan de contrôle, vous trouverez plus d'informations sur ces erreurs dans les métriques du programmeur et les 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 Google Cloud console :

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 pour lequel vous souhaitez résoudre les problèmes. 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 pour lequel vous souhaitez résoudre les problèmes. Si vous ne trouvez pas votre espace de noms, saisissez-le dans le filter_list Filtre champ.

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

L'état PodUnschedulable peut se produire si les ressources de processeur, de mémoire ou autres sont insuffisantes pour répondre aux requêtes du pod.

Symptômes

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

Cause

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.

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

Solution

Essayez les solutions suivantes :

• Ajustez la demande de ressources du pod en spécifiant une valeur inférieure dans le champ spec: containers: resources: requests. Le nombre de requêtes par défaut sur le processeur est de 100 millions ou 10% d'un processeur (ou un cœur).

• Créez un pool de nœuds avec des nœuds disposant de suffisamment de ressources pour répondre aux requêtes du pod.

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

Erreur : MatchNodeSelector

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

Symptômes

L'état ou les événements du pod affichent une erreur MatchNodeSelector.

Cause

Les libellés spécifiés dans le champ nodeSelector du fichier manifeste du pod n'existent sur aucun nœud du cluster.

Solution

Pour résoudre cette erreur, assurez-vous que les libellés spécifiés dans le champ nodeSelector du pod correspondent aux libellés d'au moins un nœud de votre cluster :

1. Identifiez les exigences de libellé recherchées par le pod en vérifiant son champ spec: nodeSelector.

2. Pour voir si des libellés correspondent aux exigences du pod, affichez les libellés réels attribués aux nœuds de votre cluster :

   kubectl get nodes --show-labels
   

3. Si un nœud est destiné à exécuter ce pod, associez-lui le libellé nécessaire :

   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

Une erreur PodToleratesNodeTaints indique que le pod ne peut pas être planifié sur un nœud, car il ne dispose pas de tolérances correspondant aux rejets de nœuds existants.

Symptômes

L'état ou les événements du pod affichent une erreur PodToleratesNodeTaints.

Cause

Le pod ne peut pas être planifié sur un nœud, car il ne dispose pas de tolérances correspondant aux rejets de nœuds existants.

Solution

1. Vérifiez les rejets sur le nœud :

   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 .

2. Supprimez le rejet du nœud. Par exemple, pour supprimer un 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é.

Symptômes

L'état du pod affiche une erreur PodFitsHostPorts.

Cause

Un pod demande un port hôte déjà utilisé par un autre pod ou processus sur le nœud cible.

Solution

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

Si vous devez utiliser un port hôte, vérifiez les fichiers manifestes des pods et assurez-vous que tous les pods du même nœud ont des valeurs uniques définies pour le paramètre hostPort.

Erreur : Disponibilité minimale non présente

Cette erreur peut se produire si un nœud dispose de ressources suffisantes, mais n'est pas disponible pour la planification.

Symptômes

• L'erreur Does not have minimum availability s'affiche.

• L'état du nœud affiche SchedulingDisabled ou Cordoned.

Cause

L'état "Cordoned" du nœud empêche la planification de nouveaux pods sur celui-ci.

Solution

Pour que la planification soit de nouveau possible sur le nœud, annulez l'état "Cordoned" :

kubectl get nodes

kubectl uncordon NODE_NAME

Erreur : Nombre maximal de pods par nœud atteint

L'erreur Too many pods indique qu'un pod ne peut pas être planifié, car le nœud cible a atteint sa capacité maximale de pods configurée.

Symptômes

• Les pods sont bloqués dans l'état Unschedulable.
• Un message contenant l'expression Too many pods s'affiche.

Cause

La limite Nombre maximal de pods par nœud est atteinte par tous les nœuds du cluster.

Solution

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 Google Cloud console.

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é

Ce problème se produit lorsqu'un pool de nœuds a atteint sa taille maximale configurée sous l'autoscaler de cluster.

Symptômes

GKE ne déclenche pas de scaling à la hausse pour un pod qui serait autrement programmé avec ce pool de nœuds. Au lieu de cela, le pod reste à l'état Pending.

Cause

Le pool de nœuds a atteint sa Taille maximale Selon sa configuration d'autoscaler de cluster.

Solution

Augmentez la taille maximale du pool de nœuds en modifiant la configuration de l'autoscaler de cluster configuration.

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

Ce problème se produit lorsqu'un pool de nœuds a atteint sa taille maximale et que l'autoscaler de cluster est désactivé.

Symptômes

GKE ne peut pas planifier le pod avec le pool de nœuds.

Cause

Le pool de nœuds a atteint son nombre maximal de nœuds et l'autoscaler de cluster est désactivé.

Solution

Pour résoudre ce problème, essayez l'une des solutions suivantes :

• Augmentez la taille de votre pool de nœuds.
• Activez l'autoscaler de cluster pour redimensionner automatiquement votre cluster.

Erreur : PersistentVolumeClaims non liés

L'erreur Unbound PersistentVolumeClaims indique que le pod fait référence à un objet PersistentVolumeClaim non lié.

Symptômes

L'état ou les événements du pod affichent une erreur Unbound PersistentVolumeClaims.

Cause

Cette erreur peut se produire pour l'une des raisons suivantes :

• Échec du provisionnement de votre PersistentVolume.
• Erreur de configuration lors du provisionnement manuel préalable d'un PersistentVolume et de sa liaison à un PersistentVolumeClaim.

Solution

1. Vérifiez si le provisionnement a échoué en récupérant les événements associés à votre PersistentVolumeClaim :

   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.

2. Essayez de provisionner à nouveau le volume.

Erreur : quota insuffisant

Si GKE tente d'effectuer un scaling à la hausse de votre cluster pour planifier un pod, mais rencontre des contraintes de quota, le scaling à la hausse échoue.

Symptômes

Le message d'erreur scale.up.error.quota.exceeded s'affiche dans les événements de votre pod.

Cause

Le scaling à la hausse du cluster dépasserait le quota disponible de votre projet.

Solution

Vérifiez que votre projet dispose d'un quota Compute Engine suffisant pour que GKE puisse effectuer le scaling à la hausse de votre cluster. Pour en savoir plus, consultez la section Erreurs liées au scaling à la hausse.

Problème : API obsolètes

L'utilisation d'API qui ne sont plus compatibles dans vos fichiers manifestes peut empêcher le déploiement de la charge de travail.

Symptômes

Les charges de travail ne peuvent pas être déployées ni exécutées en raison de l'utilisation d'API obsolètes.

Cause

Vos fichiers manifestes utilisent des API obsolètes qui sont supprimées dans la version mineure de votre cluster.

Solution

Assurez-vous de ne pas utiliser d'API obsolètes. Mettez à jour vos fichiers manifestes pour utiliser des API compatibles. 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

La liaison d'un pod à un port hôte limite l'endroit où GKE peut planifier le pod, car chaque combinaison d'adresse hostIP, de paramètre hostPort et de valeur protocol doit être unique.

Symptômes

Une erreur semblable à celle-ci s'affiche :

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.

Cause

Plusieurs pods du même nœud spécifient la même valeur définie dans le champ hostPort.

Solution

Pour résoudre ce problème, essayez l'une des solutions suivantes :

• Suivez les bonnes pratiques Kubernetes et utilisez un service NodePort au lieu d'un port hôte.
• Si vous devez utiliser un port hôte, vérifiez les fichiers manifestes des pods et assurez-vous que tous les pods du même nœud ont des valeurs uniques définies pour le champ hostPort.

Problème : Échecs d'application et de sonde dans les pods

Ce problème se produit lorsque vous exécutez des applications qui utilisent le protocole HTTPS pour communiquer avec un serveur.

Symptômes

Les échecs de ces applications sont semblables à ce qui suit :

• Les pods ne démarrent pas et les conteneurs plantent avec le code de sortie 137.

• Les sondes de vivacité ou de disponibilité échouent avec un message d'erreur semblable au suivant :

  probeResult="failure" output="Get "https://example.com/healthy": EOF"
  

• Les pods s'exécutent comme prévu, mais les journaux d'application indiquent des échecs de connexion.

Cause

Les versions 1.30 et ultérieures de Kubernetes utilisent des versions de Golang qui désactivent les suites de chiffrement TLS suivantes :

• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA

Solution

Utilisez des suites de chiffrement compatibles à partir de TLS 1.2 et versions ultérieures.

Étape suivante

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

  • Ouvrir une demande d'assistance en contactant Cloud Customer Care.
  • 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 #kubernetes-engine canal Slack pour obtenir une assistance supplémentaire de la communauté.
  • Signaler des problèmes ou demander des fonctionnalités à l'aide de l' outil public de suivi des problèmes.