Kubectl on Zwindler's Reflection

GenAI et développement logiciel, épisode 2 : kubectl-debug-pvc, de l'idée à krew en 2x30 minutes

Tue, 17 Mar 2026 18:00:00 +0100

Précédemment, dans “GenAI et dev”

Dans mon article précédent, je vous parlais de mon retour d’expérience avec PodSweeper, un projet développé avec OpenCode et Claude Opus. Le bilan était nuancé : vitesse brute impressionnante, mais race conditions, gestion d’erreur laxiste, et nécessité constante de supervision humaine (entre autres déconvenues).

Aujourd’hui, je vous parle d’un deuxième projet, bien plus simple, né d’un vrai besoin en production. Et le constat est assez différent.

L’incident qui a tout déclenché

Vous connaissez peut-être cette situation : un pod en production, en état de fonctionnement, qui utilise un PVC en ReadWriteOnce. Vous avez besoin d’aller regarder le contenu de ce volume. Bonne pratique de production : le pod en question ne dispose pas de shell (on réduit la surface d’attaque). Pas de /bin/sh, pas de /bin/bash, rien.

Pas grave, on a kubectl debug pour ça, me direz-vous !

Ok, créons un conteneur éphémère dans le pod et… ah non. kubectl debug ne permet pas de monter les volumes du pod dans le conteneur éphémère. Il n’expose tout simplement pas l’option volumeMounts pour les conteneurs éphémères.

On pourrait couper le pod, ce qui permet de monter le PVC RWO dans un autre pod avec un shell, mais on n’a pas envie, c’est de la prod.

Mon collègue Maxime (encore lui !) me propose une méthode de contournement. La procédure manuelle, c’est :

Créer un conteneur éphémère sur le pod avec kubectl debug
Construire à la main un patch JSON pour ajouter des volumeMounts au conteneur éphémère qu’on vient de créer
Dans un autre terminal, se brancher ~~au cul du camion~~ sur l’API de kube en direct avec kubectl proxy
Appliquer le patch via un curl sur l’API Kubernetes
Attendre que le conteneur soit prêt, s’attacher au conteneur
Se dire qu’il y avait quand même plus simple comme métier que patcheur de container à coup de curl.

Pour ceux qui pensent que c’est jouable, “téma la gueule du patch” comme disent (disaient ?) les jeunes :

curl http://localhost:8001/api/v1/namespaces/<namespace>/pods/<pod>/ephemeralcontainers \
 -X PATCH \
 -H 'Content-Type: application/strategic-merge-patch+json' \
 -d '{
 "spec": {
 "ephemeralContainers": [
 {
 "name": "debugger",
 "image": "ubuntu",
 "command": ["/bin/sh"],
 "targetContainerName": "<target-container>",
 "stdin": true,
 "tty": true,
 "volumeMounts": [
 {
 "name": "<volume-name>",
 "mountPath": "/debug/<volume-name>"
 }
 ]
 }
 ]
 }
 }'

Si vous pensez que c’est error prone, vous avez raison. Et si vous pensez que c’est pénible à faire sous pression pendant un incident de prod, vous avez encore plus raison.

Side note

Les plus aguerri·es d’entre vous dans les versions récentes de Kubernetes ont peut être entendu parler du KEP-2590, qui introduit un (relativement) nouveau flag --subresource de kubectl. En effet, les containers éphémères créés par la commande kubectl debug ne sont pas des resources (un pod, un deployment, …) mais des subresources.

Jusqu’à cette version 1.33, il était littéralement impossible de réaliser des opérations sur les subresources avec kubectl, seulement les resources.

Kubernetes v1.33: Octarine apporte le support du flag –subresource, mais seulement pour 3 subresources pour l’instant status, scale and resize

Pas de solution de ce côté-là non plus…

Le prompt de réunion

J’avais cette idée en tête depuis l’incident. Lundi matin, au début d’une réunion (pendant que les gens faisaient encore des blagues), j’ai lancé OpenCode avec Claude Opus et j’ai tapé un prompt qui décrivait :

Le problème : kubectl debug ne monte pas les volumes PVC s’ils sont en RWO
La procédure manuelle que je faisais à la main (les étapes douloureuses décrites un peu plus haut)
Ce que je voulais : un outil qui automatise tout ça

OpenCode + Opus m’ont posé 2 questions (et j’ai ajouté une consigne) :

“Quel langage ?” → Go (je persiste)
“CLI seule ou TUI ?” → Les deux (mode non-interactif pour le scripting, TUI pour l’usage quotidien)
Et je lui ai demandé de toujours vérifier à chaque fois qu’il estime avoir fini de lancer le linter golangci-lint (trauma de mon précédent test avec opencode)

Il est parti de lui-même sur l’idée d’une TUI avec Bubble Tea. Puis j’ai arrêté de regarder & j’ai suivi ma réunion.

~30 minutes plus tard, fin de la réunion, j’ai regardé le résultat. Le POC était fonctionnel.

Ce qu’Opus a produit en 30 minutes

Sans aucune intervention de ma part, le LLM a scaffoldé un projet Go complet :

Structure propre : cmd/ pour le CLI Cobra, pkg/k8s/ pour toute l’interaction Kubernetes, pkg/tui/ pour la TUI Bubble Tea
Le coeur du sujet : un appel direct à l’API Kubernetes pour patcher le subresource ephemeralcontainers du pod avec un strategic merge patch incluant les volumeMounts
Mode non-interactif : -n namespace -p pod -v volume:/mount/path, prêt pour le scripting
TUI complète : navigation vim-style (j/k), filtrage fuzzy (/), multi-sélection de volumes, spinner de chargement…
Makefile avec tout un tas de targets (vet, lint, test, build, install)

