Study Hub / Certified Kubernetes Administrator (CKA) / Domain 2.0
Certified Kubernetes Administrator (CKA) Domain 2.0: Workloads & Scheduling — Explained
Domain 2.0 is about the work Kubernetes runs: how applications are packaged as pods, kept alive by controllers, placed by the scheduler, and scaled with demand. Understand the objects and their relationships and the domain clicks into place.
Pods: the smallest deployable unit
- What a pod is — one or more containers sharing network (one IP) and storage, scheduled together on one node. The atom of Kubernetes scheduling: you never schedule a lone container.
- Multi-container patterns — sidecar (helper alongside the main container: log shippers, proxies), init containers (run to completion before app containers start: setup, migrations).
- Probes — liveness (is it alive? restart if not), readiness (is it ready for traffic? pull from service if not), startup (give slow starters time before liveness kicks in). Readiness ≠ liveness: a pod can be alive but not ready.
- Labels and selectors — the glue: labels tag objects, selectors match them. Services find pods by selector, not by name — which is why pods can die and be replaced freely.
Controllers: keeping the desired state
- Deployments — the standard way to run stateless apps: declare "3 replicas of this pod," and the deployment maintains it through failures and updates. Rolling updates replace pods gradually; rollbacks revert.
- ReplicaSets — what deployments manage underneath: ensures N pod copies exist. You rarely touch one directly.
- StatefulSets — for stateful apps (databases): stable network identities, ordered deployment/scaling, persistent storage per pod. When identity and order matter, StatefulSet.
- DaemonSets — one pod per node (or per selected nodes): log collectors, monitoring agents, network plugins. "Every node gets one."
- Jobs and CronJobs — run-to-completion work: a Job runs once; a CronJob runs on a schedule. Batch migrations, nightly reports.
Scheduling and resources
- How scheduling works — the scheduler watches for unscheduled pods, filters nodes that can't run them (insufficient CPU/memory, taints), then scores the rest and picks the best. It doesn't run containers — the kubelet does.
- Requests vs. limits — requests guarantee resources (scheduling decisions use them); limits cap usage (breach CPU limit → throttled; breach memory limit → OOM-killed). Requests ≤ limits, always.
- Node affinity / taints and tolerations — affinity attracts pods to nodes ("run on SSD nodes"); taints repel pods unless they tolerate them ("no general workloads on GPU nodes").
- Autoscaling — HPA (horizontal pod autoscaler) adds replicas on metrics like CPU; VPA adjusts requests/limits; cluster autoscaler adds nodes. Three different scalers for three different bottlenecks.
The must-memorize table: workload controllers
Which controller for which workload.
| Controller | Use it for | Key trait |
|---|---|---|
| Deployment | Stateless applications | Rolling updates + rollbacks; manages ReplicaSets |
| StatefulSet | Databases, stateful apps | Stable identity, ordered ops, per-pod storage |
| DaemonSet | Per-node agents | One pod per (selected) node |
| Job | Run-to-completion tasks | Runs until success, then stops |
| CronJob | Scheduled tasks | Cron schedule for Jobs |
Try it: 4 sample questions
Sample questions to check your understanding of this domain. Answers and full reasoning are tucked under each one.
1. A team runs a web API that must survive pod failures and update without downtime. Which controller fits, and why?
- A. A. Job — it runs the API to completion
- B. B. Deployment — maintains replicas and does rolling updates
- C. C. DaemonSet — one API pod per node
- D. D. A bare Pod — simplest possible
Show answer & reasoning
B. Deployments maintain the declared replica count through failures (self-healing) and roll out new versions gradually (rolling updates) with rollback available. Jobs (A) terminate; DaemonSets (C) are for node agents, not scaled APIs; bare pods (D) are never rescheduled when they die.
2. A pod is running but a dependent cache isn't ready, so the pod shouldn't receive traffic yet. Which probe controls this?
- A. A. Liveness — it will restart the pod
- B. B. Readiness — it controls whether the pod gets traffic
- C. C. Startup — it delays all other probes
- D. D. None — probes can't control traffic
Show answer & reasoning
B. Readiness gates traffic: failing readiness removes the pod from service endpoints without restarting it. Liveness (A) would restart a merely-unready pod — the classic misconfiguration that turns a slow dependency into a crash loop. Alive ≠ ready.
3. A pod specifies CPU request 500m and limit 1000m. What do these mean?
- A. A. It always uses exactly 750m
- B. B. The scheduler guarantees 500m; the pod is throttled if it tries to exceed 1000m
- C. C. It can use 1000m only on weekends
- D. D. Requests and limits must be equal
Show answer & reasoning
B. Requests are the scheduling guarantee (the scheduler only places the pod where 500m is free); limits are the enforcement ceiling (CPU throttling beyond 1000m; memory beyond limit → OOM kill). Requests drive placement; limits drive runtime enforcement.
4. Traffic to an API doubles every weekday morning. Which autoscaler adds more pod replicas based on CPU?
- A. A. Vertical Pod Autoscaler (VPA)
- B. B. Cluster autoscaler
- C. C. Horizontal Pod Autoscaler (HPA)
- D. D. CronJob
Show answer & reasoning
C. HPA scales replicas (horizontal) on metrics like CPU — more pods for more traffic. VPA (A) resizes requests/limits (vertical); the cluster autoscaler (B) adds nodes; CronJobs (D) run scheduled tasks. "More pods" → horizontal → HPA.
This was one domain. The simulator drills all 5.
This free preview covered Workloads & Scheduling (Domain 2.0, 15%). Not covered here: Cluster Architecture, Installation & Configuration (Domain 1.0, 25%); Troubleshooting (Domain 5.0, 30%). The two highest-weight domains — cluster builds and live troubleshooting, the most hands-on CKA material — stay in the paid guide and practice bank. The ByteBar Practice Exam Simulator drills every domain with 1,000 exam-style questions — $9.99 one-time unlocks all 28 exams. Prefer to read? The full CKA Study Guide is in the ByteBar shop on Etsy.
Practice Exam Simulator — $9.99 one-time, all 28 exams Full Study Guides on Etsy