Comment enquêter sur les problèmes de conteneur Kubernetes avec « Kubectl Debug »

Il peut être difficile de diagnostiquer les problèmes d’exécution des charges de travail Kubernetes. Vous aurez peut-être la chance de trouver la cause dans les logs de votre application, via le kubectl logs commande. Dans certains cas, il est cependant impossible d’éviter une session de débogage en direct, où vous interagissez de manière interactive avec vos pods pour découvrir les problèmes.

La kubectl debug La commande simplifie ces tâches de débogage en fournissant un nouveau conteneur éphémère à l’intérieur de votre pod. Cela peut être utilisé pour inspecter l’environnement du pod afin que vous puissiez commencer à résoudre les problèmes qui apparaissent dans vos conteneurs existants.

Se préparer à utiliser Kubectl Debug

kubectl debug a été lancé avec la v1.18 de Kubernetes et Kubectl. Il repose sur la disponibilité de conteneurs éphémères dans votre cluster. Les conteneurs éphémères sont devenus une fonctionnalité bêta dans Kubernetes v1.23 et sont désormais activés par défaut. Vous devrez activer manuellement la porte de fonctionnalité si votre cluster exécute une ancienne version de Kubernetes.

Les conteneurs éphémères sont conçus pour les tâches transitoires où vous devez connecter temporairement un conteneur supplémentaire à un pod existant. Ceci est idéal pour les opérations de débogage où vous souhaitez inspecter avec précision un pod sans affecter les instances de conteneur en direct.

La plupart des images de conteneur manquent d’outils de débogage ; les installer dans un conteneur en cours d’exécution modifierait son environnement et entraînerait potentiellement des effets secondaires. Attacher un conteneur éphémère à votre pod est un moyen plus sûr de débogage qui vous offre un environnement de travail propre. Vous pouvez utiliser une image plus lourde qui comprend tous les outils dont vous avez besoin.

Bien que les conteneurs éphémères fassent partie de leur pod hôte, il y a encore quelques différences à prendre en compte. Les conteneurs éphémères ne prennent pas en charge les liaisons de port, les sondes ou les réservations de ressources, car ils ne sont que de nature temporaire. Ils ne seront jamais redémarrés automatiquement et ne pourront pas être modifiés une fois qu’ils auront été créés. Une liste complète des fonctionnalités prises en charge est disponible dans la documentation.

Utiliser le débogage Kubectl

Avant de continuer, créez un déploiement de base à utiliser à des fins de test :

$ kubectl create deployment nginx --image=nginx:latest
deployment.apps/nginx created

Utilisez ensuite le get pods commande pour trouver le nom du pod de votre déploiement :

$ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-55649fd747-qsnr2   1/1     Running   0          5s

Le pod de notre déploiement s’appelle nginx-55649fd747-qsnr2.

Vous pouvez maintenant utiliser le kubectl debug commande pour démarrer une session de débogage dans votre pod :

$ kubectl debug -it --image=ubuntu:20.04 nginx-55649fd747-qsnr2

La syntaxe de la commande est similaire à un hybride de kubectl create et kubectl debug. L’argument sans nom fourni à la commande identifie un pod existant auquel s’attacher. La --image L’argument spécifie l’image à utiliser pour le nouveau conteneur. Nous utilisons ubuntu:20.04 ici pour obtenir l’accès aux commandes familières incluses dans la distribution Ubuntu Linux.

La -it drapeau équivaut à --stdin --tty. L’inclusion de ces arguments allouera un TTY au conteneur, l’attachera et connectera le flux stdin de votre terminal. Cela vous donne un shell interactif à l’intérieur de votre nouveau conteneur.

Vous pouvez maintenant effectuer vos tâches de débogage depuis votre conteneur éphémère.

Copier des modules

Une autre façon d’utiliser kubectl debug est avec un --copy-to dispute. Cela crée une copie du pod cible et ajoute le conteneur éphémère à la copie. Le Pod d’origine est laissé intact.

$ kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug nginx-555649fd747-qsnr2

Cette fonctionnalité vous donne encore plus d’assurance que les modifications apportées lors du débogage n’auront pas d’impact direct sur votre application de production.

La copie du pod vous permet également d’activer le partage d’espace de noms de processus. Cela rend les processus existants dans votre pod visibles pour votre conteneur éphémère. Il ne peut pas être utilisé avec des conteneurs existants car leur spec.shareProcessNamespace champ sera généralement défini sur false. Fonctionnement kubectl debug avec le --copy-to et --share-processes activera le partage de processus sur le pod copié, rendant cette procédure beaucoup plus intuitive :

$ kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --share-processes nginx-555649fd747-qsnr2

La liste des processus visible par votre conteneur Ubuntu éphémère inclura désormais un processus NGINX :

$ ps ax
PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    9 root      0:00 nginx: master process nginx -g daemon off;

Ce processus est toujours en cours d’exécution dans le conteneur NGINX séparé de votre pod. Le partage d’espace de noms permet également d’accéder au système de fichiers du conteneur cible via /proc:

$ ls /proc/9/root/etc/nginx
conf.d fastcgi_params mime.types modules nginx.conf ...

Copier le Pod de cette manière est donc un puissant outil de débogage. Vous pouvez facilement inspecter les fichiers et les processus du pod à l’aide d’un conteneur séparé préparé avec des outils familiers.

Arguments facultatifs

La --copy-to flag laisse toujours le pod d’origine intact par défaut. Vous pouvez faire en sorte que l’opération agisse comme un remplacement à la place en utilisant --replace. Cela arrêtera le premier Pod.

$ kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --replace nginx-555649fd747-qsnr2

Kubernetes planifiera le pod copié sur n’importe quel nœud disponible. Cela peut être problématique si vous souhaitez garantir un environnement de test cohérent. Ajouter --same-node planifiera la copie sur le nœud du pod existant, éliminant ainsi toutes les différences pouvant exister entre les machines de votre cluster.

$ kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --same-node nginx-555649fd747-qsnr2

Une autre option utile est --env pour définir des variables d’environnement supplémentaires dans votre conteneur éphémère. Vous devrez peut-être l’utiliser pour configurer des outils de débogage ou remplacer les valeurs héritées de votre pod cible.

$ kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --env EDITOR=/usr/bin/nano nginx-555649fd747-qsnr2

Enfin, rappelez-vous que les conteneurs créés par kubectl debug n’ont pas besoin d’être interactifs. Vous pouvez facilement exécuter des commandes ponctuelles sur vos pods à l’aide kubectl exec-comme la syntaxe. La --attach est pris en charge pour contrôler si votre shell est connecté au conteneur lorsque vous n’exécutez pas avec -i (--stdin).

$ kubectl debug --image=ubuntu:20.04 --copy-to nginx-debug --share-processes --attach true nginx-555649fd747-qsnr2 -- ls /proc/9/root/etc/nginx
conf.d fastcgi_params mime.types modules nginx.conf ...

Conclusion

Les contenants éphémères et les kubectl debug La commande fournit une expérience de débogage simplifiée pour les charges de travail Kubernetes. Vous pouvez exécuter des commandes dans un pod en utilisant une image différente de vos conteneurs habituels. Cela vous permet d’accéder à des outils de débogage qui ne sont pas inclus dans l’image de votre application.

kubectl debug peut également créer des copies de Pods et partager leurs processus avec l’original. Ce mécanisme vous permet d’inspecter les processus dans les conteneurs du pod cible, à partir d’un conteneur éphémère séparé sur lequel vous avez un contrôle total. Il fournit des options de débogage plus avancées lorsque vous devez interroger les processus en cours d’exécution.