Résoudre les problèmes liés aux événements CrashLoopBackOff

Cette page vous aide à résoudre les problèmes liés aux pods qui rencontrent des événements CrashLoopBackOff dans Google Kubernetes Engine (GKE).

Cette page s'adresse aux développeurs d'applications qui souhaitent identifier les problèmes au niveau de l'application, tels que les erreurs de configuration ou les bugs liés au code, qui entraînent le plantage de leurs conteneurs. Il s'adresse également aux administrateurs et opérateurs de plate-forme qui doivent identifier les causes racines au niveau de la plate-forme pour les redémarrages de conteneurs, comme l'épuisement des ressources, les perturbations des nœuds ou les vérifications d'activité mal configurées. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Trusted Cloud by S3NS , consultez Rôles utilisateur et tâches courantes de GKE.

Comprendre un événement CrashLoopBackOff

Lorsque votre pod est bloqué à l'état CrashLoopBackOff, un conteneur qu'il contient démarre, plante ou se ferme de manière répétée. Ce CrashLoop déclenche Kubernetes pour tenter de redémarrer le conteneur en respectant son restartPolicy. À chaque redémarrage infructueux, le délai de BackOff avant la prochaine tentative augmente de manière exponentielle (par exemple, 10 s, 20 s, 40 s), jusqu'à un maximum de cinq minutes.

Bien que cet événement indique un problème dans votre conteneur, il constitue également un signal de diagnostic précieux. Un événement CrashLoopBackOff confirme que de nombreuses étapes fondamentales de la création de pods, telles que l'attribution à un nœud et l'extraction de l'image de conteneur, ont déjà été effectuées. Ces informations vous permettent de concentrer votre enquête sur l'application ou la configuration du conteneur, plutôt que sur l'infrastructure du cluster.

L'état CrashLoopBackOff se produit en raison de la façon dont Kubernetes, et plus précisément le kubelet, gère l'arrêt des conteneurs en fonction de la règle de redémarrage du pod. Le cycle suit généralement ce schéma :

1. Le conteneur démarre.
2. Le conteneur se ferme.
3. Le kubelet observe le conteneur arrêté et le redémarre en fonction de la restartPolicy du pod.
4. Ce cycle se répète, le conteneur étant redémarré après un intervalle exponentiel entre les tentatives de plus en plus long.

Le restartPolicy du pod est la clé de ce comportement. La règle par défaut, Always, est la cause la plus fréquente de cette boucle, car elle redémarre un conteneur s'il se ferme pour n'importe quelle raison, même après une fermeture réussie. La règle OnFailure est moins susceptible de provoquer une boucle, car elle ne redémarre que sur les codes de sortie différents de zéro, et la règle Never évite complètement le redémarrage.

Identifier les symptômes d'un événement CrashLoopBackOff

Un pod dont l'état est CrashLoopBackOff est la principale indication d'un événement CrashLoopBackOff.

Toutefois, vous pouvez rencontrer des symptômes moins évidents d'un événement CrashLoopBackOff :

• Aucune réplique opérationnelle pour une charge de travail.
• Une forte diminution du nombre de réplicas sains.
• Les charges de travail pour lesquelles l'autoscaling horizontal de pods est activé sont mises à l'échelle lentement ou ne le sont pas du tout.

Si une charge de travail system (par exemple, un agent de journaux ou de métriques) présente l'état CrashLoopBackOff, vous pouvez également remarquer les symptômes suivants :

• Certaines métriques GKE ne sont pas signalées.
• Certains tableaux de bord et graphiques GKE présentent des lacunes.
• Problèmes de connectivité au niveau du réseau du pod.

Si vous constatez l'un de ces symptômes moins évidents, vous devez ensuite vérifier si un événement CrashLoopBackOff s'est produit.

Confirmer un événement CrashLoopBackOff

