Exit Code 143 sur Kubernetes : comprendre les 8 causes et y remédier

Comment diagnostiquer l'Exit Code 143 de Kubernetes

Diagnostiquer le code de sortie 143 revient à déterminer qui a envoyé SIGTERM et pourquoi. Kubernetes utilisant fréquemment ce signal dans la gestion normale des workloads, le code de sortie à lui seul n'indique pas une défaillance.

Commencez par le statut du pod et du conteneur, puis corrélez l'heure de terminaison avec les logs, les événements, les rollouts, l'activité de scaling et les opérations sur les nœuds. Vérifiez également que l'application réagit correctement à la réception de SIGTERM.

Étape 1 : Inspecter le statut du pod

Commencez par vérifier l'état actuel du pod et son statut détaillé :

kubectl get pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace>

Recherchez les redémarrages de conteneurs, les conditions du pod, les événements récents et les informations de terminaison. kubectl describe pod peut aussi révéler des échecs de sondes, une activité d'éviction, des changements de planification et d'autres événements liés à l'arrêt.

Si le pod est géré par un Deployment, un StatefulSet ou un autre contrôleur, identifiez également son propriétaire. Cela aide à déterminer si la terminaison faisait partie de l'activité normale du contrôleur.

Étape 2 : Vérifier le code de sortie du conteneur et le motif de terminaison

Inspectez l'état de terminaison actuel et précédent du conteneur. Pour un conteneur redémarré, Kubernetes peut conserver des détails comme le code de sortie, le motif, le signal et les horodatages :

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.status.containerStatuses[*].lastState.terminated}'

Confirmez que le code de sortie enregistré est bien 143. Vérifiez aussi le motif de terminaison ainsi que les horodatages startedAt et finishedAt, que vous pouvez corréler avec les événements Kubernetes et les logs applicatifs.

Ne partez pas du principe que le code 143 explique à lui seul la cause. Il vous indique que le processus s'est terminé à cause de SIGTERM, mais pas quelle opération Kubernetes ou quel processus externe a initié la terminaison.

Étape 3 : Examiner les logs du conteneur actuel et du précédent

Consultez les logs applicatifs autour de l'heure de terminaison :

kubectl logs <pod-name> -n <namespace>

Si le conteneur a redémarré, examinez les logs de l'instance précédente :

kubectl logs <pod-name> -n <namespace> --previous

Recherchez les messages d'arrêt, les messages de réception de signal, les requêtes inachevées, les erreurs de connexion et les exceptions applicatives. Une séquence propre — réception de SIGTERM, arrêt des nouvelles tâches, fermeture des ressources, puis sortie — indique généralement un arrêt en douceur.

Pour les pods multi-conteneurs, précisez le conteneur concerné avec -c <container-name>.

Étape 4 : Inspecter les événements Kubernetes

Les événements Kubernetes peuvent fournir du contexte sur ce qui s'est passé juste avant la terminaison :

kubectl get events -n <namespace> \
  --sort-by=.metadata.creationTimestamp

Recherchez les messages liés aux sondes en échec, à l'éviction de pods, aux redémarrages de conteneurs, au scaling, à la planification ou aux problèmes de nœuds. Comparez les horodatages des événements avec celui de la terminaison du conteneur.

Les événements sont utiles, mais ne constituent pas une piste d'audit complète. Ils peuvent expirer, et toutes les causes de terminaison de pod ne génèrent pas un événement expliquant clairement pourquoi SIGTERM a été envoyé.

Étape 5 : Vérifier l'activité de déploiement et de rollout

Déterminez si le conteneur s'est arrêté pendant une mise à jour de Deployment ou un autre changement de workload :

kubectl rollout status deployment/<deployment-name> -n <namespace>
kubectl rollout history deployment/<deployment-name> -n <namespace>

Inspectez également les ReplicaSets lors du dépannage d'un Deployment. L'apparition d'un nouveau ReplicaSet autour de l'heure de terminaison indique fortement que les anciens pods étaient remplacés pendant un rollout.

Si le code 143 n'apparaît que lors du déploiement de nouvelles versions de l'application, il s'agit généralement du remplacement normal des pods. La question suivante est de savoir si ces pods se sont arrêtés proprement, sans perdre de requêtes ni de travail.

Étape 6 : Rechercher des événements de scaling, d'éviction ou liés aux nœuds

Vérifiez si des changements de réplicas, l'autoscaling, des drains de nœuds ou des opérations d'infrastructure coïncident avec la terminaison. Pour les workloads utilisant un HorizontalPodAutoscaler, inspectez son état actuel et son comportement récent :

kubectl get hpa -n <namespace>
kubectl describe hpa <hpa-name> -n <namespace>

Inspectez aussi le nœud qui hébergeait le pod :

kubectl describe node <node-name>

Recherchez les arrêts de nœuds, les opérations de maintenance, les conditions de pression, l'activité de l'autoscaler ou les événements liés à l'éviction. Si de nombreux pods sans lien entre eux se terminent à peu près au même moment, une opération au niveau du nœud ou du cluster est plus probable qu'un problème propre à l'application.

