Utiliser `describe` pour investiguer un problème (Pod, Service...)

Plonger au coeur des ressources avec `kubectl describe`

Lorsque vos applications ou composants Kubernetes ne se comportent pas comme prévu, la commande `kubectl get` fournit un aperçu rapide, mais souvent insuffisant pour comprendre la cause racine du problème. C'est là que `kubectl describe` devient votre outil d'investigation privilégié. Il offre une vue beaucoup plus détaillée de l'état interne d'une ressource spécifique, de sa configuration et, surtout, des événements récents qui l'ont affectée.

Contrairement à `get` qui se concentre sur l'état général, `describe` agit comme une loupe, révélant des informations contextuelles précieuses. Que ce soit un Pod qui refuse de démarrer, un Service qui ne route pas le trafic correctement ou un Déploiement bloqué, `describe` est souvent la première commande à exécuter pour recueillir des indices pertinents.

Nous allons explorer comment utiliser `kubectl describe` spécifiquement pour diagnostiquer les problèmes courants rencontrés avec les Pods et les Services, deux des types de ressources les plus fondamentaux et fréquemment sujets à des dysfonctionnements.

Diagnostiquer les problèmes de Pods avec `describe`

Les Pods sont l'unité d'exécution de base dans Kubernetes, et de nombreux problèmes se manifestent à ce niveau. Utiliser `kubectl describe pod ` est essentiel pour comprendre pourquoi un Pod est dans un état inattendu (par exemple `Pending`, `CrashLoopBackOff`, `Error`, `ImagePullBackOff`).

La sortie de `describe pod` est riche en informations. Portez une attention particulière aux sections suivantes :

• Status: Indique l'état général (Pending, Running, Failed...). S'il est `Pending`, cherchez la raison dans les événements.
• Conditions: Fournit des détails sur l'état du Pod (Initialized, Ready, ContainersReady, PodScheduled). Si `PodScheduled` est `False`, le planificateur (scheduler) n'a pas pu lui assigner de Noeud.
• Containers: Pour chaque conteneur, vérifiez son `State` (Waiting, Running, Terminated), `Reason` (ex: `ContainerCreating`, `CrashLoopBackOff`, `ImagePullBackOff`), `Last State` (en cas de redémarrage), et le nombre de `Restarts`.
• Events: C'est souvent la section la plus cruciale. Elle liste chronologiquement les événements liés au cycle de vie du Pod. Recherchez les événements de type `Warning`. Par exemple :
  • `FailedScheduling`: Indique pourquoi le Pod n'a pas pu être planifié (manque de ressources CPU/mémoire, taints/tolerations, node selectors/affinity...).
  • `FailedMount`: Problème lors du montage d'un volume.
  • `FailedSync` ou `ErrImagePull` / `ImagePullBackOff`: Problème pour télécharger l'image du conteneur (nom incorrect, tag inexistant, problème d'authentification avec le registre).
  • `Back-off restarting failed container`: Indique que le conteneur principal crashe en boucle (`CrashLoopBackOff`). Dans ce cas, il faut consulter les logs du conteneur (`kubectl logs`).
  • `Unhealthy`: Une Liveness ou Readiness Probe a échoué.

Prenons un exemple. Si un Pod `mon-app-pod-123` est en état `Pending`, exécutez :

kubectl describe pod mon-app-pod-123

Si un Pod est en `CrashLoopBackOff`, `describe` vous montrera le conteneur qui pose problème et le nombre de redémarrages. L'étape suivante sera alors d'utiliser `kubectl logs mon-app-pod-123` (et potentiellement `kubectl logs mon-app-pod-123 --previous`) pour comprendre pourquoi l'application à l'intérieur du conteneur crashe.

Investiguer les problèmes de Services avec `describe`

Les Services Kubernetes fournissent une abstraction réseau stable pour accéder aux Pods. Si vous n'arrivez pas à joindre une application via son Service, `kubectl describe service ` peut vous aider à identifier la cause.

Lors de l'analyse de la sortie de `describe service`, concentrez-vous sur ces éléments :

