Free lesson · CKA Prep Program · Module 3: Workloads and scheduling

Choose the Right Workload Controller

The controller is the promise around your pods: how many, where, with what identity, and what done means. Picking wrong is the root cause behind half of all scheduling surprises.

11 min reading

Objectives

Match Deployment, DaemonSet, StatefulSet and Job to the workload shape
Say what each controller guarantees about identity, placement and completion
Convert a plain pod into a managed workload without changing its containers
Predict what survives a node loss under each controller

Why this matters

A Deployment keeps N identical replicas running and replaces the dead. A DaemonSet runs one pod per matching node for agents and drivers. A StatefulSet gives each pod a stable name plus stable storage for databases and quorum systems. A Job runs pods until the work finishes, then stops. These are not interchangeable flavors; each answers a different question, and the exam asks the mapping relentlessly.

Concepts

Deployments own ReplicaSets and roll out new images with revision history, pause, resume and rollback built in. Pods are fungible: any replica serves, none has a name worth remembering. Reach for Deployments for every stateless service you run.

DaemonSets place one pod on each selected node automatically, including nodes added later. Logging agents, monitoring exporters and storage drivers live here. Tolerations let them land on tainted nodes too, which is exactly how system DaemonSets cover the whole fleet.

StatefulSets add ordered identity: pod-0, pod-1, pod-2 with stable hostnames plus one PersistentVolumeClaim template entry each. Databases, Kafka-style brokers and anything with quorum rules need this stability. Ordered scaling and ordered updates come with it, which is slower than Deployments on purpose.

Jobs and CronJobs own finite work (see the dedicated lesson): completions, parallelism, deadlines. Never park batch work in a Deployment just because the YAML is familiar.

Worked example

Three workloads, three controllers, one cluster:

# stateless API: Deployment, 3 fungible replicas
kubectl create deployment api --image=api:2.4 --replicas=3
# per-node log shipper: DaemonSet, automatic coverage
kubectl apply -f fluent-bit-daemonset.yaml
kubectl get pods -l app=fluent-bit -o wide  # one per node
# nightly export: Job, runs once, then done
kubectl create job nightly-export --image=exporter:1.0
kubectl wait --for=condition=complete job/nightly-export --timeout=300s

Node loss separates them visibly: the Deployment reschedules its replicas, the DaemonSet replaces the lost node pod on the next matching node, and the Job restarts only if it had not completed.

Exam notes

StatefulSet versus Deployment is the most tested choice: stable identity plus storage means StatefulSet, everything else leans Deployment. DaemonSet questions hinge on automatic per-node placement plus tolerations. And a CronJob is a Job with a schedule, never a Deployment with a sleep loop.

Quick check

A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.

Lesson feedback

No published feedback yet.

Exercise

For four fictional workloads (public API, GPU metrics agent, three-node message queue, hourly invoice run) name the controller and justify each choice in one sentence. Then describe what happens to each when its node dies unexpectedly.

Pass criteria

All four controllers correct with a fitting justification each; node-loss behavior correct per controller (reschedule, replace, quorum-aware wait, restart-if-incomplete).