We Open-Sourced Our 22-Hour Kubernetes Course

We run Kubernetes in production. Our own stack (GKE, Traefik, Cloud SQL, a fleet of Go microservices) lives on it, and over the last year we built a 22-hour course to teach it to the developers we work with. It is now open source: github.com/rflkt/k8s-training, free under CC BY-NC 4.0.

This post is not the syllabus. It is the reasoning: why the course is shaped the way it is, the calls we would defend, and what we would tell anyone starting Kubernetes today.

---

Why we gave it away

Two reasons, both selfish enough to be honest about.

First, teaching something forces you to actually understand it. Half the material started as notes we wrote to stop making the same mistakes twice. Publishing it raises the bar on our own explanations, because now they are in public.

Second, most Kubernetes tutorials are either a five-minute kubectl run demo or a 40-hour certification grind. There is very little in between for a competent backend developer who just needs to become dangerous in a weekend. That gap is exactly where our clients sit, so we filled it, and there is no reason to keep it private.

What is actually in it

Eleven sessions of two hours, each roughly 45 minutes of theory and 75 minutes hands-on. Everything runs on a local kind cluster, so there is no cloud bill to start.

Each lab ships as a starter/ with TODOs and a working solution/, plus kubectl, Helm and Terraform cheatsheets. The course materials are in French; the code, manifests and commands are universal.

The opinionated calls

A course is a series of decisions about what to leave out. These are the ones we would argue for.

One real application, broken on purpose. The thread running through every session is a single app: a Go REST API talking to PostgreSQL, and an nginx frontend that proxies to it and refreshes every five seconds so you see pods rotate. You are not applying disconnected YAML snippets. You deploy something that behaves like a real service, and then you make it fail: kill a pod, exhaust a resource limit, break a readiness probe, and watch what Kubernetes does. Toy examples teach syntax. A real app that misbehaves teaches operations.

kind, not minikube, not a managed cluster. We start entirely local on a three-node kind cluster. Multiple nodes matter, because a single-node cluster hides everything interesting about scheduling, affinity and rolling updates. Local matters because nobody learns well while worrying about spend. GKE shows up in session 8, once the concepts are already yours and the cloud is just where you run them.

Secrets get two full sessions. This is the part most courses wave at, and it is the part that hurts you in production. Session 5 covers the mechanics and the uncomfortable truth that a Kubernetes Secret is base64, not a vault. Session 6 is the one people remember: wiring the External Secrets Operator to GCP Secret Manager, mounting through the CSI driver, and actually rotating a secret without a redeploy. If you take one session, take that one.

Terraform, because clicking in a console is not a skill. Sessions 7 to 9 provision a real GKE cluster from code: network module, cluster module, node pool of e2-small spot VMs with autoscaling, everything prefixed per student. You learn Kubernetes the way you should run it: reproducibly, in version control, with a terraform destroy that gives you your afternoon back.

It ends where real work starts. The last session is CI/CD: GitHub Actions builds the image, pushes it, and deploys to GKE on every push, with separate environments. That is the finish line on purpose. The point of the course is not to know Kubernetes. It is to ship to it on a Tuesday without ceremony.

What we would tell someone starting today

• Learn the objects before the tools. Helm and operators are wonderful once you know what they generate. Learn them first and they are magic you cannot debug. Write the raw Deployment by hand at least once.
• Read the events, not just the logs. kubectl describe and kubectl get events explain nine failures out of ten. Most people stare at application logs for a scheduling problem the events already spelled out.
• Set resource requests early. Pods without requests are the single biggest cause of clusters that behave fine in a demo and fall over under load. It is one line. Write it.
• Probes are a promise, not decoration. A readiness probe that always returns 200 is worse than none, because Kubernetes now trusts a lie. Make it check something real.

How to use it

Clone it, run ./setup/prerequisites.sh, spin up the kind cluster, and start at session 1. It works for self-study, and it works as a spine for someone running an internal workshop. The license is CC BY-NC 4.0: use it, adapt it, teach from it internally, just credit it and do not resell it as paid training without asking.

If your team needs the guided version, or you want the same rigor pointed at your actual infrastructure, that is what we do. Either way, the material is yours: github.com/rflkt/k8s-training.