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 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 des pods 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 :
Dans la console Google Cloud , accédez à la page Charges de travail.
Sélectionnez la charge de travail que vous souhaitez examiner. L'onglet Aperçu affiche l'état de la charge de travail.
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 listé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 le résultat, le champ Events affiche plus d'informations sur les erreurs.
Pour en savoir plus, consultez les journaux de conteneur :
kubectl logs POD_NAME
Ces journaux peuvent vous aider à déterminer si une commande ou un code dans le conteneur a provoqué l'échec du pod.
Une fois l'erreur identifiée, utilisez les sections suivantes pour essayer de résoudre le problème.
Erreur : CrashLoopBackOff
L'état CrashLoopBackOff n'indique pas une erreur spécifique, mais plutôt qu'un conteneur plante de manière répétée après le redémarrage.
Pour en savoir plus, consultez Résoudre les problèmes liés aux événements CrashLoopBackOff.
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 obtenir de l'aide sur le dépannage de ces états, consultez Résoudre les problèmes d'extraction d'images.
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é les 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 :
Accédez au playbook interactif des pods non programmables:
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 Filtre.
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 champ Filtre.
Pour identifier la cause, parcourez chacune des sections du playbook :
- Analyser les ressources de processeur et de mémoire
- Analyser le nombre maximal de pods par nœud
- Analyser le comportement de l'autoscaler
- Analyser les autres modes de défaillance
- Corréler des événements de modification
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.
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 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 possède pas de tolérances correspondant aux rejets de nœud existants.
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 tous les pods du même nœud ont des valeurs uniques définies pour hostPort.
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.
Console
Procédez comme suit :
Accédez à la page Google Kubernetes Engine dans la console Google Cloud .
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 :
Dans la liste, cliquez sur le nœud que vous souhaitez examiner.
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 :
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 .Obtenez la liste des nœuds:
kubectl get nodesPour 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 -lSi 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 ce problème, essayez de préprovisionner à nouveau le volume.
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 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, cela signifie probablement que plusieurs pods sur le même nœud ont 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.
L'association d'un pod à un hostPort limite l'emplacement 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 tous les pods du même nœud ont des valeurs uniques définies pour hostPort.
É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-enginepour rechercher des problèmes similaires. Vous pouvez également rejoindre le canal Slack#kubernetes-enginepour 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.