Ce que je lui ai demandé d’ajouter :

Discovery intelligente : au lieu de scanner tous les pods de tous les namespaces (lent sur un de mes gros cluster), l’outil liste d’abord les PVCs cluster-wide (un seul appel API) pour identifier les namespaces pertinents, PUIS les pods dans le namespace sélectionné. On réduit drastiquement le nombre d’appels à l’API server de kube et la TUI ne montre que les namespaces et pods qui ont des volumes PVC
Héritage du SecurityContext : le conteneur éphémère copie le securityContext du conteneur cible, ce qui lui permet de passer les PodSecurity policies (restricted, baseline…). C’est un cas que je n’avais pas envisagé dans mon prompt initial et qui a planté immédiatement sur un cluster bien configuré.

Sans ces petites améliorations le tool était déjà utilisable (sauf pour le cas où vous avez configuré des SecurityContext), mais c’est nettement plus confortable à l’usage (parce que oui, je l’utilise).

Le code de la mécanique centrale (le patch de l’API) fait quelques centaines de lignes de Go propre. Il récupère le pod, construit le patch JSON avec le conteneur éphémère et ses volumeMounts, l’applique via Patch() sur le subresource, attend que le conteneur soit Running, puis lance kubectl attach. Rien de sorcier, c’est juste ce qu’il faut, bien fait du premier coup.

 ephemeralContainer := corev1.EphemeralContainer{
 EphemeralContainerCommon: corev1.EphemeralContainerCommon{
 Name: containerName,
 Image: opts.Image,
 Command: []string{"/bin/sh"},
 Stdin: true,
 TTY: true,
 VolumeMounts: mounts,
 SecurityContext: targetSecurityContext,
 },
 TargetContainerName: targetContainer,
 }
...
 _, err = c.Clientset.CoreV1().Pods(opts.Namespace).Patch(
 ctx,
 opts.PodName,
 types.StrategicMergePatchType,
 patchBytes,
 metav1.PatchOptions{},
 "ephemeralcontainers",
 )

Les itérations suivantes (30 minutes-ish)

Une fois le POC validé, j’ai enchaîné quelques prompts ciblés. Je lui ai demandé ce qu’on pouvait améliorer. Il a proposé (et implémenté) :

quelques corrections mineures de code qu’il avait mal codé (mais non bloquant)
Warnings : si le SecurityContext hérité a readOnlyRootFilesystem, runAsNonRoot, ou autre mesure de sécurité, l’outil prévient l’utilisateur avant l’attach
Ajouté une CI complète à base de goreleaser et de github actions
Ajouté de la documentation

La cerise sur le Macdo : publication sur Krew

Une fois que j’avais une version propre, j’ai demandé à Opus comment faciliter l’installation du plugin. Il m’a proposé brew, ou alors Krew, le gestionnaire de plugins kubectl.

Je lui ai demandé si le processus d’acceptation du plugin était complexe. Il a dit que non, je lui ai dit “chiche !”.

Il a réalisé l’intégralité du processus :

Création d’un fork de krew-index
Rédaction du manifeste Krew (le fichier .yaml qui décrit le plugin)
Prise en compte de toutes les bonnes pratiques demandées par les maintainers de krew-index (format des URLs de téléchargement, descriptions courtes, checksums SHA256, etc.)
Préparation de la PR, directement sur krew-index

J’ai juste regardé. La PR a été mergée 12 heures plus tard par les mainteneurs.

Résultat : kubectl krew install debug-pvc fonctionne.

Mini échec - déléguer aussi la démo

Fort de ce succès avec la PR pour krew-index, je me suis demandé si on ne pourrait pas faire une démo visuelle (un GIF à ajouter dans le README.md du projet qui montre comment ça fonctionne) avec le LLM.

Je lui ai demandé s’il pouvait le faire avec asciinema et le LLM m’a répondu que “oui” (oui, je discute avec le LLM comme avec mes collègues). Banco, on a essayé.

Le résultat était presque bon, j’aurais pu m’en contenter si j’étais pas quelqu’un de pénible : c’était un poil lent. J’ai l’impression la réactivité du LLM dans ses actions était inégale, ce qui rendait le rendu un peu désagréable au visionnage. J’aurais pu insister jusqu’à avoir quelque chose de correct, mais j’ai finalement enregistré moi-même une vidéo, convertie en GIF avec ffmpeg. C’était plus fluide et plus rapide que d’itérer.

Le diff avec PodSweeper

La différence de ressenti entre ce projet et PodSweeper est frappante. Là où PodSweeper était un combat constant (race conditions, amnésie du LLM, fonctionnalités hors-spécifications), kubectl-debug-pvc s’est déroulé sans accroc notable.

Pourquoi ? Je pense que ça tient à la nature du projet :

Une seule chose à faire, clairement définie : patcher un subresource Kubernetes avec des volumeMounts
Pas de logique concurrente : on fait une requête API, on attend, on s’attache
Un domaine bien documenté : l’API Kubernetes, Cobra, Bubble Tea. Le LLM connaît tout ça par coeur
Pas d’état partagé complexe : pas de goroutines qui se marchent dessus, pas de graceful shutdown à gérer, de microservices multiples
Scope limité : le projet entier tient dans une quinzaine de fichiers, CI et documentation incluses

