Kubernetes Learning Roadmap

Containers and images

Kubernetes runs containers, so start there. A container image packages your app with everything it needs, and a container is a running instance of it, isolated with Linux namespaces and cgroups. Images are built from a Dockerfile in layers and stored in a registry such as Docker Hub, GitHub Container Registry or Amazon ECR. Kubernetes doesn't use Docker itself to run them. It talks to a runtime such as containerd or CRI-O through the Container Runtime Interface, but images built with Docker work everywhere.

What to learn

• Images vs containers, layers, and tags vs digests
• Write a Dockerfile with a multi-stage build and a non-root user
• Build, run, inspect logs and push to a registry
• Why images should be small and immutable, and why :latest is a bad tag
• Container runtimes: containerd, CRI-O and the CRI

Free resources

• Docker: Get started docs
• Dockerfile best practices docs

Practice

Containerise a small web app with a multi-stage Dockerfile that runs as a non-root user, keep the image under 100 MB and push it to a registry.

Tools on this site

• Dockerfile linter

Kubernetes architecture

Kubernetes keeps your apps in the state you describe. The control plane holds that desired state and makes it happen: the API server is the front door for everything, etcd stores the state, the scheduler picks a node for each new Pod, and the controller manager runs the loops that keep reality matching what you asked for. Each worker node runs the kubelet (which starts containers through the runtime) and kube-proxy or a CNI plugin for Service networking.

The key idea is declarative configuration: you don't say "start three containers", you say "there should be three". If one dies, a controller notices and replaces it.

What to learn

• Control plane components and what each does
• Node components: kubelet, container runtime, kube-proxy
• Declarative desired state and the reconciliation loop
• What happens, step by step, when you create a Deployment
• The cloud native landscape and CNCF projects

Free resources

• Cluster architecture docs
• Kubernetes components docs
• CNCF Landscape interactive map

Practice

On a local cluster, list the control plane Pods in kube-system and explain in one sentence what each one does.

A local cluster: kind, minikube or k3d

You don't need a cloud account to learn Kubernetes. kind runs a whole cluster inside Docker containers and can create multi-node clusters in seconds. minikube is beginner-friendly, with add-ons such as a dashboard and metrics. k3d runs the lightweight k3s distribution. Pick one, learn to create and delete clusters freely, and keep everything you build in YAML files so you can recreate it any time.

For free in-browser practice without installing anything, try the Kubernetes scenarios on Killercoda.

What to learn

• Install kubectl and one of kind, minikube or k3d
• Create a multi-node cluster and delete it again
• Kubeconfig files, contexts and switching clusters
• Load a locally built image into the cluster

Free resources

• kind quick start docs
• minikube start docs
• Killercoda playgrounds free browser labs

Practice

Create a kind cluster with one control-plane and two worker nodes, then switch between it and a second cluster using kubectl contexts.

kubectl and YAML manifests

Every Kubernetes object is described in YAML with four parts: apiVersion, kind, metadata and spec. Apply files with kubectl apply -f and keep them in Git. Learn to generate manifests instead of typing them from memory: kubectl create deployment web --image=nginx --dry-run=client -o yaml gives you a correct starting point. kubectl explain documents every field from the command line. These two habits save a lot of time in hands-on exams.

What to learn

• YAML syntax: maps, lists, indentation and multi-document files (---)
• get, describe, apply, delete, logs, exec
• Generate YAML with --dry-run=client -o yaml
• Look up fields with kubectl explain pod.spec.containers
• Output formats: -o wide, -o yaml, -o jsonpath
• Imperative commands vs declarative apply

Free resources

• kubectl quick reference docs
• Learn Kubernetes basics tutorial

Practice

Without writing YAML by hand, generate a Deployment manifest, change the replica count to 3 in the file, apply it and print every Pod's IP with -o jsonpath.

Tools on this site

• YAML ⇄ JSON
• JSON formatter

Pods

A Pod is the smallest thing Kubernetes runs: one or more containers that share a network address and can share volumes. Pods are disposable. They get a new IP when replaced and are never "repaired", so you rarely create them directly. Higher-level objects such as Deployments create them for you. Learn the Pod lifecycle (Pending, Running, Succeeded, Failed), restart policies, and how to read kubectl describe pod events. That's where most problems explain themselves.

What to learn

