Consulter les logs d'un conteneur avec `logs`

Regarder à l'intérieur des conteneurs : l'importance des logs

Les conteneurs encapsulent vos applications, mais cette isolation rend l'observation directe de leur fonctionnement interne plus complexe qu'avec des processus traditionnels. Les logs applicatifs, qui capturent les événements, les erreurs et les informations de diagnostic générés par vos applications, deviennent alors une source d'information cruciale. Dans l'écosystème Kubernetes, la commande `kubectl logs` est l'outil standard pour accéder à ces précieuses données.

Que ce soit pour vérifier qu'une application a démarré correctement, pour comprendre pourquoi une requête échoue, pour suivre une transaction ou pour diagnostiquer la cause d'un crash, la consultation des logs est une étape incontournable du cycle de vie opérationnel et de développement sur Kubernetes. `kubectl logs` permet d'extraire les flux de sortie standard (stdout) et d'erreur standard (stderr) des conteneurs s'exécutant dans vos Pods.

Maîtriser cette commande et ses options vous permettra de gagner un temps précieux lors du dépannage et d'obtenir une meilleure visibilité sur le comportement de vos applications conteneurisées.

Syntaxe de base et cas du conteneur unique

L'utilisation la plus simple de `kubectl logs` consiste à récupérer les logs d'un Pod qui ne contient qu'un seul conteneur. La syntaxe est directe :

kubectl logs  [-n ]

Par exemple, pour afficher les logs du Pod nommé `mon-app-frontend-7b5d...` dans le namespace par défaut :

kubectl logs mon-app-frontend-7b5d...

Cette commande récupérera l'intégralité des logs conservés par Kubernetes pour ce conteneur (la quantité conservée dépend de la configuration du cluster et de la rotation des logs au niveau du noeud). La sortie affichée correspond à ce que l'application écrit sur sa sortie standard et sa sortie d'erreur standard.

Gestion des Pods multi-conteneurs

Les Pods peuvent contenir plusieurs conteneurs (par exemple, un conteneur applicatif principal et un conteneur "sidecar" pour le logging ou le monitoring). Dans ce cas, `kubectl logs` a besoin que vous spécifiez de quel conteneur vous souhaitez voir les logs.

L'option `-c` (ou `--container`) est utilisée à cet effet :

kubectl logs  -c  [-n ]

Imaginons un Pod `api-gateway-xyz` contenant un conteneur `nginx-proxy` et un conteneur `log-forwarder`. Pour voir les logs du proxy Nginx :

kubectl logs api-gateway-xyz -c nginx-proxy

Si vous omettez l'option `-c` pour un Pod multi-conteneurs, `kubectl` renverra une erreur vous demandant de spécifier un nom de conteneur.

Suivre les logs en temps réel avec `-f`

Souvent, vous ne voulez pas seulement voir les logs passés, mais observer ce qui se passe en direct. L'option `-f` (ou `--follow`) permet de streamer les logs au fur et à mesure qu'ils sont produits par le conteneur, de manière सिमिलaire à la commande `tail -f` sous Linux.

La syntaxe est simple :

kubectl logs -f  [-c ] [-n ]

Par exemple, pour suivre en direct les logs du conteneur `backend-service` dans le Pod `mon-app-backend-123` :

kubectl logs -f mon-app-backend-123 -c backend-service

La commande restera active et affichera les nouvelles lignes de log dès qu'elles apparaissent. Pour arrêter le streaming, utilisez `Ctrl+C`. C'est extrêmement utile pour observer le comportement d'une application lors de tests, de déploiements ou pendant l'investigation d'un problème en cours.

Accéder aux logs précédents avec `--previous`

Un scénario fréquent en débogage est celui où un conteneur crashe et redémarre (par exemple, en entrant dans un état `CrashLoopBackOff`). Lorsque vous utilisez `kubectl logs` sur ce Pod, vous voyez par défaut les logs de la *nouvelle* instance du conteneur, qui peuvent être vides ou ne pas contenir l'erreur initiale.

Pour examiner les logs de l'instance *précédente* du conteneur (celle qui a crashé), utilisez l'option `--previous` :

kubectl logs  --previous [-c ] [-n ]

Si le Pod `worker-job-abc` a un conteneur qui redémarre en boucle :

kubectl logs worker-job-abc --previous

Cette commande affichera les logs de la dernière exécution terminée du conteneur, ce qui est souvent indispensable pour identifier la cause exacte du crash (par exemple, une exception non gérée, une erreur de configuration fatale, etc.). Notez que `--previous` ne fonctionnera que si une instance précédente du conteneur existe et si ses logs sont encore disponibles.

Options utiles pour filtrer et formater la sortie

`kubectl logs` offre plusieurs autres options pour affiner votre recherche :

• `--tail=N` : N'affiche que les `N` dernières lignes de log. Très utile pour obtenir rapidement les logs les plus récents sans être submergé par l'historique complet. Exemple : `kubectl logs mon-pod --tail=50`
• `--since=DURATION` : N'affiche que les logs produits depuis une certaine durée relative (par exemple, `10s`, `5m`, `2h`). Exemple : `kubectl logs mon-pod --since=1h`
• `--since-time=RFC3339_TIMESTAMP` : N'affiche que les logs produits après une date et heure spécifiques (format RFC3339). Exemple : `kubectl logs mon-pod --since-time=2023-10-27T10:00:00Z`
• `--timestamps=true` : Ajoute un timestamp au début de chaque ligne de log récupérée. Utile si l'application elle-même n'inclut pas de timestamps dans ses logs.
• `--limit-bytes=N` : Limite la sortie aux N derniers octets de logs.

La combinaison de ces options permet d'extraire très précisément les informations dont vous avez besoin. Par exemple, pour voir les 100 dernières lignes de logs du conteneur `app` dans le Pod `mon-pod`, produites au cours des 30 dernières minutes, avec timestamps :

kubectl logs mon-pod -c app --tail=100 --since=30m --timestamps=true

Les logs : une fenêtre essentielle sur vos applications

La commande `kubectl logs` est un outil fondamental pour quiconque opère ou développe sur Kubernetes. Elle fournit le moyen principal d'inspecter la sortie des applications exécutées dans les conteneurs, ce qui est indispensable pour la surveillance et le dépannage.

Que vous ayez besoin de consulter l'historique des logs, de suivre l'activité en temps réel, d'investiguer un crash en examinant les logs précédents, ou de filtrer les logs selon des critères temporels ou de taille, `kubectl logs` et ses options (`-c`, `-f`, `--previous`, `--tail`, `--since`...) vous offrent la flexibilité nécessaire.

N'oubliez pas que l'efficacité de `kubectl logs` dépend de la qualité des logs produits par vos applications. Encourager de bonnes pratiques de logging au sein de vos équipes de développement est donc tout aussi crucial que de maîtriser l'outil permettant de les consulter.