Se connecter à un conteneur avec `exec` (pour du debug avancé)

Entrer dans le conteneur : quand les logs ne suffisent plus

Parfois, l'analyse des logs (`kubectl logs`) ou l'inspection des métadonnées (`kubectl describe`) ne suffit pas à cerner un problème complexe au sein d'un conteneur. Vous pourriez avoir besoin de vérifier l'état interne du conteneur, d'inspecter son système de fichiers, de tester la connectivité réseau depuis l'intérieur du Pod, ou d'exécuter des outils de diagnostic spécifiques non exposés par l'application principale. C'est là qu'intervient la commande `kubectl exec`.

`kubectl exec` vous permet d'exécuter une commande arbitraire à l'intérieur d'un conteneur déjà en cours d'exécution dans un Pod. C'est un outil extrêmement puissant pour le dépannage avancé et l'investigation en direct, offrant une porte d'entrée directe dans l'environnement d'exécution de votre application.

Cependant, sa puissance implique aussi des responsabilités. L'utilisation de `exec` doit être considérée comme une mesure de débogage plutôt qu'une pratique opérationnelle standard, car elle sort du cadre déclaratif habituel de Kubernetes et peut avoir des implications en termes de sécurité et de reproductibilité.

Exécuter une commande unique dans un conteneur

La forme la plus simple d'utilisation de `kubectl exec` consiste à exécuter une seule commande non interactive dans un conteneur spécifique et à afficher sa sortie.

La syntaxe générale est la suivante :

kubectl exec  [-c ] [-n ] --  [argument1] [argument2] ...

Il est crucial de noter la présence du double tiret `--`. Il sert à séparer les arguments destinés à `kubectl` de la commande et des arguments qui doivent être exécutés à l'intérieur du conteneur. Sans ce séparateur, `kubectl` pourrait essayer d'interpréter les arguments de votre commande interne.

Voici quelques exemples concrets :

• Lister les fichiers dans le répertoire `/app` du conteneur `webserver` du Pod `mon-frontend-pod` :

  kubectl exec mon-frontend-pod -c webserver -- ls /app

• Afficher les variables d'environnement vues par le conteneur `backend-api` du Pod `mon-backend-pod` :

  kubectl exec mon-backend-pod -c backend-api -- env

• Vérifier la connectivité réseau vers un autre service (`mon-service-db`) depuis le Pod `mon-app-pod` (si l'image contient l'outil `ping`) :

  kubectl exec mon-app-pod -- ping -c 3 mon-service-db

Comme pour `logs`, si le Pod n'a qu'un seul conteneur, l'option `-c` peut être omise.

Obtenir un shell interactif : le débogage immersif

Pour des investigations plus poussées, exécuter des commandes une par une peut s'avérer fastidieux. Il est souvent plus pratique d'obtenir un shell interactif directement à l'intérieur du conteneur. Cela vous permet d'explorer le système de fichiers, de lancer des processus, d'éditer temporairement des fichiers (avec prudence !) et d'utiliser les outils disponibles dans l'image du conteneur.

Pour obtenir un shell interactif, vous devez combiner `kubectl exec` avec les options `-i` (ou `--stdin`) et `-t` (ou `--tty`). L'option `-i` permet de passer l'entrée standard (votre clavier) au processus dans le conteneur, tandis que `-t` alloue un pseudo-terminal (TTY), ce qui rend la session interactive et similaire à une connexion SSH.

La commande typique pour ouvrir un shell Bourne (`sh`) est :

kubectl exec -it  [-c ] [-n ] -- /bin/sh

Si l'image du conteneur inclut le shell Bash, vous préférerez peut-être utiliser :

kubectl exec -it  [-c ] [-n ] -- /bin/bash

Si ni `/bin/sh` ni `/bin/bash` n'existent dans l'image (cas fréquent avec les images minimalistes comme celles basées sur `distroless` ou `alpine` sans shell ajouté), cette commande échouera. Une fois connecté, votre terminal se comporte comme si vous étiez à l'intérieur du conteneur. Vous pouvez utiliser les commandes Linux standard disponibles ( `ls`, `cd`, `cat`, `ps`, `netstat`, `curl`, `wget`, éditeurs de texte comme `vi` ou `nano` s'ils sont présents). Pour quitter le shell interactif, tapez simplement `exit` ou utilisez `Ctrl+D`.

Scénarios de débogage avancé avec `exec`

`kubectl exec` ouvre la porte à de nombreuses techniques de dépannage :

• Vérification de la connectivité réseau interne : Utilisez `ping`, `curl`, `wget` ou `telnet` (s'ils sont disponibles) depuis l'intérieur du Pod pour tester la résolution DNS et la connectivité vers d'autres Services, Pods ou points de terminaison externes. Exemple : `curl http://mon-autre-service:8080/health`.
• Inspection des fichiers de configuration : Accédez au système de fichiers du conteneur (`cd /etc/monapp`, `cat config.yaml`) pour vérifier que les fichiers de configuration montés via des ConfigMaps ou des Secrets sont corrects et présents là où l'application s'attend à les trouver.
• Examen de l'environnement d'exécution : Listez les processus en cours (`ps aux`) pour voir si votre application tourne comme prévu, ou vérifiez les variables d'environnement (`env`) effectivement disponibles pour le processus.
• Lancement d'outils de diagnostic spécifiques : Si votre image contient des outils de diagnostic propres à votre application ou à votre langage (par exemple, un client de base de données, un outil de profiling), vous pouvez les lancer via `exec`.
• Modification temporaire pour test : Avec une extrême prudence, vous pourriez modifier un fichier de configuration directement dans le conteneur pour tester rapidement un paramètre, mais rappelez-vous que cette modification sera perdue au redémarrage du conteneur.

Précautions d'usage et alternatives

Malgré sa grande utilité, `kubectl exec` doit être manié avec précaution :

• Caractère éphémère : Toute modification effectuée via `exec` (installation de paquet, modification de fichier) est limitée à la durée de vie de ce conteneur spécifique. Elle ne survivra pas à un redémarrage ou à une recréation du Pod. Ne l'utilisez jamais pour des configurations permanentes.
• Sécurité (RBAC) : La capacité d'exécuter des commandes dans un conteneur est une permission puissante. Contrôlez strictement qui a le droit d'utiliser `exec` via le système RBAC (Role-Based Access Control) de Kubernetes. Limitez cette permission aux rôles qui en ont absolument besoin (administrateurs, équipes de débogage).
• Images minimales : Les bonnes pratiques de sécurité encouragent l'utilisation d'images conteneurs minimales, qui embarquent souvent très peu d'outils, voire pas de shell du tout. Dans ces cas, `kubectl exec` peut être inutilisable ou très limité.
• Alternatives : Pour le débogage dans des environnements à images minimales, considérez les "Ephemeral Debug Containers" (une fonctionnalité plus récente de Kubernetes) qui permettent d'attacher temporairement un conteneur de débogage (avec tous les outils nécessaires) à un Pod existant sans modifier sa définition originale. Les sidecars de débogage peuvent aussi être une option planifiée à l'avance.
• Audit : Assurez-vous que les logs d'audit de votre cluster Kubernetes sont activés et configurés pour enregistrer les appels `exec`, afin de savoir qui exécute quoi et quand.

En résumé, `kubectl exec` est un outil indispensable pour le dépannage en profondeur lorsque les méthodes d'observation standard ne suffisent pas. Il offre une visibilité et un contrôle directs sur l'environnement interne des conteneurs. Utilisez-le judicieusement, comprenez ses limitations et implications, et explorez les alternatives lorsque cela est pertinent.