• Pod spec: containers, image, ports, command and args, env
• Pod phases, container states and restart policies
• Read events with kubectl describe
• kubectl logs (including --previous) and kubectl exec
• Why you shouldn't create bare Pods in production

Free resources

• Pods docs
• Pod lifecycle docs

Practice

Run a Pod with a typo in the image name, find the cause in its events, fix it, then exec into the working Pod and check its environment variables.

Namespaces, labels and selectors

Namespaces divide a cluster into separate areas for teams or environments, each with its own names, permissions and quotas. Labels are key/value tags such as app=web or tier=frontend, and selectors pick objects by label. This is how a Deployment finds its Pods and a Service finds where to send traffic, so a label typo is a classic reason why "my Service has no endpoints". Annotations hold extra information for tools rather than for selection.

What to learn

• Create namespaces and set a default namespace for your context
• Labels vs annotations
• Equality and set-based selectors (-l app=web,tier!=db)
• ResourceQuotas and LimitRanges per namespace

Free resources

• Namespaces docs
• Labels and selectors docs

Practice

Create dev and prod namespaces with a ResourceQuota on dev, and try to exceed it.

Linux and networking basics

Kubernetes sits on top of Linux and networking, and troubleshooting quickly takes you there: processes and signals, file permissions, IP addresses and CIDR ranges, ports, DNS and HTTP. If any of these are new, a few hours here will make the rest of the roadmap much easier.

What to learn

