Nous publions notre formation Kubernetes de 22 h en open source

Nous faisons tourner Kubernetes en production. Notre propre stack (GKE, Traefik, Cloud SQL, une flotte de microservices Go) vit dessus, et sur la dernière année nous avons construit une formation de 22 h pour l'enseigner aux développeurs avec qui nous travaillons. Elle est maintenant en open source : github.com/rflkt/k8s-training, libre sous licence CC BY-NC 4.0.

Cet article n'est pas le programme. C'est le raisonnement derrière : pourquoi la formation a cette forme, les choix que nous défendons, et ce que nous dirions à quelqu'un qui démarre Kubernetes aujourd'hui.

---

Pourquoi la rendre libre

Deux raisons, assez intéressées pour être honnêtes.

D'abord, enseigner une chose oblige à vraiment la comprendre. La moitié du contenu a commencé comme des notes écrites pour ne pas refaire deux fois les mêmes erreurs. Le publier relève le niveau de nos propres explications, parce qu'elles sont désormais publiques.

Ensuite, la plupart des tutoriels Kubernetes sont soit une démo kubectl run de cinq minutes, soit un marathon de certification de 40 h. Il y a très peu de choses entre les deux pour un développeur backend compétent qui veut simplement devenir opérationnel en un week-end. C'est exactement là que se situent nos clients, alors nous avons comblé ce vide, et il n'y a aucune raison de le garder privé.

Ce qu'elle contient vraiment

Onze sessions de deux heures, chacune environ 45 minutes de théorie et 75 minutes de pratique. Tout tourne sur un cluster kind local : aucune facture cloud pour commencer.

Chaque lab est fourni en starter/ avec des TODO et une solution/ qui marche, plus des aide-mémoire kubectl, Helm et Terraform. Les supports sont en français ; le code, les manifests et les commandes sont universels.

Les partis pris

Une formation, c'est une suite de décisions sur ce qu'on laisse de côté. Voici celles que nous défendons.

Une seule vraie application, cassée exprès. Le fil rouge de chaque session est une seule app : une API REST Go qui parle à PostgreSQL, et un frontend nginx qui l'appelle et se rafraîchit toutes les cinq secondes pour que vous voyiez les pods tourner. Vous n'appliquez pas des bouts de YAML sans lien. Vous déployez quelque chose qui se comporte comme un vrai service, puis vous le faites échouer : tuer un pod, saturer une limite de ressources, casser une readiness probe, et observer la réaction de Kubernetes. Les exemples jouets enseignent la syntaxe. Une vraie app qui déraille enseigne l'exploitation.

kind, pas minikube, pas un cluster managé. On démarre entièrement en local sur un cluster kind à trois nœuds. Le multi-nœuds compte, parce qu'un cluster mono-nœud cache tout ce qui est intéressant : scheduling, affinité, rolling updates. Le local compte parce que personne n'apprend bien en surveillant la facture. GKE arrive en session 8, une fois les concepts acquis et le cloud réduit à un endroit où faire tourner tout ça.

Les secrets occupent deux sessions entières. C'est la partie que la plupart des formations effleurent, et c'est celle qui fait mal en production. La session 5 couvre la mécanique et la vérité inconfortable : un Secret Kubernetes, c'est du base64, pas un coffre-fort. La session 6 est celle dont les gens se souviennent : brancher l'External Secrets Operator sur GCP Secret Manager, monter via le driver CSI, et faire tourner un secret sans redéploiement. Si vous ne prenez qu'une session, prenez celle-là.

Terraform, parce que cliquer dans une console n'est pas une compétence. Les sessions 7 à 9 provisionnent un vrai cluster GKE depuis le code : module réseau, module cluster, node pool de VM e2-small spot avec autoscaling, le tout préfixé par étudiant. Vous apprenez Kubernetes comme il faut le faire tourner : de façon reproductible, sous gestion de versions, avec un terraform destroy qui vous rend votre après-midi.

Elle s'arrête là où le vrai travail commence. La dernière session, c'est le CI/CD : GitHub Actions construit l'image, la pousse, et déploie sur GKE à chaque push, avec des environnements séparés. C'est la ligne d'arrivée, volontairement. Le but n'est pas de connaître Kubernetes. C'est d'y livrer un mardi, sans cérémonie.

Ce que nous dirions à quelqu'un qui démarre

• Apprenez les objets avant les outils. Helm et les opérateurs sont formidables une fois que vous savez ce qu'ils génèrent. Appris d'abord, ce sont des tours de magie que vous ne saurez pas déboguer. Écrivez au moins une fois le Deployment brut à la main.
• Lisez les events, pas seulement les logs. kubectl describe et kubectl get events expliquent neuf pannes sur dix. Beaucoup fixent les logs applicatifs pour un problème de scheduling que les events avaient déjà décrit.
• Posez les resource requests tôt. Les pods sans requests sont la première cause des clusters impeccables en démo et à genoux sous charge. C'est une ligne. Écrivez-la.
• Une probe est une promesse, pas une décoration. Une readiness probe qui renvoie toujours 200 est pire que rien : Kubernetes fait maintenant confiance à un mensonge. Faites-lui vérifier quelque chose de réel.

Comment l'utiliser

Clonez-la, lancez ./setup/prerequisites.sh, montez le cluster kind, et commencez à la session 1. Elle marche en autoformation, et elle marche comme colonne vertébrale pour animer un atelier interne. La licence est CC BY-NC 4.0 : utilisez-la, adaptez-la, enseignez avec en interne, créditez simplement et ne la revendez pas comme formation payante sans demander.

Si votre équipe veut la version accompagnée, ou la même rigueur appliquée à votre infrastructure réelle, c'est notre métier. Dans tous les cas, le matériel est à vous : github.com/rflkt/k8s-training.