Kubectl describe et kubectl logs

Lorsque vous managez un cluster Kubernetes, il est essentiel de pouvoir diagnostiquer rapidement les problèmes qui peuvent affecter vos pods, conteneurs et services. C’est là que kubectl describe et kubectl logs deviennent indispensables.

• kubectl describe vous permet d’obtenir des informations détaillées sur une ressource Kubernetes (pods, nœuds, services…) et d’identifier les événements récents qui peuvent expliquer un dysfonctionnement.
• kubectl logs vous aide à analyser les journaux d’un conteneur, ce qui est important pour comprendre pourquoi une application plante ou ne fonctionne pas comme prévu.

kubectl logs : Analyser les journaux d’un conteneur

La commande kubectl logs est essentielle pour analyser les journaux d’un conteneur Kubernetes et comprendre pourquoi une application ne fonctionne pas correctement. Elle vous permet de voir les messages de sortie de l’application et de détecter d’éventuelles erreurs.

Cependant, il est important de noter que kubectl logs ne fonctionne pas sur un conteneur qui est en erreur et ne tourne plus. Dans ce cas, on peut utiliser --previous pour récupérer les logs de l’exécution précédente.

Syntaxe générale de la commande

kubectl logs <nom-du-pod>

Exemples d’utilisation :

• Lire les logs d’un pod en cours d’exécution :

  kubectl logs mon-pod

• Lire les logs d’un conteneur spécifique dans un pod multi-conteneur :

  kubectl logs mon-pod -c mon-conteneur

• Afficher les logs en continu (mode live) :

  kubectl logs -f mon-pod

  Regardez du coté de stern pour une meilleure expérience de suivi des logs.

• Récupérer les logs d’un conteneur qui a planté (previous) :

  kubectl logs --previous mon-pod

  Si un pod est en CrashLoopBackOff, cette option vous permet d’accéder aux logs de son exécution précédente.

• Récupérer les logs d’un pod dans un namespace spécifique :

  kubectl logs -n mon-namespace mon-pod

Interprétation des logs et analyse des erreurs

Vérifier les logs d’un conteneur en cours d’exécution

Si votre pod tourne normalement, mais que mon application ne fonctionne pas comme prévu, commencez par lire ses logs avec :

kubectl logs mon-pod

Dans un pod multi-conteneur, on doit préciser le conteneur concerné :

kubectl logs mon-pod -c mon-conteneur

À analyser dans les logs :

• Messages d’erreur ou d’exception (Error, Exception, Failed).
• Logs de démarrage pour vérifier si l’application charge bien sa configuration.
• Requêtes HTTP pour identifier des erreurs (500 Internal Server Error, 403 Forbidden…).

Diagnostiquer un pod en CrashLoopBackOff

Si un pod redémarre en boucle, vous ne pourrez pas voir ses logs en direct, mais vous pouvez récupérer les logs de l’exécution précédente avec :

kubectl logs --previous mon-pod

On peut ainsi identifier la dernière erreur avant que le conteneur ne plante.

Cas d’erreurs courants dans les logs :

• Problème d’environnement (Missing environment variable).
• Échec de connexion à une base de données (Connection refused).
• Fichier de configuration introuvable (FileNotFoundError).

Lorsque kubectl logs ne suffit pas à identifier un problème, j’utilise kubectl exec et kubectl debug pour aller plus loin dans l’analyse et la résolution des erreurs.

kubectl describe : Explorer les ressources Kubernetes**

La commande kubectl describe est essentielle pour obtenir des informations détaillées sur une ressource Kubernetes et comprendre pourquoi un pod, un nœud ou un service ne fonctionne pas correctement. Elle vous permet d’analyser l’état de la ressource, de voir les événements récents et de détecter d’éventuelles erreurs.

Syntaxe générale de la commande

kubectl describe <ressource> <nom>

Exemples d’utilisation :

• Décrire un pod :

  kubectl describe pod mon-pod

• Décrire un nœud :

  kubectl describe node mon-nœud

• Décrire un service :

  kubectl describe svc mon-service

• Décrire un déploiement :

  kubectl describe deployment mon-deploiement

Informations retournées par kubectl describe pod

Lorsque vous exécutez kubectl describe pod mon-pod, la commande retourne plusieurs sections importantes que vous devez analyser en fonction du problème rencontré.

Informations générales

Affiche des détails sur le pod et ses métadonnées :