C’est probablement le terrain de jeu idéal pour un LLM. Un problème bien cadré, un domaine technique bien balisé, une solution linéaire.

Qu’est-ce que j’en pense ?

Objectivement, ce genre de projet “simple” (une chose à faire, simple à comprendre) marche vraiment super bien avec OpenCode + Opus. Je pense que c’est ce genre à cause (grâce) de ce genre de petits projets que la hype est tellement forte autour du développement agentique. On a une idée en tête qu’on avait la flemme de dev, on teste, ça marche. “WOW”.

Mais je ne veux pas non plus minimiser le travail réalisé. Le fait qu’un outil fonctionnel, propre, publié sur Krew et utilisable par n’importe qui ait pu émerger d’un prompt lancé en début de réunion, c’est quand même assez dingue.

Un peu flippant aussi, de se dire qu’un nombre hallucinant de micro tools vont apparaître dans les prochains mois, avec un niveau de qualité probablement inégal.

Le projet

Le code est disponible ici :

https://github.com/zwindler/kubectl-debug-pvc

Installation :

# Via Krew (recommandé)
kubectl krew install debug-pvc

# Utilisation interactive (TUI)
kubectl debug-pvc

# Utilisation non-interactive
kubectl debug-pvc -n my-namespace -p my-pod-0 -v data:/debug/data

Si vous aussi vous avez déjà galéré à inspecter un PVC sur un pod sans shell, essayez. Et si vous trouvez des bugs, vous pourrez blâmer le LLM 😄.

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

Test de SKS, le Kubernetes managé chez Exoscale !

Mon, 03 May 2021 06:20:00 +0000

Kewa ? Exoscale a un Kubernetes Managé ?

Lorsque Mathieu Corbin m’a parlé du Kubernetes managé qu’ils étaient en train de monter chez Exoscale, je lui ai tout de suite proposé de me le montrer, pour que je lui donne mon point de vue.

Sans être un expert absolu des offres Kubernetes en SaaS, j’en ai quand même testé quelques uns, notamment AKS d’Azure, OVH et quelques autres (GCP, Kapsule, … pour lesquels je n’ai pas fait d’article).

Et puis, bon, Kubernetes, c’est un peu mon métier maintenant ;-).

Au moment où j’ai rédigé le premier brouillon de cet article, on était encore en bêta fermée. Il n’y avait pas d’interface graphique dans le portail (uniquement la CLI), certains paramètres étaient pas totalement dans les règles de l’art (problèmes connus chez eux), …

Et puis le temps a passé et je n’ai pas sorti l’article (comme souvent par manque de temps) avant que la solution passe GA.

Heureusement, le passage en GA c’est aussi une bonne occasion pour moi de refaire le test et de comparer le boulot qui a été accompli (en peu de temps) pour gommer les quelques défauts de jeunesse que la solution pouvait encore avoir.

Mais d’abord, Exoscale ?

J’vais pas mentir, même si j’avais déjà croisé le nom d’Exoscale plusieurs fois, je n’avais jamais pris le temps de tester leur offre. Pour ceux qui l’ignorent donc, Exoscale est un cloud provider avec plusieurs points de présence en Europe.

Niveau taille de l’acteur, on est pas du tout comparables à un OVH (ou même Scaleway), mais ils sont suffisamment nombreux pour se permettre d’avoir une team dédiée à la release d’un Kubernetes managé. Tout en gardant suffisamment de bande passante pour quand même avoir une API ouverte et documentée, comme les grands.

Et donc, SKS ?

Cette micro introduction d’Exoscale passée, revenons donc à nos nuages.

L’offre Kubernetes managée d’Exoscale s’appelle SKS (pour Scalable Kubernetes Service).

On nous promet donc sur le site d’Exoscale un service scalable (horizontalement), qui démarre normalement en 90 secondes.

La gestion du cycle de vie du control plane est entièrement gérée, on peut le déployer via CLI, API, depuis le portail et il existe aussi un provider terraform.

Enfin, Exoscale a développé un composant permettant de faciliter l’intégration de son load balancer managé dans SKS (pour l’instant).

Et comme je vous l’avais promis, l’API de SKS est documentée ici si jamais vous aimez faire des cURL.

Et ça coute cher ?

Dans les offres managées de Kubernetes, il y a plusieurs clans. Ceux qui proposent un SLA sur le control plane et ceux qui n’en proposent pas. Et il y a ceux qui font payer le control plane et ceux qui ne le font pas payer.

Souvent, ceux qui ne font pas payer le control plane sont également les mêmes qui ne proposent pas de SLA sur le control plane.

Et pour avoir discuté avec un commercial de chez Azure en fait il y a une certaine logique à ne pas proposer de SLA sur un control plane gratuit. Un SLA étant un contrat, difficile de s’engager sur un service gratuit (et encore plus, difficile de vous rembourser ce que vous ne payer pas en cas de problème).

Chez Exoscale, c’est fromage ou dessert, vous avez le choix. SKS est offert en 2 offres distinctes :

une payante, avec SLA (99,95%)
l’autre gratuite, sans SLA

Classiquement, les workers sont quant à eux facturés au même prix que n’importe quelle machine IaaS chez Exoscale.

