Lab Kubernetes : un cluster k3s à un nœud pour chaque élève, sur une VM Ubuntu privée

Ce lab donne à chaque élève son propre cluster Kubernetes. k3s, un petit Kubernetes, tourne sur l’unique VM Ubuntu de l’élève comme un seul nœud, et l’élève travaille avec la vraie commande kubectl : il fait tourner des serveurs web avec un Deployment, regarde Kubernetes ramener un pod supprimé, donne un seul nom aux pods avec un Service, leur fournit une ConfigMap et cherche pourquoi un pod ne démarre pas.

Rien n’est installé sur l’ordinateur de l’élève et rien n’est partagé avec les autres élèves : une erreur coûte un cluster, et le lab peut être relancé.

Ce que les élèves apprennent

Ce que fait Kubernetes : vous dites ce qui doit tourner, et il le maintient en marche. En cinq parties. D’abord un tour du cluster, de son nœud, de ses espaces de noms et des pods que Kubernetes lance lui-même. Puis un Deployment de trois serveurs web, augmenté et réduit, avec un pod supprimé pour le voir revenir. Puis un Service, qui donne aux pods un seul nom qu’un autre pod trouve grâce au DNS propre du cluster. Puis une ConfigMap, dont le texte se retrouve dans chaque page, et le fait qu’un pod en marche ne voit un changement qu’une fois remplacé. Enfin trois Deployments cassés, chacun à sa façon, à réparer en lisant kubectl describe et kubectl logs.

Ce que contient la machine

Un nœud, k3s version 1.35, installé par le script du lab depuis les versions publiques du projet k3s sur GitHub. Les fichiers sont fixés par leurs sommes de contrôle, celles que la version publie, et tout autre fichier est refusé. Traefik, l’équilibreur de charge des services et le serveur de métriques sont désactivés pour tenir en mémoire : il n’y a donc ni Ingress ni kubectl top. kubectl, crictl et ctr sont présents.

La VM d’un élève atteint l’archive de paquets d’Ubuntu, PyPI, npm et GitHub, et aucun registre d’images. Tous les pods de ce lab font donc tourner la seule image fournie avec k3s, busybox version 1.37.0, qui a sh, httpd, wget et nslookup, et c’est tout ce qu’il faut aux leçons. Un pod qui demande une image comme nginx reste en ImagePullBackOff, ce que le README dit dès ses premières lignes.

Le lancer dans votre navigateur

Les labs VM se donnent comme tâche de lab dans un module, et l’exemple se trouve sur la page du lab. La machine demande 2 processeurs, 2 Go de mémoire et 10 Go de disque. k3s utilise environ un demi-gigaoctet quand rien ne tourne dessus, et le reste sert aux pods et à Ubuntu.

  1. Ajouter le lab. Dans un module que vous enseignez, ajoutez une tâche et choisissez la carte Lab VM Ubuntu. La page montre une courte description de la machine au lieu d’un fichier compose.
  2. Partir de l’exemple. La page propose des labs tout prêts. Choisissez Kubernetes avec k3s. Utiliser un exemple remplace le texte, et Annuler rend le vôtre.
  3. Publier et démarrer votre propre copie. Publiez, puis Démarrez. Le script d’installation du lab télécharge k3s depuis ses versions publiques sur GitHub au premier démarrage de la VM, environ 270 Mo, et écrit la commande k3slab, les deux fichiers de travail et le README. Le cluster est prêt quelques minutes plus tard.
  4. Ouvrir le terminal. Ouvrez son terminal, lancez k3slab status jusqu’à ce qu’il dise que le cluster est prêt, puis lisez README.md dans le dossier personnel : il dit quoi faire en cinq parties et ne donne aucune réponse.

Qui peut le lancer

Le lab a besoin des 2 Go, c’est-à-dire de la machine d’un compte d’établissement. Pour un compte gratuit, la machine a 1 Go : le lab n’y démarre pas k3s tout seul et le dit, et sudo k3slab install --anyway est pour l’élève qui veut essayer, sans promesse que cela tienne. Un visiteur sans compte a 1 Go et n’atteint que l’archive d’Ubuntu : k3s ne peut donc pas être téléchargé. Donnez le lab à une classe dans un établissement.

Une leçon de base sur ce lab

Kubernetes Basics est une petite leçon donnée dans ce lab, une VM Ubuntu. Elle a une accroche, un objectif « je peux », des mots-clés, une mise en route, une vérification après chaque idée, une erreur fréquente et une vérification finale, et chaque étape a un bouton Exécuter qui tape sa commande dans le terminal de la machine. L’élève lit le nœud et les pods système, crée un Deployment de trois pods, supprime les pods et voit trois nouveaux apparaître, puis passe à cinq.

