Lorsque l’on déploie un cluster kubernetes ou des entités (pods, stockage …) sur un cluster déja existant, il arrive parfois (pour ne pas dire souvent… ) d’être obligé d’investiguer sur les logs des différents éléments. Nous allons ici voir comment injecter le support bundle collecté dans un outil d’analyse capable de remonter la configuration sous forme de ressources exploitables rendant l’analyse plus facile.
Nutanix Kubernetes Platform (NKP) embarque nativement un outil ou plutot une commande qui permet d’exporter un bundle de diagnostique contenant tout un tas d’information sur la configuration en place du cluster lié (au KUBECONFIG utilisé) ainsi qu’un bundle de logs des entités composants le cluster.
La commande en question est la suivante :
nkp diagnose
Cette commande, comme toute commande nkp hérite du kubeconfig déclaré en variable d’environnement ou indiqué avec l’argument –kubeconfig.
En exécutant, cette commande un bundle de diagnostique va être généré et pouvoir être utilisé en analyse sans persistance de connexion à un cluster.
Ce bundle peut servir pour faire appel au support, ou pour s’auto-dépanner sur son installation.
Si l’on exécute cette commande, la collecte de donnée se lance et la sortie suivante apparaît :
Le bundle est ensuite récupérable sous forme d’archive.
En recherchant comment rendre plus aisée l’analyse j’ai tenté d’injecter le bundle dans l’outil d’analyse pour cluster kubernetes suivant : https://github.com/mhrabovcin/troubleshoot-live
Cet outil va être capable de collecter et de remonter les ressources en utilisant un Kubernetes API server. Ici, je laisse nkp gérer ma collecte, mais j’importe le bundle dans l’outil.
Après avoir suivi l’installation documentée dans le readme, j’intègre mon bundle de la manière suivante :
troubleshoot-live serve my-nkp-support-bundle.tar.gz
Une fois executée la commande va monter les ressources nécessaires et m’indiquer le KUBECONFIG à utiliser pour m’y connecter.
Je teste donc ensuite la connexion et l’accès aux ressources :
J’ai donc un aperçu des différentes ressources qui tournaient sur le cluster sur lequel j’ai lancé le diagnostique.
Je peux par exemple lire les logs d’un pod sur lequel je souhaite investiguer :
J’ai donc ici un véritable outil d’analyse de mon bundle qui me permet d’investiguer sur les ressources sans avoir à chercher dans différents fichiers et en utilisant les commandes kubectl habituelles.
En revanche si cet outil non officiel est bien utile, il ne remplace pas une véritable investigation opérée par le support de l’éditeur, mais constitue un moyen rapide de mener les premières recherches.