• Shell basics, processes, signals (SIGTERM vs SIGKILL)
• File permissions and users (why containers shouldn't run as root)
• IP addresses, CIDR notation and private ranges
• Ports, DNS records and HTTP status codes

Free resources

• The Linux Command Line by William Shotts free book
• An overview of HTTP MDN

Practice

Work out how many addresses a 10.244.0.0/16 Pod network and a 10.96.0.0/12 Service network hold, and check with the CIDR calculator.

Tools on this site

• CIDR calculator
• chmod calculator
• HTTP status codes

Deployments, ReplicaSets and rollouts

A Deployment runs a set number of identical Pods and manages updates to them. Behind the scenes it creates a ReplicaSet per version. When you change the image, it performs a rolling update controlled by maxSurge and maxUnavailable, and you can watch, pause or undo it with kubectl rollout. Blue/green and canary releases are built on the same ideas with labels, two Deployments, or tools such as Argo Rollouts.

What to learn

• Deployment spec: replicas, selector, Pod template
• Scale with kubectl scale and change images with kubectl set image
• Rolling update settings: maxSurge and maxUnavailable
• kubectl rollout status, history and undo
• Recreate vs RollingUpdate strategies, blue/green and canary ideas

Free resources

• Deployments docs
• Performing a rolling update tutorial

Practice

Deploy version 1 of an app with 4 replicas, roll out a broken version 2, watch the rollout get stuck and roll back with one command.

Services and service discovery

Pods come and go, so other apps can't rely on their IPs. A Service gives a stable virtual IP and DNS name (web.default.svc.cluster.local) and load-balances to whichever Pods match its selector. ClusterIP is reachable inside the cluster only, NodePort opens a port on every node, and LoadBalancer asks the cloud provider for an external load balancer. A headless Service (clusterIP: None) returns the Pod IPs directly, which StatefulSets use.

What to learn

• ClusterIP, NodePort, LoadBalancer and ExternalName
• port vs targetPort vs nodePort
• Service DNS names across namespaces
• EndpointSlices, and debugging a Service with no endpoints
• Headless Services

Free resources

• Service docs
• DNS for Services and Pods docs

Practice

Expose a Deployment with a ClusterIP Service and call it by DNS name from a temporary Pod in another namespace (kubectl run tmp --rm -it --image=busybox).

Tools on this site

• API request tester

ConfigMaps and Secrets

Keep configuration out of images. A ConfigMap holds settings and a Secret holds sensitive values. Both can be injected as environment variables or mounted as files, and mounted files update when the object changes, while environment variables don't. Important: Secret values are only Base64-encoded, not encrypted. Protect them with RBAC, turn on encryption at rest, and consider an external store (such as AWS Secrets Manager or Vault through the External Secrets Operator).

What to learn

• Create ConfigMaps and Secrets from literals, files and .env files
• Use them as environment variables (envFrom) and as mounted volumes
• Which changes reach running Pods and which need a restart
• Secret types (opaque, TLS, docker-registry) and why Base64 isn't security
• Encryption at rest and external secret stores

Free resources

• ConfigMaps docs
• Secrets docs
• External Secrets Operator project

Practice

Turn an app's .env file into a ConfigMap and a Secret, mount the Secret as files, then decode a value with kubectl get secret -o jsonpath to see why access must be restricted.

Tools on this site

• .env → ConfigMap / Secret
• Base64 encode/decode

Health probes

Probes tell Kubernetes whether your container is working. A failing liveness probe restarts the container. A failing readiness probe takes the Pod out of its Services until it recovers, which is what makes rolling updates seamless. A startup probe gives slow-starting apps time before the other probes begin. A common mistake is a liveness probe that checks a database: when the database blips, every Pod restarts at once.

What to learn

• Liveness vs readiness vs startup probes
• HTTP, TCP, exec and gRPC probe types
• initialDelaySeconds, periodSeconds, failureThreshold
• Graceful shutdown: SIGTERM, terminationGracePeriodSeconds and preStop

Free resources

• Liveness, readiness and startup probes docs
• Configure probes task

Practice

Add readiness and liveness probes to your app, then make the readiness endpoint fail on one Pod and confirm it drops out of the Service's endpoints without restarting.

Tools on this site

• HTTP status codes

Resource requests, limits and QoS

Requests are what the scheduler reserves for a container, and limits are the ceiling. Going over the CPU limit slows the container down (throttling). Going over the memory limit kills it (OOMKilled). The combination puts each Pod in a QoS class (Guaranteed, Burstable or BestEffort), which decides who gets evicted first when a node runs short. Pods without requests make scheduling and autoscaling guesswork.

What to learn

• CPU units (250m) and memory units (256Mi)
• Requests vs limits, throttling vs OOMKilled
• QoS classes and eviction order
• LimitRanges and ResourceQuotas
• See real usage with kubectl top (needs metrics-server)

Free resources

• Resource management for Pods and containers docs
• Pod Quality of Service classes docs

Practice

Give a container a 64Mi memory limit, run something that uses more, and find OOMKilled in kubectl describe.

Jobs and CronJobs

A Job runs Pods until a task completes, with retries (backoffLimit) and optional parallelism. A CronJob creates Jobs on a schedule written in standard five-field cron syntax, with an optional timeZone. Set concurrencyPolicy to control overlapping runs and history limits so old Jobs get cleaned up.

What to learn

• Job completions, parallelism, backoffLimit and ttlSecondsAfterFinished
• CronJob schedules and the timeZone field
• concurrencyPolicy: Allow, Forbid, Replace
• Trigger a CronJob by hand with kubectl create job --from=cronjob/…

Free resources

• Jobs docs
• CronJob docs

Practice

Write a CronJob that backs up a database every night at 02:30 in your time zone, never runs two copies at once and keeps only the last 3 Jobs.

Tools on this site

• Cron expression builder

Init containers and sidecars

Some Pods need more than one container. Init containers run to completion before the app starts, for example to wait for a database or run migrations. Sidecar containers run alongside the app for its whole life: a log shipper, a proxy, a config reloader. Native sidecars are declared as init containers with restartPolicy: Always, which guarantees they start before and stop after the main container.

What to learn

• Init containers and their ordering
• Native sidecar containers (restartPolicy: Always)
• Sharing files between containers with an emptyDir volume
• Common patterns: sidecar, ambassador, adapter

Free resources

• Init containers docs
• Sidecar containers docs

Practice

Build a Pod whose init container waits until a Service resolves in DNS, and whose sidecar tails the app's log file from a shared emptyDir.

Gateway API and Ingress

To route HTTP traffic from outside to your Services by host name and path, Kubernetes now recommends the Gateway API. A platform team defines a GatewayClass and a Gateway (the listener, ports and TLS), and app teams attach HTTPRoutes with their routing rules, header matching, traffic splitting for canaries and more. It's implemented by controllers such as Envoy Gateway, Istio, Cilium, NGINX Gateway Fabric and Traefik, and by cloud load balancers.

The older Ingress API still works and you'll meet it in existing clusters. Note that the popular community Ingress NGINX controller was retired in March 2026 and gets no more updates or security fixes, so plan migrations to the Gateway API (the ingress2gateway tool helps).

What to learn

• GatewayClass, Gateway and HTTPRoute, and who owns each
• Host and path routing, header matches and weighted traffic splits
• TLS termination with a certificate Secret (and cert-manager to automate it)
• Read existing Ingress objects and convert them to HTTPRoutes

Free resources

• Gateway API official site
• Gateway API in the Kubernetes docs docs
• Ingress NGINX retirement announcement
• cert-manager docs

Practice

Install a Gateway API controller on your local cluster and route app.local/api and app.local/ to two different Services, then send 10% of /api traffic to a new version.

Tools on this site

• SSL certificate decoder
• HTTP status codes

Cluster networking, DNS and CNI

Kubernetes has a simple network model: every Pod gets its own IP and can reach every other Pod without NAT. A CNI plugin (Calico, Cilium, Flannel and others) makes that happen and often enforces NetworkPolicies too. Services get virtual IPs from a separate range, implemented by kube-proxy or by the CNI (Cilium can replace kube-proxy with eBPF). CoreDNS gives every Service a DNS name. Most "it can't connect" problems are DNS, a wrong port or a policy.

What to learn

• The Kubernetes network model: Pod IPs, Service IPs, node IPs
• What a CNI plugin does, and popular choices
• kube-proxy modes and eBPF alternatives
• CoreDNS, search domains, and debugging with nslookup from a Pod

Free resources

• Services, load balancing and networking docs
• Debugging DNS resolution task

Practice

From a debug Pod, resolve a Service in another namespace by its short name, its namespaced name and its full name, and explain why the short name fails.

Tools on this site

• CIDR calculator
• IP range checker

NetworkPolicies

By default every Pod can talk to every other Pod. NetworkPolicies are firewalls for Pods: once a policy selects a Pod, only the traffic it allows gets through, chosen by Pod labels, namespaces or IP ranges, for ingress, egress or both. Start with a default-deny policy per namespace, then open only what each app needs. Remember that policies only work if your CNI plugin enforces them.

What to learn

• podSelector, namespaceSelector and ipBlock rules
• Default-deny ingress and egress policies
• Allow DNS egress (port 53) so a default-deny doesn't break everything
• Check which CNI plugins enforce policies

Free resources

• Network Policies docs
• Network Policy Editor visual tool

Practice

In a namespace with a frontend, an API and a database, apply default-deny, then allow only frontend → API and API → database, plus DNS. Prove that frontend → database is blocked.

Tools on this site

• IP range checker

Volumes, PersistentVolumes and StorageClasses

Container files disappear when the container restarts. Volumes fix that: an emptyDir lives as long as the Pod, while a PersistentVolumeClaim asks for durable storage that outlives Pods. A StorageClass tells the cluster how to create that storage on demand through a CSI driver (for example EBS volumes on AWS). Access modes (ReadWriteOnce, ReadWriteMany) and the reclaim policy decide who can mount it and what happens to the data when the claim is deleted.

What to learn

• emptyDir, hostPath (and why to avoid it), configMap and secret volumes
• PersistentVolume vs PersistentVolumeClaim, and static vs dynamic provisioning
• StorageClasses and CSI drivers
• Access modes and reclaim policies (Retain vs Delete)
• Volume expansion and snapshots

Free resources

• Persistent Volumes docs
• Storage Classes docs

Practice

Run a database with a PersistentVolumeClaim, write some data, delete the Pod and confirm the data is still there when it comes back.

StatefulSets and DaemonSets

A StatefulSet is for apps where each replica has an identity, such as databases and message brokers: Pods get stable names (db-0, db-1), stable DNS through a headless Service, their own PersistentVolumeClaim each, and start and stop in order. A DaemonSet runs one Pod on every node (or every matching node), which is how log collectors, monitoring agents and CNI plugins are deployed.

What to learn

• StatefulSet identity, ordering and volumeClaimTemplates
• Headless Services for stable per-Pod DNS
• DaemonSets, node selectors, taints and tolerations
• When a managed database beats running one in Kubernetes

Free resources

• StatefulSets docs
• DaemonSet docs
• Taints and tolerations docs

Practice

Run a 3-replica StatefulSet and reach web-1 directly by its DNS name. Then run a DaemonSet that only lands on nodes with a logging=true label.

Helm

Helm is the package manager for Kubernetes. A chart is a set of templated manifests plus a values.yaml of defaults. Installing it creates a release you can upgrade, roll back and uninstall as a unit. Most third-party software (monitoring stacks, databases, controllers) is installed with Helm, so you'll use other people's charts far more often than you write your own.

What to learn

• Add repositories, search, install, upgrade, roll back and uninstall
• Override values with -f values.yaml and --set
• Render templates locally with helm template to see what will be applied
• Chart structure, templates and helpers
• OCI registries for charts

Free resources

• Helm documentation docs
• Artifact Hub: find charts registry

Practice

Install a chart from Artifact Hub with custom values, upgrade it, roll back, then package your own app as a chart with a configurable replica count and image tag.

Tools on this site

• YAML ⇄ JSON
• Text diff (compare rendered manifests)

Kustomize

Kustomize customises plain YAML without templates. You keep a base and add overlays per environment that patch it: more replicas in prod, a different image tag in staging, extra labels everywhere. It's built into kubectl (kubectl apply -k) and works well with GitOps tools. Many teams use Helm for third-party software and Kustomize for their own apps.

What to learn

• kustomization.yaml: resources, namePrefix, labels, images
• Bases and overlays for dev / staging / prod
• Strategic merge and JSON patches
• configMapGenerator and secretGenerator

Free resources

• Declarative management with Kustomize docs

Practice

Create a base for your app and dev/prod overlays that change replicas, image tag and resource limits. Preview each with kubectl kustomize before applying.

Tools on this site

• Text diff

RBAC and ServiceAccounts

Role-based access control decides who may do what. A Role lists allowed verbs (get, list, create…) on resources in one namespace, and a ClusterRole does the same cluster-wide. RoleBindings and ClusterRoleBindings grant them to users, groups or ServiceAccounts, which are the identities Pods use to call the API. Pods get short-lived, automatically rotated tokens. Grant the minimum, and check with kubectl auth can-i.

What to learn

• Roles vs ClusterRoles, RoleBindings vs ClusterRoleBindings
• ServiceAccounts and projected, short-lived tokens
• kubectl auth can-i --as=system:serviceaccount:ns:name
• Turn off token mounting for Pods that don't call the API
• How cloud identities map to Kubernetes users (for example EKS access entries)

Free resources

• Using RBAC authorization docs
• Service accounts docs

Practice

Create a ServiceAccount that can only list Pods in one namespace, run a Pod with it, and prove with kubectl auth can-i that it can't delete anything.

Tools on this site

• JWT decoder (ServiceAccount tokens)

Pod security

A container that runs as root, with a writable filesystem and every Linux capability, is a gift to an attacker. Use the securityContext to run as a non-root user, drop capabilities, block privilege escalation and make the root filesystem read-only. Enforce this cluster-wide with Pod Security Admission, which applies the baseline or restricted Pod Security Standards per namespace through labels (it replaced PodSecurityPolicy). For custom rules, use the built-in ValidatingAdmissionPolicy or Kyverno.

What to learn

• securityContext: runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation, capabilities
• Pod Security Standards: privileged, baseline, restricted
• Pod Security Admission namespace labels (enforce, audit, warn)
• Policy engines: ValidatingAdmissionPolicy, Kyverno, OPA Gatekeeper

Free resources

• Pod Security Standards docs
• Pod Security Admission docs
• Kyverno docs

Practice

Label a namespace to enforce the restricted standard, watch an ordinary nginx Pod get rejected, then fix its securityContext until it's accepted.

Tools on this site

• Dockerfile linter (non-root USER)

Autoscaling

Kubernetes can scale at three levels. The Horizontal Pod Autoscaler adds or removes Pods based on CPU, memory or custom metrics (it needs metrics-server and correct resource requests). The Vertical Pod Autoscaler recommends or sets better requests. Node autoscaling with the Cluster Autoscaler or Karpenter adds nodes when Pods can't be scheduled and removes idle ones. For event-driven scaling (queue length, for example), there's KEDA.

What to learn

• HPA with CPU targets, min/max replicas and scaling behaviour
• metrics-server and why requests matter for HPA
• VPA recommendations
• Cluster Autoscaler vs Karpenter
• PodDisruptionBudgets so scale-downs and upgrades don't take an app offline

Free resources

• Horizontal Pod Autoscaling docs
• Karpenter project
• KEDA project

Practice

Put an HPA on your app targeting 50% CPU, generate load with a busy-loop Pod and watch replicas climb and then settle back down.

Monitoring and logging

In production you need to know what's happening before users tell you. Prometheus scrapes metrics from your apps and the cluster, Grafana turns them into dashboards, and Alertmanager sends alerts. The kube-prometheus-stack Helm chart installs all three with useful defaults. For logs, a DaemonSet such as Fluent Bit ships container output to a store such as Loki or a cloud service, and OpenTelemetry adds traces that follow a request across services.

What to learn

• Metrics, logs and traces, and what each is good for
• Prometheus scraping, PromQL basics and ServiceMonitors
• Grafana dashboards and Alertmanager rules
• Log collection with a node agent, and structured (JSON) logs
• OpenTelemetry basics

Free resources

• Prometheus overview docs
• Grafana documentation docs
• OpenTelemetry docs

Practice

Install kube-prometheus-stack with Helm, build a Grafana panel for your app's request rate and create an alert that fires when a Pod restarts more than 3 times in 10 minutes.

Tools on this site

• JSON formatter (structured logs)
• Timestamp converter

CI/CD and GitOps

A typical pipeline builds and tests the image in CI (for example GitHub Actions), pushes it to a registry, then updates the manifests. With GitOps, a controller inside the cluster (Argo CD or Flux) watches a Git repository and keeps the cluster matching it. Deployments become pull requests, every change has history and review, and drift from manual kubectl edits is undone automatically.

What to learn

• Build, scan and push images from CI, tagged with the commit SHA
• GitOps principles: Git as the source of truth, pull-based deploys
• Argo CD Applications, sync and health status (or Flux Kustomizations)
• Promote between environments with Kustomize overlays or Helm values

Free resources

• Argo CD documentation docs
• Flux documentation docs
• OpenGitOps principles CNCF

Practice

Install Argo CD locally and point it at a Git repo with your Kustomize overlays. Change the replica count in a commit and watch it sync, then edit the Deployment by hand and watch Argo CD revert it.

Tools on this site

• GitHub Actions builder (Docker → registry)

Managed Kubernetes: EKS, GKE and AKS

In production most teams use a managed service: Amazon EKS, Google GKE or Azure AKS. The provider runs the control plane, and you choose how nodes are managed (managed node groups, Karpenter, or serverless options such as Fargate and GKE Autopilot). The cloud adds its own integrations: load balancers for Services and Gateways, block storage through CSI drivers, and a way for Pods to get cloud permissions without stored keys (EKS Pod Identity or IRSA, GKE Workload Identity).

What to learn

• What the provider manages vs what you manage
• Node options: managed node groups, Karpenter, Fargate / Autopilot
• Load balancer and storage integrations
• Pod-level cloud permissions (EKS Pod Identity / IRSA, Workload Identity)
• Cost: control-plane fees, node sizing, and cleaning up load balancers and volumes

Free resources

• What is Amazon EKS? docs
• EKS Workshop hands-on
• GKE overview docs
• What is AKS? docs

Practice

Deploy the app you've built on this roadmap to a managed cluster with a public HTTPS endpoint, then delete the cluster and check that no load balancers or volumes were left behind.

Tools on this site

• AWS learning roadmap
• CIDR calculator (VPC view)

Troubleshooting

Most problems follow a few patterns. Pending means the scheduler can't place the Pod (not enough resources, taints, an unbound volume). ImagePullBackOff is a wrong image name or missing registry credentials. CrashLoopBackOff means the app starts and exits, so read kubectl logs --previous. A Service that doesn't respond is usually a selector, a port or a NetworkPolicy. Work from the outside in, and let describe and events tell you where to look.

What to learn

• Pending, ImagePullBackOff, CrashLoopBackOff, OOMKilled and CreateContainerConfigError
• kubectl get events --sort-by=.lastTimestamp and describe
• Debug with kubectl debug (ephemeral containers) and port-forward
• Service → endpoints → Pod checks
• Node problems: NotReady nodes, kubelet logs, disk and memory pressure

Free resources

• Debug Pods docs
• Debug Services docs
• Troubleshooting clusters docs

Practice

Ask a friend (or write a script) to break your app in five different ways, such as a wrong image, a bad label, a missing ConfigMap, too-small memory and a blocking NetworkPolicy, and find each cause in under five minutes.

Tools on this site

• HTTP status codes
• Text diff

Cluster setup, upgrades and backups

Administrators need to know how a cluster is built and kept alive. kubeadm bootstraps a cluster from plain machines and upgrades it one minor version at a time: control plane first, then each node after draining it. Back up etcd with etcdctl snapshot save and practise restoring it, and use tools such as Velero to back up workloads and volumes. Kubernetes releases about three minor versions a year and each gets roughly a year of patches, so upgrades are routine work, not a one-off.

What to learn

• Install a cluster with kubeadm on VMs
• Upgrade the control plane and nodes; drain, cordon and uncordon
• Back up and restore etcd
• Certificates and kubeconfig files for admins
• Workload backups with Velero, and the Kubernetes release and support cycle

Free resources

• Creating a cluster with kubeadm docs
• Upgrading kubeadm clusters docs
• Operating etcd clusters docs
• Velero docs

Practice

Build a one-control-plane, two-worker cluster with kubeadm on VMs, take an etcd snapshot, upgrade it by one minor version, then restore the snapshot to a test cluster.

Supply chain and runtime security

Secure what goes into the cluster and watch what runs there. Scan images for known vulnerabilities (Trivy), sign them and verify signatures before they run (Sigstore cosign plus an admission policy), use minimal or distroless base images, and pin images by digest. At runtime, Falco detects suspicious behaviour, such as a shell starting inside a container. Audit logs record every API request.

What to learn

• Image scanning in CI and in the registry
• Image signing and verification
• Minimal base images and SBOMs
• Runtime threat detection with Falco, and API audit logging

Free resources

• Trivy project
• Sigstore docs
• Falco docs

Practice

Add a Trivy scan to your CI pipeline that fails on critical vulnerabilities, then switch your base image until it passes.

Tools on this site

• Hash generator (digests)

Service mesh

A service mesh adds encryption (mutual TLS), retries, timeouts, traffic splitting and detailed metrics between services without changing application code. Istio (including its sidecar-less ambient mode), Linkerd and Cilium are the common choices. It's powerful but adds moving parts, so reach for it when you have many services and a real need for mTLS or fine-grained traffic control.

What to learn

• What a mesh adds: mTLS, retries, traffic shifting, observability
• Sidecar vs sidecar-less (ambient / eBPF) designs
• How meshes relate to the Gateway API

Free resources

• What is Istio? docs
• Linkerd overview docs

Practice

Install a mesh on your local cluster, turn on mTLS between two services and confirm in its dashboard that traffic is encrypted.

CRDs and operators

Kubernetes can be extended with your own object types. A CustomResourceDefinition (CRD) adds a new kind, such as Certificate or PostgresCluster, and an operator is a controller that watches those objects and does the work, encoding a human operator's knowledge (backups, failover, upgrades) in code. Many tools you've met on this roadmap, such as cert-manager, Argo CD and Prometheus, work this way.

What to learn

• CRDs: schema, versions and kubectl get on custom kinds
• The controller pattern and reconciliation loops
• Install and use an existing operator (for example a database operator)
• Building operators: kubebuilder or Operator SDK (overview)

Free resources

• Operator pattern docs
• Extend the API with CustomResourceDefinitions docs

Practice

Install cert-manager, create a self-signed Issuer and a Certificate, and watch the operator create the TLS Secret for you.

Tools on this site

• SSL certificate decoder

Certification exam preparation

The Linux Foundation and CNCF run four main Kubernetes exams. KCNA is a 90-minute multiple-choice exam on concepts (US$250). CKAD (developers), CKA (administrators) and CKS (security, requires passing the CKA first) are 2-hour, hands-on exams where you solve tasks in real clusters from a terminal (US$445 each). They're currently based on Kubernetes v1.37, include one free retake and are valid for 2 years. Prices and versions change, so check the official pages.

Hands-on exams reward speed: generate YAML with --dry-run=client -o yaml, use kubectl explain, set an alias (alias k=kubectl), switch to the context each question names, and skip hard questions and come back to them.

What to learn

• Read the official curriculum for your exam and map it to topics on this page
• Practise in the exam simulator included with your registration
• Get fast with imperative commands, explain and vim/nano editing
• Bookmark the official docs pages you'll need (they're allowed during the exam)
• Do two full timed practice runs before booking

Free resources

• KCNA official
• CKAD official
• CKA official
• CKS official
• CNCF exam curricula GitHub

Practice

Finish a full practice exam within the time limit, scoring at least 80%, before you book the real one.