Interagir avec des Pods

Introduction

Dans ce lab, vous apprendrez les techniques essentielles pour interagir avec des Pods en cours d’exécution. Il s’agit de compétences fondamentales pour le débogage dans Kubernetes, car les workloads sont souvent distribués et ne sont pas directement visibles comme peuvent l’être des processus locaux.

Nous aborderons trois techniques de débogage puissantes :

Journaux : lire le journal de votre application pour voir ce qu’elle indique.
Exec : entrer dans le conteneur pour l’inspecter et y exécuter des commandes.
Redirection de port : créer un tunnel temporaire pour accéder à votre application depuis votre ordinateur local.

Ces compétences sont indispensables à tout ingénieur DevOps ou développeur. À la fin de ce lab, vous serez à l’aise pour examiner des Pods en cours d’exécution.

Consulter les journaux

Dans cette étape, vous apprendrez à inspecter les journaux d’un Pod en cours d’exécution. Considérez les journaux comme la « voix » de votre application. En cas de problème, ils constituent généralement le premier endroit où chercher des indices.

En arrière-plan, kubectl logs lit généralement ce que le processus principal du conteneur écrit sur la sortie standard et la sortie d’erreur standard. C’est pourquoi de nombreuses applications conteneurisées sont conçues pour écrire leurs journaux dans le terminal plutôt que dans des fichiers locaux. Dans Kubernetes, la sortie du terminal est plus facile à collecter et à exposer de manière cohérente pour la plateforme.

L’environnement démarre pour vous, en arrière-plan, un Pod nommé my-nginx. Commencez par attendre que le Pod soit créé :

until kubectl get pod my-nginx > /dev/null 2>&1; do sleep 2; done

Attendez ensuite que son conteneur soit prêt :

kubectl wait --for=condition=ready pod/my-nginx --timeout=300s

Vérifiez maintenant qu’il est en cours d’exécution :

kubectl get pods

Vous devez voir my-nginx avec l’état Running. S’il n’est pas encore prêt, attendez un instant, puis réessayez.

Une fois le Pod en cours d’exécution, utilisez la commande kubectl logs pour lire ce que le conteneur a écrit sur la sortie standard :

kubectl logs my-nginx

Nginx étant un serveur web stable, il peut n’afficher que peu de résultats au début, voire simplement un message indiquant qu’il est prêt à accepter des connexions.

Pour suivre les journaux en temps réel, comme un flux vidéo en direct, ajoutez l’option -f (follow) :

kubectl logs -f my-nginx

Le curseur reste en attente de nouveaux messages. Cette commande est utile pour observer les requêtes au moment où elles arrivent. Appuyez sur Ctrl+C pour arrêter le suivi des journaux et revenir à l’invite de commande du terminal.

Exécuter des commandes dans un conteneur

Dans cette étape, vous dépasserez la simple lecture des journaux et exécuterez des commandes dans le Pod. Vous pourrez ainsi vérifier qu’un fichier de configuration existe, confirmer qu’un outil est installé ou tester la connectivité réseau depuis l’intérieur du Pod.

Pour cela, utilisez la commande kubectl exec. Elle permet d’exécuter une commande dans un conteneur en cours d’exécution. On l’utilise souvent pour ouvrir un shell interactif et entrer ainsi dans le conteneur.

Il s’agit d’une distinction importante : kubectl exec ne vous « déplace » pas vers une autre machine comme le ferait SSH. Il demande au kubelet du nœud de démarrer un nouveau processus dans un conteneur déjà en cours d’exécution. Vous voyez donc le système de fichiers et l’environnement du conteneur, et non ceux de votre terminal local.

Exécutez la commande suivante pour ouvrir un shell bash dans le Pod my-nginx :

kubectl exec -it my-nginx -- /bin/bash

Examinons les options utilisées :

-i (Interactive) : laisse l’entrée ouverte afin que vous puissiez saisir des commandes.
-t (TTY) : alloue un pseudo-terminal pour afficher une invite de commande normale.
-- : indique à kubectl que tout ce qui suit est une commande destinée au conteneur, et non à kubectl.