Pour confirmer et examiner un événement CrashLoopBackOff, rassemblez des preuves à partir des événements Kubernetes et des journaux d'application du conteneur. Ces deux sources fournissent des points de vue différents, mais complémentaires, sur le problème :

• Les événements Kubernetes confirment qu'un pod plante.
• Les journaux d'application du conteneur peuvent vous indiquer pourquoi le processus à l'intérieur du conteneur échoue.

Pour afficher ces informations, sélectionnez l'une des options suivantes :

Utiliser le playbook interactif sur le plantage en boucle des pods

Après avoir confirmé un événement CrashLoopBackOff, commencez à résoudre le problème à l'aide du playbook interactif :

1. Dans la console Trusted Cloud , accédez à la page Playbook interactif GKE – Plantage en boucle des pods.

   Accéder à la section "Plantage en boucle des pods"

2. Dans la liste 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.

3. Dans la liste 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.

4. Parcourez chaque section pour vous aider à répondre aux questions suivantes :

   1. Identifier les erreurs d'application : quels conteneurs sont en cours de redémarrage ?
   2. Examiner les problèmes de mémoire insuffisante : y a-t-il une erreur de configuration ou une autre erreur liée à l'application ?
   3. Examiner les perturbations de nœud : des perturbations sur la ressource de nœud sont-elles la cause des redémarrages du conteneur ?
   4. Analyser les échecs des vérifications d'activité : les vérifications d'activité arrêtent-elles vos conteneurs ?
   5. Corréler des événements de modification : que s'est-il passé aux environs du moment où les conteneurs ont commencé à planter ?

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

Si votre problème persiste après avoir utilisé le playbook, lisez le reste du guide pour en savoir plus sur la résolution des événements CrashLoopBackOff.

Résoudre un événement CrashLoopBackOff

Les sections suivantes vous aident à résoudre les problèmes les plus courants liés aux événements CrashLoopBackOff :

• Épuisement des ressources (OOMKilled)
• Échec de la vérification d'activité
• Application mal configurée

Résoudre l'épuisement des ressources

Un événement CrashLoopBackOff est souvent dû à un problème de mémoire saturée (OOM, Out Of Memory). Vous pouvez vérifier s'il s'agit de la cause du problème si le résultat de kubectl describe affiche les informations suivantes :

Last State: Terminated
  Reason: OOMKilled

Pour savoir comment diagnostiquer et résoudre les événements OOM, consultez Résoudre les problèmes d'événements OOM.

Résoudre les échecs des vérifications d'activité

Une sonde de disponibilité est une vérification de l'état périodique effectuée par kubelet. Si la vérification échoue un nombre de fois spécifié (trois fois par défaut), kubelet redémarre le conteneur, ce qui peut entraîner un événement CrashLoopBackOff si les échecs de vérification persistent.

Vérifier si une vérification d'activité est à l'origine du problème

Pour vérifier si les échecs de vérification d'activité déclenchent l'événement CrashLoopBackOff, interrogez vos journaux kubelet. Ces journaux contiennent souvent des messages explicites indiquant des échecs de sonde et des redémarrages ultérieurs.

1. Dans la console Trusted Cloud , accédez à la page Explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans le volet de requête, filtrez les redémarrages liés à la vérification de l'activité en saisissant la requête suivante :

   resource.type="k8s_node"
   log_id("kubelet")
   jsonPayload.MESSAGE:"failed liveness probe, will be restarted"
   resource.labels.cluster_name="CLUSTER_NAME"
   

   Remplacez CLUSTER_NAME par le nom de votre cluster.

3. Examinez le résultat. Si l'échec d'une vérification d'activité est à l'origine de vos événements CrashLoopBackOff, la requête renvoie des messages de journal semblables à ceux-ci :

   Container probe failed liveness probe, will be restarted
   

Une fois que vous avez confirmé que les sondes de vivacité sont à l'origine de l'événement CrashLoopBackOff, passez à la résolution des causes courantes :

