25 hands-on labs to practise for the Certified Kubernetes Administrator, roughly 8 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.
Administering a cluster: installation, upgrades, networking, storage, etcd backups and troubleshooting, in a terminal, on real clusters.
- 25labs
- 8hours of practice
- 25on real VMs
Levels 2 beginner 15 intermediate 8 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
-
Place a static Pod on a worker, without going through the API
Run a Pod that the worker's kubelet manages on its own, from a manifest dropped on the node, and see it appear in the API under its mirror name. The file must sit where the kubelet's own configuration says, and the worker's runtime must really be running the container.
dsoxlab start cka-static-pod -
An agent on every node, including the control plane
Deploy a DaemonSet that places an agent on every node of the cluster, including the control plane, protected by its taint. The tests count one Pod per node, check that the taint is still there and that the agent runs on it anyway, and read its logs to prove that it is doing its job.
dsoxlab start cka-daemonset-all-nodes -
Give an application an identity: ServiceAccount, Role, RoleBinding
An application refuses to start because its ServiceAccount does not exist. Create it, grant it the right to read the Pods of its namespace and nothing else, then prove from inside the Pod, with its own token, that listing goes through and that deleting, reading Secrets or looking elsewhere are denied.
dsoxlab start cka-rbac-serviceaccount -
Reserve a node: taint, toleration and nodeSelector
Reserve the worker for production with a taint and a label, then place a Pod that must go there, toleration and nodeSelector, and a Pod that must not. The tests read the node, the actual placement of each Pod and the declared mechanisms: a Pod pinned with nodeName bypasses the taint and does not pass.
dsoxlab start cka-taints-tolerations-placement -
Placing with nodeAffinity: required constraint and preference
Place a Deployment with a required node affinity on a label that accepts several values, add a weighted preference to it, then unblock a Pod that is waiting for a node which does not exist yet, by setting the label it demands. The tests read the node labels, the declared affinities and the actual node of every Pod.
dsoxlab start cka-node-affinity -
Isolate the database: only the backend gets in
Write the NetworkPolicy that lets nothing into the database but the backend of its own namespace, on its port. The tests attempt the connections: the one that must go through, the frontend one that must be blocked, the one from a Pod with the right label but in another namespace, and they check that the database can still reach out.
dsoxlab start cka-networkpolicy-isolate-db -
Route two applications on a single host, and prove each gets its own
Two applications, one hostname, and no rule saying which is which. Route by path, and prove it the only way that counts: each path answers with its own application's name, and an undeclared path answers with neither.
dsoxlab start cka-ingress-path-routing -
Route with the Gateway API, and watch the Gateway report itself programmed
Same two applications, same single hostname, and the successor to Ingress. Declare a Gateway, attach a route to it, and prove the routing: each path answers with its own application's name, an undeclared path answers with neither.
dsoxlab start cka-gateway-api-httproute -
A persistent volume: PersistentVolume, PersistentVolumeClaim and a Pod that writes
On a cluster with no dynamic provisioning, create a PersistentVolume on a node's disk, claim it with a PersistentVolumeClaim, mount it in a Pod that writes to it. The tests read the volume, the binding, the mount, the file inside the Pod, then the same file on the node's disk: that is where persistence is proven.
dsoxlab start cka-pv-pvc-storageclass -
Get a volume no administrator created, and follow what becomes of it
A claim stuck in Pending because nobody prepared a volume by hand. Let the cluster provision it on demand, then observe what the class decides when the claim disappears: the volume goes with it.
dsoxlab start cka-storageclass-provisionnement-dynamique -
Roll back a stuck rollout, then ship the right version
An update went out with a wrong image name and the rollout is stuck. Go back to the revision that worked through the Deployment history, then ship the correct image with a change cause. The tests read the ReplicaSets and their revision numbers: they tell the story of what happened, and a Deployment recreated from scratch tells no story at all.
dsoxlab start cka-deployment-rollout-rollback -
Drain a worker for maintenance, without cutting the service
Protect an application with a PodDisruptionBudget, take the worker out of scheduling, evict it while respecting that budget and the DaemonSets, then put it back in service and record the operation. The tests prove that the Pods really were recreated elsewhere, that the node came back, and that the CNI DaemonSet did not move.
dsoxlab start cka-node-drain-cordon -
Scale out automatically with a HorizontalPodAutoscaler
Put an HPA on a Deployment, generate load, watch the replica count go up, then cut the load. The tests read the HPA, its current metrics, and the rescale event the controller emitted: an HPA that has never rescaled is not a validated HPA.
dsoxlab start cka-hpa-autoscaling -
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 -
Get a Pod out of ImagePullBackOff
A Pod does not start because its image will not download. Read the runtime's exact message in the events, fix the image reference, and prove that the server answers.
dsoxlab start cka-troubleshoot-imagepullbackoff -
Get a Deployment out of CrashLoopBackOff
The Pods of a Deployment have been restarting in a loop since the last release. Read what the process said before it died, work out what it is missing, fix the Deployment, and prove the application serves again.
dsoxlab start cka-troubleshoot-crashloopbackoff -
Get inside a container with no shell using kubectl debug
A Pod whose image contains no shell offers nothing to kubectl exec. Attach an ephemeral container to it that shares its processes, reach the node's filesystem through a debug Pod, and leave proof of it.
dsoxlab start cka-kubectl-debug -
Restore the cluster's DNS resolution
No Pod resolves a service name any more. Find out why the cluster DNS has stopped answering, put it back in service, and prove that a client Pod resolves and reaches a Service by its name again.
dsoxlab start cka-troubleshoot-dns -
Restore traffic to a Service
A Service no longer serves its Pods: wrong selector, wrong port, and a network policy that closes everything. Set the Service straight, reopen exactly what is needed without removing the security policy, and prove that a client reaches the Service by its name.
dsoxlab start cka-troubleshoot-networking -
Bring a NotReady node back into the cluster
A worker has gone NotReady, and the application reserved for it is degraded. Find out on the node why it no longer talks to the control plane, put its agent back in service for good, and prove that the application is back.
dsoxlab start cka-troubleshoot-node-notready -
Repair a kubelet that refuses to start
A worker's kubelet stops as soon as it is launched, and the node is NotReady. Read in the journal what it holds against its configuration, fix the file without breaking anything else, and prove that the node and its application are back.
dsoxlab start cka-troubleshoot-kubelet -
Bring the API server back into service
kubectl no longer answers: the control plane's API server exits with an error at startup. With no API, diagnose on the node, in the containers and in the kubelet journal, fix the static manifest, and prove the API answers without having weakened its authorization.
dsoxlab start cka-troubleshoot-apiserver -
Back up etcd, then restore the cluster from a snapshot
A namespace has disappeared. Take a fresh backup of the current state first, then restore the cluster from yesterday evening's snapshot, without stopping the wrong component and without leaving the API server on a stale cache. The tests prove that etcd runs on a data directory produced during the lab, that the objects come back with their original UID, and that what was written after the backup is gone.
dsoxlab start cka-etcd-backup-restore -
Upgrade a cluster one minor version, without interrupting what runs on it
A cluster one minor version behind, an application that must keep serving, and the upgrade to run: the control plane first, then the node, each with its own command. The tests read the versions and check nothing was left drained.
dsoxlab start cka-kubeadm-upgrade -
Capstone: bring the portal back, with nobody left to ask
A namespace handed over by a team that is gone, a portal that answers nothing, and no ticket saying why. Three independent faults to find, two requirements that were never met, and a single measure of success: the portal answers on every node of the cluster.
dsoxlab start cka-capstone-portail