Petite subtilité qui m’a fait sourire, là où les clouds providers se battaient sur qui bill à l’unité de temps la plus petite il y a 10 ans (d’abord l’heure, puis progressivement à la minute), chez Exoscale, vous êtes billé à la seconde. Difficile de faire plus précis.

Pour tout ce qui concerne le pricing, je vous laisse aller voir ici. N’ayant aucun intérêt financier à vous pousser vers Exoscale (ou OVH, ou Azure), je ne vais pas insister plus que ça ;-).

Bon, on teste ?

Maintenant qu’on a fait le tour de la question, et si on essayait un peu de voir ce que ça donne ?

La première chose à faire est de se créer un compte sur www.exoscale.com et aussi télécharger la dernière version de la CLI.

J’insiste bien sur la « dernière version » car pendant la bêta j’avais téléchargé la mauvaise version et l’API et les paramètres avaient changé de manière significative en peu de temps.

A l’heure où j’écris l’article, la dernière version est la 1.28 (1.23 quand j’ai testé la bêta en début d’année) mais les releases sont dispos ici : github.com/exoscale/cli/releases

wget https://github.com/exoscale/cli/releases/download/v1.28.0/exoscale-cli_1.28.0_linux_amd64.tar.gz
tar xzf exoscale-cli_1.28.0_linux_amd64.tar.gz
➜ ./exo
Manage your Exoscale infrastructure easily
[...]

A noter, il existe aussi pour les distributions linux des packages (.deb, .rpm, etc).

Configuration du compte

Maintenant qu’on a notre CLI sur notre poste, on va aller dans le portail créer une clé d’API qui va nous servir à nous authentifier.

La documentation officielle est disponible ici.

Une fois que vous aurez cliqué sur « Create », l’ID de la clé ainsi que la clé apparaitra. Attention, comme toujours avec ce genre de mécanisme, la clé ne sera visible que cette fois ci. Sauvegardez là donc bien précieusement (sinon au pire il faudra en générer une nouvelle).

On peut ensuite configurer notre CLI

./exo config

Et on teste que la connexion marche bien avec la commande permettant de lister les versions de Kubernetes disponibles sur SKS

./exo sks versions

Bon, je sais pas vous mais moi a me donne le sourire de voir que fin avril, Exoscale a déjà la 1.21 dispo :-)

Création du security group

Exoscale dispose, comme tous les cloud providers, d’un système de firewalling qui permet d’appliquer des règles de sécurité à nos futures machines.

Même si la création d’un groupe de sécurité n’est pas obligatoire pour instancier notre cluster SKS, c’est mieux si on le fait dès le début.

Tout peut se faire via la CLI ou via le portail, comme pour le reste chez Exoscale

./exo firewall create sks-zwindler-sg
./exo firewall add sks-zwindler-sg -d "NodePort services" -p tcp -P 30000-32767
./exo firewall add sks-zwindler-sg -d "SKS Logs" -p tcp -P 10250
./exo firewall add sks-zwindler-sg -d "Calico traffic" -p udp -P 4789 -s sks-zwindler-sg

Si vous préférez le faie sur le portail, ça ressemblera à ça :

J’ai juste repris les valeurs par défaut dans la doc de Quick Start

Créer un cluster

La commande exo sks create permet de créer notre cluster. On peut rajouter des flags pour modifier certains paramètres :

exo sks create -h

Au delà des options pour choisir la taille du cluster et le type de node, les options intéressantes sont les 3 « –no- » qui vous permettent de désactiver l’installation automatique de :

la CNI (Calico par défaut). Calico par défaut est un bon choix mais si vous préférez Cillium ou kube-router (ou flannel… nan j’déconne !).
la CCM (Cloud Controller Manager), composant développé en interne par Exoscale et qui permettra à Kube d’interagir avec les autres services d’Exoscale (notamment le loadbalancer)
metrics-server mais là je vois pas pourquoi vous ne voudriez pas metrics-server …

./exo sks create sks-zwindler --description "Test SKS cluster" --nodepool-name "sks-zwindler-pool" --nodepool-size 3 --nodepool-security-group "sks-zwindler-sg" --zone de-fra-1 --service-level pro
&#x2714; Creating SKS cluster "sks-zwindler"... 1m57s
&#x2714; Adding Nodepool "sks-zwindler-pool"... 3s

Je ne sais pas si je n’ai pas eu de chance car il me semblait que ça allait un peu plus vite que les deux minutes que j’affiche dans cet extrait de shell. Mais 2 minutes c’est déjà plus que respectable quand on sait que chez Azure, AKS met plus de 20 minutes à poper (quand ça ne plante pas), sans compter les VMs (qui elles aussi mettent parfois 10 minutes avant d’être disponibles)…

kubeconfig

Disponible… ok … Mais comment on s’y connecte en fait ?

Pas de panique, la CLI permet de générer le kubeconfig qui va vous permettre de vous connecter à l’API server ! (ouf)

Un point intéressant de l’implémentation d’Exoscale est que vous pouvez tuner un peu le kubeconfig qu’il va vous générer (là où la plupart du temps, c’est un kubeconfig admin, point). Vous pouvez notamment choisir le groupe RBAC ainsi qu’une durée de vie.

Dans un environnement de production avec beaucoup d’utilisateurs, on préfèrera surement ajouter une authentification tierce (coucou OIDC), cependant, c’est quand même « nice to have ».

./exo sks kubeconfig sks-zwindler kube-admin --group system:masters --zone de-fra-1 > sks-zwindler-30d.kubeconfig

