Job on Zwindler's Reflection

Recompiler les dashboards Grafana "MetaMonitoring" de Mimir pour Kubernetes

Thu, 12 Dec 2024 18:00:00 +0200

Contexte

Quand on travaille sur l’observabilité, il y a un outil qui vient toujours en tête en premier : Grafana.

Grafana est un outil de visualisation open source développé par Grafana Labs, et je suis sûr que vous le connaissez tous (et j’ai aussi écrit à son sujet de nombreuses fois). Mais au-delà de cela, ils développent également beaucoup d’autres outils utiles dans le paysage de l’observabilité, au point qu’on peut en théorie construire toute sa stack d’observabilité uniquement avec des outils Grafana Labs.

Pour répondre au manque de stockage long terme de Prometheus et au manque de fonctionnalités de haute disponibilité (je n’ai JAMAIS compris pourquoi l’équipe Prometheus refuse de travailler là-dessus), Grafana Labs a forké Cortex il y a quelques années et l’a renommé Mimir.

Je ne vais pas couvrir l’installation de Mimir ici, il y a plein de tutoriels sur Internet et une documentation officielle pour ça.

À la place, je vais parler d’un problème que j’ai avec le chart helm officiel de Mimir, et plus précisément avec les dashboards Grafana intégrés qui viennent avec.

Des dashboards, vous dites ?

Mimir est livré avec de nombreux dashboards Grafana utiles pour s’assurer que les composants fonctionnent correctement.

Ces dashboards sont compatibles avec les différents modes de déploiement de Mimir. Dans Kubernetes, si vous utilisez le chart helm officiel mimir-distributed, cela peut être activé par une simple valeur :

metaMonitoring:
 dashboards:
 enabled: true

Mais, par défaut, tous les dashboards installés via la valeur metaMonitoring dans les charts helm de Mimir sont des manifestes JSON précompilés utilisant jsonnet/mixin.

Par exemple, voici la version précompilée du “Mimir / Overview dashboard” :

github.com/grafana/mimir/blob/2640b8f72127548e9e3da281a763476b03fb4aae/operations/mimir-mixin-compiled/dashboards/mimir-overview.json

Par conception, vous ne pouvez pas changer des choses comme le préfixe du nom des pods mimir, ce qui rend ces dashboards précompilés inutiles dans un environnement type helm où le nom de release (mimir-) est un préfixe du pod.

kubectl -n monitoring get pods
NAME READY STATUS RESTARTS AGE
mimir-alertmanager-0 1/1 Running 0 24h
mimir-alertmanager-1 1/1 Running 0 24h
mimir-compactor-0 1/1 Running 0 24h
mimir-distributor-5d668b479f-ksltr 1/1 Running 1 (24h ago) 6d1h
...

Dans ce cas, tous les dashboards seront cassés, affichant tous “no data” dans Grafana car les données seront incorrectement filtrées. Par exemple, le panneau “Write requests / sec” dans “Mimir / Overview dashboard” a un label job=~"($namespace)/((distributor..., mais notre pod est mimir-distributor, pas distributor :

sum by (status) (
label_replace(label_replace(rate(cortex_request_duration_seconds_count{cluster=~"$cluster", job=~"($namespace)/((distributor.*|cortex|mimir|mimir-write.*))", route=~"/distributor.Distributor/Push|/httpgrpc.*|api_(v1|prom)_push|otlp_v1_metrics"}[$__rate_interval]),
"status", "${1}xx", "status_code", "([0-9]).."),
"status", "${1}", "status_code", "([a-zA-Z]+)"))

La solution est de désactiver le flag metaMonitoring du chart, et de construire / déployer les dashboards séparément.

Procédure

Récupérez les sources de Mimir :

git clone https://github.com/grafana/mimir.git

Heureusement, les fichiers jsonnet/mixin incluent une variable job_prefix qui va nous aider à corriger cela :

sed -i.bak "s/job_prefix: '(\$namespace)\/',/job_prefix: '(\$namespace)\/mimir-',/" operations/mimir-mixin/config.libsonnet

Recompilez les dashboards :

make build-mixin

podman image inspect grafana/mimir-build-image:pr9491-80f5778956 >/dev/null 2>&1 || podman pull grafana/mimir-build-image:pr9491-80f5778956
podman tag grafana/mimir-build-image:pr9491-80f5778956 grafana/mimir-build-image:latest
[...]
make: Leaving directory '/go/src/github.com/grafana/mimir'
 10,10 real 0,02 user 0,01 sys

