A self-paced lab for standing up a single-node K3s cluster and working through core Kubernetes primitives — workloads, networking, dual-track persistent storage (local block via LVM, and network via NFS), config management, and troubleshooting.
This lab is designed to run on Ubuntu or Fedora (RHEL is intentionally avoided to keep the lab free of subscription/registration requirements).
| Resource | Allocation | Notes |
|---|---|---|
| Operating System | Ubuntu 22.04/24.04 LTS or Fedora Server (latest) | Either works; instructions below note where the two diverge. |
| Compute | 2 vCPUs minimum | Combined control-plane + worker workload. |
| Memory | 4-8 GB RAM | Scale toward 8 GB if you plan to add monitoring/telemetry later. |
| Root Disk | 20-40 GB | OS + K3s binaries + container images. |
| Secondary Disk | 10-20 GB, raw/unformatted | Attached separately for the LVM/block storage track in the lab exercises (Exercise 21, Track A). Do not partition or format it ahead of time. |
| NFS Export (optional) | Any host on the same network able to export an NFS share (a hypervisor, NAS, or separate Linux box) | Only needed for the optional network storage track (Exercise 21, Track B). Not required to complete the rest of the lab. |
| Network | Static or DHCP-reserved IP, outbound internet access | Needed to pull the K3s install script and container images. |
How you attach the secondary disk depends on your hypervisor/platform — this lab doesn't assume a specific one — but the general shape is the same everywhere:
- VirtualBox: VM Settings → Storage → add a second virtual hard disk
(a new
.vdi/.vmdkfile) on the same or a different controller from the OS disk. - VMware Workstation/Fusion/ESXi: VM Settings → Add a new hard disk → create a new virtual disk of the size above.
- Proxmox: VM → Hardware → Add → Hard Disk, on any available storage.
- A cloud VM (AWS/Azure/GCP/etc.): attach a second block-storage volume (EBS/Managed Disk/Persistent Disk) to the instance.
In every case: attach it as a second, independent disk — not a partition
on the existing OS disk — and leave it completely raw (no filesystem, no
partition table). The lab exercises handle partitioning, LVM, and
formatting themselves; anything pre-formatted here will just need to be
wiped again later. After attaching it and booting the VM, lsblk should
show it as an extra whole-disk entry (commonly /dev/sdb, but confirm
rather than assume) with no FSTYPE and no children — this is exactly
what the lab's storage exercise checks for.
Exercise 21's Track B (network-attached storage) needs an NFS share
exported from outside this VM — a hypervisor, a NAS, or any other
Linux host on the same network with nfs-kernel-server (or equivalent)
configured to export a directory to this VM's IP or subnet. Setting up
that export is outside the scope of this lab, since it depends entirely on
what's available in your environment — Track A (local block storage via
LVM) alone is enough to complete every other exercise in this lab. Skip
this requirement entirely if you don't have infrastructure to export a
share from; Exercise 21 covers this explicitly as an optional track.
Once your VM meets the requirements above, head to the K3s/Headlamp Install guide to install K3s itself and, optionally, the Headlamp web UI.
Once K3s is installed and healthy, move on to the exercises below.
Unlike a simple pass/fail checklist, each exercise is a short, narrative
walkthrough of one topic: you run a command, read what it prints, and the
text tells you why you ran it and what to look for in the output before
moving to the next one. The same handful of inspection commands
(kubectl get, describe, logs, events) come up again and again on
purpose — the goal of this lab is comfort navigating a running cluster from
the CLI, not just completing tasks.
Every exercise ends with a short recap and a link to the next one, so you can either:
-
Start at Exercise 1 and follow the "Next" link at the bottom of each page straight through to the end, or
-
Jump directly to whichever topic you want from the index below.
Exercises are grouped into modules, and are meant to be worked in order within a module — later exercises assume resources created in earlier ones still exist.