Plugin Kubectl-debug pour le débogage dans les pods Kubernetes

À la fin de l'année dernière, Reddit a introduit un plugin pour kubectl, qui aide à déboguer dans les pods du cluster Kubernetes - kubectl-debug . Cette idée a tout de suite semblé intéressante et utile à nos ingénieurs, nous avons donc décidé de regarder sa mise en œuvre et sommes heureux de partager nos résultats avec les lecteurs de l'hubr.

Pourquoi est-ce même nécessaire?

Pour le moment, il y a un sérieux inconvénient dans le processus de débogage de quelque chose dans le cadre de pods. L'objectif principal lors de l'assemblage de l'image du conteneur est de la minimiser , c'est-à-dire le rendre aussi petit que possible en taille et contenant le moins possible "d'excès" à l'intérieur. Cependant, lorsqu'il s'agit de problèmes de fonctionnement du logiciel final dans des conteneurs ou de débogage de sa communication avec d'autres services du cluster / extérieur ... le minimalisme nous joue un tour - après tout, il n'y a rien dans les conteneurs pour le processus réel de recherche de problèmes. En règle générale, les utilitaires tels que netstat / ip / ping / curl / wget, etc. ne sont pas disponibles.

Et souvent, tout se termine par le fait que l'ingénieur prépare le logiciel nécessaire directement dans le conteneur en cours d'exécution afin de «voir» et de voir le problème. C'est dans de tels cas que le plugin kubectl-debug semble être un outil très utile - car il évite les douleurs urgentes.

Avec son aide, vous pouvez lancer un conteneur avec tous les outils nécessaires à bord dans le cadre d'un pod de problème avec une seule commande et étudier tous les processus «de l'extérieur», à l'intérieur. Si vous avez déjà rencontré le dépannage de Kubernetes, cela semble attrayant, n'est-ce pas?

Quel est ce plugin?

D'une manière générale, l'architecture de cette solution ressemble à un tas de plugins pour kubectl et à un agent qui commence à utiliser le contrôleur DaemonSet. Le plugin sert des commandes commençant par le kubectl debug … et interagit avec les agents sur les nœuds du cluster. L'agent, à son tour, s'exécute sur le réseau hôte et l'hôte docker.sock est monté dans le conteneur d'agent pour un accès complet aux conteneurs sur ce serveur.

Par conséquent, lorsque vous demandez à lancer un conteneur de débogage dans le module spécifié:
il existe un processus pour identifier le hostIP et une demande est envoyée à l'agent (travaillant sur un hôte approprié) pour lancer un conteneur de débogage dans les espaces de noms correspondant au pod cible.

Une vue plus détaillée de ces étapes est disponible dans la documentation du projet .

Qu'est-ce qui est nécessaire pour travailler?

L'auteur de kubectl-debug prétend être compatible avec les versions du client / cluster Kubernetes 1.12.0+ , cependant, j'avais K8s 1.10.8 à portée de main, sur lequel tout fonctionnait sans problèmes visibles ... avec une seule note: pour que l'équipe de kubectl debug fonctionne sous cette forme, la version kubectl est exactement 1.12+ . Sinon, toutes les commandes sont similaires, mais ne sont appelées que via kubectl-debug …

Lorsque vous démarrez le modèle DaemonSet décrit dans README vous ne devez pas oublier la souillure que vous utilisez sur les nœuds: sans les tolérances appropriées, les pods de l'agent ne s'y installeront pas et, par conséquent, vous ne pourrez pas utiliser les pods vivant sur ces nœuds. peut se connecter avec un débogueur.

L’aide du débogueur est très complète et semble décrire toutes les possibilités actuelles de lancement / configuration du plugin. En général, l'utilitaire satisfait avec un grand nombre de directives à exécuter: vous pouvez attacher des certificats, spécifier le contexte kubectl, spécifier une configuration kubectl distincte ou l'adresse du serveur API de cluster, et plus encore.

Travailler avec un débogueur

L'installation jusqu'au moment où «tout fonctionne» est réduite à deux étapes:

1. exécuter kubectl apply -f agent_daemonset.yml ;
2. installez directement le plugin lui-même - en général, tout est comme décrit ici .

Comment l'utiliser? Supposons que nous ayons le problème suivant: les métriques de l'un des services du cluster ne sont pas collectées - et nous voulons vérifier s'il y a des problèmes de réseau entre Prometheus et le service cible. Comme vous pouvez le deviner, l'image Prometheus n'a pas les outils nécessaires.