• Selector: Vérifiez que les labels définis ici correspondent exactement aux labels des Pods que le Service est censé cibler. Une faute de frappe ou une incohérence est une cause fréquente de problème.
• Type: Assurez-vous que le type de Service (`ClusterIP`, `NodePort`, `LoadBalancer`) correspond à vos attentes et à votre environnement.
• IP / LoadBalancer Ingress: Pour un Service `ClusterIP`, vérifiez que l'IP est assignée. Pour un `LoadBalancer`, attendez que l'IP externe ou le nom DNS apparaisse dans `LoadBalancer Ingress`. Si ce champ reste vide (``), il peut y avoir un problème avec le contrôleur de cloud provider.
• Ports: Contrôlez que les `Port` (port exposé par le Service), `TargetPort` (port sur lequel le conteneur écoute) et `NodePort` (pour le type NodePort) sont corrects. Le `TargetPort` doit correspondre au port réellement exposé par vos conteneurs applicatifs.
• Endpoints: C'est une section très importante. Elle liste les adresses IP et ports des Pods qui correspondent actuellement au `Selector` et qui sont considérés comme `Ready`. Si cette section est vide (``) alors que vous avez des Pods correspondants en cours d'exécution, plusieurs raisons sont possibles :
  • Le `Selector` est incorrect.
  • Les Pods ciblés n'ont pas le statut `Ready` (peut-être à cause d'une Readiness Probe qui échoue).
  • Il y a un problème réseau ou de configuration plus profond.
• Events: Comme pour les Pods, les événements peuvent signaler des problèmes, notamment lors de la création de Load Balancers externes.

Par exemple, si le Service `mon-frontend-svc` ne semble pas fonctionner, exécutez :

kubectl describe service mon-frontend-svc

Utilisation de `describe` pour d'autres ressources Kubernetes

Bien que nous ayons mis l'accent sur les Pods et les Services, `kubectl describe` est tout aussi utile pour investiguer d'autres types de ressources Kubernetes.

Pour un Déploiement (`kubectl describe deployment `), `describe` vous montre l'état des ReplicaSets gérés, la stratégie de mise à jour, le nombre de réplicas désirés, actuels, mis à jour et disponibles, ainsi que les événements liés aux déploiements (scaling, rollouts). C'est utile pour comprendre pourquoi un déploiement est bloqué ou pourquoi le nombre de Pods n'est pas celui attendu.

Pour un Noeud (`kubectl describe node `), `describe` affiche des informations critiques sur l'état du Noeud : ses `Conditions` (Ready, MemoryPressure, DiskPressure, PIDPressure...), sa capacité et les ressources allouées, la liste des Pods qui y sont planifiés, ainsi que les événements liés au Noeud (comme `NodeNotReady`). C'est indispensable pour diagnostiquer des problèmes au niveau de l'infrastructure du cluster.

De même, `describe` peut être appliqué aux `ReplicaSets`, `StatefulSets`, `DaemonSets`, `ConfigMaps`, `Secrets`, `PersistentVolumeClaims`, `Ingress`, etc. Chaque type de ressource révèle des informations spécifiques et des événements pertinents via la commande `describe`.

L'art de l'investigation avec `describe` : points clés

`kubectl describe` est un couteau suisse indispensable pour tout administrateur ou développeur travaillant avec Kubernetes. Il fournit une vision détaillée et contextuelle qui va bien au-delà des informations sommaires de `kubectl get`.

Lorsque vous rencontrez un problème avec une ressource Kubernetes, prenez le réflexe d'utiliser `describe` sur cette ressource. Portez une attention toute particulière à la section `Events`, qui contient souvent la clé du diagnostic en révélant les erreurs ou les avertissements émis par les contrôleurs Kubernetes.

En combinant les informations obtenues via `describe` (état, configuration, conditions, événements) avec d'autres commandes comme `logs` (pour les applications dans les Pods) et `get -o yaml` (pour voir la configuration complète), vous disposez d'un ensemble puissant d'outils pour identifier et résoudre efficacement les problèmes dans votre cluster Kubernetes.