C’est un besoin qui m’est venu naturellement car devant gérer un nombre croissant de clusters et n’ayant pas toujours de solution type Prometheus installée dans chacun, ni d’aggrégateur d’alertes. Il me fallait donc un outil, si possible en cli, pour savoir d’un coup d’oeil quelle piste privilégier en cas de problème avéré sur une installation.

Cet outil, je l’ai écrit en langage Go. Pour ceux qui ne connaissent pas, il s’agit d’un langage relativement récent (bientôt 10 ans d’existence à l’heure où ces lignes sont écrites), initié par Google, fortement typé et compilé, et désormais le principal langage des plateformes “cloud” et de leurs outils.

Les sources sont visibles sur mon espace Gitlab. Vous y trouverez la documentation associée, mais voici un petit récap en français.

Installation

Pour les systèmes Linux, le plus simple pour l’installer est de récupérer l’artefact de compilation construit par le dernier job CI configuré sur Gitlab, puis de le placer dans un dossier faisant partie de son $PATH :

curl -s -L -o /tmp/kubectl-health.zip https://gitlab.com/guillaume.fenollar/kubectl-health/-/jobs/artifacts/master/download?job=build
sudo unzip -d /usr/bin/ /tmp/kubectl-health.zip

Mais je vous encourage plutôt à cloner le repo, et le builder vous même. Cette méthode est alors compatible avec tous langages d’exploitation.

DST=$GOPATH/gitlab.com/guillaume.fenollar/
mkdir -p $DST && cd $DST
git clone [email protected]:guillaume.fenollar/kubectl-health.git
cd kubectl-health && go build . -o /usr/bin/kubectl-health

Usage

Un plugin Kubectl est simplement un binaire dont le nom commence par kubectl-. La commande kubectl passe donc les arguments tapés par l’utilisateur s’il détecte un binaire matchant le nom de la première commande. Ainsi, pour l’utiliser :

$ kubectl health
INFO Using context cluster-qual
INFO Found 4 nodes, gathering data...
WARNING Conditions detected ! Please review :

LEVEL          NAMESPACE  KIND NAME                        MESSAGE
ALERT         namespace1  pod mydeploy1-xxxxxxxxxx-yyyyy   Pod isn't ready with message : containers with unready status: [container1]
ALERT         namespace2  pod mydeploy2-xxxxxxxxxx-yyyyy   Pod isn't ready with message : containers with unready status: [container2]
WARNING       namespace2  pod kafka-0                      Pod kafka-0's data volume is full at 78%
WARNING                   node qual-master-1               Node's memory available is 21%
WARNING                   node qual-master-1               Node's Image FS is full at 75%

Kubectl-health s’appuie comme sa commande mère, sur un fichier kubeconfig, vous n’avez donc rien à faire. Comme l’utilisation de Kubectl le permet, il est possible de spécifier un namespace ou un contexte différent à l’exécution.

Kubectl utilise alors 3 sources de données pour remonter d’éventuels problèmes :

• L’API Pods pour remonter tout pod et conteneur en échec
• L’API Nodes pour remonter tout problème au niveau d’un objet Node
• L’API stats de chaque Kubelet correspondant à chaque Node du cluster

Cette dernière API est fournie par les Kubelet, et c’est celle qui donne le plus d’informations. Ainsi, Kubectl-health va d’abord lister les nodes du cluster, et contacter les Kubelet sur leur endpoint (décrit dans l’objet Node) en mode insecure (incohérence dans les certificats de celles-ci oblige). Sont alors analysés tout ce qui peut l’être, incluant l’utilisation des volumes persistants sur les pods du node ou encore l’usage CPU/Mémoire du node.

Bien entendu, ce programme est un work-in-progress et sera amélioré au fur et à mesure. N’hésitez pas à m’envoyer vos idées de nouvelles features ou vos observations si le coeur vous en dit ;)