Note : Si vous n’avez pas docker sur votre machine (j’utilise podman), la commande make va échouer car elle ne peut pas trouver docker et le binaire docker est hardcodé dans les commandes make. Modifiez le Makefile pour remplacer docker par podman.

Les fichiers json dans operations/mimir-mixin-compiled/dashboards sont maintenant construits avec les noms de pods corrects.

Créez un chart helm grafana-dashboards (appelé yourDashboardsChart ici).

helm create yourDashboardsChart

Dans ce chart, créez un répertoire src/dashboards/mimir (pour les sources des dashboards json) à côté du répertoire classique templates contenant les manifestes YAML go-templatés. Nous allons créer les fichiers helm gotemplate juste après :

cp operations/mimir-mixin-compiled/dashboards/* ../yourDashboardsChart/src/dashboards/mimir

Maintenant, pour chaque fichier json généré par jsonnet, nous allons créer un fichier yaml helm gotemplaté, qui à son tour créera une ConfigMap pour chaque dashboard dans notre cluster Kubernetes. Ils ressembleront à ceci :

---
# Source: mimir-distributed/templates/metamonitoring/grafana-dashboards.yaml
apiVersion: v1
kind: ConfigMap
metadata:
 name: mimir-alertmanager-dashboard
 namespace: '{{ $.Release.Namespace }}'
 labels:
 grafana_dashboard: "1"
 annotations:
 k8s-sidecar-target-directory: /tmp/dashboards/Mimir Dashboards
data:
 mimir-alertmanager.json: |-
 {{ $.Files.Get "src/dashboards/mimir/mimir-alertmanager.json" | fromJson | toJson }}

Pour accélérer le processus, vous pouvez réutiliser helm template et quelques commandes bash pour générer tous les fichiers helm gotemplate pour vous :

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

mkdir -p mimir

helm -n monitoring template mimir grafana/mimir-distributed --set metaMonitoring.dashboards.enabled=true > helm-output.yaml

# Compter le nombre de séparateurs de documents
doc_count=$(grep -c '^---$' helm-output.yaml)

# Diviser le fichier YAML en fichiers séparés pour chaque document
csplit -f mimir/helm-output- helm-output.yaml '/---/' "{$((doc_count - 2))}" >/dev/null

# Un peu de nettoyage
for file in mimir/helm-output-*; do
 if grep -q 'kind: ConfigMap' "$file" && grep -q 'dashboard' "$file"; then
 name=$(yq eval '.metadata.name' "$file")
 yq eval -i 'del(.metadata.labels."helm.sh/chart", .metadata.labels."app.kubernetes.io/name", .metadata.labels."app.kubernetes.io/instance", .metadata.labels."app.kubernetes.io/version", .metadata.labels."app.kubernetes.io/managed-by")' "$file"
 yq eval -i '.metadata.namespace = "{{ $.Release.Namespace }}"' "$file"
 yq eval -i '.data |= with_entries(.value = "{{ $.Files.Get \"src/dashboards/mimir/" + .key + "\" | fromJson | toJson }}")' "$file"
 mv "$file" "mimir/${name}.yaml"
 else
 rm "$file"
 fi
done

mv mimir/* ../yourDashboardsChart/templates/mimir

Maintenant, vous devriez avoir tous les fichiers nécessaires pour régénérer les dashboards Grafana dans votre cluster Kubernetes, avec le préfixe correct.

Have fun!

Source

Sauvegarder des dashboards Grafana dans Kubernetes, en s’amusant (j’explique les RBAC, Job et les CronJob)

Tue, 01 Oct 2024 18:00:00 +0200

Note : Pour les allergiques à Kubernetes, cet article peut être vu comme une entrée en la matière, car je vais progressivement explorer certains concepts, de manière très progressive.

Note 2 : par convention dans cet article, j’ai essayé de nommer tous les objets Kubernetes avec une majuscule à tous les mots (exemple : ServiceAccount) pour que ce soit plus clair.

Grafana

Je ne vous ferai pas l’affront de vous présenter Grafana, l’outil de visualisation open source de la société éponyme. C’est un outil que j’utilise depuis un moment et qui est quasiment incontournable dans toutes les solutions de monitoring modernes (ou non ? xD).

D’ailleurs, j’ai écrit déjà quelques articles sur Grafana au fil des années, c’est un outil aussi simple qu’irremplaçable (jusqu’à ce qu’on trouve mieux, bien entendu).

Si vous avez déjà utilisé au moins une fois Grafana, vous savez donc que les visualisations sont organisées comme suit :

des dossiers
dans lesquels on range des dashboards
qui contiennent des panels (nos visualisations)

On peut donc créer des dashboards à gogo en fonction du besoin, les cloner, les modifier, les importer depuis un magasin sur grafana.com (assez inutilisable maintenant, mais bon) et en afficher le code JSON.

Et ça, c’est super cool, parce que si mon Grafana brûle (mes machines persos ne sont pas hébergées dans les conditions les plus pros possibles… 😱), je n’ai pas envie de tout perdre. Mais aller régulièrement copier / coller le code JSON de chaque dashboard, c’est pénible.

Because I’m API

Un truc qui est cool avec Grafana, c’est que comme tout logiciel un peu pro qui se respecte, il dispose d’une API. Je ne vais pas juger de sa qualité globale d’API (vous connaissez peut-être bien mieux que moi), mais elle a le mérite d’exister.

Récemment, je me suis donc demandé quelle quantité d’effort, il faudrait déployer pour sauvegarder de manière automatisée des dashboards Grafana avec l’API et Kubernetes (oui hein, vous n’allez pas y couper).

Partons donc du principe que j’ai un cluster Kubernetes sur lequel j’ai déployé la chart Helm officielle de Grafana (rappel, Helm, c’est à la fois un package manager et un moyen de déployer des applications dans Kubernetes).

À partir de là, de quoi j’ai besoin ?

Je suis le roi des fainéants, je ne veux pas avoir à aller créer les accès dans Grafana moi même (via 3 clics clics). Il faut donc que j’automatise la création d’un token pour communiquer avec l’API
Une fois que j’ai mon token, je veux créer une tâche périodique qui va se connecter à l’API, lister les dashboards disponibles et les sauvegarder sur un bucket s3 chez Scaleway (il y a 75 Go gratuit dans le free-tier, ça suffira largement)

Se préparer à créer un token

Bon, là en apparence, on se retrouve face à un problème d’œuf / poule. Comment je fais pour me connecter à l’API si je n’ai pas un accès à l’API ?

Heureusement, on va tricher… grâce à Kubernetes 😏

Quand on déploie Grafana dans Kubernetes, la chart officielle va créer un Secret (au sens Kubernetes du terme) qui contient le login / password du compte local administrateur de Grafana.

apiVersion: v1
kind: Secret
metadata:
 creationTimestamp: "2024-10-01T13:11:48Z"
 name: grafana
 namespace: grafana
 resourceVersion: "1234567"
 uid: deadbeef-dead-cafe-baba-123456789012
data:
 admin: YWRtaW4=
 password: TmV2ZXJHb25uYUdpdmVZb3VVcAo=
type: Opaque

S’il est déconseillé de l’utiliser au jour le jour (mieux vaut utiliser des comptes nominatifs, idéalement via un Identity Provider), c’est super pratique ici !

Il suffit de créer un Job Kubernetes avec suffisamment de droits pour lire ce Secret, qui va se connecter (une seule fois) sur l’API avec le compte admin, créer un token, le récupérer, et le stocker dans un autre Secret !

Sans rentrer à fond dans les détails de comment fonctionne le RBAC (Role Based Access Control) dans Kubernetes, voilà à quoi ça ressemble :

---
apiVersion: v1
# le compte de service (ServiceAccount) qui va être utilisé par le Job et qui a besoin de droits particuliers
kind: ServiceAccount
metadata:
 name: grafana-backup-sa
 namespace: grafana
---
apiVersion: rbac.authorization.k8s.io/v1
# le rôle, c'est la politique de sécurité qui va nous permettre de faire des trucs
kind: Role
metadata:
 namespace: grafana
 name: grafana-backup-role
rules:
# ici je n'autorise qu'à lire le secret contenant l'admin/password de grafana, pas plus
- apiGroups: [""]
 resources: ["secrets"]
 resourceNames: ["grafana"]
 verbs: ["get"]
# ici, je vais autoriser le fait de modifier un secret qui s'appelle grafana-backup
- apiGroups: [""]
 resources: ["secrets"]
 resourceNames: ["grafana-backup"]
 verbs: ["get", "update", "patch"]
# ici, je vais autoriser le fait de créer des secrets
- apiGroups: [""]
 resources: ["secrets"]
 verbs: ["create"]
---
# ici, je lie simplement ServiceAccount à un Role pour lui donner les droits dont j'ai besoin
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: grafana-backup-rolebinding
 namespace: grafana
subjects:
- kind: ServiceAccount
 name: grafana-backup-sa
 namespace: grafana
roleRef:
 kind: Role
 name: grafana-backup-role
 apiGroup: rbac.authorization.k8s.io

Note : vous aurez remarqué que je n’ai pas autorisé la création ET la modification du Secret grafana-backup en une seule étape, mais en deux. Ceci est dû à une limitation de l’API de Kubernetes, qui ne permet pas de limiter la création d’un objet via son “ressource name”. Je vous laisse aller lire la doc officielle si ça vous intéresse.

Sachez que je me suis un peu “embêté” à gérer la politique de droits et qu’on aurait pu faire bien plus simple. Mais c’est pour respecter le principe en sécurité informatique du moindre privilège (c’est important).

Bon… on va le créer, ce token ??

Maintenant qu’on a géré les aspects de sécurité (ça limitera les possibilités d’un attaquant qui réussirait à prendre la main sur notre Pod / container), on peut créer la tâche qui va créer le token.

Ici, il n’y a pas de raison de laisser tourner un container ad vitam une fois que le token est créé, on peut l’éteindre. Pour ça, il existe un objet dans Kubernetes qui s’appelle le Job (avec une gestion d’erreur et de retry intégré). Voilà à quoi il va ressembler :

---
apiVersion: batch/v1
kind: Job
metadata:
 name: grafana-backup-api-token-job
 namespace: grafana
spec:
 template:
 spec:
 # on lui donne bien le bon ServiceAccount sinon on a fait tout ce RBAC pour rien T_T
 serviceAccountName: grafana-backup-sa 
 containers:
 - name: grafana-create-api-token
 # une petite astuce pour de la bidouille, merci Jérôme :-*
 image: nixery.dev/shell/curl/jq/kubectl:latest
 # on "monte" le Secret Kubernetes comme des fichiers dans notre container
 volumeMounts:
 - name: grafana-secret-volume
 mountPath: /etc/grafana-secret
 readOnly: true
 command:
 - /bin/sh
 - -c
 - |
 # Comme on a monté le secret dans notre container, c'est super facile de récupérer
 # l'utilisateur et le mot de passe admin sans avoir à le stocker nulle part (surtout pas sur github)
 GRAFANA_ADMIN_USER=$(cat /etc/grafana-secret/admin)
 GRAFANA_ADMIN_PASS=$(cat /etc/grafana-secret/password)

 # On peut maintenant faire une requête HTTP via curl sur l'API de Grafana
 GRAFANA_API_TOKEN=$(curl -s -X POST http://@IPgrafana:80/api/auth/keys \
 -u "$GRAFANA_ADMIN_USER:$GRAFANA_ADMIN_PASS" \
 -H "Content-Type: application/json" \
 -d '{
 "name": "Kubernetes Backup Token",
 "role": "Admin",
 "secondsToLive": 31536000
 }' | jq -r '.key')

 # On termine par stocker le token dans le nouveau Secret grafana-backup
 kubectl create secret generic grafana-backup \
 --from-literal=GRAFANA_API_TOKEN=$GRAFANA_API_TOKEN \
 --dry-run=client -o yaml | kubectl apply -f -
 restartPolicy: OnFailure
 volumes:
 - name: grafana-secret-volume
 secret:
 secretName: grafana

Normalement, avec ce bon script code BASH, j’ai réconcilié les amateurs de bash avec Kubernetes.

Comment ça, “non” ?

Il ne me reste plus qu’à appliquer le manifest YAML sur mon cluster Kubernetes et le Secret grafana-backup contenant la clé d’API devrait apparaitre sur notre cluster :

kubectl apply -f job.yaml

kubectl get secrets
NAME TYPE DATA AGE
grafana-backup Opaque 1 1m

kubectl describe secret grafana-backup
Name: grafana-backup
Namespace: grafana
Labels: <none>
Annotations: <none>

Type: Opaque

Data
====
GRAFANA_API_TOKEN: 104 bytes

Première victoire :)

RBAC, again

On peut s’attaquer à la deuxième partie du problème : comment récupérer puis sauvegarder les JSON ?

Ben, avec une nouvelle couche de moindres privilèges, pardi !!

Vous connaissez la musique maintenant. On crée un ServiceAccount, on ne lui donne le droit qu’à lire les Secrets qui nous intéressent via un Role / RoleBinding pour ne pas faciliter le travail d’un attaquant qui aurait compromis mon Pod.

---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: grafana-backup-cron-sa
 namespace: grafana
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: grafana
 name: grafana-backup-cron-role
rules:
- apiGroups: [""]
 resources: ["secrets"]
 resourceNames: ["grafana-backup", "grafana-backup-s3-credentials"]
 verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: grafana-backup-cron-rolebinding
 namespace: grafana
subjects:
- kind: ServiceAccount
 name: grafana-backup-cron-sa
 namespace: grafana
roleRef:
 kind: Role
 name: grafana-backup-cron-role
 apiGroup: rbac.authorization.k8s.io

Petite subtilité, ici, je vais aussi devoir créer un Secret supplémentaire pour que mon container puisse s’authentifier sur le bucket S3 sur lequel je vais déposer mes JSONs. Je ne rentre pas dans les détails, on sort du cadre de l’article, vous pouvez aller lire la doc officielle de scaleway qui est plutôt bien faite (Using Object Storage with the AWS-CLI).

Voilà à quoi ressemble le Secret grafana-backup-s3-credentials :

apiVersion: v1
kind: Secret
metadata:
 name: grafana-backup-s3-credentials
 namespace: grafana
type: Opaque
stringData:
 # le Secret se compose de 2 entrées, qui seront montés comme des fichiers textes 
 # dans le container ; pratique pour des fichiers de config avec des secrets !!
 credentials: |
 [default]
 aws_access_key_id=SCxxxxxxxxxxxxxxxxxx
 aws_secret_access_key=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 config: |
 [default]
 region = fr-par
 output = json
 services = scw-fr-par
 [services scw-fr-par]
 s3 =
 endpoint_url = https://s3.fr-par.scw.cloud

Et pour finir, on veut donc créer une tâche planifiée, qui va s’occuper de réaliser notre sauvegarde régulièrement. Dans Kubernetes, il s’agit de l’objet CronJob, qui va lancer périodiquement des Job (le même qu’on a vu précédemment).

---
apiVersion: batch/v1
kind: CronJob
metadata:
 name: grafana-backup-cronjob
 namespace: grafana
spec:
 schedule: "0 */2 * * *"
 jobTemplate:
 spec:
 template:
 spec:
 serviceAccountName: grafana-backup-cron-sa
 containers:
 - name: grafana-backup
 image: nixery.dev/shell/curl/jq/awscli:latest
 volumeMounts:
 - name: grafana-backup-s3
 mountPath: /.aws/credentials
 subPath: credentials
 - name: grafana-backup-s3
 mountPath: /.aws/config
 subPath: config
 restartPolicy: OnFailure
 env:
 - name: GRAFANA_API_TOKEN
 valueFrom:
 secretKeyRef:
 name: grafana-backup
 key: GRAFANA_API_TOKEN
 command:
 - /bin/sh
 - -c
 - |
 # Ici, on récupère un gros JSON listant les dashboards et on utilise jq pour extraire l'identifiant unique "uid"
 dashboards=$(curl -s -H "Authorization: Bearer $GRAFANA_API_TOKEN" 'http://@IPgrafana:80/api/search?query=&type=dash-db' | jq -r '.[] | .uid')

 # On boucle ensuite sur la liste des uid
 for uid in $dashboards; do
 # On récupère le JSON qu'on copie en local
 dashboard_json=$(curl -s -H "Authorization: Bearer $GRAFANA_API_TOKEN" http://@IPgrafana:80/api/dashboards/uid/$uid)
 echo "$dashboard_json" > /tmp/dashboard-$uid.json

 # Puis on utilise aws-cli pour uploader le fichier sur notre bucket s3
 aws s3 cp /tmp/dashboard-$uid.json s3://grafana-backup/grafana-backups/dashboard-$uid.json --profile default
 done
 volumes:
 - name: grafana-backup-s3
 secret:
 secretName: secret-grafana-backup-credentials

Toutes les deux heures, nos dashboards seront tous sauvegardés sur notre bucket chez Scaleway. Si la fonction de versioning a été activé sur le bucket, on pourra même garder un historique des versions.

Deuxième victoire :)

