Productivité on Zwindler's Reflection

kubectl tips and tricks n°4

Mon, 06 Sep 2021 06:55:00 +0000

Encore des tips pour kubectl !!

J’en suis donc bien au numéro 4 pour ces tips and tricks sur kubectl (sans compter d’autres articles plus généralistes) et il y a encore beaucoup à dire !!

J’arrive plus à me loguer sur mon cluster Kubernetes 😭

Dans plusieurs contextes, j’ai eu à aider des collègues qui n’arrivaient plus à utiliser kubectl (après expiration d’un jeton, changements de confs dans le cluster, etc).

Un moyen rapide pour « régler » une partie des problèmes dans ce genre de cas peut être simplement de supprimer le contenu des caches de kubectl :

rm -r ~/.kube/cache
rm -r ~/.kube/http-cache

Non mais ya quoi dans mon cluster ?

Vous le savez, Kubernetes c’est plein d’API misent bout à bout (portée par l’API server et persistée par etcd) et d’autres composants qui se connectent dessus pour faire des choses utiles. Ça implique qu’il y ait un certain nombre d’objets logiques à connaître pour interagir avec l’API server et déployer vos applications. Cependant, difficile pour le néophyte de les connaître tous.

Bien sûr, on peut toujours parcourir l’API à coup de cURL mais vous avouerez qu’il y a plus user-friendly comme méthode ;). Et même pour l’admin chevronné, l’ajout de CRDs (Custom Resource Definition), difficile de savoir, sur des clusters un peu touffus, quel objet est présent et à quoi il sert.

Pour ça, vous disposez de deux aides avec kubectl

kubectl api-resources va vous permettre de lister la totalité des objets logiques de l’API disponibles (CRDs comprises) sur votre cluster, ainsi qu’une autre information très utile, s’ils sont « namespacés » ou non.

Dernier intérêt de cette commande, elle permet également de connaitre les abréviations (shortnames) autorisés, pratique pour sous économiser quelques caractères ;-)

kubectl api-resources
NAME SHORTNAMES APIGROUP NAMESPACED KIND
bindings true Binding
componentstatuses cs false ComponentStatus
configmaps cm true ConfigMap
endpoints ep true Endpoints
events ev true Event
limitranges limits true LimitRange
namespaces ns false Namespace
nodes no false Node
[...]

Un autre outil intéressant pour savoir à quoi sert tel ou tel objet/API est kubectl explain, qui va vous afficher la documentation en ligne :

kubectl explain RoleBinding
KIND: RoleBinding
VERSION: rbac.authorization.k8s.io/v1
DESCRIPTION:
RoleBinding references a role, but does not contain it. It can reference a
Role in the same namespace or a ClusterRole in the global namespace. It
adds who information via Subjects and namespace information by which
namespace it exists in. RoleBindings in a given namespace only have effect
in that namespace.
FIELDS:
apiVersion <string>
[...]

Malheureusement, j’ai remarqué que plusieurs éditeurs mettant à disposition des CRDs ne mettent pas de doc accessible avec « explain ». C’est vraiment super dommage :/

Afficher des labels

Tous les objets Kubernetes que vous créés peuvent être agrémentés de labels et d’annotations. Au delà de l’aspect informatif (ce Pod appartient à tel équipe, ce Node à telle capacité en RAM), c’est aussi très pratique pour filtrer les informations renvoyées par les commandes kubectl get.

Dans le tout premier kubectl tips and tricks, j’avais parlé de l’option –selector, qui permet de filtrer l’action d’une commande kubectl (get, delete, …) à un couple label+valeur

blog.zwindler.fr/2019/10/30/kubectl-tips-tricks-1/

Par défaut, les informations renvoyées par le kubectl get sont assez concises et parfois on manque un peu d’information.

Dans ce genre de cas, la première chose à tester est simplement d’ajouter un « -o wide » qui permet d’ajouter quelques colonnes (qui dépendent du type d’objet requêté) :

kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
scw-k8s-zealous-chaum-default-4b71eda80e934790 Ready <none> 24m v1.21.3 10.70.116.23 51.158.79.36 Ubuntu 20.04.1 LTS c200a86960 5.4.0-80-generic containerd://1.5.4

Cependant, dans le cas ça n’est toujours pas suffisant et qu’on ne veut pas filtrer mais bien obtenir rapidement la valeur d’un label bien particulier sur un ensemble d’objets Kubernetes, il existe une option « –label-columns » qui permet d’ajouter des colonnes supplémentaires en fonction d’un ou plusieurs labels donnés.

kubectl get nodes --label-columns=kubernetes.io/os
NAME STATUS ROLES AGE VERSION OS
scw-k8s-zealous-chaum-default-4b71eda80e934790 Ready <none> 19m v1.21.3 linux

Les labels sont donc d’autant plus utiles qu’ils sont faciles à afficher !

Note : les plus chevronnés d’entre vous savent certainement peut aller encore plus loin dans les colonnes ou les informations qu’on peut afficher avec kubectl (notamment via le « -o »). Mais je garde ça pour un prochain épisode… Donc en attendant, have fun ;-)

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