L’authentification se fait donc par certificat avec une durée que vous pouvez configurer en secondes (par défaut 30 jours). Bon, comme je vois que ce que je crois, j’ai fait le test avec 60 secondes et a priori ça marche ;-).

./exo sks kubeconfig sks-zwindler kube-admin --group system:masters --zone de-fra-1 --ttl 60 > test-60s.kubeconfig
kubectl --kubeconfig test-60s.kubeconfig get nodes
NAME STATUS ROLES AGE VERSION
pool-afa3f-apzqy Ready <none> 6h v1.21.0
pool-afa3f-iehif Ready <none> 6h v1.21.0
pool-afa3f-ysvki Ready <none> 6h v1.21.0
#plus tard
kubectl --kubeconfig test-60s.kubeconfig get nodes
error: You must be logged in to the server (Unauthorized)

Déployer une application disponible sur Internet

Comme la CCM nous permet de faire communiquer notre Kubernetes et Exoscale, on va en profiter pour créer un service Kubernetes de type Loadbalancer.

Ce service Loadbalancer va commander à Exoscale un NLB chez eux, ce qui va nous permettre de router le trafic Internet directement dans notre cluster (il vaudrait mieux passer par un IngressController brancher sur ce service Loadbalancer dans la vraie vie).

kubectl --kubeconfig sks-zwindler-30d.kubeconfig create service loadbalancer toto --tcp=80:80
kubectl --kubeconfig sks-zwindler-30d.kubeconfig get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8h
toto LoadBalancer 10.111.39.139 <pending> 80:30001/TCP 22s
kubectl --kubeconfig sks-zwindler-30d.kubeconfig get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8h
toto LoadBalancer 10.111.39.139 89.145.161.242 80:30001/TCP 23s

Puis on déploie un nginx de test avec un label similaire à celui créé par défaut par le service (app=toto)

kubectl --kubeconfig sks-zwindler-30d.kubeconfig run --image nginx --labels app=toto toto

Très rapidement, vous devriez avoir accès à votre pod via l’IP du NLB Exoscale

Nettoyage

Si vous avez mis votre carte de crédit, n’oubliez de supprimer votre cluster de test avant de partir ;-)

./exo sks delete sks-zwindler -n
[+] Are you sure you want to delete Nodepool "sks-zwindler-pool"? [yN]: y
&#x2714; Deleting Nodepool "sks-zwindler-pool"... 6s
[+] Are you sure you want to delete SKS cluster "sks-zwindler"? [yN]: y
&#x2714; Deleting SKS cluster "sks-zwindler"... 18s

Et faites pareil si vous avez un instancié un Loadbalancer pour connecter vos services dans Kubernetes avec l’extérieur (j’avais oublié… oups).

Conclusion

J’avais été impressionné par l’implémentation d’OVH de Kubernetes managé, mais je dois reconnaitre que je le suis encore plus par celui d’Exoscale.

Le cluster (control plane) est créé TRES vite, mais surtout les VMs popent également extrêmement vite (quelques secondes versus 10 minutes chez Azure !!!). C’est vraiment chouette !

De ce que j’ai vu (et pu échanger) des entrailles de SKS, tout me parait très sain et bien conçu (sécurité, best practices). Et pourtant, Exoscale donne quand même pas mal de libertés sur la customisation du cluster (CCM, CNI, configuration kubeconfig).

Les petits bugs de jeunesses (quelques erreurs de configuration du kubelet, des erreurs cosmétiques dans les commands lines, le CCM à installer soit même, …) que j’avais pu remonter à Mathieu lors de mon test en janvier/février ont toutes été gommés en moins de 2 mois.

Donc, selon moi, si vous cherchez un kube managé, SKS est une alternative viable.

Mettre à jour le CA de Kubernetes, « the hard way »

Mon, 15 Feb 2021 07:56:12 +0000

Les CA (Certificate Authority), ça expire !

Dans cet article, je vais vous ferai un petit retour d’expérience d’un souci un peu tricky que j’ai rencontré il y a quelques mois.

Cela concerne des clusters Kubernetes, la Certificate Authority (CA), un Vault (Hashicorp) et le tout dans un contexte opérationnel, en production, avec des millions d’utilisateurs.

Attachez vos ceintures, ça risque de secouer :)

The « automated » hard way

J’ai récemment changé de boite.

Dans ce nouveau contexte technique, Kubernetes est en production depuis plusieurs années. Aujourd’hui, il existe de très nombreuses options pour déployer un cluster Kubernetes (j’en ai déjà abondamment parlé ici, là, là, là ou encore là). Chaque a ses avantages et ses inconvénients, qui dépendent de la topologie du cluster ainsi que de vos besoins (vous êtes plutôt cloud, baremetal, edge,…).

Plot twist : Vous l’avez peut-être deviné, le titre de l’article est une référence au célèbre “Kubernetes the hard way” de Kelsey Hightower.

La raison pour laquelle j’ai choisi ce titre est que, en 2017, les clusters Kubernetes de l’entreprise dans laquelle je travaille ont été déployés avec des playbooks Ansible écrits à la main. Et d’un point de vue extérieur, ça ressemble un peu à automatiser « Kubernetes the hard way » avec Ansible 😉.

