Introduction
Un problème courant dans les clusters Kubernetes est la mort soudaine de pods sans raison apparente. Dans cet article, nous allons explorer une histoire vraie de débogage d'une telle situation, où un pod a été tué sans être victime d'une erreur OOMKill (Out of Memory Kill). Nous allons découvrir les mécanismes sous-jacents et les étapes de débogage pour identifier la cause racine du problème.
Contexte Technique
Le problème s'est présenté dans un cluster EKS (Elastic Kubernetes Service) sur AWS, où un pod a été tué sans aucune modification de configuration ou de déploiement. L'analyse des données de Grafana a montré que l'utilisation de la mémoire avait augmenté jusqu'à 832 MiB avant de tomber abruptement à zéro, suivie d'une période d'inactivité de 45 minutes avant le redémarrage d'un nouveau pod.
La première étape de débogage a consisté à vérifier si le pod avait été tué en raison d'une utilisation excessive de mémoire (OOMKill), mais il s'est avéré que les limites de mémoire n'avaient pas été configurées pour le pod. Cela signifiait que le conteneur pouvait utiliser autant de mémoire que disponible sur le nœud.
Analyse et Implications
L'analyse des événements Kubernetes a révélé que le nœud lui-même avait été marqué comme non prêt (NodeNotReady) en raison de l'absence de battements cardiaques du processus kubelet. Le kubelet est responsable de l'envoi de battements cardiaques périodiques au serveur API pour indiquer que le nœud est en vie et en bonne santé.
La vérification de l'utilisation du CPU et de la mémoire sur le nœud a montré que le CPU était utilisé à 100 % pendant toute la journée, mais que les pods sur le nœud n'utilisaient que très peu de CPU. Cela a conduit à l'hypothèse qu'un problème de mémoire se produisait au niveau du système d'exploitation ou du noyau.
En utilisant AWS Systems Manager (SSM) pour exécuter des commandes sur l'instance sans SSH, nous avons pu vérifier les statistiques de charge et de mémoire sur le nœud. Les résultats ont montré une charge moyenne élevée et une utilisation de la mémoire très élevée, avec seulement 86 Mo de mémoire libre sur un nœud de 4 Go.
Perspective
Les étapes de débogage ont finalement révélé que le problème était dû à un problème de mémoire au niveau du noyau, avec une fuite de mémoire de 2+ Go qui n'était pas comptabilisée dans les statistiques de mémoire des pods. Cette fuite de mémoire a provoqué un swap thrashing, où le CPU passe la plupart de son temps à attendre les opérations de disque au lieu de faire un travail utile.
Cet exemple montre l'importance de surveiller les ressources système et de comprendre les interactions entre les composants du système pour identifier et résoudre les problèmes de performance et de fiabilité dans les clusters Kubernetes.
