Field course · Modules 00—26
Kubernetes,
without the magic.
No Kubernetes experience is needed. Start with one running program, place it in a container, and learn why teams use Kubernetes when many containers must keep working together. You will see each idea before you have to remember its name.
four boundaries · one laptop
The recurring method
Try it, see it, then name it.
- Predict
- Deploy
- Observe
- Break
- Explain
- Repair
- Prove
- Clean up
Choose what you want to build
Start together. Specialise later.
Everyone learns the same basics first. The route filter only changes the later modules you need to finish, and you can switch routes at any time.
Course map
Showing 27 modules · later terms are previews, not prerequisites
Season 1 · 00–06
Why the platform exists
Learn the basic words by building from one running program to a small cluster.- 00 Where is the cluster, really? Learn what Kubernetes, a cluster, a node, and kubectl mean while building a local cluster you can safely erase.
- 01 A process with boundaries Start with an ordinary running program, package it as a container, connect two services, and stop them safely.
- 02 Desired state and feedback loops Tell Kubernetes what should be running, watch it notice a difference, and see it repair that difference.
- 03 Read the API before the YAML Ask the cluster what it supports, then read its objects, status messages and event history.
- 04 The smallest scheduling unit Learn why some containers share one address, storage and lifetime inside a Pod while others should stay separate.
- 05 Who keeps the work alive? Run a service that should stay alive and a task that should finish, then watch Kubernetes repair each one.
- 06 Change behavior without rebuilding Change settings without rebuilding an image, and give applications credentials without placing them in source code.
Season 2 · 07–10
How applications actually run
Follow packets, data and scheduling decisions through the cluster.- 07 Follow one packet Follow one request from a name to a stable service address and finally to a changing Pod address.
- 08 North–south and east–west traffic Let selected traffic enter the cluster, block traffic that should not pass, and test both decisions.
- 09 State outlives a Pod—sometimes Keep data when a Pod is replaced, then separate storage, copies, backups and real recovery.
- 10 Why did this Pod land here? Give workloads CPU and memory needs, predict which node can run them, and test the limits of a shared cluster.
Season 3 · 11–17
How applications survive production
Secure, observe, release and repair a system using evidence.- 11 Which boundary stopped the attack? Give each workload only the identity, permissions, network access and container privileges it needs.
- 12 Ask the system a falsifiable question Join status, events, logs, measurements and request traces to explain what a user experienced.
- 13 Promote evidence, not mutable state Check one fixed release, then move that exact release from testing toward production.
- 14 Choose the loop that should react Keep traffic away from unready work, replace versions safely, survive planned stops and add capacity when needed.
- 15 Find the layer that stopped progressing Use a repeatable checklist to find where progress stopped, keep a timeline and make the smallest safe repair.
- 16 Correctness lives above the scheduler Handle duplicate requests, retries, queues, overload and shutdown without losing or repeating important work.
- 17 Build a safe reconcile loop Teach Kubernetes a new kind of object and write a controller that safely keeps it up to date.
Season 4 · 18–26
How inference changes the system
Add model lifecycle, accelerators, batching, topology and nested control loops.- 18 Name the inference request path Follow one model request through admission, waiting, generation and streaming, then measure what the user feels.
- 19 A model is a versioned dependency Download and verify a model, warm it up, decide when it is ready, stream a response and stop safely.
- 20 From device request to placement Show Kubernetes which special devices exist and place model workers where the required capacity is available.
- 21 Choose the owner of each lifecycle Compare common serving tools by the work each one owns, the work you still own and how each one fails.
- 22 Measure the latency–throughput frontier Measure the trade-off between response time and total work while changing batches, queues and memory limits.
- 23 One replica, several coordinated workers Split one model across several workers and make the group start, update and fail as one service.
- 24 Keep control loops from fighting Send requests to suitable model workers and add or remove capacity without two automatic systems fighting.
- 25 Operate for useful tokens Practise a planned incident across model loading, worker failures, shared users, safe releases and cost.
- 26 Prove the complete system Build and explain a complete software or model-serving system, including what must change beyond a laptop.
Before Module 00
You do not need Kubernetes experience.
A Mac with 16 GB of memory and Docker Desktop. Module 00 gives the install links, checks each small command-line tool, and explains what it does.
You can create a local cluster, run applications, follow requests, cause safe failures, and understand how Kubernetes repairs them.
Real GPU clusters, specialised data-centre networking, and production performance tests. Those are explained later without pretending one laptop can reproduce them.
Course research checked 2026-08-15. Each lab fixes its tool versions, tells you what success looks like, and explains what would be different in production. Module 00 also shows how to clone the lab repository or download it as a ZIP; every lab command links directly to the files it uses.