Conclusion

Ok, écrire ces scripts et les manifests qui vont avec a surement pris un peu plus de temps que d’aller manuellement créer un token dans l’UI de Grafana, puis de le donner en dur dans un gros script bash.

Cependant, il y a quand même quelques différences avec cette approche :

A part pour les crédentials du bucket S3 (et encore on aurait pu utiliser minIO dans Kubernetes), on a manipulé aucun identifiant. Toute cette gestion des Secrets est déléguée à Kubernetes, loin de l’admin (avec les limitations que ça peut avoir). On n’aura pas de leaks sur github de secrets git-és par erreur et si on gère son RBAC correctement, seuls les Pods qui sont habilités à lire ses Secrets pourront le faire.
Tout est géré “as-code” et automatisé. Le faire une fois à la main va plus vite. Le faire 100 fois, car on a 100 clusters identiques, c’est quand même dommage.
On profite des fonctions de Kubernetes de gestion des erreurs et de retries des Jobs et des Cronjobs. C’est du code (bash ou autre) en moins à gérer si on veut fiabiliser l’outil dans une utilisation plus “industrielle”.

Que je vous aie convaincu ou pas, au-delà de l’exemple, le but était surtout d’introduire quelques concepts de Kubernetes (le RBAC et les Jobs, comment on construit des manifests, …) et j’espère que ça vous a plu.