Essayons de nous connecter au conteneur avec Prometheus (s'il y a plusieurs conteneurs dans le pod, vous devrez spécifier celui auquel se connecter, sinon le débogueur sélectionnera le premier par défaut):

 kubectl-debug --namespace kube-prometheus prometheus-main-0 Defaulting container name to prometheus. pulling image nicolaka/netshoot:latest... latest: Pulling from nicolaka/netshoot 4fe2ade4980c: Already exists ad6ddc9cd13b: Pull complete cc720038bf2b: Pull complete ff17a2bb9965: Pull complete 6fe9f5dade08: Pull complete d11fc7653a2e: Pull complete 4bd8b4917a85: Pull complete 2bd767dcee18: Pull complete Digest: sha256:897c19b0b79192ee5de9d7fb40d186aae3c42b6e284e71b93d0b8f1c472c54d3 Status: Downloaded newer image for nicolaka/netshoot:latest starting debug container... container created, open tty... [1] → root @ / 

Auparavant, nous avons découvert que le service problématique vit sur l'adresse 10.244.1.214 et écoute sur le port 8080. Bien sûr, nous pouvons également vérifier la disponibilité à partir des hôtes, cependant, pour un processus de débogage fiable, ces opérations doivent être reproduites dans des conditions identiques (ou aussi proches que possible). Par conséquent, la vérification à partir d'un pod / conteneur avec Prometheus est la meilleure option. Commençons par un simple:

  [1] → ping 10.244.1.214 PING 10.244.1.214 (10.244.1.214) 56(84) bytes of data. 64 bytes from 10.244.1.214: icmp_seq=1 ttl=64 time=0.056 ms 64 bytes from 10.244.1.214: icmp_seq=2 ttl=64 time=0.061 ms 64 bytes from 10.244.1.214: icmp_seq=3 ttl=64 time=0.047 ms 64 bytes from 10.244.1.214: icmp_seq=4 ttl=64 time=0.049 ms ^C --- 10.244.1.214 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 61ms rtt min/avg/max/mdev = 0.047/0.053/0.061/0.007 ms 

Tout va bien. Peut-être que le port n'est pas disponible?

  [1] → curl -I 10.244.1.214:8080 HTTP/1.1 200 OK Date: Sat, 12 Jan 2019 14:01:29 GMT Content-Length: 143 Content-Type: text/html; charset=utf-8 

Et il n'y a aucun problème. Ensuite, nous vérifierons si la communication réelle entre Prometheus et le point final avec des métriques a lieu:

  [2] → tcpdump host 10.244.1.214 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 14:04:19.234101 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [P.], seq 4181259750:4181259995, ack 2078193552, win 1444, options [nop,nop,TS val 3350532304 ecr 1334757657], length 245: HTTP: GET /metrics HTTP/1.1 14:04:19.234158 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [.], ack 245, win 1452, options [nop,nop,TS val 1334787600 ecr 3350532304], length 0 14:04:19.290904 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [P.], seq 1:636, ack 245, win 1452, options [nop,nop,TS val 1334787657 ecr 3350532304], length 635: HTTP: HTTP/1.1 200 OK 14:04:19.290923 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [.], ack 636, win 1444, options [nop,nop,TS val 3350532361 ecr 1334787657], length 0 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel 

Des demandes de réponses arrivent. Sur la base des résultats de ces opérations, nous pouvons conclure qu'il n'y a pas de problème au niveau de l'interaction réseau, ce qui signifie (très probablement) que vous devez regarder du côté appliqué. Nous nous connectons au conteneur avec l'exportateur (également, bien sûr, en utilisant le débogueur en question, car les exportateurs ont toujours des images extrêmement minimalistes) et ... nous sommes surpris de constater qu'il y a un problème dans la configuration du service - par exemple, nous avons oublié de diriger l'exportateur vers le bon Adresse de l'application de destination L'affaire est résolue!

Bien sûr, d'autres moyens de débogage sont possibles dans la situation décrite ici, mais nous les laisserons hors du champ de l'article. Le résultat est que kubectl-debug a de nombreuses possibilités d'utilisation: vous pouvez exécuter n'importe quelle image dans le travail, et si vous le souhaitez, vous pouvez même en assembler une spécifique (avec l'ensemble d'outils nécessaire).

Quelles autres applications vous viennent immédiatement à l'esprit?

• Une application "silencieuse", à laquelle les développeurs nuisibles n'ont pas implémenté la journalisation normale. Mais il a la possibilité de se connecter au port de service et de déboguer avec un outil spécifique, qui, bien sûr, ne doit pas être mis dans l'image finale.
• Lancez à côté de l'application de combat identique en mode «manuel», mais avec le débogage activé - pour vérifier l'interaction avec les services voisins.

En général, il est évident qu'il existe beaucoup plus de situations dans lesquelles un tel outil peut être utile. Les ingénieurs qui les rencontrent quotidiennement au travail pourront évaluer le potentiel de l'utilitaire en termes de débogage «en direct».

Conclusions

Kubectl-debug est un outil utile et prometteur. Bien sûr, il existe des clusters et des applications Kubernetes pour lesquels cela n'a pas beaucoup de sens, mais il y a encore plus de cas où il fournira une aide inestimable dans le débogage - surtout s'il s'agit de l'environnement de combat et de la nécessité de trouver rapidement, ici et maintenant, les raisons le problème que vous avez rencontré.

La première expérience d'utilisation a révélé un besoin urgent de pouvoir se connecter à un pod / conteneur, qui ne démarre pas jusqu'au bout (par exemple, il se bloque dans CrashLoopbackOff ), juste pour vérifier à la volée les raisons pour lesquelles l'application ne démarre pas. À cette occasion, j'ai créé un problème correspondant dans le référentiel du projet, auquel le développeur a répondu positivement et a promis la mise en œuvre dans un proche avenir. Très satisfait de la rétroaction rapide et adéquate. Nous attendons donc avec impatience les nouvelles fonctionnalités de l'utilitaire et son développement!

PS

Lisez aussi dans notre blog:

• « Outils pour les développeurs d'applications fonctionnant sur Kubernetes »;
• « Trucs et astuces Kubernetes: accès aux sites de développement »;
• « Kubebox et autres coques de console pour Kubernetes »;
• « Présentation de loghouse - un système open source pour travailler avec les journaux dans Kubernetes »;
• " Monitoring and Kubernetes (revue et reportage vidéo) ."