Aujourd’hui, vous (je) le feriez pas comme ça. Mais il faut se replacer dans le contexte. Au moment où le cluster a été déployé, les options étaient bien plus limitées qu’aujourd’hui en termes de déploiements. Particulièrement pour les installations de type baremetal. kubeadm par exemple, maintenant GA, affichait encore des gros messages d’avertissement « NOT PRODUCTION READY« .

It’s the final countdown

Toutes nos applications ne sont pas hébergées dans Kubernetes, mais une portion relativement significative d’entre elles y sont. Suffisamment en tout cas pour que si le cluster Kubernetes était down, nos utilisateurs finaux finiraient pas d’en rendre compte. Et c’est là où notre histoire commence :

L’autorité de certification de notre Kubernetes va expirer dans quelques mois, et avec elle, toute la chaîne de certifications

Un zwindler un peu inquiet Pour illustrer un peu mon propos, imaginez qu’à la place de ces indicateurs verts rassurants, il y avait du orange (rouge ?) partout.

Comme toutes les communications à l’intérieur du cluster Kubernetes sont chiffrées et authentifiées avec ce CA, le laisser expirer serait une très mauvaise idée. En gros, on perdrait le contrôle du cluster et de toutes les applications hébergées dedans 😱. Si vous faites des petites recherches sur Internet, vous trouverez peut-être des postmortem de ce genre de souci (je vous en mets un en fin d’article).

Donc, j’avais pour mission de trouver un moment de renouveler le certificat, sans interruption pour les utilisateurs de notre service, et AVANT la date d’expiration.

Pourquoi est ce que c’est un problème ?

Renouveler un certificat, ce n’est pas la mer à boire. Cependant, ici, comme le CA est responsable de toutes les communications des composants internes de Kubernetes, c’est un peu moins trivial.

Pour rendre les choses encore plus complexe, la documentation officielle est incomplète (et même fausse, j’ai fait une PR et il faudrait probablement en faire d’autre) et les documentations externes sont parcellaires.

Il y a plein de raisons pour ça. La première est que beaucoup d’organisations préfèrent utiliser Kubernetes via une offre managée chez leur cloud provider préféré, qui leur cache la complexité de la gestion du cluster Kubernetes pour eux. Dans ce cas-là, les clouds providers sont ceux qui s’inquiètent de ce genre de problématiques (mais s’y inquiètent ils ?).

Parmi les utilisateurs restants (on-prem donc), la plupart utilisent les outils comme Kubespray ou kubeadm, qui contiennent dans une certaine mesures des outils pour faciliter les procédures de renouvellement de certificats (mais qui n’étaient pas disponibles au moment où les clusters ont été déployés).

Enfin, pour les rares damnés qui restent, régénérer un CA à la main n’est pas quelque chose qu’on fait souvent. Les CAs sont généralement générés pour des durées allant de 3 à 10 ans (même si les bonnes pratiques préfèrent des durées courtes). Si on compare cette durée moyenne par rapport à l’adoption relativement récente de Kubernetes (un projet vieux de seulement 6 ans), on peut supposer que beaucoup de CA n’ont pas encore eu l’occasion d’expirer ;-).

Et maintenant ? Que vais-je faire ?

On doit donc trouver un moyen de modifier le CA de Kubernetes à la volée sans impact utilisateur. Heureusement, avec un peu de planification, ça devrait être possible pour la grande majorité des workloads.

La première chose à savoir est que, même si le cluster ne répond plus pendant qu’on renouvelle les certificats, les applications qui sont dans Kubernetes (les Pods) qui sont déjà déployés sont toujours opérationnels. Cependant, les nouveaux Jobs ne seront pas démarrés, les Pods en erreur ou les applications sur des nœuds HS ne seront pas redémarrés sur des nœuds en bonne santé.

La seconde chose à savoir est que toutes vos applications (dans les Pods) sont exécutées avec un contexte de sécurité qui dépend d’un ServiceAccount. Si vous n’en spécifiez pas dans le manifeste de l’application, vous hériterez par défaut de celui du Namespace (d’ailleurs, pour information, ça peut être un problème de sécurité).

Là où les choses se compliquent, c’est que le token qui authentifie ce ServiceAccount est généré par le Kubernetes Controller Manager. Et pas de bol, quand vous générez le CA, tous les tokens sont bons à jeter à la poubelle…

Donc… Le but du jeu va être de ne redémarrer que ce qui est nécessaire, dans le bon ordre, puis de régénérer tous les tokens. Et tout ça, suffisamment vite pour qu’aucune application ne plante ou qu’un Node tombe en panne pendant l’opération.

Easy peasy

MAIS !

Car bien sûr, il y a un mais car sinon ça serait trop facile :

Les applications qui ont besoin de communiquer avec l’API de Kubernetes seront perturbées dans leur fonctionnement tant qu’elles n’auront pas été redémarrées (une fois leur token régénéré). Cela inclus probablement vos applications de supervision (comme Prometheus) qui scrap l’API. Vous serez « aveugles » pendant quelques minutes.
Les applications qui maintiennent des connexions longues (typiquement des WebSockets par exemple) seront probablement coupées à un moment donné car vous devrez probablement redémarrer vos IngressControllers, qui ont souvent besoin d’accéder à l’API server (cf point précédent). Si vous avez implémenté un mécanisme de retry dans vos applications, ça devrait aller.
Toutes les applications devront à un moment donné être redémarrées pour obtenir leur nouveau token. Si vos applications n’ont pas de replicas (1 seul Pod), il y aura nécessairement une coupure. Pour éviter ça (et c’est valable pour tous les contextes, pas seulement quand on renouvelle des certificats) essayez de toujours avoir des replicas pour toutes vos applications. Dans le cas présent, si ces applications n’ont pas besoins d’accéder à l’API de Kubernetes, vous pouvez reporter le redémarrage à plus tard.