Name:         mon-pod
Namespace:    default
Node:         worker-node-1
Start Time:   Thu, 20 Feb 2025 10:30:00 +0000
Labels:       app=web
Status:       Running

À vérifier :

• Le nom du nœud où tourne le pod.
• L’heure de démarrage du pod.
• Les labels pour voir s’il correspond bien aux sélections des services ou des déploiements.

Informations sur les conteneurs

Détaille les conteneurs du pod, leurs images et leurs configurations :

Containers:
  my-container:
    Container ID:   docker://abcdef12345
    Image:          nginx:latest
    Ports:          80/TCP
    State:          Running
      Started:      Thu, 20 Feb 2025 10:30:10 +0000
    Ready:          True
    Restart Count:  0

À vérifier :

• Image utilisée (nginx:latest dans cet exemple) → Vérifier que l’image est correcte.
• État du conteneur (Running, Waiting, Terminated).
• Nombre de redémarrages (Restart Count).
  • Si ce nombre est élevé, c’est un signe que le pod plante et redémarre en boucle (CrashLoopBackOff).
• Ports exposés pour vérifier s’ils correspondent au service associé.

Événements récents et erreurs

Affiche la liste des événements récents affectant le pod :

Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  5m                default-scheduler  Successfully assigned default/mon-pod to worker-node-1
  Normal   Pulled     4m                kubelet            Container image "nginx:latest" already present on machine
  Normal   Created    4m                kubelet            Created container my-container
  Normal   Started    4m                kubelet            Started container my-container
  Warning  Unhealthy  2m                kubelet            Liveness probe failed: HTTP probe failed with status code 500

À vérifier :

• Échecs des probes de santé (Liveness probe failed) indiquant un problème d’application.
• Événements en Warning (erreurs de scheduling, image non trouvée, etc.).
• Délais de lancement des conteneurs (Pulling, Created, Started).

Analyse détaillée des erreurs possibles avec kubectl describe

Pod bloqué en Pending

Symptômes : kubectl get pods affiche Pending.

Diagnostic avec :

kubectl describe pod mon-pod

Solutions possibles :

• Vérifier si un volume ne peut pas être monté.
• Voir les événements pour détecter une erreur de scheduling.

CrashLoopBackOff (Redémarrage en boucle)

Symptômes : kubectl get pods montre CrashLoopBackOff.

Diagnostic avec :

kubectl describe pod mon-pod

Solutions possibles :

• Vérifier les logs (kubectl logs mon-pod).
• Vérifier l’environnement (kubectl exec mon-pod -- env).

Erreur ErrImagePull ou ImagePullBackOff

Symptômes : L’image ne se télécharge pas.

Diagnostic avec :

kubectl describe pod mon-pod

Solutions possibles :

• Vérifier que l’image existe (docker pull <image>).
• Vérifier les credentials pour un registre privé.
• Vérfier que les tags d’image sont corrects.

Pod supprimé immédiatement (Evicted)

Symptômes : kubectl get pods montre Evicted.

Diagnostic avec :

kubectl describe pod mon-pod

Solutions possibles :

• Vérifier les événements (kubectl get events).
• Vérifier si le pod manque de ressources (kubectl describe pod).

Autres ressources que vous pouvez analyser avec kubectl describe**

Ressource	Commande
Pods	kubectl describe pod mon-pod
Nœuds	kubectl describe node mon-nœud
Services	kubectl describe svc mon-service
Deployments	kubectl describe deployment mon-deploiement
ConfigMaps	kubectl describe configmap mon-configmap

Grâce à kubectl describe, vous pouvez comprendre pourquoi un pod ne fonctionne pas, voir les événements récents et identifier les erreurs de scheduling ou d’exécution. C’est une première étape essentielle dans le diagnostic Kubernetes.

Conclusion

kubectl describe et kubectl logs sont des outils indispensables pour diagnostiquer et résoudre les problèmes dans un cluster Kubernetes. Tandis que kubectl describe permet d’examiner l’état des ressources et d’identifier les événements récents, kubectl logs offre un accès direct aux journaux des conteneurs pour comprendre les erreurs applicatives.

En complément, kubectl exec permet d’exécuter des commandes dans un conteneur en cours d’exécution, et kubectl debug facilite le dépannage des pods qui ne démarrent pas. En combinant ces commandes, je peux identifier rapidement les causes des dysfonctionnements et appliquer des correctifs adaptés.