Étape 7 : Déterminer si l'application gère correctement SIGTERM

Enfin, vérifiez comment le processus principal de l'application réagit à SIGTERM. Il doit normalement cesser d'accepter de nouvelles tâches, terminer ou annuler en toute sécurité les opérations actives, écrire les données nécessaires, fermer les connexions externes et se terminer avant l'expiration du délai de grâce.

Vérifiez le délai de grâce configuré pour le pod :

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.spec.terminationGracePeriodSeconds}'

Vérifiez aussi que les signaux atteignent réellement l'application. Les conteneurs qui lancent les applications via des scripts shell ou des gestionnaires de processus mal configurés peuvent perturber la transmission des signaux lorsque l'application n'est pas le PID 1.

Si l'arrêt en douceur dépasse systématiquement le délai disponible, améliorez la procédure d'arrêt ou augmentez terminationGracePeriodSeconds le cas échéant. Tester l'application directement avec SIGTERM permet de confirmer que son gestionnaire de signal s'exécute et se termine dans le temps imparti.

Bonnes pratiques pour prévenir l'Exit Code 143 de Kubernetes {#best-practices-to-prevent-kubernetes-exit-code-143}

Voici quelques moyens de prévenir le code de sortie 143 lorsque vous travaillez avec Kubernetes.

1. Implémenter une gestion propre de SIGTERM

Les applications doivent gérer explicitement SIGTERM et entamer un arrêt ordonné à la réception du signal. Un service doit cesser d'accepter de nouvelles tâches, terminer ou annuler en toute sécurité les requêtes actives, fermer les connexions, vider les données en mémoire tampon, puis se terminer.

Assurez-vous que l'application reçoit effectivement le signal. Les scripts shell d'encapsulation et les gestionnaires de processus peuvent empêcher les signaux d'atteindre l'application s'ils ne les transmettent pas correctement. Utiliser exec dans un script d'entrypoint permet de remplacer le shell par le processus de l'application :

exec /app/my-service

L'application devient ainsi le PID 1 et reçoit directement les signaux de terminaison du conteneur.

2. Définir un terminationGracePeriodSeconds adapté

Définissez terminationGracePeriodSeconds avec une durée suffisante pour que l'application achève sa procédure d'arrêt normale. Kubernetes utilise 30 secondes par défaut, ce qui peut être insuffisant pour des requêtes longues, des jobs batch, des consommateurs de messages ou des applications avec un nettoyage conséquent.

Par exemple :

spec:
  terminationGracePeriodSeconds: 60

Basez cette valeur sur les temps d'arrêt observés plutôt que de simplement définir un délai élevé. Les applications doivent malgré tout se terminer aussi vite que possible, car un délai de grâce inutilement long peut ralentir les rollouts, les opérations de scaling et la maintenance des nœuds.

3. Utiliser un hook preStop lorsqu'une logique d'arrêt supplémentaire est nécessaire

Un hook preStop peut exécuter une logique supplémentaire avant que le conteneur ne reçoive son signal d'arrêt habituel. Il est utile lorsque l'arrêt nécessite une commande explicite, le désenregistrement d'un service ou une autre opération en dehors du gestionnaire SIGTERM standard de l'application.

Par exemple :

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "/app/prepare-shutdown.sh"]

Gardez le hook court et fiable. Son temps d'exécution est décompté du délai de grâce du pod : un hook preStop lent réduit donc le temps dont dispose l'application pour s'arrêter après réception de SIGTERM.

4. Faire en sorte que les workers d'arrière-plan s'arrêtent en toute sécurité

Les workers d'arrière-plan ont autant besoin d'une gestion de la terminaison que les services HTTP. Lorsqu'un worker reçoit SIGTERM, il doit normalement cesser de prendre de nouveaux jobs et soit terminer le job en cours, soit remettre le travail inachevé dans la file en utilisant le mécanisme prévu par le système de files d'attente.

Évitez de quitter immédiatement alors qu'un job est partiellement traité. Selon le workload, cela peut entraîner du travail perdu, des traitements en double, des mises à jour de base de données incomplètes ou un état applicatif incohérent.

Pour les jobs de longue durée, assurez-vous que le délai de grâce est compatible avec les temps de traitement attendus. Lorsque les jobs ne peuvent pas se terminer de façon fiable dans ce délai, concevez-les pour être réexécutables ou reprenables.

5. Surveiller le code de sortie 143 dans son contexte

Ne déclenchez pas d'alerte à chaque occurrence du code de sortie 143. Il est attendu lors des déploiements progressifs, de la suppression manuelle de pods, des opérations de scale-down, des drains de nœuds et d'autres activités Kubernetes de routine.

À la place, corrélez le code 143 avec les taux de redémarrage des pods, l'activité de déploiement, les événements Kubernetes, les opérations sur les nœuds, les erreurs applicatives et les requêtes en échec. Des terminaisons SIGTERM répétées sans opération de cluster connue méritent une investigation plus poussée.

