Dépannage avancé : Plongée approfondie dans les logs, événements et métriques Kubernetes

Le dépannage Kubernetes devient plus facile lorsque vous séparez trois questions : qu'a dit le conteneur, qu'a fait le plan de contrôle et que montrent les métriques ? Les logs, événements et métriques répondent à différentes parties du même incident.

Les exemples ci-dessous montrent comment utiliser les trois ensemble lorsqu'un pod plante, qu'une image ne peut pas être tirée, qu'une charge de travail ne peut pas être planifiée ou qu'un service semble sain mais répond lentement.

Logs Kubernetes : Les fondations du débogage

Les logs sont les enregistrements détaillés de ce qu'une application ou un processus système fait. Dans Kubernetes, les logs sont générés par les conteneurs s'exécutant dans vos pods. Ils sont souvent le premier endroit à regarder lorsqu'une application ne se comporte pas comme prévu.

Accéder aux logs des conteneurs

La commande kubectl logs est votre outil principal pour récupérer les logs des pods. Elle est polyvalente et offre plusieurs options utiles.

Obtenir les logs d'un seul conteneur dans un pod :
```
kubectl logs <nom-du-pod>
```
Si un pod n'a qu'un seul conteneur, cette commande fonctionne directement.
Obtenir les logs d'un conteneur spécifique dans un pod multi-conteneurs :
```
kubectl logs <nom-du-pod> -c <nom-du-conteneur>
```
Voir les logs d'une instance précédente d'un conteneur planté : Si un conteneur a redémarré en raison d'une erreur, vous pouvez voir ses logs avant le redémarrage en utilisant le drapeau --previous :
```
kubectl logs <nom-du-pod> --previous
```
Suivre les logs en temps réel : Similaire à tail -f, le drapeau -f (ou --follow) vous permet de diffuser en continu les nouvelles entrées de log au fur et à mesure qu'elles sont générées, ce qui est inestimable pour déboguer des problèmes en direct.
```
kubectl logs -f <nom-du-pod> -c <nom-du-conteneur>
```
Filtrer les logs par temps : Vous pouvez spécifier combien de lignes depuis la fin récupérer (--tail) ou les logs d'une durée spécifique (--since).
```
kubectl logs <nom-du-pod> --tail=100 # Dernières 100 lignes
kubectl logs <nom-du-pod> --since=1h # Logs de la dernière heure
```

Solutions de journalisation centralisée

Bien que kubectl logs soit excellent pour le débogage immédiat, ce n'est pas pratique pour la gestion des logs à grande échelle et à long terme. Pour les environnements de production, les solutions de journalisation centralisée sont essentielles. Ces solutions impliquent généralement :

Agents de logs : Exécution d'un agent (par exemple, Fluentd, Fluent Bit, Filebeat) sur chaque nœud pour collecter les logs de tous les pods.
Stockage et indexation des logs : Stockage des logs dans un référentiel central (par exemple, Elasticsearch, Loki, Splunk).
Visualisation et analyse des logs : Fournir une interface pour rechercher, filtrer et visualiser les logs (par exemple, Kibana, Grafana, UI Splunk).

Meilleures pratiques pour la journalisation

Journalisation structurée : Émettre des logs dans un format structuré (par exemple, JSON) pour les rendre facilement analysables et interrogeables par les systèmes de journalisation centralisée.
Niveaux de log appropriés : Utiliser différents niveaux de log (DEBUG, INFO, WARN, ERROR, FATAL) pour catégoriser les messages et contrôler la verbosité.
Éviter les informations sensibles : Ne pas journaliser les données sensibles (mots de passe, PII) directement.

Événements Kubernetes : Le conteur du cluster

Les événements Kubernetes sont des enregistrements des changements d'état et des opérations se produisant dans le cluster. Ils fournissent des informations cruciales sur ce que Kubernetes lui-même fait (ou ne parvient pas à faire) en réponse à votre état souhaité. Les événements sont inestimables pour comprendre pourquoi les pods ne se planifient pas, les images ne se tirent pas ou les volumes ne se montent pas.

Accéder aux événements Kubernetes

Événements à l'échelle du cluster :

kubectl get events

Cette commande montre tous les événements récents dans l'espace de noms actuel. Vous pouvez ajouter --all-namespaces pour voir les événements sur tout le cluster.

