Pods and Workload Management – the heart of how Kubernetes runs your applications. Without these concepts, you cannot deploy, scale, or fix anything in a cluster. They matter for KCNA because the exam tests exactly how each workload type behaves and when to use it.
Jump to a section
A simple way to picture Pods and Workload Management
Picture a food truck festival with 12 trucks serving lunch. Each truck is a single container – it has its own cooking equipment, ingredients, and menu. The organiser groups the trucks into 4 sections (3 per section) to make them easier to manage. Each section is a Pod – a tight, logical bundle of containers that share the same space, network, and storage.
Now think about how the organiser manages all the trucks. She writes a plan for 4 sections, each with 3 trucks, and gives that plan to her team. This plan is a Deployment. If one truck breaks down, the team automatically sends a replacement truck to keep the section full – that's the ReplicaSet ensuring the desired number of trucks is always running. If a special dessert truck is needed at every festival entrance, that's a DaemonSet – one truck per location, no more, no less. If a truck needs a unique name and its own reserved parking spot (because it sells custom cakes ordered by name), that's a StatefulSet. Finally, a one-off ice-cream test run for a single afternoon is a Job – it runs once and stops.
Kuber organises applications into objects. An object is a record of intent – it tells the system what you want. The smallest, most fundamental object is a Pod.
A Pod is a single wrapper around one or more containers. A container is a lightweight, standalone package that includes everything an application needs to run: code, runtime, system tools, libraries, and settings. Containers inside the same Pod share the same network IP address, the same storage volumes, and the same port space. They communicate with each other using localhost, meaning they can send data back and forth without going through any network gateways. You almost never create a Pod by itself in production. Instead, you use workload controllers that manage Pods for you.
The most common workload controller is a Deployment. A Deployment is a blueprint that describes a desired state: how many copies (called replicas) of a Pod should be running, which container image to use, and how to update them. When you create a Deployment, Kubernetes automatically creates a ReplicaSet. A ReplicaSet is a watchdog that counts Pods and creates or deletes Pods to match the replica count you defined. If a Pod crashes, the ReplicaSet starts a new one. If you scale the Deployment from 3 replicas to 5, the ReplicaSet creates 2 more Pods. If you roll back to 3, it deletes 2.
A DaemonSet is different. It ensures that exactly one copy of a Pod runs on every node in the cluster. A node is a worker machine – a physical or virtual server. DaemonSets are perfect for infrastructure tasks that must be present on every machine, such as log collectors, monitoring agents, or network proxies. When a new node joins the cluster, the DaemonSet automatically starts the Pod there. When a node is removed, the DaemonSet removes the Pod.
A StatefulSet is built for applications that need stable, unique identities. Databases, message queues, and distributed storage systems need each Pod to have a sticky name and its own persistent storage. StatefulSets assign each Pod a deterministic name like mysql-0, mysql-1, mysql-2. If a Pod dies and is replaced, the new one gets the same name and the same storage. Pods are created and shut down in a strict order – the first one starts first, the last one shuts down first. This ordering prevents data corruption during scaling or rollouts.
A Job is a workload that runs to completion. It creates one or more Pods and keeps retrying until a specified number of them successfully finish. Jobs are ideal for batch processing tasks like data exports, backups, or image thumbnailing. A CronJob acts like a cron scheduler on Linux – it runs Jobs on a time-based schedule, for example every hour or every day at midnight.
These controllers replace the old way of managing servers manually. Previously, an IT team installed applications directly on a server, configured everything by hand, and hoped the server didn't crash. If it did, someone had to rebuild it. With Kubernetes, you declare your desired state in a YAML file (a human-readable configuration file), and the system does the rest. This shift from manual to declarative management is the core of cloud-native operations.
Define the desired state
Write a YAML file that describes exactly what you want. For a Deployment, you specify the container image, the number of replicas, and update strategy. This YAML is called a manifest. It acts as the source of truth for Kubernetes.
Submit the manifest to the API server
Use kubectl apply -f manifest.yaml to send your manifest to the Kubernetes API server. The API server receives your request, validates it, and stores the desired state in etcd – the cluster's key-value store. This step turns your intent into a permanent record.
The controller watches for changes
The Deployment controller runs in the control plane and constantly watches for changes. When it sees a new Deployment manifest, it creates a corresponding ReplicaSet. The ReplicaSet controller then creates the exact number of Pods specified.
Scheduler places Pods on nodes
The Kubernetes scheduler examines all pending Pods (those not yet assigned to a node) and chooses the best node for each one based on resource requirements, constraints, and available capacity. The scheduler's decision is stored in the Pod object.
Kubelet runs the Pods
On each worker node, the kubelet agent continuously monitors the API server for Pods assigned to that node. When it sees a Pod it should run, it pulls the container image and starts the container(s) inside the Pod. It then reports the Pod status back to the API server.
Monitor and repair
The ReplicaSet controller continuously checks the actual number of running Pods against the desired count. If a Pod crashes, the controller creates a replacement. This self-healing loop runs automatically without human intervention.
Update or rollback
When you change the Deployment manifest (for example, a new image version), the Deployment controller creates a new ReplicaSet with the new image and scales it up while scaling the old ReplicaSet down. This rolling update ensures zero downtime. If something goes wrong, you can use kubectl rollout undo to revert to the previous ReplicaSet.
An IT professional manages a company's online shopping platform running on Kubernetes. They need to deploy a new version of the product catalogue service.
First, they update the Deployment's YAML file to reference the new container image tag, say v2.3.1. They apply the change using kubectl apply -f catalogue-deployment.yaml. Kubernetes sees the difference between the current state (v2.3.0) and the desired state (v2.3.1). It creates a new ReplicaSet for v2.3.1 Pods and gradually replaces the old v2.3.0 Pods – this is called a rolling update.
During the rollout, the professional monitors the status with kubectl rollout status deployment/catalogue. If the new version has a bug (for example, it crashes on startup), the ReplicaSet notices that Pods are failing and pauses the rollout. The professional runs kubectl rollout undo deployment/catalogue to roll back to the previous, stable ReplicaSet. The whole process takes seconds.
Later, the company launches a Black Friday sale and expects 10x traffic. The professional scales the Deployment from 5 replicas to 50 using kubectl scale deployment/catalogue --replicas=50. The ReplicaSet spins up 45 new Pods across multiple nodes. They also use a DaemonSet to run a CPU usage logger (like Prometheus Node Exporter) on every node to detect hot spots.
For the user database, the professional uses a StatefulSet with 3 replicas. Each Pod has its own persistent volume claim (PVC) – a request for storage. If the primary database node crashes, the StatefulSet ensures the replacement Pod gets the same name, same storage, and same network identity so the replicas can still sync.
Finally, at the end of the sale, the team runs a Job to generate a sales report. It spins up a Pod, processes data, writes the report to a shared volume, and exits. A CronJob schedules this report to run every night at 2 a.m.
In daily work, the professional uses these commands and tools: - kubectl get pods - kubectl get deployments - kubectl describe statefulset database - kubectl logs daemonset/fluentd - kubectl create job --image=busybox test-job 'echo hello'
The KCNA exam tests your understanding of when to use each workload controller. You will not need to write YAML, but you must recognise the correct controller for a given scenario.
Multiple-choice questions often present a scenario (e.g., 'You need to run a log collector on every node') and ask which workload type fits. The trap is that beginners confuse DaemonSet with Deployment. Remember: DaemonSet = one per node, Deployment = desired count across nodes.
Another common trap: questions about StatefulSet ordering. They might ask: 'Which workload guarantees that Pods are created in order and shut down in reverse order?' The answer is StatefulSet. They sometimes include 'Deployment' as a distractor because beginners think all controllers provide ordering – they don't.
Questions about ReplicaSet focus on its relationship with Deployment. They might ask: 'If you delete a ReplicaSet, what happens to the Pods it manages?' The correct pattern is: the ReplicaSet does not delete the Pods directly – it just stops tracking them. However, KCNA often tests that a Deployment creates and manages a ReplicaSet, so deleting the Deployment deletes everything.
Job and CronJob are tested predominantly with lifecycle questions. Which controller ensures a Pod runs exactly once and then stops? Job. Which controller runs a Job on a schedule? CronJob. The trap is that a CronJob creates Jobs, not Pods directly – beginners sometimes pick 'CronJob creates Pods'.
Key definitions to memorise:
Pod: smallest deployable unit, wraps one or more containers, shares network and storage.
ReplicaSet: ensures a specified number of Pod replicas are running at all times.
Deployment: declarative updates for Pods and ReplicaSets, supports rolling updates and rollbacks.
DaemonSet: ensures one Pod per node.
StatefulSet: stable, unique identities with ordered startup/shutdown.
Job: runs Pods to completion.
CronJob: runs Jobs on a schedule.
Exam questions might also test the difference between StatefulSet and Deployment for stateful applications. They love asking: 'Which controller would you use for a MySQL database?' The correct answer is StatefulSet, not Deployment, because the database needs stable storage and network identity.
Finally, be aware of trick questions about Pod lifecycle. Controllers manage Pods – if you create a Pod directly, it will not restart if it fails. Only controllers handle restarts.
A Pod is the smallest deployable unit in Kubernetes and can wrap one or more containers that share the same network and storage.
A Deployment manages Pod updates and rollbacks by creating and swapping ReplicaSets, not by changing Pods directly.
A ReplicaSet is a self-healing controller that maintains a steady number of Pod replicas, but it does not support versioned updates.
A DaemonSet runs exactly one Pod on every node in the cluster, making it ideal for infrastructure agents like log collectors and monitoring tools.
A StatefulSet assigns each Pod a stable, unique identity and persistent storage, with ordered startup and shutdown for stateful applications.
A Job runs Pods to completion – once the specified number of Pods finish successfully, the Job stops with no further action.
A CronJob runs Jobs on a recurring schedule, similar to the Linux cron daemon, but it creates Jobs, not Pods directly.
These come up on the exam all the time. Here's how to tell them apart.
Deployment
Pod names are random and non-unique
No guaranteed startup or shutdown order
Each Pod gets a new persistent volume claim if created from scratch
StatefulSet
Pod names are stable and sequential (e.g., web-0, web-1)
Pods start and stop in a defined order
Each Pod retains its persistent volume across reschedules
ReplicaSet
Runs a desired number of Pods across any nodes
Used for stateless applications that need scaling
Does not run a Pod on every node by default
DaemonSet
Runs exactly one Pod per node
Used for node-specific infrastructure tasks
Automatically places a Pod on every node
Job
Runs a set of Pods once to completion
No scheduling capability
Stops after the specified number of completions
CronJob
Creates Jobs on a schedule (like cron)
Supports time-based scheduling (e.g., every hour)
Each triggered schedule creates a new Job
Deployment
Supports rolling updates and rollbacks
Manages multiple ReplicaSets over time
Is a higher-level abstraction
ReplicaSet
Only ensures replica count, no update logic
Directly creates and manages Pods
Is a lower-level controller often created by a Deployment
Pod (directly created)
No automatic restart if it fails
No scaling capability
Is not replaced if the node fails
Pod (managed by a Deployment)
Automatically restarted by the ReplicaSet
Can be scaled up or down via the Deployment
Self-healing: replaced on node failure
Mistake
A Pod always contains exactly one container.
Correct
A Pod can contain one or more containers. Multiple containers in a Pod work closely together, sharing the same network and storage. For example, a web server container and a sidecar log-collector container can share a Pod.
Many beginners come from the Docker world where a container is the smallest unit. In Kubernetes, the Pod is the smallest unit, and it can wrap multiple containers.
Mistake
ReplicaSet and Deployment are the same thing.
Correct
A ReplicaSet ensures a fixed number of Pods run, but it does not support rolling updates or rollbacks. A Deployment manages ReplicaSets and adds features like updating the container image, scaling, and rolling back to a previous version.
The names sound similar and Deployments create ReplicaSets behind the scenes, so beginners assume they are interchangeable.
Mistake
DaemonSet runs one Pod per cluster, not per node.
Correct
DaemonSet runs exactly one Pod on every node in the cluster. If you have 10 nodes, you get 10 Pods. It is for node-level services like monitoring agents.
The word 'Daemon' suggests a single background process, which leads people to think it is a singleton. In fact, it is a per-node singleton.
Mistake
StatefulSet is only for databases.
Correct
StatefulSet is for any application that needs stable, unique network identities, persistent storage per Pod, and ordered deployment. This includes databases, but also key-value stores, message queues, and distributed file systems.
Databases are the most common example given in tutorials, so beginners pigeonhole StatefulSet to only that use case.
Mistake
A Job runs forever like a Deployment.
Correct
A Job runs Pods that perform a task and then stop. The Pods exit once the task is complete. If a Pod fails, the Job creates a new one until the specified number of completions is reached.
The name 'Job' sounds like a background service. Beginners forget that the key feature is completion (termination), not persistence.
Mistake
You must use a Deployment for stateless apps and a StatefulSet for stateful apps.
Correct
Stateless apps are best run with Deployment. But some stateful apps can still run with Deployment if they do not need stable network identities or ordered startup. For example, a caching layer that can rebuild its state from scratch can use a Deployment.
This oversimplification ignores the nuance: statefulness is a spectrum, and Deployment vs StatefulSet depends on whether the app requires stable naming and ordering.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, a Pod can contain multiple containers. They share the same network namespace, so they can communicate using localhost (e.g., localhost:8080) and can share files through shared volumes mounted in the Pod.
Yes, deleting a Deployment deletes the ReplicaSet and all Pods it manages. If you want to delete the Deployment but keep the Pods running, you must delete the Deployment's ReplicaSet separately or change the Pods' owner reference.
You can, but you should not. StatefulSet adds overhead with stable identities and ordered deployment. For a stateless web server, a Deployment is simpler and faster. Only use StatefulSet when your app needs persistent storage or stable network names.
No. When you create a Deployment, it automatically creates and manages a ReplicaSet. You only need to interact directly with a ReplicaSet if you use it standalone (rare) or if you want to troubleshoot scaling issues.
A Job runs a set of Pods to completion once. A CronJob creates Jobs on a schedule, similar to cron. So a CronJob is a higher-level controller that generates Jobs at specified times.
Yes. The DaemonSet controller watches for new nodes joining the cluster. When a new node appears, it creates a Pod on that node. When a node is removed, it deletes the corresponding Pod.
You've finished Pods and Workload Management. Continue through the KCNA study guide to build a complete picture of the exam.
Done with this chapter?