Votre invite de commande doit devenir similaire à root@my-nginx:/#. Vous vous trouvez maintenant dans le conteneur concerné du cluster Kubernetes.

Listez les fichiers du répertoire pour confirmer que vous êtes dans un nouvel environnement :

ls -F

Vous voyez les fichiers du conteneur Nginx, totalement distincts de ceux de votre espace de travail LabEx.

Examiner l’environnement

Dans cette étape, vous allez examiner l’environnement à l’intérieur du conteneur. Une tâche courante de débogage consiste à vérifier quel système d’exploitation (OS) utilise le conteneur. Cela vous aide à déterminer quelles commandes, comme apt ou apk, sont disponibles.

Cette étape présente également une notion importante concernant les conteneurs : l’image du conteneur détermine les outils et les fichiers de l’espace utilisateur disponibles. Deux Pods peuvent tous deux utiliser « Linux » tout en étant très différents : l’un peut être basé sur Debian, l’autre sur Alpine, tandis qu’un troisième peut contenir presque aucun outil de shell.

Tant que votre invite affiche root@my-nginx:/#, exécutez cette commande pour lire le fichier indiquant la version du système d’exploitation :

cat /etc/os-release

La sortie identifie la distribution Linux, probablement « Debian GNU/Linux ». L’image officielle Nginx est en effet construite à partir de Debian.

Lorsque vous avez terminé votre exploration, quittez le conteneur pour revenir à votre terminal principal. Saisissez :

exit

Votre invite doit redevenir labex:~/project.

Pour confirmer que vous avez terminé cette vérification, créez un fichier nommé os_version.txt et écrivez-y le nom du système d’exploitation trouvé, par exemple « Debian ».

echo "Debian" > ~/project/os_version.txt

Redirection de port

Dans cette étape, vous allez accéder au Pod Nginx grâce à une redirection de port. Par défaut, les Pods sont isolés. Ils ressemblent à des maisons dans un quartier résidentiel fermé : ils peuvent communiquer entre eux, mais les personnes extérieures, comme vous depuis votre terminal local, ne peuvent pas facilement les atteindre.

Pour accéder depuis votre machine locale au serveur web exécuté dans my-nginx, vous pouvez créer un « tunnel temporaire » à l’aide de la redirection de port.

La redirection de port est pratique pour le débogage, mais ce n’est pas la méthode habituelle pour publier une application en production. Elle crée un tunnel temporaire entre votre poste de travail actuel et un seul Pod. Cette méthode convient parfaitement aux inspections et aux tests rapides, car elle évite de créer un Service complet ou de modifier la stratégie réseau externe.

Exécutez la commande suivante pour rediriger votre port local 8080 vers le port 80 du Pod :

kubectl port-forward my-nginx 8080:80 &

Observez bien le & final ! Il demande à Linux d’exécuter ce processus en arrière-plan. Si vous l’omettez, la commande bloquera votre terminal et vous ne pourrez plus rien saisir tant que vous ne l’aurez pas arrêtée.

Vous devez voir un message similaire à Forwarding from 127.0.0.1:8080 -> 80.

Vous pouvez maintenant accéder à la page web Nginx par ce tunnel avec curl :

curl localhost:8080

Vous devez voir le code HTML de la page « Welcome to nginx! ». C’est réussi : vous avez atteint le cluster et récupéré des données par l’intermédiaire du tunnel.

Récapitulatif

Dans ce lab, vous avez pratiqué les trois compétences essentielles pour déboguer des applications Kubernetes :

Journaux : vérifier la sortie de votre application avec kubectl logs.
Exec : entrer dans l’environnement du conteneur avec kubectl exec pour inspecter des fichiers et exécuter des commandes.
Redirection de port : accéder localement à des services internes avec kubectl port-forward.

Ces outils sont votre stéthoscope et votre radiographie. Lorsque vous rencontrez un problème dans Kubernetes, ce sont les premiers outils à utiliser pour en diagnostiquer la cause.