• Vérifiez la configuration de la vérification d'activité.
• Inspectez l'utilisation du processeur et des E/S du disque.
• Gérer les déploiements à grande échelle
• Corrigez les erreurs temporaires.
• Gérez la consommation de ressources des vérifications d'adresse.

Examiner la configuration de la vérification d'activité

Les sondes mal configurées sont une cause fréquente d'événements CrashLoopBackOff. Vérifiez les paramètres suivants dans le fichier manifeste de votre vérification :

• Vérifiez le type de vérification : la configuration de votre vérification doit correspondre à la façon dont votre application indique son état. Par exemple, si votre application dispose d'une URL de vérification de l'état (comme /healthz), utilisez le type de sonde httpGet. Si son état est déterminé par l'exécution d'une commande, utilisez le type de vérification exec. Par exemple, pour vérifier si un port réseau est ouvert et à l'écoute, utilisez le type de sonde tcpSocket.
• Vérifier les paramètres de la sonde :
  • Chemin d'accès (pour le type de sonde httpGet) : assurez-vous que le chemin d'accès HTTP est correct et que votre application y effectue des vérifications d'état.
  • Port : vérifiez que le port configuré dans la sonde est réellement utilisé et exposé par l'application.
  • Commande (pour le type de sonde exec) : assurez-vous que la commande existe dans le conteneur, qu'elle renvoie un code de sortie 0 en cas de réussite et qu'elle se termine dans la période timeoutSeconds configurée.
  • Délai avant expiration : assurez-vous que la valeur timeoutSeconds est suffisante pour que l'application puisse répondre, en particulier au démarrage ou sous charge.
  • Délai initial (initialDelaySeconds) : vérifiez si le délai initial est suffisant pour que l'application démarre avant le début des tests.

Pour en savoir plus, consultez Configurer des vérifications d'activité, d'aptitude et de démarrage dans la documentation de Kubernetes.

Inspecter l'utilisation du processeur et des E/S sur le disque

La contention des ressources entraîne des délais avant expiration des vérifications, ce qui est une cause majeure d'échec des vérifications de liveness. Pour déterminer si l'utilisation des ressources est à l'origine de l'échec de la vérification de l'activité, essayez les solutions suivantes :

• Analysez l'utilisation du processeur : surveillez l'utilisation du processeur du conteneur concerné et du nœud sur lequel il s'exécute pendant les intervalles de vérification. kubernetes.io/container/cpu/core_usage_time est un indicateur clé à suivre. Une utilisation élevée du processeur sur le conteneur ou le nœud peut empêcher l'application de répondre à la vérification à temps.
• Surveiller les E/S disque : vérifiez les métriques d'E/S disque pour le nœud. Vous pouvez utiliser la métrique compute.googleapis.com/guest/disk/operation_time pour évaluer le temps passé sur les opérations de disque, qui sont classées par lectures et écritures. Des E/S de disque élevées peuvent ralentir considérablement le démarrage du conteneur, l'initialisation de l'application ou les performances globales de l'application, ce qui entraîne des délais d'attente des sondes.

Gérer les déploiements à grande échelle

