Labs

Labs

Unless a lab says otherwise, run everything on support01, and create every file directly in your home directory - the labs cd ~ before writing anything, so kubectl apply -f pod.yaml always finds what you just wrote. The only exceptions create their own folder and say so: the Docker build contexts in Labs 03 and 04, helm create in Lab 21, and the git clone in the extended labs.

Labs come in two flavours, and the difference is deliberate:

• Guided - every command is given, with an explanation of what it does and what you should see. Use these to build the vocabulary.
• Discovery Infodiscover - you get the task and the expected result, but the command is hidden behind a Show the command box. Try first, look second. This is what the job actually feels like, and the cheat sheets plus kubectl explain and --help are your reference.

Day 1

Day 2

Day 3

Extended labs

Two longer challenge labs built on one real application - a Blazor frontend, an ASP.NET Core API and a highly available PostgreSQL cluster run by an operator. They live in their own repository, together with the application source and a script that grades each stage, so you can work through them alone and at your own pace - during the course, or long after it.

git clone https://github.com/ecaha/kubequiz.git ~/kubequiz
cd ~/kubequiz && ./labs/verify.sh a0

Lab 24 covers deployment and operations: an operator-managed database, probes, a database failover under load, autoscaling, draining a node and a NetworkPolicy. Lab 25 covers the pipeline: fork the repository, change one line of C#, and follow it through GitHub Actions, a container registry, git and Argo CD into the running cluster.

Rules of the house

1. Every lab ends with a clean-up step. Run it - the next lab assumes a tidy cluster.
2. In a discovery task, spend two minutes trying before you open the box. The answer you find yourself is the one you keep.
3. kubectl explain and --help are not cheating. They are the job.