Kubernetes Roadmap
Eight stages, each gated by a capability rather than a lesson count. Every stage ends with a concrete check — something you can either do or cannot — so progress is measurable rather than a feeling.
Dependencies that are not optional
Most lessons can be taken in any order within a stage. These four cannot.
- Services & DNS before everything about networking You cannot debug a packet path without knowing what a Service actually is.
- Resources & QoS before autoscaling Every autoscaler is arithmetic on requests. Without them, an HPA reports <unknown> and does nothing.
- Probes before rollouts and PDBs Readiness decides Service membership, rollout progress and drain safety.
- The control loop before CRDs and operators An operator is that loop applied to a type you invented. Get the model wrong and the controller is a script.
Stage 1 — Fundamentals
~2hRead what the cluster is telling you
Containers: you can build an image and run it with docker/podman. Basic Linux and YAML.
- ▸Explain any behaviour as a reconciliation loop rather than a command
- ▸Trace kubectl apply through admission, etcd, controller, scheduler, kubelet
- ▸Name what breaks when each control-plane component dies
- ▸Diagnose a Pending pod from the scheduler’s own message
- ▸Connect a Service to pods and explain why endpoints are empty
Given a pod stuck in Pending and a Service with no endpoints, you find both root causes with `kubectl describe` and `kubectl get endpointslices` — and you never once open the application logs.
Stage 2 — Workloads & Configuration
~2hShip something that survives a bad Tuesday
Stage 1 — especially the spec/status model and Service→endpoint routing.
- ▸Choose between Deployment, StatefulSet, DaemonSet and Job on their real trade-offs
- ▸Keep configuration outside the image without leaking secrets into env vars
- ▸Configure probes so a slow dependency never causes a restart storm
- ▸Use native sidecars (1.33+) instead of the old workarounds
- ▸Set requests and limits from measurement, and spot CPU throttling
A deploy of a broken image stalls at one pod instead of taking the service down, and you can point at the readiness probe that stopped it.
Stage 3 — Storage
~0.5hState is the part you cannot roll back
Stage 2, StatefulSets in particular.
The thinnest stage in the path — one lesson. Snapshots, StatefulSet storage operations and IOPS tuning are known gaps, not omissions by design.
- ▸Follow a PVC through StorageClass, provisioner and CSI to a real volume
- ▸Pick access modes that match what the workload actually does
- ▸Avoid the zone deadlock that WaitForFirstConsumer exists to prevent
- ▸Know what a reclaim policy will and will not delete
You can explain why a StatefulSet pod is Pending in a multi-zone cluster without reading a single application log — and say whether the volume or the scheduler bound first.
Stage 4 — Scheduling & Scaling
~0.5hDecide where pods land, and how many
Requests and limits from Stage 2. Every autoscaler is arithmetic on them.
- ▸Spread replicas across zones, not just nodes
- ▸Use affinity, anti-affinity and taints without making pods unschedulable
- ▸Choose between HPA, VPA, Cluster Autoscaler and Karpenter deliberately
- ▸Explain why an HPA reports <unknown> and does nothing
Your workload survives the loss of an entire zone, and you can say which autoscaler reacts first, how long it takes, and what it does if the other one disagrees.
Stage 5 — Networking
~1hFollow the packet, do not guess
Services & cluster DNS from Stage 1.
- ▸Follow a packet hop by hop and name every place it can be dropped
- ▸Diagnose conntrack exhaustion and MTU mismatch from their signatures
- ▸Choose between Ingress and the Gateway API knowing why one replaced the other
- ▸Write NetworkPolicy that is neither useless nor an outage
You can explain why a Service is unreachable by working up from pod IP to DNS in five commands, and your default-deny NetworkPolicy ships with the DNS and monitoring exceptions already in it.
Stage 6 — Security
~1.5hLeast privilege that still ships
Stage 5 — NetworkPolicy is half of workload isolation.
- ▸Build least-privilege RBAC and prove it with `auth can-i`
- ▸Know what a ServiceAccount token actually grants, and for how long
- ▸Apply Pod Security Admission without breaking the next rollout
- ▸Harden a workload without making it undebuggable
Project 1 — you ship a workload that passes a restricted PSA namespace, holds no permission it does not use, and still survives a node drain.
Stage 7 — Operations & Production
~3.5hBe the person called when the cluster is the problem
Stages 1–6, plus Project 1 completed and verified.
- ▸Template and deliver manifests with Helm, Kustomize and GitOps
- ▸Alert on symptoms rather than on utilisation
- ▸Upgrade a cluster without a PDB blocking the drain
- ▸Snapshot and restore etcd, and know what a restore actually reverts
- ▸Share a cluster between teams without one starving another
- ▸Size a cluster against the limits that bite before CPU does
- ▸Run a fixed triage sequence instead of guessing
- Helm, Kustomize & GitOps 19m
- Observability: Metrics, Logs, Events & Traces 19m
- Cluster Upgrades, PDBs & Node Drain 20m
- etcd Operations, Backup & Disaster Recovery 19m
- Multi-Tenancy, Quotas & Cost Control 18m
- Capacity Planning & Production Readiness 18m
- The Production Debugging Playbook 20m
- Project Zero-Downtime Cluster Upgrade 75m
You can name your cluster’s etcd fsync p99, its request-vs-allocatable ratio, and every PDB with zero allowed disruptions — from memory, because you check them.
Stage 8 — Extending Kubernetes
~3hJudgement, not knowledge
Stage 7, plus Projects 1 and 3.
- ▸Extend the API with CRDs and admission control — safely
- ▸Write a controller that is idempotent, owns its children and cleans up after itself
- ▸Know when an operator is the wrong answer
- ▸Capture evidence before it expires, and correlate across every layer
- ▸Review someone else’s manifests and name the failure before it happens
Handed an unfamiliar cluster and a vague "it is slow", you produce a correct diagnosis and a written timeline inside thirty minutes — and you can say which 200 lines of a 400-line operator should not exist.
Version policy
This module is pinned to Kubernetes 1.36. Kubernetes supports the three most recent minor releases, so the current window is 1.34–1.36. Material written even two years ago is frequently wrong about specifics — these three catch people out most:
Where a lesson depends on a version, it says so explicitly. When in doubt, check
kubectl api-resources against your own
cluster rather than trusting any document, including this one.