Dans les scénarios où un grand nombre de pods sont déployés simultanément (par exemple, par un outil CI/CD tel qu'ArgoCD), un afflux soudain de nouveaux pods peut submerger les ressources du cluster, entraînant l'épuisement des ressources du plan de contrôle. Ce manque de ressources retarde le démarrage de l'application et peut entraîner l'échec répété des vérifications d'activité avant que les applications ne soient prêtes.

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

• Mettez en œuvre des déploiements échelonnés : mettez en œuvre des stratégies pour déployer les pods par lots ou sur une période plus longue afin d'éviter de surcharger les ressources des nœuds.
• Reconfigurez ou mettez à l'échelle les nœuds : si les déploiements échelonnés ne sont pas possibles, envisagez de mettre à niveau les nœuds avec des disques plus rapides ou plus volumineux, ou des revendications de volume persistant, pour mieux gérer l'augmentation de la demande d'E/S. Assurez-vous que l'autoscaling de votre cluster est correctement configuré.
• Attendez et observez : dans certains cas, si le cluster ne manque pas trop de ressources, les charges de travail peuvent finir par se déployer après un délai important (parfois 30 minutes ou plus).

Résoudre les erreurs temporaires

L'application peut rencontrer des erreurs temporaires ou des ralentissements lors du démarrage ou de l'initialisation, ce qui entraîne l'échec initial de la sonde. Si l'application finit par récupérer, envisagez d'augmenter les valeurs définies dans les champs initialDelaySeconds ou failureThreshold du fichier manifeste de votre sonde de liveness.

Gérer la consommation de ressources des vérifications d'adresse

Dans de rares cas, l'exécution de la vérification d'activité elle-même peut consommer des ressources importantes, ce qui peut déclencher des contraintes de ressources pouvant entraîner l'arrêt du conteneur en raison d'un OOM kill. Assurez-vous que vos commandes de sonde sont légères. Une sonde légère est plus susceptible de s'exécuter rapidement et de manière fiable, ce qui lui permet de rendre compte plus fidèlement de l'état réel de votre application.

Résoudre les problèmes de configuration des applications

Les erreurs de configuration d'applications sont à l'origine de nombreux événements CrashLoopBackOff. Pour comprendre pourquoi votre application s'arrête, la première étape consiste à examiner son code de sortie. Ce code détermine la procédure de dépannage à suivre :

• Le code de sortie 0 indique une sortie réussie, ce qui est inattendu pour un service de longue durée et indique des problèmes avec le point d'entrée du conteneur ou la conception de l'application.
• Un code de sortie non nul signale un plantage de l'application, ce qui vous permet de vous concentrer sur les erreurs de configuration, les problèmes de dépendance ou les bugs dans le code.

Trouver le code de sortie

Pour trouver le code de sortie de votre application, procédez comme suit :

1. Décrivez le pod :

   kubectl describe pod POD_NAME -n NAMESPACE_NAME
   

   Remplacez les éléments suivants :

   • POD_NAME : nom du pod qui pose problème.
   • NAMESPACE_NAME : espace de noms du pod.

2. Dans le résultat, examinez le champ Exit Code situé dans la section Last State pour le conteneur concerné. Si le code de sortie est 0, consultez Résoudre les problèmes de sorties réussies (code de sortie 0). Si le code de sortie est un nombre autre que 0, consultez Résoudre les problèmes de plantage d'application (code de sortie non nul).

Résoudre les problèmes liés aux sorties réussies (code de sortie 0)

Un code de sortie 0 signifie généralement que le processus du conteneur s'est terminé avec succès. Bien que ce soit le résultat souhaité pour un Job basé sur une tâche, cela peut signaler un problème pour un contrôleur de longue durée tel qu'un Deployment, un StatefulSet ou un ReplicaSet.

Ces contrôleurs veillent à ce qu'un pod soit toujours en cours d'exécution. Ils considèrent donc toute sortie comme un échec à corriger. kubelet applique ce comportement en respectant le restartPolicy du pod (qui est défini par défaut sur Always), en redémarrant le conteneur même après une sortie réussie. Cette action crée une boucle, qui finit par déclencher l'état CrashLoopBackOff.

Voici les raisons les plus courantes d'une sortie réussie inattendue :

• La commande de conteneur ne démarre pas de processus persistant : un conteneur ne reste en cours d'exécution que tant que son processus initial (command ou entrypoint) l'est. Si ce processus n'est pas un service de longue durée, le conteneur se ferme dès que la commande est terminée. Par exemple, une commande telle que ["/bin/bash"] se ferme immédiatement, car elle n'a pas de script à exécuter. Pour résoudre ce problème, assurez-vous que le processus initial de votre conteneur démarre un processus qui s'exécute en continu.

• L'application Worker se ferme lorsqu'une file d'attente de tâches est vide : de nombreuses applications Worker sont conçues pour vérifier si une file d'attente contient une tâche et se fermer proprement si la file d'attente est vide. Pour résoudre ce problème, vous pouvez utiliser un contrôleur de job (conçu pour les tâches qui s'exécutent jusqu'à la fin) ou modifier la logique de l'application pour qu'elle s'exécute en tant que service persistant.

• L'application se ferme en raison d'une configuration manquante ou non valide : votre application peut se fermer immédiatement si elle ne dispose pas des instructions de démarrage requises, comme des arguments de ligne de commande, des variables d'environnement ou un fichier de configuration critique.

  Pour résoudre ce problème, commencez par inspecter les journaux de votre application afin de trouver des messages d'erreur spécifiques liés au chargement de la configuration ou aux paramètres manquants. Ensuite, vérifiez les points suivants :

  • Arguments ou environnement de l'application : assurez-vous que tous les arguments de ligne de commande et les variables d'environnement nécessaires sont correctement transmis au conteneur, comme prévu par votre application.
  • Présence du fichier de configuration : vérifiez que tous les fichiers de configuration requis sont présents aux chemins d'accès attendus dans le conteneur.
  • Contenu du fichier de configuration : validez le contenu et le format de vos fichiers de configuration pour détecter les erreurs de syntaxe, les champs obligatoires manquants ou les valeurs incorrectes.

  Ce problème se produit souvent lorsqu'une application est configurée pour lire un fichier installé avec un volume ConfigMap. Si le ConfigMap n'est pas associé, est vide ou comporte des clés mal nommées, une application conçue pour se fermer lorsque sa configuration est manquante peut s'arrêter avec un code de sortie 0. Dans ce cas, vérifiez les paramètres suivants : - Le nom ConfigMap dans la définition du volume de votre pod correspond à son nom réel. - Les clés de ConfigMap correspondent à ce que votre application s'attend à trouver en tant que noms de fichiers dans le volume monté.

Résoudre les problèmes de plantage d'application (code de sortie différent de zéro)

Lorsqu'un conteneur s'arrête avec un code différent de zéro, Kubernetes le redémarre. Si le problème sous-jacent à l'origine de l'erreur persiste, l'application plante à nouveau et le cycle se répète, ce qui aboutit à un état CrashLoopBackOff.

Le code de sortie non nul indique clairement qu'une erreur s'est produite dans l'application elle-même, ce qui oriente vos efforts de débogage vers son fonctionnement interne et son environnement. Voici les problèmes qui entraînent souvent cette résiliation :

• Erreurs de configuration : un code de sortie non nul indique souvent des problèmes liés à la configuration de l'application ou à l'environnement dans lequel elle s'exécute. Vérifiez que votre application ne présente pas les problèmes courants suivants :

  • Fichier de configuration manquant : il est possible que l'application ne parvienne pas à localiser ni à accéder à un fichier de configuration requis.
  • Configuration non valide : le fichier de configuration peut contenir des erreurs de syntaxe, des valeurs incorrectes ou des paramètres incompatibles, ce qui entraîne le plantage de l'application.
  • Problèmes d'autorisations : il est possible que l'application ne dispose pas des autorisations nécessaires pour lire ou écrire le fichier de configuration.
  • Variables d'environnement : des variables d'environnement incorrectes ou manquantes peuvent entraîner un dysfonctionnement ou un échec du démarrage de l'application.
  • entrypoint ou command non valide : la commande spécifiée dans le champ entrypoint ou command du conteneur est peut-être incorrecte. Ce problème peut se produire avec les images nouvellement déployées lorsque le chemin d'accès à l'exécutable est incorrect ou que le fichier lui-même n'est pas présent dans l'image de conteneur. Cette erreur de configuration entraîne souvent le code de sortie 128.

  • Mises à jour d'images non contrôlées (tag :latest) : si les images de votre charge de travail utilisent le tag :latest, les nouveaux pods peuvent extraire une version d'image mise à jour qui introduit des modifications incompatibles.

    Pour garantir la cohérence et la reproductibilité, utilisez toujours des tags d'image spécifiques et immuables (par exemple, v1.2.3) ou des condensés SHA (par exemple, sha256:45b23dee08...) dans les environnements de production. Cette pratique permet de s'assurer que le même contenu d'image est extrait à chaque fois.

• Problèmes de dépendances : votre application peut planter si elle ne parvient pas à se connecter aux autres services dont elle dépend, ou si elle ne parvient pas à s'authentifier ou ne dispose pas des autorisations suffisantes pour y accéder.

  • Service externe indisponible : l'application peut dépendre de services externes (par exemple, des bases de données ou des API) qui sont inaccessibles en raison de problèmes de connectivité réseau ou d'indisponibilité des services. Pour résoudre ce problème, connectez-vous au pod. Pour en savoir plus, consultez Déboguer les pods en cours d'exécution dans la documentation Kubernetes.

    Une fois connecté au pod, vous pouvez exécuter des commandes pour vérifier l'accès aux fichiers et aux bases de données, ou pour tester le réseau. Par exemple, vous pouvez utiliser un outil tel que curl pour essayer d'accéder à l'URL d'un service. Cette action vous aide à déterminer si un problème est dû aux règles réseau, au DNS ou au service lui-même.

  • Échecs d'authentification : l'application peut ne pas pouvoir s'authentifier auprès de services externes en raison d'identifiants incorrects. Inspectez les journaux du conteneur pour rechercher des messages tels que 401 Unauthorized (mauvaises identifiants) ou 403 Forbidden (autorisations insuffisantes), qui indiquent souvent que le compte de service du pod ne dispose pas des rôles IAM nécessaires pour effectuer des appels de service Trusted Cloud by S3NSexternes.

    Si vous utilisez GKE Workload Identity Federation, vérifiez que l'identifiant principal dispose des autorisations requises pour la tâche. Pour en savoir plus sur l'attribution de rôles IAM aux principaux à l'aide de GKE Workload Identity Federation, consultez Configurer l'autorisation et les principaux. Vous devez également vérifier que l'utilisation des ressources du serveur de métadonnées GKE n'a pas dépassé ses limites.

  • Délai avant expiration : l'application peut rencontrer des délais avant expiration lors de l'attente de réponses de services externes, ce qui peut entraîner des plantages.

• Erreurs spécifiques à l'application : si la configuration et les dépendances externes semblent correctes, l'erreur peut se trouver dans le code de l'application. Inspectez les journaux de l'application pour détecter les erreurs internes courantes suivantes :

  • Exceptions non gérées : les journaux d'application peuvent contenir des traces de pile ou des messages d'erreur indiquant des exceptions non gérées ou d'autres bugs liés au code.
  • Blocages ou blocages actifs : l'application peut être bloquée dans un blocage, où plusieurs processus attendent la fin des autres. Dans ce scénario, l'application peut ne pas se fermer, mais elle cesse de répondre indéfiniment.
  • Conflits de ports : l'application peut ne pas démarrer si elle tente de s'associer à un port déjà utilisé par un autre processus.
  • Bibliothèques incompatibles : l'application peut dépendre de bibliothèques ou de dépendances manquantes ou incompatibles avec l'environnement d'exécution.

  Pour trouver la cause première, inspectez les journaux du conteneur pour trouver un message d'erreur ou une trace de pile spécifique. Ces informations vous aident à décider si vous devez corriger le code de l'application, ajuster les limites de ressources ou corriger la configuration de l'environnement. Pour en savoir plus sur les journaux, consultez À propos des journaux GKE.

É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-engine pour rechercher des problèmes similaires. Vous pouvez également rejoindre le canal Slack #kubernetes-engine pour 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.