Bonus

Si vous trouvez ces scripts trop limités pour vos besoins, vous pouvez aller voir les outils suivants, plus poussés. Attention cependant, certains ne sont pas/plus maintenu, et je n’ai pas audité le code. A vos risques et périls donc :

kubectl tips and tricks n°2

Mon, 20 Jan 2020 07:30:00 +0000

kubectl

Comme vous pouvez le voir, il s’agit du 2ème article d’une série sur la productivité quand on est dans un environnement Kubernetes. Et qui dit productivité dit forcément ligne de commande, donc kubectl :trollface:!

Le premier article, si vous l’avez loupé, est toujours disponible ici : kubectl tips and tricks n°1. J’avais parlé du flag “wait”, de comment relancer un Job ou un CronJob et de comment utiliser les selectors.

Et j’ai aussi écris un article sur kubectx et kubens qui pourrait vous plaire.

Normalement, les astuces que je vais vous montrer ici ne sont pas dans la plupart des tutos que j’ai pu trouver sur le net. Cet article se concentre tout particulièrement sur les Secrets de Kubernetes.

C’est parti pour du fun avec kubectl !

Encoder/décoder facilement en base64 les Secrets

Quelque chose qu’on a TOUT le temps à faire quand on manipule les objets de type Secrets dans Kubernetes, c’est d’afficher en clair les “secrets” contenus dans notre Secret (ou de les encoder).

