Consultation des logs du Pod

L'importance des logs pour le diagnostic

Accéder à votre application via le navigateur est une excellente validation, mais que se passe-t-il si quelque chose ne fonctionne pas comme prévu ? Ou si vous voulez simplement observer ce que fait votre application ? Dans l'univers des conteneurs et de Kubernetes, l'accès aux journaux (logs) générés par vos applications est fondamental pour le monitoring et le débogage.

Les logs applicatifs capturent les événements, les erreurs, les requêtes traitées et d'autres informations cruciales émises par les processus s'exécutant à l'intérieur de vos conteneurs. Kubernetes centralise l'accès à ces logs via son API et l'outil `kubectl`, vous évitant d'avoir à vous connecter manuellement à chaque conteneur.

Savoir consulter efficacement les logs d'un Pod est donc une compétence indispensable. Cela vous permet de comprendre le comportement de votre application, d'identifier rapidement la cause d'une erreur (par exemple, un Pod en état `CrashLoopBackOff`) ou de suivre son activité en temps réel.

Utilisation de la commande `kubectl logs`

La commande principale pour récupérer les logs d'un conteneur au sein d'un Pod est `kubectl logs`. Sa syntaxe la plus simple est :

kubectl logs 

Avant d'exécuter cette commande, vous devez connaître le nom exact du Pod dont vous voulez voir les logs. Rappelez-vous que les Pods créés par un Déploiement ont des noms uniques, générés automatiquement, qui incluent un hash. Pour retrouver les noms de nos Pods Nginx, nous pouvons réutiliser la commande de l'étape précédente :

kubectl get pods -l app=nginx

La sortie ressemblera à ceci :

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-5d5f47b88d-abcde   1/1     Running   0          5m
nginx-deployment-5d5f47b88d-fghij   1/1     Running   0          5m

Choisissez l'un des noms de Pod listés (par exemple, `nginx-deployment-5d5f47b88d-abcde`) et utilisez-le avec `kubectl logs` :

# Remplacez par le nom réel d'un de vos Pods
kubectl logs nginx-deployment-5d5f47b88d-abcde

Cette commande affichera la sortie standard (stdout) et la sortie d'erreur standard (stderr) du conteneur principal (`nginx-webserver`) depuis son démarrage. Pour Nginx, vous verrez probablement les logs d'accès web, indiquant les requêtes que vous avez faites via le navigateur.

Si votre Pod contenait plusieurs conteneurs, vous devriez spécifier lequel cibler avec l'option `-c `. Dans notre cas, avec un seul conteneur, ce n'est pas nécessaire.

Options utiles : suivi en temps réel et logs précédents

Il est souvent utile de voir les logs arriver au fur et à mesure que l'application s'exécute, par exemple pour observer le traitement d'une requête en direct. L'option `-f` (ou `--follow`) permet de "suivre" le flux de logs :

# Remplacez par le nom réel d'un de vos Pods
kubectl logs -f nginx-deployment-5d5f47b88d-abcde

La commande restera active et affichera les nouvelles lignes de log dès qu'elles sont générées. Essayez d'accéder à nouveau à votre application via le navigateur (http://:30080) pendant que cette commande est en cours d'exécution ; vous devriez voir apparaître de nouvelles lignes correspondant à vos requêtes HTTP. Appuyez sur `Ctrl+C` pour arrêter le suivi.

Une autre option pratique est `-p` (ou `--previous`). Si un conteneur a planté et a été redémarré par Kubernetes (ce qui incrémenterait la colonne `RESTARTS` dans `kubectl get pods`), `kubectl logs` affiche par défaut les logs de l'instance actuelle du conteneur. Pour consulter les logs de l'instance *précédente* (celle qui a planté), vous pouvez utiliser :

# Remplacez par le nom réel d'un de vos Pods (si redémarré)
kubectl logs -p nginx-deployment-5d5f47b88d-abcde

Ceci est extrêmement utile pour diagnostiquer la raison d'un crash récurrent (comme un état `CrashLoopBackOff`). La maîtrise de `kubectl logs` et de ses options est une étape clé pour devenir autonome dans la gestion et le dépannage d'applications sur Kubernetes.