La leçon travaille dans un espace de noms à elle et le supprime ; elle laisse à l’élève la tâche du lab, le Service, la ConfigMap et les Deployments cassés, et ne donne donc aucune réponse.

Comment il est noté

Le lab a une vérification. Elle s’exécute sur une copie de la machine enregistrée après un démarrage neuf, attend que k3s démarre avec le travail de l’élève toujours dedans, et interroge le cluster, pas les fichiers. Le Deployment web doit avoir trois pods prêts et le Service web doit envoyer le port 80 vers le port 8080 des trois. Un pod du cluster interroge ensuite http://web douze fois : le nom doit fonctionner, les réponses doivent venir de plus d’un pod, et chaque page doit montrer le texte de la ConfigMap. Puis la vérification change la ConfigMap pour un mot que personne n’a vu et supprime un pod : le Deployment doit en ramener un dont la page montre le nouveau mot, ce que ne fait jamais une page écrite dans le Deployment. Enfin les trois Deployments cassés doivent tourner, et le troisième doit dire dans son journal qu’il est prêt. La première ligne de ce que la vérification a affiché dit pourquoi elle n’a pas réussi.

La vérification dispose de trois minutes : l’élève doit donc arrêter le lab avec le cluster en marche et le laisser démarrer.

  1. La distribuer. Attribuez le lab comme n’importe quelle tâche, avec une date limite si vous voulez. Chaque élève a sa propre VM, conservée entre les séances, et le cluster est sur son disque.
  2. Lancer la vérification. Sur la ligne d’un élève dans la liste de classe, appuyez sur Lancer la vérification. Elle démarre une copie de sa machine enregistrée, sans rien réenregistrer, attend que le cluster démarre, l’interroge et montre si elle a réussi, ce qu’elle a affiché et quand. L’élève n’est pas informé du résultat.
  3. La noter. Lisez la première ligne de ce que la vérification a affiché : elle dit ce qui ne va pas, par exemple pas de Service nommé web, une page qui ne montre pas la ConfigMap, ou un Deployment cassé qui ne tourne toujours pas. Renvoyez le travail avec un motif s’il faut aller plus loin.

La définition sur GitHub

Le fichier est toute la définition du lab, le texte même que la plateforme exécute : taille, script d’installation, commande k3slab, les deux fichiers de travail, README et vérification. Copiez-le et changez les Deployments, ou les pannes de broken.yaml, pour faire un lab plus long.

Essayer ce lab, et ce qu’il coûte

Un compte personnel gratuit permet de suivre les leçons de base de ce lab, avec chaque mois assez de crédit gratuit pour suivre la plupart des leçons, sans carte. Pour une classe, un établissement a ses 365 premiers jours gratuits pour 50 élèves au plus, puis paie par élève et par an, tous les labs compris et les enseignants gratuits.

Questions fréquentes

Le lab Kubernetes demande-t-il une licence ?
Non. k3s est un logiciel libre sous licence Apache 2.0, téléchargé depuis les versions du projet k3s au démarrage de la VM de l’élève ; nous n’en distribuons rien. Les images de son paquet sont celles du projet, sans modification.
Pourquoi les pods utilisent-ils busybox et pas nginx ?
La VM d’un élève n’atteint aucun registre d’images : un pod ne peut donc faire tourner qu’une image que la machine a déjà. k3s en apporte quelques-unes, et busybox est celle qui sert à quelque chose : elle sert une page web, en récupère une et résout des noms. Tout ce qui concerne les Deployments, les Services et les ConfigMaps est identique quelle que soit l’image.
Les élèves peuvent-ils casser quelque chose ?
Seulement leur propre copie. Le cluster est un nœud dans la VM, qui atteint l’archive d’Ubuntu, PyPI, npm et GitHub et rien d’autre. Si un élève casse le cluster, k3slab files remet les deux fichiers en place, et kubectl delete namespace lab recommence les exercices.
Un élève avec un compte gratuit peut-il l’utiliser ?
Pas de façon fiable. La machine d’un compte gratuit a 1 Go et k3s demande environ 2 Go avec quelques pods : le lab ne le démarre donc pas tout seul sur cette machine. La machine d’un compte d’établissement a 2 Go, ce que demande le lab.
Le lab a-t-il été testé dans une vraie VM d’élève ?
L’installation avec ses vrais téléchargements, les commandes de la leçon et la vérification, avec chaque façon de la tromper, ont été exécutées dans un vrai Ubuntu 26.04 avec k3s en marche, dans un conteneur à la place de la VM. Une VM d’élève réellement démarrée, qui lance k3s depuis une unité systemd, avec 2 Go et le proxy réseau de la plateforme, mérite un essai avant un cours.