Car, pour ceux qui ne le savent pas, les Secrets dans Kubernetes ne sont malheureusement pas très secrets, puisqu’il s’agit ni plus ni moins que des strings encodées en base64 (ce qui est donc TOUT sauf secure). A vrai dire, je me demande même pourquoi s’être embêter à les encoder tout court. La seule sécurité qu’on ajoute par rapport aux ConfigMaps, c’est simplement que la string n’est pas lisible par un humain qui passerait sa tête par dessus votre épaule.

Enfin bref, vous allez surement devoir encoder ou décoder des strings en base64 et c’est parfois un peu pénible. La méthode communément admise est simplement d’utiliser les binaires linux echo et base64.

echo "ma string" | base64
bWEgc3RyaW5nCg==
echo bWEgc3RyaW5nCg== | base64 -d
ma string

C’est relou à taper, mais c’est relativement trivial.

It’s a trap !

Sauf qu’il y a des pièges !

Le premier vous l’aurez à l’encodage. Dans mon premier exemple, la string est très courte. Et parfois, la taille compte.

echo "ma string très longue string pour montrer que ça va pas le faire" | base64
bWEgc3RyaW5nIHRyw6hzIGxvbmd1ZSBzdHJpbmcgcG91ciBtb250cmVyIHF1ZSDDp2EgdmEgcGFz
IGxlIGZhaXJlCg==

