Dépannage des workloads

Introduction

Les déploiements ne se déroulent pas toujours comme prévu. Lorsqu’un problème survient, vous devez disposer d’une méthode de dépannage reproductible.

Dans ce lab, vous allez résoudre « L’affaire de l’image introuvable ».

Dans Kubernetes, le dépannage commence souvent par l’état de l’objet, puis par les événements, avant de passer à une inspection plus détaillée. Ce lab se concentre sur cette méthode fondée sur les éléments observables.

Vous allez :

Créer une scène de crime : déployer volontairement un Pod défectueux.
Enquêter : utiliser les « jumelles » (get) pour constater qu’un problème est survenu.
Rassembler des preuves : utiliser une « loupe » (describe) pour trouver la cause racine.
Résoudre l’affaire : corriger la configuration et observer le rétablissement de l’application.

Créer un Pod défectueux

Commencez par déployer un Pod contenant une faute de frappe volontaire. Cela simule une erreur courante : spécifier une image qui n’existe pas.

Cela rappelle utilement que Kubernetes accepte de nombreux manifests dont les problèmes ne sont détectés que plus tard. Un fichier YAML peut être syntaxiquement valide tout en étant incorrect sur le plan opérationnel. Le dépannage doit donc distinguer « L’objet a-t-il été accepté ? » de « Le workload a-t-il réellement démarré correctement ? ».

Créez un fichier nommé broken-pod.yaml :

nano broken-pod.yaml

Collez le contenu suivant. Remarquez le tag d’image suspect wrongtag123.

apiVersion: v1
kind: Pod
metadata:
  name: broken-pod
spec:
  containers:
    - name: nginx
      image: nginx:wrongtag123

Enregistrez le fichier et quittez (Ctrl+X, Y, Enter).

Déployez le Pod :

kubectl apply -f broken-pod.yaml

Kubernetes accepte le fichier parce que le format YAML est correct. Le « crime » n’a pas encore été détecté.

Observer l’échec

Examinez maintenant l’état de notre déploiement. C’est comme utiliser des jumelles pour observer la scène.

Des états tels que ErrImagePull et ImagePullBackOff sont des symptômes, et non des explications définitives. Ils vous indiquent où poursuivre l’enquête. Un bon dépannage consiste à considérer la sortie d’état comme un premier indice, et non comme un diagnostic complet.

Vérifiez les Pods dans l’espace de noms par défaut :

kubectl get pods

Vous verrez peut-être d’abord ContainerCreating, mais après quelques secondes, l’état devrait probablement devenir ImagePullBackOff ou ErrImagePull.

ImagePullBackOff est la manière dont Kubernetes indique : « J’ai essayé de récupérer cette image, mais j’ai échoué. Je vais patienter un moment, puis réessayer plus tard. »

Cela confirme que la victime, c’est-à-dire le Pod, n’est pas saine.

Examiner les événements

Nous savons qu’il a échoué, mais nous ne savons pas pourquoi. Pour le découvrir, nous devons examiner la situation de plus près.

La commande kubectl describe est votre loupe. Elle affiche les événements internes et les journaux d’une ressource donnée.

La section Events est particulièrement utile, car elle conserve un court récit produit par des composants Kubernetes tels que le scheduler et le kubelet. Lorsque les débutants appliquent directement des corrections au hasard sans lire les événements, ils perdent souvent du temps à résoudre le mauvais problème.

Examinez le Pod défectueux :

kubectl describe pod broken-pod

Cette commande affiche beaucoup d’informations. Faites défiler la sortie jusqu’en bas pour trouver la section Events.

Vous devriez voir quelque chose de similaire :

Type     Reason     Message
----     ------     -------
Normal   Pulling    Pulling image "nginx:wrongtag123"
Warning  Failed     Failed to pull image "nginx:wrongtag123": manifest unknown
Warning  Failed     Error: ErrImagePull

Le message manifest unknown est la preuve décisive. Il signifie que le registre Docker, où sont stockées les images, ne possède aucune référence à nginx:wrongtag123.

Affaire résolue : le tag de l’image n’est pas valide.

Corriger le Pod

Maintenant que vous connaissez la cause racine, vous pouvez corriger le problème.

Cette dernière étape illustre également une méthode plus générale : observer, formuler une hypothèse à partir des éléments disponibles, effectuer une modification ciblée, puis vérifier le rétablissement. Cette boucle rigoureuse est plus fiable que l’application simultanée de plusieurs corrections spéculatives.

Ouvrez à nouveau le fichier broken-pod.yaml :

nano broken-pod.yaml

Corrigez la « faute de frappe ». Remplacez nginx:wrongtag123 par nginx (qui utilise par défaut nginx:latest, une image valide).

apiVersion: v1
kind: Pod
metadata:
  name: broken-pod
spec:
  containers:
    - name: nginx
      image: nginx

Enregistrez le fichier et quittez.

Appliquez la correction. Kubernetes est suffisamment intelligent pour mettre à jour le Pod existant avec ces nouvelles informations.

kubectl apply -f broken-pod.yaml

Observez maintenant le rétablissement :

kubectl get pods -w

Vous devriez voir l’état passer de ImagePullBackOff à Running.

Appuyez sur Ctrl+C pour arrêter la surveillance.

Excellent travail, détective ! Vous avez identifié l’erreur et rétabli le service avec succès.

Résumé

Dans ce lab, vous avez appris la méthode fondamentale de dépannage de Kubernetes :

Observer : vérifiez kubectl get pods pour identifier les workloads défaillants.
Examiner : utilisez kubectl describe pod pour consulter le journal des événements et trouver les messages d’erreur.
Corriger : mettez à jour le manifest YAML et appliquez la correction.

Cette méthode — Get, Describe, Fix — permet de résoudre 90 % des problèmes de déploiement que vous rencontrerez au cours de votre carrière Kubernetes.