Un vrai Kubernetes par apprenant

On n'apprend pas Kubernetes en lisant. On l'apprend en déployant, en cassant, en réparant, sur un cluster où l'on a les pleins pouvoirs. Le problème : donner à chaque apprenant un vrai cluster est cher, lent à provisionner, et dangereux dès qu'ils partagent la même infrastructure.

Le dilemme

Deux options classiques, mauvaises toutes les deux :

Un cluster partagé, avec des namespaces. Économique, mais l'apprenant n'a pas les droits d'administration : il ne verra jamais un , un CRD, un webhook d'admission. Il apprend une moitié de Kubernetes.
Un vrai cluster par personne. Fidèle, mais lourd : des minutes de provisionnement, une facture qui grimpe, et une purge à gérer après chaque session.

Notre réponse : un cluster virtuel par apprenant

Chaque apprenant reçoit son propre cluster virtuel : un serveur d'API Kubernetes à lui, avec son , ses namespaces, ses rôles, ses CRDs, un plan de contrôle complet, isolé de celui des autres.

bash

kubectl create deployment web --image=nginx
kubectl get pods -A

Ces commandes tournent contre SON cluster. Il peut créer un , installer un opérateur, malmener son , sans jamais toucher au cluster d'à côté ni à la plateforme.

Isolé, et jetable

L'isolation est réelle : les ressources d'un apprenant sont invisibles pour les autres. Et comme le cluster est virtuel, il apparaît en quelques instants et disparaît à la fin de la session, aucune trace, aucune purge manuelle.

Ce que ça débloque

Des ateliers qu'un namespace partagé interdit : RBAC au niveau cluster, contrôleurs d'admission, opérateurs, CRDs, mises à niveau. Bref, le vrai métier d'un administrateur Kubernetes, pas sa version bridée.

En bref

Un namespace apprend à utiliser Kubernetes. Un cluster apprend à l'administrer. Le cluster virtuel donne le second au prix du premier, et c'est ce qui rend un atelier Kubernetes enfin honnête.