Ici, on se retrouve avec un saut de ligne dans notre string en sortie. Mais, si vous copiez collez ça dans votre YAML Kubernetes, vous allez vous prendre une bonne grosse erreur de syntaxe.

Le YAML ne sera valide que si vous mettez la string complète, sur une seule ligne.

echo "ma string très longue string pour montrer que ça va pas le faire" | base64 -w0
bWEgc3RyaW5nIHRyw6hzIGxvbmd1ZSBzdHJpbmcgcG91ciBtb250cmVyIHF1ZSDDp2EgdmEgcGFzIGxlIGZhaXJlCg==

Et c’est pas fini !

Le 2 ème piège est encore un souci de saut de ligne, mais dans la string en base64 cette fois.

En fait, c’est hyper traitre car vous n’allez pas le voir à l’écran de prime abord, mais il faut savoir que echo rajoute un saut de ligne à la fin de votre string. Le retour que vous avez eu en base64 contient donc un saut de ligne, qui sera quasiment systèmatiquement non souhaité lorsqu’on gère des Secrets.

La bonne commande n’est donc pas echo mais echo -n !

#Pas bien
echo "ma string" | base64
bWEgc3RyaW5nCg==
#Bien
echo -n "ma string" | base64 -w0
bWEgc3RyaW5n

