Tricks on Zwindler's Reflection

kubectl tips and tricks 3

Mon, 22 Jun 2020 06:35:00 +0000

Déjà le numéro 3 pour les kubectl tips and tricks !

Vous le savez peut être car j’en parle abondamment, mais j’utilise Kubernetes quotidiennement, en particulier kubectl` ! Certes il y a des UI sympas pour améliorer l’expérience utilisateur de la ligne de commande avec Kubernetes, mais j’aime bien savoir exactement ce que je fais et souvent je préfère reste au plus proche de l’outil (c’est personnel). Je collecte donc de petites astuces qu’on ne trouve pas toujours quand on débute dans kube, que je vous partage ici.

Note: numéro 3 signifie bien entendu un n°1 et un n°2, que vous pourrez retrouver ici :

Et aussi dans la même veine :

Qu’est ce qui bouffe mes ressources !

Un inconditionnel lorsqu’on héberge des applications (et encore plus quand elles cohabitent) est savoir laquelle bouffe toutes les ressources et bloque les autres (ça marche aussi dans la vraie vie, en coloc) !

L’idéal est bien entendu de pouvoir compter sur une supervision complète (allez voir cet article sur Prometheus et Grafana si vous voulez en savoir plus), mais des fois, pour aller vite (ou si votre cluster est vraiment par terre et que Prom répond plus, avoir des outils intégrés permet de gagner du temps dans l’analyse du problème.

Heureusement pour nous, kubectl` intègre une commande “top”, qui, comme sa commande homonyme sous Linux, va nous permettre d’afficher les consommations de CPU et de RAM des objets dans notre cluster.

Il existe deux modes pour ce “top”. Le premier permet de lister la consommation des nodes :

kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
zwindlerzzzz01-11111111-vmss000000 118m 3% 1274Mi 10%
zwindlerzzzz01-11111111-vmss000001 119m 3% 1777Mi 14%
zwindlerzzzz01-11111111-vmss000002 320m 8% 2611Mi 20%
zwindlermntr01-11111111-vmss000000 113m 2% 1653Mi 6%
zwindlerzone01-11111111-vmss000000 200m 5% 1559Mi 12%
zwindlerzone01-11111111-vmss000001 215m 5% 1510Mi 11%

On a à la fois les infos en terme de CPU (en cores ou millicores et en pourcentage total) ainsi que la consommation RAM (en Mio et en %age total de ce qu’il y a sur la machine).

Le second permet de lister les pods.

Un point d’attention cependant : contrairement aux nodes, qui sont des objets visibles dans tous les namespaces Kubernetes, les pods sont liés à un namespace particulier. Il sera donc nécessaire de spécifier le namespace qui vous intéresse ou alors d’ajouter un --all-namespaces.

kubectl top pod --all-namespaces
NAMESPACE NAME CPU(cores) MEMORY(bytes)
default appli1-aaaaa 1m 36Mi
default appli2-aaaaa 1m 36Mi
default appli3-aaaaa 1m 36Mi
ingress traefik-v2-aaaaa-aaaaa 3m 17Mi

[Edit] Suite à une remarque de Thibault Le Reste, je me suis rappelé de 2 options dont je n’avais pas parlé initialement dans l’article --sort-by=cpu et --sort-by=memory.

A y repenser, je me suis souvenu pourquoi je n’en ai par parlé… c’est parce que cette option ne marchait pas quand j’ai écris l’article ;-)

En fait il y a un bug, fixé dans la version 1.18 de kubectl (issue Github 81270), donc si vous êtes à jour, vous pouvez utiliser ces deux options !

Logs

Un autre must dans l’hébergement d’applications, c’est comprendre pourquoi une application plante. Et il peut y avoir tellement de causes (pas seulement liées à Kubernetes) qu’il est important de garder une vision complète de toutes les sources de debugging à votre portée.

D’abord, l’application est peut être juste mal configurée. On pourrait simplement se connecter dessus mais il y a fort à craindre que le pod se kill tout seul le temps que vous tentiez de vous connecter.

Heureusement pour nous, la plupart des images sont pensées de telle sorte que les logs importants sont envoyés sur la sortie standard, sortie que nous pouvons récupérer avec la commande “logs”, que vous connaissez sûrement.

