Kube DOOM représente les pods d’un cluster Kubernetes par des monstres dans Doom : en tuer un déclenche une demande de suppression du pod correspondant. Ce vieux projet open source donne une occupation assez inhabituelle à un cluster de homelab. Et derrière le plaisir de sortir le fusil à pompe, il offre une façon très visuelle de comprendre comment Kubernetes remplace les pods supprimés.
Un pod, un démon#
Le principe de Kube DOOM tient sur une capture : les monstres portent les noms des pods, et le joueur se promène au milieu de son infrastructure. Le projet descend de Docker DOOM, lui-même dérivé de psDoom, qui associait les monstres aux processus Unix. La méthode a donc une certaine tradition.
Le jeu tourne dans un conteneur et s’affiche avec un client VNC. Le README propose même les raccourcis pour aller directement au sujet : saisir idspispopd, traverser le mur de droite et retrouver les pods sous forme de monstres roses. Ctrl permet de tirer et Échap de mettre le jeu en pause.
L’interface d’administration manque un peu de filtres et de tableaux triables. En revanche, elle dispose d’un lance-roquettes.
Ce que fait vraiment la gâchette#
Le raccordement à Kubernetes est assez simple. Un petit programme Go récupère la liste des pods avec kubectl, puis la transmet au jeu par une socket Unix. Quand un monstre associé à un pod meurt, le jeu demande sa suppression et le programme lance kubectl delete pod dans le namespace correspondant. Ces deux étapes sont visibles dans le code du jeu et dans le programme Go.
La suppression passe donc par les identifiants et les permissions Kubernetes fournis au programme. Un monstre abattu ne prouve pas que la requête a abouti : le code lance la commande sans en remonter l’éventuelle erreur au joueur.
Pour un pod géré par un Deployment, le ReplicaSet cherche ensuite à rétablir le nombre de réplicas demandé. C’est un nouveau pod qui est créé, pas le même conteneur qui ressuscite. Cette boucle de contrôle donne tout son intérêt à la démonstration : le joueur supprime, Kubernetes reconstruit.
Le terrain de jeu : un cluster jetable#
Les suppressions sont réelles. Le bon terrain est donc un cluster dédié à l’expérience, avec une application sans données à conserver. Un namespace séparé dans le cluster qui héberge les services de la maison ne suffit pas à isoler cette bidouille : le manifeste RBAC fourni par le projet accorde le rôle cluster-admin à son compte de service.
La variable NAMESPACE permet de limiter les pods proposés comme cibles, mais elle ne réduit pas ces permissions. Le programme possède aussi un mode de suppression de namespaces entiers. Pour l’exercice, autant rester sur le mode pods et ne fournir au jeu que les accès du cluster jetable.
Il faut aussi prévoir un peu de remise en état. Au 22 octobre 2026, le Dockerfile du dépôt utilise encore Ubuntu 21.10 et fixe par défaut kubectl à la version 1.23.2. Pour rester dans la plage de compatibilité prise en charge avec un cluster récent, il faut au minimum actualiser kubectl : Kubernetes ne prend en charge qu’une version mineure d’écart entre ce client et le serveur API. C’est une curiosité à bricoler, avec une procédure de lancement ancienne.
Le vrai score : est-ce que l’application continue de répondre ?#
Une expérience intéressante consiste à prendre une petite application web sans état, avec trois réplicas, puis à supprimer un pod à la fois depuis le jeu. L’objectif est d’observer le délai de remplacement et le comportement de l’application pendant ce temps.
Pour un lab déjà configuré, les commandes suivantes permettent de suivre le résultat. Elles sont en lecture seule et nécessitent kubectl ainsi que les droits de lecture sur les pods et les Deployments. Remplacez kind-doom-lab et doom-lab par le contexte et le namespace de ce cluster.
Dans un premier terminal, suivre les changements des pods :
kubectl --context kind-doom-lab -n doom-lab get pods --watchLe pod visé doit passer en terminaison, puis disparaître. Un remplaçant doit apparaître sous un nouveau nom et devenir prêt à servir. Dans un second terminal, suivre le nombre de réplicas prêts et disponibles :
kubectl --context kind-doom-lab -n doom-lab get deployments --watchCes compteurs montrent la reconstruction, mais ne prouvent pas que les utilisateurs n’ont rencontré aucune erreur. Il faut aussi observer les requêtes côté client pendant l’exercice. Et un PodDisruptionBudget ne bloquera pas les tirs : la suppression directe d’un pod contourne ce mécanisme.
Voilà une bonne raison de garder un petit lab à côté des services utiles : pouvoir apprendre quelque chose en faisant une manipulation franchement absurde. Le prochain exercice sur les ReplicaSets aura au moins une meilleure bande-son.
Sources#
- Kube DOOM : dépôt, origine et utilisation.
- Capture du jeu publiée dans le dépôt, utilisée pour le visuel de cet article.
- Programme Go : liste des cibles et demandes de suppression.
- Code de Doom : traitement de la mort des monstres.
- Manifeste RBAC de Kube DOOM.
- Dockerfile de Kube DOOM.
- Kubernetes : Deployments et ReplicaSets.
- Kubernetes : référence de kubectl get.
- Kubernetes : perturbations et limites des PodDisruptionBudgets.
- Kubernetes : compatibilité des versions de kubectl.