Maintenant vous savez tout, allons y 😊 !

Okééééé. On renouvelle un CA dans Kubernetes, en prod, sans interruption (visible)

Avant de faire quoique ce soit qu’on pourrait regretter, le mieux est quand même d’être certain qu’on est capable de revenir à l’état initial au cas où on devrait rollback. Cela signifie des sauvegardes et surtout tester les procédures de restauration !

Sauvegardez tous les certificats que vous utilisez actuellement (probablement dans /etc/kubernetes, mais aussi dans /var/lib/kubelet) ainsi que ceux d’etcd.

CURDATE=`date +"%y%m%d%H%M"`
tar czf /tmp/pkibackup.${CURDATE}.tgz /var/lib/kubelet/pki/kubelet.* /etc/kubernetes

Vous allez probablement vouloir aussi sauvegarder tous vos tokens actuels (dans vos ServiceAccounts). Je rappelle que ces tokens sont générés par le Kubernetes Controller Manager et qu’ils sont utilisés par les Pods pour communiquer avec l’API server de Kubernetes (mais on y reviendra).

for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
kubectl get $token --namespace "$namespace" -o yaml >> /tmp/token_dump.${CURDATE}.yaml
done
done

Et enfin, faire une sauvegarde complète de l’état du cluster via un dump de la base etcd est probablement une bonne idée aussi (if all else fail comme on dit).

ETCDCTL_API=3 etcdctl --cacert=yourca.pem --cert=etcd.pem --key=etcd-key.pem --endpoints 127.0.0.1:2379 snapshot save /tmp/etcd.backup.$(date +'\%Y\%m\%d_\%H\%M\%S')

Hashicorp Vault ?

Historiquement, les certificats avaient été générés à l’aide de la commande openssl, en se basant sur les recommandations officielles de la documentation de Kubernetes.

Ça fonctionne parfaitement bien (la documentation met plutôt en avant l’outil cfssl aujourd’hui, mais c’est le même principe). Cependant, cette façon de faire n’est ni efficace, ni vraiment safe (la clé privée du CA est stockée sur disque) et est également un facteur d’erreur humaine.

Parallèlement à ça, nous utilisons depuis plusieurs années l’outil Vault de Hashicorp pour stocker nos secrets. Nous avons donc profité de l’opportunité offerte par ce renouvellement pour utiliser le module « pki » d’Hashicorp Vault.

Dans cet article, je ne rentrerai pas dans les détails de Vault et de son moteur PKI (j’ai fait quelques articles sur les produits Hashicorp en revanche), mais grosso modo l’idée est :

créer un nouveau « secret engine »
générer un CA qui sera gardé au chaud dans Vault
configurer un rôle permettant de paramétrer les futurs certificats pour correspondre aux recommandations de Kubernetes
générer les certificats et les déposer sur les serveurs

vault policy write pki-policy pki-policy.hcl
vault secrets enable -path=pki_k8s pki
vault secrets tune -max-lease-ttl=43800h pki_k8s
vault write pki_k8s/root/generate/internal common_name="kubernetes-ca" ttl=43800h
vault write pki_k8s/roles/kubernetes allowed_domains="kubernetes, default, svc, example.org" allow_subdomains=true allow_bare_domains=true max_ttl="43800h"

Certs for everyone

Pour déposer de manière sécurisée et automatisée les certificats, on utilise un autre outil d’Hashicorp (décidémment) qui s’appelle consul-template. Ce binaire va nous permettre de générer des fichiers à partir de fichiers templates et des objets qu’on a stockés dans Vault (et Consul).

Là encore, sans rentrer dans les détails, un template va ressembler à ça (je vous prends l’exemple du certificat pour l’API server) :

{{- /* apiserver-cert.tpl */ -}}
{{ with secret "pki_k8s/issue/kubernetes" "common_name=kube-apiserver" "alt_names=kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.kubernetes, example.org" "ip_sans=100.64.0.1, IP.ADDRESS.MASTER.1, IP.ADDRESS.MASTER.2, IP.ADDRESS.MASTER.3" "exclude_cn_from_sans=true" "ttl=17520h" }}
{{ .Data.certificate }}{{ end}}

Le fichier de configuration de consul-template ressemblera lui à ça :