kubectl --namespace=monitoring logs thanos-query-7bc9986f59-c7njv
level=info ts=2020-05-06T15:23:35.600327763Z caller=main.go:168 msg="Tracing will be disabled"
level=info ts=2020-05-06T15:23:35.656544832Z caller=main.go:288 component=query msg="disabled TLS, key and cert must be set to enable"
level=info ts=2020-05-06T15:23:35.656572032Z caller=query.go:460 msg="starting query node"
level=info ts=2020-05-06T15:23:35.956571601Z caller=query.go:430 msg="Listening for query and metrics" address=0.0.0.0:10902

Cependant, ce que vous ignorez peut être c’est qu’il existe plusieurs flags très utiles qui permettent de reproduire les fonctions indispensable de tout admin linux qui lit des logs.

Par exemple, on peut faire l’équivalent d’un “tail -500” pour lister les 500 dernières lignes de log uniquement (très pratique si vous en avez des tartines) en ajoutant simplement le flag --tail=500.

On peut aussi faire l’équivalent du “tail -f” (suivre les lignes qui vont apparaître a posteriori en temps réel) avec le flag -f (tout simplement)

kubectl --namespace=monitoring logs thanos-query-7bc9986f59-c7njv --tail=1 -f
level=info ts=2020-05-06T15:26:18.048901191Z caller=storeset.go:266 component=storeset msg="adding new store to query storeset" address=prom-thanos-sidecar-zwindlerk8s.monitoring.svc.cluster.local:10901
[et là le prompt attend jusqu'à ce qu'une nouvelle ligne apparaisse ou que vous Ctrl-C]

Dans le cas d’un plantage en boucle, il arrive qu’on ait pas eu le temps de voir la trace du conteneur précédent avant que Kube en lance un nouveau. Vous pouvez accéder aux logs du conteneur précédent avec le -p !

kubectl logs pod-qui-crashe-en-boucle -p
Content root path: /app
Now listening on: http://[::]:80
Application started. Press Ctrl+C to shut down.
Application is shutting down...

Dans le cas où vous avez besoin de voir rapidement la date a laquelle a été écrite une ligne de log et que vous n’avez pas l’information dans le log lui même, sachez qu’il existe un --timestamps. Lorsque vous ajoutez ce flag, il va preppend un timestamp devant chaque ligne.