Surveiller le contexte environnant fait du code 143 un véritable signal de diagnostic. Il permet de distinguer une activité de cycle de vie saine des échecs de sondes, des workloads instables, des terminaisons de processus inattendues ou des changements d'infrastructure.

FAQ

L'exit code 143 de Kubernetes est-il une erreur ? Généralement non. Le code de sortie 143 signifie que le processus principal du conteneur a reçu SIGTERM et s'est arrêté. Kubernetes envoie ce signal lors d'activités normales comme les rolling updates, la suppression de pods, le scale-down et les drains de nœuds ; ce code seul n'indique donc pas une défaillance.

Quelle est la différence entre l'exit code 143 et l'exit code 137 ? Le code de sortie 143 correspond à 128 + 15 et signifie que le processus s'est arrêté après SIGTERM, ce qui laisse à l'application la possibilité de s'arrêter en douceur. Le code de sortie 137 correspond à 128 + 9 et signifie SIGKILL, qui ne peut pas être intercepté. Il peut survenir lorsqu'un conteneur dépasse son délai de grâce de terminaison ou est tué faute de mémoire.

Combien de temps Kubernetes attend-il avant d'envoyer SIGKILL ? Le délai de grâce de terminaison est de 30 secondes par défaut et se configure via terminationGracePeriodSeconds. Un hook preStop s'exécute dans cette même fenêtre : un hook lent laisse donc moins de temps à l'application pour gérer SIGTERM.

Comment identifier l'origine du SIGTERM ? Commencez par kubectl describe pod et le dernier état de terminaison du conteneur, puis comparez les horodatages avec les événements Kubernetes, l'historique des rollouts, l'activité du HPA et les événements des nœuds. Si rien ne correspond côté cluster, consultez les logs de l'application et du gestionnaire de processus, car un script, un superviseur ou un sidecar peut aussi envoyer SIGTERM.

Faut-il créer des alertes sur l'exit code 143 ? Non, pas à chaque occurrence. Alertez plutôt sur des schémas récurrents, comme des terminaisons SIGTERM répétées sans rollout, scaling ou opération de nœud connus, ou des terminaisons coïncidant avec des requêtes en échec ou une hausse des taux de redémarrage.

Des workloads Kubernetes stables à chaque terminaison avec PerfectScale

Le code de sortie 143 est généralement le signe d'une activité de cycle de vie saine, mais la fréquence des rollouts, des scale-downs et des changements de nœuds rend plus difficile de distinguer les terminaisons de routine des véritables problèmes de résilience. PerfectScale for Kubernetes by DoiT apporte une automatisation adaptée aux workloads avec une approche axée sur la stabilité, en plaçant la santé des applications au cœur de chaque recommandation d'optimisation. Les équipes plateforme, SRE et FinOps disposent d'une vue unique sur la santé, les performances et les coûts du cluster, pour repérer les problèmes de résilience et redimensionner les workloads sans surveillance ni reconfiguration manuelles permanentes.

Principales capacités de PerfectScale for Kubernetes :

• Détection des problèmes de résilience : Podfit offre une vue granulaire de la santé et des coûts du cluster, en priorisant les points nécessitant une attention et en aidant les équipes à identifier rapidement les ressources gaspillées et les problèmes de résilience.
• Right-sizing axé sur la stabilité : le right-sizing contextuel adapte les actions à partir des bases de référence de performance, des schémas de trafic et de la criticité métier, pour que l'optimisation ne se fasse jamais au détriment de la santé applicative.
• Optimisation autonome des workloads : des recommandations fondées sur les données et des workflows d'automatisation redimensionnent les workloads en continu, éliminant le cycle de reconfiguration permanent qui accapare le temps des équipes d'ingénierie.
• Analyse de la configuration des autoscalers : des recommandations concrètes aident à améliorer les configurations HPA et KEDA, tandis qu'Infrafit maximise l'efficacité des autoscalers de nœuds comme Karpenter.
• Visibilité sur l'utilisation des nœuds : Infrafit identifie la capacité inutilisée des nœuds et recommande les nœuds adaptés à vos workloads, pour des performances et une fiabilité optimales du cluster.
• Suivi des ressources au niveau conteneur : surveillez le CPU et la mémoire au niveau des conteneurs pour éliminer le gaspillage et définir les ressources en fonction de l'utilisation réelle.
• Garde-fous et politiques : définissez des règles d'optimisation selon la criticité des workloads et le type d'environnement afin de protéger vos workloads de production.
• Visibilité multi-cloud et multi-cluster : bénéficiez d'une intelligence fondée sur les données, de l'application de politiques et d'actions d'optimisation sur un nombre illimité de clusters et de fournisseurs cloud, y compris le suivi de l'utilisation des GPU.

Prêt à exécuter des workloads Kubernetes fiables et économes ? Découvrez PerfectScale for Kubernetes.