template {
source = "/etc/consul.d/templates/ca.pem.tpl"
destination = "/etc/kubernetes/pki/ca.pem"
}
template {
source = "/etc/consul.d/templates/admin-cert.tpl"
destination = "/etc/kubernetes/pki/admin.pem"
}
template {
blah blah blah
...

On lancera la commande suivante, qui remplacera d’un coup tous les anciens certificats par de nouveaux qui respectent les besoins de notre cluster et qui sont validé par notre nouveau CA :

consul-template -config /etc/consul.d/templates/consul-template-config-master.hcl

Petit bémol, cette solution ne marche pas pour tous les certificats. A chaque appel de consul-template, un nouveau certificat est produit. Pour tous les certificats individuels, comme les certificats pour chaque node, cela fonctionne très bien. Cependant, ce n’est pas vrai pour certains, par exemple pour la clé privée de l’API server qui nécessite d’être la même pour tous les serveurs. Nous avons donc fait une exception dans notre processus : tous les certificats nécessaires pour les masters ont été générés pour un seul serveur puis copiés sur les autres masters.

Ground control to Major Tom

Tous les certificats sont maintenant régénérés. Mais pour autant, tous les composants de Kubernetes ne supportent pas le renouvellement de certificats à chaud. On va devoir tout redémarrer (et dans le bon ordre, en plus…).

La première urgence est de redémarrer les serveurs etcd, tous en même temps. Une fois que c’est fait, la course commence car l’API server ne sera plus capable d’interroger etcd pour connaître (et mettre à jour) l’état du cluster. Nous avons perdu tout contrôle sur notre cluster 😱.

systemctl restart etcd

A partir de maintenant, toutes les commandes kubectl vont échouer. Toutes les fonctionnalités de Kubernetes (autoscaling, scheduling des pods, etc) vont arrêter de fonctionner.

Cela va heureusement facilement se régler, simplement en redémarrant l’api-server manuellement (soit via le service systemd soit, si c’est un Pod, envoyer un SIGKILL).

On peut ensuite s’attaquer au reste des composants du control plane qui nécessitent etcd ou l’API server.

Je vous conseille de commencer par le CNI (comme flannel par exemple), puis de supprimer la paire de certificats de vos kubelet (ils seront régénérés automatiquement) avant de les redémarrer, sur tous les Nodes.

rm /var/lib/kubelet/pki/kubelet.{crt,key}
systemctl restart kubelet

Et pour finir, on peut redémarrer tous les composants du control plane restant avec des commandes kubectl depuis un master (ça devrait remarcher).

/usr/bin/kubectl --namespace kube-system delete pods --selector component=kube-apiserver
/usr/bin/kubectl --namespace kube-system delete pods --selector component=kube-controller-manager
/usr/bin/kubectl --namespace kube-system delete pods --selector component=kube-scheduler

Notre control plane est de nouveau opérationnel 🎉.

The tokens sleep tonight

Maintenant que notre control plane fonctionne avec nos nouveaux certificats, si vous regardez ce qui se passe dans les logs de l’API server, vous remarquerez qu’il y aura beaucoup de messages pas super explicites à propos de tokens pourris.

Si vous vous souvenez bien, on avait dit qu’il allait falloir rafraîchir tous nos tokens, qui sont tous invalidés depuis qu’on a redémarré l’API server. Cette partie est heureusement gérée par le Kubernetes Controller Manager mais il va falloir lui donner un petit coup de pouce : on va supprimer les tokens contenus dans les Secrets de type service-account-token relatifs à chaque ServiceAccount grâce à cette boucle :

for ns in `kubectl get ns | grep Active | awk '{ print $1 }'`; do
for token in `/usr/bin/kubectl get secrets --namespace $ns --field-selector type=kubernetes.io/service-account-token -o name`; do
/usr/bin/kubectl get $token --namespace $ns -o yaml | /bin/sed '/token: /d' | /usr/bin/kubectl replace -f - ;
done
done

Et nous pouvons donc commencer à redémarrer nos applications.

Now, the applications

Je vous conseille de redémarrer coredns en premier (ou kubedns, selon votre installation). Sans ça, la résolution de nom à l’intérieur de votre cluster Kubernetes va commencer à échouer (et ça, ça craint).

/usr/bin/kubectl --namespace kube-system rollout restart deployment.apps/coredns

Mais vous devriez aussi redémarrer tous les applications qui vous semblent importantes pour le fonctionnement du cluster, comme notamment (mais pas uniquement) :

kube-proxy
les Ingress controllers
prometheus
toute autre application de monitoring

Enfin, redémarrer toutes les applications qui nécessitent un accès à l’API server pour fonctionner correctement. Pour les autres, vous avez le temps de le faire plus tard.

Wrapping this up

Le CA de votre cluster Kubernetes a été renouvelé. Vous devriez pouvoir de nouveau dormir tranquilles pour quelques mois 😊.

Renouveler vos CA n’est pas une tâche triviale dans Kubernetes, mais j’espère vous avoir montré que ce n’est pas impossible et que dans la plupart des cas et en le planifiant bien, il est possible de le faire sans interruption.

Toutes les tâches décrites dans cet article ont été automatisées dans des playbooks Ansible, que nous avons joué sur des environnements moins critiques autant de fois que nécessaire jusqu’à ce que nous ayons été sûr de leur exécution.

En décembre dernier, l’intervention a été planifiée sur les clusters de production. Toute la procédure a été jouée en quelques minutes, aucun impact utilisateur n’a été détecté et les services qui nécessitaient un accès à l’API n’ont pas été perturbées plus que prévu.

Sources

Github — Kelsey Hightower’s “Kubernetes the hard way”

Postmortems d’expiration de certificats CA

Vadosware — 2019–12 K8s certificate expiration outage

Construire et détruire des clusters Kubernetes à la volée

Youtube — Continuously Deliver your Kubernetes Infrastructure — Mikkel Larsen, Zalando SE

Documentation officielle de Kubernetes a propos des certificats

Hashicorp Vault

Hashicorp — Build Your Own Certificate Authority (CA) (lien mort)
Hashicorp Vault — PKI Secrets Engine (API)
Digital Ocean — Using Vault as a Certificate Authority for Kubernetes
Youtube — Streamline Certificate Management

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