21 hands-on labs to practise for the Certified Kubernetes Application Developer, roughly 6 hours of work, each one graded on the state of your machine rather than on the commands you typed. They run on your own hardware with the `dsoxlab` command line, and cost nothing.
The point of view of whoever ships an application: Pod design, configuration, observability, rolling updates and service access.
- 21labs
- 6hours of practice
- 21on real VMs
Levels 6 beginner 13 intermediate 2 advanced
Official exam objectives published by CNCF
These are not exam questions. They are hands-on exercises on the skills the exam measures, graded on the state of your machine.
Kubernetes, CKA, CKAD and CKS
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training
CKA, Certified Kubernetes Administrator
-
Cap a namespace without blocking those who forget to declare themselves
A namespace with no ceiling and no defaults: one team can take the whole cluster, and a Pod with no requests is scheduled blind. Set both, and prove each: a Pod asking too much is refused, a Pod asking nothing is accepted and completed.
dsoxlab start cka-resourcequota-limitrange
CKAD, Certified Kubernetes Application Developer
-
A two-container Pod, with budgets, labels and an annotation
Write by hand a Pod with two containers, each with its own requests and limits, with labels and an annotation, and prove from inside each container that the memory limit is the one the kernel enforces.
dsoxlab start ckad-pod-resources-labels -
Inject configuration and secrets into a Pod
Give an application its configuration through environment variables and through a mounted file, and its credentials through a Secret, without ever writing a password in the Pod manifest. Prove, from inside the container, that everything arrived.
dsoxlab start ckad-configmap-secret-injection -
Take a password out of a manifest, without the application noticing
A password sits in plain sight inside a Deployment manifest, which anyone who can read the manifest can read too. Move it into a Secret, inject it both as an environment variable and as a mounted file, and keep the application running.
dsoxlab start ckad-secret-injection-protection -
Three probes on one Pod: startup, liveness, readiness
Fit an application with all three probes, with settings that make sense: a slow start tolerated, liveness watched, traffic that only arrives once the Pod is ready. Prove the probes act: the Pod is Ready only because they answer.
dsoxlab start ckad-probes-all-types -
Wait for a dependency with an init container
Keep an application from starting before the Service it depends on answers, with an init container that waits. Watch the Pod held in Init, put the dependency in place, and see the application start on its own.
dsoxlab start ckad-init-container -
A native sidecar that tails the application logs
Have a second container read the logs an application writes to a file, with a native sidecar, declared as an init container with restartPolicy Always, and a shared volume. Prove that the sidecar really does pass the lines on.
dsoxlab start ckad-multi-container-sidecar -
Let one container read what another writes, and nothing else
Two containers in one Pod, one writing and one reading, and nothing shared between them. Give them a volume whose lifetime is the Pod's, and prove it both ways: what is written inside the volume crosses, what is written beside it does not.
dsoxlab start ckad-volumes-partage-entre-conteneurs -
Expose a Deployment through a ClusterIP Service
Deploy three replicas of a server and expose them through an internal Service. Prove from a client that the Service answers under its name, and that it really spreads the requests across the three Pods.
dsoxlab start ckad-expose-service -
Harden a Pod with a securityContext
Run a web server with no privilege: non-root user, no escalation, read-only root filesystem, every capability dropped. And still give it somewhere to write where it needs to, otherwise it will not start. Prove, from the inside, that the confinement holds and that the application serves.
dsoxlab start ckad-security-context-hardened -
Grant read-only access to Pods with RBAC
Let a user read the Pods of a namespace and their logs, and nothing more: no creating, no deleting, no looking into the other namespaces. Prove both sides with kubectl auth can-i, what is allowed and what stays denied.
dsoxlab start ckad-rbac-role-rolebinding -
Partition three tiers with ingress and egress NetworkPolicy
Frontend, backend, database: allow only the intended flows, in both directions, DNS included, and forbid everything else. Prove every rule with a real connection, the one that goes through and the one that is blocked.
dsoxlab start ckad-networkpolicy-ingress-egress -
Tune a rolling update: maxSurge and maxUnavailable
Constrain the way a Deployment replaces its Pods, never more than two extra ones nor more than one unavailable, then trigger an image update and prove it went all the way through: old revision down to zero, new one complete.
dsoxlab start ckad-rolling-update-strategy -
Switch traffic from one version to the other: blue-green
Run two versions of an application side by side, then switch all the traffic from one to the other by changing a Service selector. Prove the switch from a client: every request reaches the new version, none the old one.
dsoxlab start ckad-blue-green-deployment -
One Kustomize base and two overlays, dev and prod
Describe an application only once, in a Kustomize base, and deploy it into two namespaces with overlays that change the replica count, prefix the names and add an environment label. Prove that both environments are running and look alike.
dsoxlab start ckad-kustomize-overlays -
Install, upgrade and roll back with Helm 4
Deploy a chart with Helm, upgrade it with new values, then go back to the first revision. Prove through the release history and the state of the Deployment that the three operations took place, in that order.
dsoxlab start ckad-helm-install-upgrade -
A Job with parallel completions, and a CronJob
Run a workload four times, two at a time, with a Job, and prove that the runs really did overlap. Then schedule a cleanup every five minutes with a CronJob that keeps a bounded history.
dsoxlab start ckad-job-cronjob -
Resize a Pod in place, without restarting it
Raise the CPU and the memory of a running Pod, without recreating it and without restarting its container, through the resize subresource. Prove that the kernel applies the new limit and that the container stayed the same.
dsoxlab start ckad-in-place-pod-vertical-scaling -
A Pod blocked by a ConfigMap that does not exist
A Pod does not start and says nothing in its logs, because it has no container yet: its events are the ones that talk. Read the cause, create the missing resource with the expected content, and prove that the application serves.
dsoxlab start ckad-troubleshoot-missing-configmap -
Three Pods in CrashLoopBackOff, three causes
Three Pods restart in a loop for three different reasons: a command that does not exist, a missing environment variable, a memory limit set too low. Read for each one what kills it, fix it, and prove that all three hold.
dsoxlab start ckad-troubleshoot-crashloop -
Capstone: ship the shop, from the specification alone
A full delivery, given as a specification rather than a walkthrough. Six requirements to satisfy in one namespace: configuration, secret, probes, identity, exposure and isolation. Nothing says which object to create, and the last test checks the only thing that matters: a frontend Pod reaches the shop, and a Pod that is not one does not.
dsoxlab start ckad-capstone-boutique