Ok ça commence à devenir franchement pénible…

Pour décoder heureusement, c’est plus simple. La commande donnée au début suffit, même s’il sera plus safe de rajouter le “-n” au echo :

echo -n bWEgc3RyaW5n | base64 -d
ma string

Gagner quelques caractères

Comme je suis fainéant, j’ai cherché une astuce pour gagner quelques caractères à taper en moins. Il existe une solution, mais qui ne marche malheureusement que pour decode, puisque dans le cas de l’encodage on risquera d’ajouter un saut de ligne non souhaité :

echo bWEgc3RyaW5n | base64 -d
base64 -d <<< bWEgc3RyaW5n
ma string

On vient de s’économiser 3 caractères (waaaah) mais surtout un “|”, bien plus pénible à faire sur un clavier azerty standard que 3 “<”.

Je vous l’accorde, c’est pas foufou.

Un peu plus simple

Heureusement, mon collègue Julien (aka JUL, car il est fan de JUL, bien entendu) nous a écris un petit script pour nous faciliter la vie, donc je vous le partage :

dgermain:~$ cat > b64 <<EOF
> #!/bin/bash
> echo -e "Base64 encoding.. \n"
> for arg in "\$@"; do
> echo "\$arg :"
> echo -n "\$arg" | base64
> echo
> done
> EOF
dgermain:~$ cat > b64d <<EOF
> #!/bin/bash
> echo -e "Base64 decoding.. \n"
> for arg in "\$@"; do
> echo "\$arg :"
> echo -n "\$arg" | base64 -d
> echo
> done
> EOF
dgermain:~$ sudo cp b64* /usr/local/bin/

Vous pouvez maintenant invoquer directement b64 suivi d’un certain nombre de strings pour avoir leur valeur encodée, ou b64d suivi d’un certain nombre de string pour les décoder.

Dernière astuce et après j’arrête

Si jamais vous voulez à l’écran toutes les strings encodées en base64 dans un Secret Kubernetes en une seule étape, j’ai également trouvé ce oneliner pas piqué des hannetons sur Stackoverflow qui tire parti de la possibilité de faire des gotemplates directement dans kubectl :

kubectl get secret name-of-secret -o go-template='
{{range $k,$v := .data}}{{printf "%s: " $k}}{{if not $v}}{{$v}}{{else}}{{$v | base64decode}}{{end}}{{"\n"}}{{end}}'

Il faudra probablement que je fasse un article entier sur le go-templating avec kubectl car c’est juste ouf ce qu’on peut faire avec ;-)

kubectl tips and tricks n°1

Wed, 30 Oct 2019 07:00:44 +0000

kubectl

Ça fait un moment que je garde sous le coudes quelques petites tips pour améliorer votre productivité via la CLI de Kubernetes kubectl.

Rassurez vous, je ne vais pas faire un énième article sur l’autocomplétion ou autre info triviale comme “vous savez que vous pouvez stocker plusieurs contexts dans votre kubectl ?” #shocking. (Si ce dernier point vous intéresse, j’avais fais un article sur kubectx et kubens qui va surement vous plaire).

Normalement, les astuces que je vais vous montrer ici ne sont pas dans la plupart des tutos que j’ai pu trouver sur le net.

C’est parti pour du fun avec kubectl !

Pour les accrocs à la flèche du haut

Si, comme moi, vous faites partie de ces gens impatients qui ne peuvent pas prendre un café le temps qu’une opération se termine toute seule et que vous appuyez frénétiquement une la combinaison “flèche du haut + entrée” pour rappeler la dernière commande “kubectl get monobjetquejattendavecimpatience”, ce paragraphe est pour vous.