kubectl --context=k8s11-euw-dev --namespace=cutting-room logs scanner-parameters-7bfd6b656d-cl2gl --timestamps
2020-06-23T08:00:08.578320749Z {"logType":"Debug","timestamp":"2020-06-23T08:00:08.575Z","level":"Info",[...]

Le mieux étant bien sûr d’externaliser toutes les lignes de log dans un système centralisé comme fluentd ou splunk pour faciliter les recherches, bien entendu…

Et enfin, un dernier flag très très cool : vous avez la possibilité de n’afficher que les messages les plus récents, mais sur un temps donné plutôt que sur un nombre de ligne de log. --since=5m vous affichera les logs des 5 dernières minutes uniquement !

Events

Je pense qu’on a fait le tour pour ce qui était des logs applicatif avec kubectl. Cependant, il existe une autre catégorie de logs dans Kubernetes : les Events. Les Events, c’est un peu les logs interne de l’API server. Ca va vous donner tout un tas d’informations sur ce qui se passe sur vos objets. Un Pod est créé, un Pod meurt car il répond pas à la Liveness Probe, une Image est pull… la tuyauterie technique de kube en somme.

Les Events sont des objets Kubernetes à part entière, comme les Pods, les Nodes, etc. Ils sont liés à un namespace et on les liste avec un kubectl get events, on peut obtenir les informations complètes d’un Event avec un kubectl describe events, etc.

kubectl --namespace=kube-system get events
LAST SEEN TYPE REASON OBJECT MESSAGE
40s Warning Unhealthy pod/omsagent-rs-758cbf9987-fb5zf Liveness probe failed:
30m Normal Killing pod/omsagent-rs-758cbf9987-fb5zf Container omsagent failed liveness probe, will be restarted
10m Warning BackOff pod/omsagent-rs-758cbf9987-fb5zf Back-off restarting failed container
9s Warning Unhealthy pod/omsagent-v7w8w Liveness probe failed:
25m Normal Killing pod/omsagent-v7w8w Container omsagent failed liveness probe, will be restarted
5m45s Warning BackOff pod/omsagent-v7w8w Back-off restarting failed container

Mais… vous voyez pas un truc chelou ?

C’est trié N’IMPORTE COMMENT !!!

Le mieux dans cette histoire, c’est que c’est “by design”. Donc vous allez devoir garder cette astuce là sous le coude car je l’utilise à peu près tout le temps.

Pour modifier le comportement par défaut de kubectl get events pour que les événements soient triés par date de dernière occurrence (c’est souvent ce qu’on veut), retenez donc que vous allez devoir ajouter à chaque fois --sort-by='{.lastTimestamp}'

kubectl get events --sort-by='{.lastTimestamp}'
LAST SEEN TYPE REASON OBJECT MESSAGE
36m Normal Killing pod/omsagent-rs-758cbf9987-fb5zf Container omsagent failed liveness probe, will be restarted
16m Warning BackOff pod/omsagent-rs-758cbf9987-fb5zf Back-off restarting failed container
11m Warning BackOff pod/omsagent-v7w8w Back-off restarting failed container
6m27s Warning Unhealthy pod/omsagent-rs-758cbf9987-fb5zf Liveness probe failed:
5m56s Warning Unhealthy pod/omsagent-v7w8w Liveness probe failed:
85s Normal Pulled pod/omsagent-rs-758cbf9987-fb5zf Container image "mcr.microsoft.com/azuremonitor/containerinsights/ciprod:ciprod03022020" already present on machine
56s Normal Killing pod/omsagent-v7w8w Container omsagent failed liveness probe, will be restarted

Conclusion

Voilà, j’arrête ici car j’en ai plein d’autres mais ça commence à faire beaucoup. La prochaine fois je parlerai très certainement de la façon dont vous allez pouvoir customiser les colonnes que vous voulez voir afficher, ainsi que des filtres.

Mais en attendant, amusez vous bien avec ça ;-)

Supprimer un namespace bloqué à Terminating

Mon, 23 Mar 2020 07:15:00 +0000

Forcer la suppression d’un namespace bloqué à “Terminating” dans Kubernetes

Il y a quelques mois, j’ai eu des soucis pour supprimer un namespace lorsque j’ai voulu démonter mon cluster Ceph (monté avec Rook).

On aurait pu croire que ça m’a énervé (bon ok, si un peu quand même) mais ça m’a permis de mettre la main sur plusieurs commandes sympa avec kubectl donc tout n’est pas perdu ;-).

Voyez ce récit comme une checklist des choses à vérifier si jamais vous avez du mal à supprimer des objets dans Kubernetes !

Note: dans la même veine, n’hésitez pas à aller voir les articles que j’ai écris sur kubectl, notamment les tips and tricks !

La base

Pensant avoir correctement supprimé les objets Ceph dans mon cluster, j’ai donc terminé le nettoyage par une suppression toute bête du namespace :

kubectl --context=sandbox delete ns rook-ceph

Sauf que, patatra, en essayant de vérifier qu’il était bien supprimé :

kubectl --context=sandbox get ns rook-ceph
NAME STATUS AGE
rook-ceph Terminating 88d

Le namespace est toujours présent, et reste bloqué à l’état “Terminating”.

Qu’à cela ne tienne, je tente de le re-supprimer. Ça ne marche pas :

kubectl --context=sandbox delete ns rook-ceph
Error from server (Conflict): Operation cannot be fulfilled on namespaces "rook-ceph": The system is ensuring all content is removed from this namespace. Upon completion, this namespace will automatically be purged by the system

Forcer la suppression

Une rapide recherche sur le net me conseille d’ajouter les flags --force, à obligatoirement associer avec le flag --grace-period=0 (si vous ne le mettez pas, il vous dira de le mettre de toute façon…)

kubectl --context=sandbox delete ns rook-ceph --force --grace-period=0
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
Error from server (Conflict): Operation cannot be fulfilled on namespaces "rook-ceph": The system is ensuring all content is removed from this namespace. Upon completion, this namespace will automatically be purged by the system.

Flute !

Vérifier qu’il ne reste pas des objets Kubernetes, dans le namespace ou associés