Une sortie d'événement typique ressemble à ceci :

LAST SEEN   TYPE      REASON      OBJECT                         MESSAGE
3m21s       Normal    Scheduled   pod/my-app-789c6f66-abcde      Successfully assigned default/my-app-789c6f66-abcde to node01
3m20s       Normal    Pulling     pod/my-app-789c6f66-abcde      Pulling image "example/my-app:1.2.3"
2m58s       Warning   BackOff     pod/my-app-789c6f66-abcde      Back-off restarting failed container app

Événements pour un seul objet :
```
kubectl describe pod <nom-du-pod>
```
La section Events en bas est souvent le moyen le plus rapide de voir les problèmes de planification, de tirage, de montage et de redémarrage pour un seul pod.

Trier les événements par heure de création :

kubectl get events --sort-by=.metadata.creationTimestamp

Ce que les événements vous disent généralement

Les événements sont des enregistrements de courte durée, donc ils sont les meilleurs pour les échecs récents. Recherchez ces raisons courantes :

FailedScheduling : Le planificateur n'a pas pu placer le pod. Vérifiez les sélecteurs de nœuds, les teintes, les tolérances, les demandes de ressources et la capacité disponible.
ImagePullBackOff ou ErrImagePull : Kubernetes n'a pas pu tirer l'image. Vérifiez le nom de l'image, l'étiquette, l'accès au registre et le secret de tirage d'image.
FailedMount : Un volume n'a pas pu monter. Vérifiez la liaison PVC, la classe de stockage, les permissions du nœud et la santé du pilote CSI.
BackOff : Un conteneur continue d'échouer. Associez l'événement avec kubectl logs --previous.

Métriques Kubernetes : La vue des ressources

Les métriques vous disent si le cluster a suffisamment de CPU, de mémoire et de capacité pour la charge de travail. Elles vous aident également à séparer les bugs d'application de la pression sur les ressources.

Vérifications rapides avec metrics-server

Si metrics-server est installé, utilisez kubectl top :

kubectl top nodes
kubectl top pods
kubectl top pod <nom-du-pod> --containers

Une mémoire de pod élevée près de la limite du conteneur correspond souvent à des redémarrages OOMKilled. Un CPU de nœud élevé peut expliquer la latence même lorsque les logs du pod semblent propres.

Métriques approfondies avec Prometheus

En production, Prometheus et Grafana fournissent généralement la vue historique qui manque à kubectl top. Les signaux utiles incluent :

Redémarrages de conteneurs au fil du temps.
Limitation CPU pour les conteneurs avec des limites CPU basses.
Ensemble de travail mémoire comparé aux limites.
Pods en attente par espace de noms.
Latence des requêtes du serveur API et taux d'erreur.
Pression disque du nœud, pression mémoire et saturation réseau.

Corréler logs, événements et métriques

Utilisez une fenêtre de temps et passez du symptôme à la cause :

Vérifiez l'état du pod :

kubectl get pod <nom-du-pod> -o wide
kubectl describe pod <nom-du-pod>

Lisez les logs actuels et précédents :

kubectl logs <nom-du-pod> -c <nom-du-conteneur>
kubectl logs <nom-du-pod> -c <nom-du-conteneur> --previous

Vérifiez les événements récents de l'espace de noms :

kubectl get events --sort-by=.metadata.creationTimestamp

Comparez l'utilisation des ressources :

kubectl top pod <nom-du-pod> --containers
kubectl top node

Par exemple, un pod avec CrashLoopBackOff, des logs précédents se terminant par une erreur de mémoire insuffisante, et des métriques montrant une mémoire proche de la limite pointent vers un problème de limite mémoire ou de mémoire d'application. Un pod bloqué dans Pending avec des événements FailedScheduling et une faible capacité de nœud pointe vers une pression de planification, pas un bug de conteneur.

À retenir

Ne déboguez pas Kubernetes à partir d'un seul signal. Les logs expliquent le comportement de l'application, les événements expliquent les décisions du plan de contrôle, et les métriques expliquent la pression sur les ressources. Lorsque vous les alignez par temps et nom d'objet, les causes racines deviennent beaucoup plus faciles à séparer des symptômes.