Lors d’une commande de type “get” avec kubectl, il existe un flag “-w” qui fait… oui vous l’avez deviné… un genre de watch sur le (ou les) objet(s) que vous attendez.

Par exemple, dans le cas où vous souhaiteriez créer un objet Service de type LoadBalancer et que vous avez hâte que votre cloud provider vous assigne une IP publique, utilisez la commande suivante :

kubectl --context=cephk8s get svc traefik-ingress-controller --namespace kube-system -w
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
traefik-ingress-controller LoadBalancer 10.0.21.75 <pending> 80:32347/TCP,443:30388/TCP 45s
traefik-ingress-controller LoadBalancer 10.0.21.75 40.89.187.183 80:32347/TCP,443:30388/TCP 56s

Dans un premier temps, seul la première ligne LoadBalancer s’affichera (tant que l’état restera à “Pending”), puis dès qu’il y aura une modification, la dernière ligne, avec l’IP publique, s’affichera.

C’est également pratique si vous avez des Pods qui mettent du temps à s’initialiser dans un Déploiement complexe.

Relancer un job

Kubernetes, en bon orchestrateur qu’il est, est capable de lancer des tâches planifiées. C’est super pratique lorsque vous avez des tâches bien précises à réaliser mais qu’il n’y a pas de raison de laisser un container tourner H24 pour ça.

On a donc la notion d’objet Kubernetes Job et de Cronjob. Sans rentrer dans les détails, le Job, c’est celui qui exécute la tâche (il lance un Pod qui contient un ou plusieurs containers). Le Cronjob, c’est une surcouche qui lance périodiquement le Job. Rien de bien sorcier.

Malheureusement pour nous, il arrive que nos Jobs échouent. Il n’y avait pas assez de ressources, ou alors on est tombé sur un bug, ou alors c’est “la faute à pas de chance”.

Qu’à cela ne tienne, il faut que votre Job tourne aujourd’hui, vous voulez donc le relancer. Pas de chance pour vous, “by design”, les Jobs ne peuvent pas être relancés dans Kubernetes.

Jusqu’à récemment, il n’y avait pas de solution propre pour relancer un Job avec kubectl. Il fallait donc passer par un exposer du JSON du Job pour en recréer un nouveau identique en tout point. “Crude but effective” comme disent nos amis anglosaxons.

kubectl --context=moncontext --namespace=monnamespace get job monjob -o json | jq 'del(.spec.selector)' | jq 'del(.spec.template.metadata.labels)' | kubectl --context=moncontext --namespace=monnamespace replace --force -f -

Si vous voulez plus de détails sur ce que oneliner fait vraiment : la première partie dump en JSON la configuration du job, la partie du milieu retire les données spécifiques au Job qui a échoué (autogénéré à la création du Job) et la dernière partie réinjecte le job dans Kubernetes, ce qui a pour effet de le relancer.

Pas mal hein ?

Mais… si vous avez une version plus récente, vous avez de la chance, cette option est maintenant disponible par défaut dans kubectl, vous permettant de créer de manière unitaire un Job à partir d’un template contenu dans un Cronjob, ce qui revient au même.

kubectl --context=moncontext --namespace=monnamespace create job --from=cronjob/lecronjobmaitre unnomuniquepourlejobrelancé

Les selecteurs dans vos kubectl

Last but not least, il est possible de réaliser des opérations sur plusieurs objets d’un même type en même temps.

La manière la plus simple de le faire est simplement d’ajouter les noms de tous les objets à la fin de votre commande. Par exemple, la commande suivante va supprimer les Pods pod1, pod2 et pod1000 :

kubectl --context=moncontexte --namespace==monnamespace delete pods pod1 pod2 pod1000

Cependant, on va rarement supprimer des pods (ou autre objet) au hasard. Généralement, on va vouloir supprimer tous les pods d’un même déploiement, ou alors supprimer tous les objets de la même applications, ou encore scaler tous les déploiements d’un même client.

Dans tous les cas, si vous avez bien fait votre travail, tous ces objets Kubernetes auront tous les labels cohérents les uns avec les autres. En partant du principe que les pods de l’exemple précédents ont tous le label app=blopiblop, je peux donc exécuter la commande suivante pour gagner du temps :

kubectl --context=moncontexte --namespace==monnamespace delete pods --selector=app=blopiblop

Attention à ne pas vous tromper dans les labels, c’est très puissant ;-)