Bon, généralement quand j’arrive pas à supprimer un namespace, c’est qu’il reste un PVC qui traine, lui même attaché à un PV. Mais là non plus, rien :

kubectl --namespace=rook-ceph get pvc
No resources found in rook-ceph namespace.
kubectl get pv

Vérifier les CRD aussi !

Un truc à vérifier aussi dans le cas de rook, c’est qu’il ne reste pas de CRD (CustomRessourceDefinition) que vous n’avez pas l’habitude de manipuler, qui seraient encore présentes et qui bloqueraient l’opération :

dgermain$ kubectl delete storageclass rook-ceph-block
Error from server (NotFound): storageclasses.storage.k8s.io "rook-ceph-block" not found
dgermain$ kubectl delete storageclass rook-cephfs
Error from server (NotFound): storageclasses.storage.k8s.io "rook-cephfs" not found

dgermain$ kubectl --context=sandbox get crd
volumes.rook.io 2019-08-19T09:46:08Z
dgermain$ kubectl --context=sandbox delete crd volumes.rook.io

Utiliser des scripts pour débloquer les objets en “Terminating”

Là ça commence à devenir pénible. Comme je ne suis évidemment pas le premier à avoir le problème, des gens ont écris des scripts pour faciliter la suppression d’objets bloqués au stade Terminating. Ces scripts prennent en charge la plupart des cas courants. Attention cependant à ce que vous faites avec (soyez sûrs de vous) !

dgermain:~/sources/knsk$ git clone https://github.com/thyarles/knsk/

dgermain:~/sources/knsk$ kubectl config use-context sandbox
Switched to context "sandbox".

dgermain:~/sources/knsk$ chmod +x knsk.sh
dgermain:~/sources/knsk$ ./knsk.sh
Deleting rook-ceph... done!

Lister tous les Objets du cluster qui s’appellent rook-ceph

Last but not least. La solution j’ai fini par la trouver en utilisant la commande suivante, qui permet de lister TOUS les types objets existants dans votre cluster :

kubectl api-resources --verbs=list --namespaced -o name

A partir de là, j’ai rajouté un petit xargs pour rechercher, dans tout le cluster, tous les objets s’appelant rook-ceph parmis tous les types d’objets qui existent. Et là surprise :

kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n rook-ceph
No resources found in rook-ceph namespace.
No resources found in rook-ceph namespace.
No resources found in rook-ceph namespace.
[...]
No resources found in rook-ceph namespace.
NAME DATADIRHOSTPATH MONCOUNT AGE STATE HEALTH
rook-ceph /var/lib/rook 1 88d Created HEALTH_OK
No resources found in rook-ceph namespace.
[...]
No resources found in rook-ceph namespace.
Error from server (NotAcceptable): the server was unable to respond with a content type that the client supports (get pods.metrics.k8s.io)
No resources found in rook-ceph namespace.
[...]

OUPS ! Il restait un CRD “cephcluster” que j’avais oublié de supprimer ! Sauf que cet objet n’apparaissait pas avec une requête d’affichage classique.

kubectl -n rook-ceph get cephcluster
NAME DATADIRHOSTPATH MONCOUNT AGE STATE HEALTH
rook-ceph /var/lib/rook 1 88d Created HEALTH_OK
kubectl -n rook-ceph delete cephcluster rook-ceph
cephcluster.ceph.rook.io "rook-ceph" deleted

Et c’est pas fini !

Malheureusement, ce n’est pas totalement terminé ! Notre namespace n’a plus d’objets qui bloquent sa suppression. Pour autant, il est encore bloqué dans l’état Terminating.

kubectl -n rook-ceph delete cephcluster rook-ceph
cephcluster.ceph.rook.io "rook-ceph" deleted
^C

Dans ce cas de figure, on peut soit relancer le script knsk, soit, à la main, patcher l’objet pour vider la metadata “finalizers” et débloquer le processus de suppression. Ca revient au même, mais je vous le met pour que vous compreniez ce que vous faites :

dgermain:~/sources/knsk$ kubectl -n rook-ceph patch cephclusters.ceph.rook.io rook-ceph -p '{"metadata":{"finalizers": []}}' --type=merge
cephcluster.ceph.rook.io/rook-ceph patched

Et maintenant, votre namespace est supprimé !

Sources

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 ;-)