Skip to main content

Exercise Lanes

This module's exercises are built around a real cluster. YAML on paper is not enough. You need kubectl apply, kubectl describe, and kubectl get against a cluster that can actually schedule and fail.

Before You Start​

Have ready:

  • a local cluster (kind, minikube, or k3d; kind is recommended) created from a repeatable command
  • kubectl, crictl, and optionally k9s
  • a debug container image (e.g. nicolaka/netshoot) available to your cluster

How To Use This Page​

  1. Finish the relevant concept pages and practice pages first.
  2. Do the lane's exercises against a real local cluster first (kind, minikube, or k3d). Managed Kubernetes is a later comparison point, not a prerequisite.
  3. If you repeat an exercise on EKS/GKE/AKS, configure billing alerts first and capture the teardown command.
  4. Keep a mistake log with tags such as wrong selector, missing ingressClass, OOMKilled, no endpoints, PVC stuck pending, RBAC permission denied.

Lane 1: Container Fundamentals​

Use this lane when you cannot yet explain, in kernel terms, what docker run does.

  • Build a container by hand with unshare and a cgroup (see Practice 01).
  • Inspect alpine:3.19 as OCI bytes: manifest, config, layers.
  • On a kind node, list the containerd-level view with crictl ps and crictl inspect.
  • Write your own 10-line Dockerfile that has no more than 3 layers, runs as non-root, and uses a distroless or alpine base.

Target outcomes:

  • 1 by-hand container with all seven namespaces unshared
  • 1 fully annotated OCI image inspection
  • 1 working Dockerfile following layering best practice

Lane 2: Kubernetes Primitives​

Use this lane when you can write a Deployment but cannot trace what happens after kubectl apply.

  • Apply the Deployment from Workshop 02 and record the full event order.
  • Cause at least 3 named failure modes (ImagePullBackOff, OOMKilled, Pending insufficient cpu) and resolve each using the kubectl workflow.
  • Write a pseudocode reconcile loop for a controller of your choice (ReplicaSet, Deployment, Endpoint).

Target outcomes:

  • 1 annotated control plane trace
  • 3 documented failure-and-fix cycles
  • 1 pseudocode reconcile loop

Lane 3: Services, Networking, and Storage​

Use this lane when you can write a Service but cannot debug "service has no endpoints."

  • Stand up Deployments web and api, expose each with a ClusterIP Service.
  • Install an ingress controller and route two paths on one hostname.
  • Deploy a 3-replica StatefulSet (Postgres or Redis) with volumeClaimTemplates.
  • Delete a StatefulSet Pod and confirm the new Pod picks up the same name, DNS, and PVC.
  • Create a NetworkPolicy that denies ingress to one namespace by default and allows only app: web.

Target outcomes:

  • 1 working Ingress with two routes
  • 1 StatefulSet with per-Pod storage and verified identity
  • 1 NetworkPolicy verified with curl between namespaces

Lane 4: Operating the Cluster​

Use this lane when you can deploy workloads but cannot yet operate them.

  • Set requests and limits on a workload, induce OOMKill, and resize.
  • Configure an HPA on a Deployment and drive load through it.
  • Apply a PSS restricted namespace and harden a Pod to pass admission.
  • Write an RBAC Role + RoleBinding for a CI ServiceAccount with minimal permissions.
  • Run a full troubleshooting walkthrough for a pod you intentionally broke, writing down every command you ran.

Target outcomes:

  • 1 HPA driven to at least 2x scale-up then back down under controlled load
  • 1 restricted PSS namespace with at least one workload that passes admission
  • 1 RBAC policy with written justification for every permission (and non-permission)
  • 1 troubleshooting runbook of at least 8 failure modes

Self-Curated Problem Set​

Build a custom set with these minimums:

  • 5 Deployments you wrote from scratch, each with probes, requests, and limits
  • 3 Services (one ClusterIP, one headless, one LoadBalancer or NodePort)
  • 2 Ingress or HTTPRoute configurations
  • 1 StatefulSet with PVCs
  • 1 HPA driven by real load
  • 1 RBAC configuration
  • 1 PSS-enforced namespace

Completion Checklist​

  • Ran at least one full lane end to end
  • Logged at least 12 real mistakes and the exact kubectl command that surfaced each
  • Wrote at least 8 manifests from memory without copy-paste
  • Reproduced at least 5 named failure modes (ImagePullBackOff, CrashLoopBackOff, OOMKilled, Pending insufficient cpu, no endpoints)
  • Traced one kubectl apply through all five control plane components