Comment enquêter sur les problèmes de conteneur Kubernetes avec “Kubectl Debug”

0
139

Il peut être difficile de diagnostiquer les problèmes d'exécution des charges de travail Kubernetes. Vous pourriez avoir de la chance et trouver la cause dans les journaux de votre application, via la commande kubectl logs. 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 commande kubectl debug simplifie ces tâches de débogage en fournissant un nouveau conteneur éphémère à l'intérieur de votre Cosse. 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.

Préparation à l'utilisation Débogage Kubectl

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. C'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 inclut 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.

Utilisation de Kubectl Debug

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

$ kubectl crée le déploiement nginx –image=nginx:latest deployment.apps/nginx créé

Utilisez ensuite la commande get pods 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

Notre déploiement&#8217 ;s Le pod s'appelle nginx-55649fd747-qsnr2.

Vous pouvez maintenant utiliser la commande kubectl debug 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. L'argument –image spécifie l'image à utiliser pour le nouveau conteneur. Nous utilisons ici ubuntu:20.04 pour accéder aux commandes familières incluses dans la distribution Ubuntu Linux.

Le drapeau -it est équivalent à –stdin –tty. L'inclusion de ces arguments allouera un TTY au conteneur, s'y attachera et connectera le flux stdin de votre terminal. Cela vous donne un shell interactif à l'intérieur de votre nouveau conteneur.

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

Copier des pods

Une autre façon d'utiliser le débogage de kubectl consiste à utiliser un argument –copy-to. 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 champ spec.shareProcessNamespace sera généralement défini sur false. L'exécution de kubectl debug avec l'indicateur –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 :< /p> $ 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

L'indicateur –copy-to 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 programmera 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. L'ajout de –same-node programmera la copie sur le nœud du pod existant, éliminant ainsi toute différence pouvant exister entre les machines de votre cluster.

$ kubectl debug -it –image=ubuntu:20.04 — copier vers 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 ne doivent pas nécessairement être interactifs. Vous pouvez facilement exécuter des commandes ponctuelles sur vos pods à l'aide d'une syntaxe de type kubectl exec. L'argument –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 conteneurs éphémères et la commande kubectl debug offrent 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 distinct 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.

LIRE LA SUITE

  • › Nouveautés de Chrome 104, disponible dès maintenant
  • › N'achetez pas de répéteur Wi-Fi : achetez plutôt celui-ci
  • › Devriez-vous augmenter la puissance de transmission de votre routeur Wi-Fi ?
  • › Premier PC de Radio Shack : 45 ans de TRS-80
  • &rsaquo ; Test de l'Edifier Neobuds S : le bon, le mauvais et le buggy
  • › Quels accessoires pour smartphone valent la peine d'être achetés ?