Your workspace
Your workspace is a VS Code running in a browser tab, with a terminal, a filesystem that belongs to you, and a Kubernetes cluster attached. Nothing is installed on your own computer, and nothing needs to be.
Three Surfaces
| What it is for | |
|---|---|
| VS Code (web) | Reading and writing YAML. The file tree on the left is your workspace filesystem |
| The terminal | Everything you type: kubectl, helm, labctl, git |
| This site | Concepts and explanations. Keep it open in another tab — labctl docs 04 will bring you to the right page |
You will move between all three constantly. That is the intended way to work, not a workaround.
Where Things Are
| Path | What it is |
|---|---|
/home/coder | Your home directory, and the only part of the filesystem that persists |
/home/coder/course-material | The workbook: labs, labctl, and the checkpoints. VS Code opens here, and new terminals start here |
/home/coder/course-material/labs/NN-name/work/ | Where your own manifests go. Git-ignored, exactly so you can make a mess |
/home/coder/.kube/config | Your cluster credentials. Already set up — you never need to touch it |
The workbook is a git clone you cannot push to, but it is writable on disk. Write your YAML in the work/ directory of whichever lab you are doing; it stays in your workspace and out of the way of the lab’s own files.
Your Cluster
Your cluster is separate from your workspace. Closing the browser tab, or the workspace being rebuilt, does not touch it — your namespaces, volumes and workloads are still there when you come back.
Check what you have:
labctl envThat reports your kubeconfig, whether the cluster answers, what you are permitted to do, and which tools are present. Among other things it tells you whether you are a cluster administrator, because a few later exercises need that and it is better to discover it early than halfway through.
Each lab creates its own namespace, named after the lab: lab-04 for Persistence. You can pass -n lab-04 on every command, or point your context at it once and stop typing it:
kubectl config set-context --current --namespace=lab-04
kubens # lists namespaces and lets you switch with the arrow keyskubens and kubectx are installed, and fzf is wired into your shell, so most of this is faster by keyboard than by typing.
labctl
Every lab is driven by one command. It is not a package you install — it is a script in the workbook — but the important part is that you only have to remember one entry point:
| Command | What it does |
|---|---|
labctl env | Check that your environment works |
labctl list | Show the labs, and how far you have got |
labctl start 04 | Create the lab’s starting state and list its checkpoints |
labctl explain 04 | The idea behind the lab and what “done” looks like |
labctl steps 04 | A guided recipe, if you would rather follow one |
labctl hint 04.2 | A nudge for one checkpoint. Ask twice for a more specific one |
labctl check 04 | Verify your work, checkpoint by checkpoint |
labctl solution 04 | Apply the reference answer |
labctl reset 04 | Put the lab back to a known-good state |
labctl status | Your progress across all the labs |
labctl docs 04 | Print the URL of the module for a lab |
If your shell cannot find
labctl, you are probably not in the workbook directory.cd /home/coder/course-materialand try again, or run./bin/labctl.
Checkpoints, and Why Being Stuck Is Fine
Each lab is broken into three to five checkpoints — small, verifiable statements about the state of the world, such as “a PersistentVolumeClaim named data exists and is Bound”. labctl check 04 tests them and tells you exactly which ones pass.
This is deliberately not a grade. It is a way of answering “am I done?” in seconds instead of waiting for someone to come round, and it means you can experiment freely: if you break something, you will know precisely what broke.
Hints and solutions are recorded when you use them. The point is not surveillance — it is that the instructor can see who is quietly stuck and come and help. Use them. An hour spent staring at a Pending volume teaches you less than ten minutes with a hint and then working out why it was true.
What Is Installed
| Tool | Notes |
|---|---|
kubectl | With shell completion in zsh |
kustomize | Through kubectl itself: kubectl kustomize <dir>, kubectl apply -k <dir> |
helm | Including helm template and helm upgrade --install |
yq, jq | For reading and rewriting YAML and JSON on the command line |
kubectx, kubens | Switch context and namespace |
git, fzf, bat | The usual conveniences |
There is no container runtime and no local Kubernetes in your workspace, and you will not need one: you have a real cluster and you talk to it over the network.
Two Habits Worth Forming Now
Let the server validate your YAML. A mis-indented manifest fails in ways that look like Kubernetes problems rather than typing problems:
kubectl apply --dry-run=server -f yourfile.yamlAsk kubectl what a field means rather than searching the web for it:
kubectl explain pod.spec.volumes
kubectl explain pvc.spec --recursiveBoth are faster than guessing, and both work offline.