Kubernetes Workload Types

Every workload in Kubernetes is one of seven resource types: Pod, ReplicaSet, Deployment, DaemonSet, StatefulSet, Job, or CronJob. Each one exists because the others cannot handle a specific scheduling or lifecycle requirement. Picking the wrong one means writing workarounds for behavior the right one gives you for free.

These six challenges cover every workload type. By the end you will know what each resource does, when to use it, and how it manages the objects below it.

Some of these objects own and manage other objects. A Deployment is the parent of a ReplicaSet, which is the parent of the Pods. A CronJob is the parent of Jobs, and each Job is the parent of the Pods. Each child object records this in metadata.ownerReferences, pointing back to the object that created it.

Pods (challenge 1): create, exec, pod immutability, restartPolicy across Always, OnFailure, and Never, terminationGracePeriodSeconds, and why a bare Pod is not self-healing.

ReplicaSets and Deployments (challenge 2): self-healing, template changes that do not affect existing Pods, scaling a Deployment, the full Deployment to ReplicaSet to Pod ownership chain, and rolling back a Deployment update.

DaemonSets (challenge 3): one Pod per node, rolling image updates, rolling back to a previous revision, and restricting coverage to a single node.

StatefulSets (challenge 4): ordered creation, stable identity, headless Service DNS per Pod, per-replica storage, scaling up and down, deleting a named Pod, and rolling back an image update.

Jobs (challenge 5): run-to-completion, backoffLimit, restartPolicy Never vs OnFailure, running work in parallel with completions and parallelism, automatic cleanup with ttlSecondsAfterFinished, suspending and resuming a running Job, and enforcing a deadline with activeDeadlineSeconds.

CronJobs (challenge 6): scheduled Jobs, manual trigger, the full CronJob to Job to Pod ownership chain, history limits, suspend, and all three concurrencyPolicy modes: Allow, Forbid, and Replace.

A Pod is the smallest deployable unit in Kubernetes. It holds one or more containers, shares a network namespace between them, and is the object every workload controller creates and manages. This challenge covers creating a Pod from scratch, verifying it runs, trying to edit an immutable field, comparing all three restart policies (Always, OnFailure, and Never), and observing graceful termination with terminationGracePeriodSeconds. Deleting a bare Pod and watching nothing recreate it sets up the motivation for every controller that follows.

A ReplicaSet keeps a target number of Pods running and recreates them if they disappear. A Deployment wraps a ReplicaSet and solves what a bare ReplicaSet cannot: replacing Pods with a new image version in a controlled sequence, instead of all at once. This challenge builds both layers by hand, confirms the full Deployment to ReplicaSet to Pod ownership chain, and rolls back an update to a previous revision.

A DaemonSet runs exactly one Pod on every node that matches its selector. There is no replica count to set - the node set is the replica count. This challenge creates a DaemonSet across all nodes, rolls an image update, rolls back to a previous revision, and restricts coverage to a single node.

A StatefulSet gives each Pod a stable name, a stable network identity, and its own PersistentVolumeClaim that survives Pod deletion. Pods are created and deleted in strict ordinal order. This challenge builds a StatefulSet with a headless Service, queries a Pod's stable DNS name, scales down and back up, proves stable identity by deleting a named Pod, then rolls an image update and rolls it back.

A Job runs one or more Pods until a target number of them complete successfully, then stops. This challenge runs a Job to completion, controls retries with backoffLimit, compares restartPolicy: OnFailure with Never, runs work in parallel with completions and parallelism, cleans up automatically with ttlSecondsAfterFinished, suspends and resumes a running Job, and enforces a deadline with activeDeadlineSeconds.

A CronJob creates a new Job on a schedule defined with cron syntax. The CronJob is the parent of the Jobs it creates, and each Job is the parent of its Pods, the same parent-child chain that links a Deployment to its ReplicaSet and Pods, from challenge 2. This challenge builds a CronJob, watches it fire on schedule, triggers a Job manually and confirms the ownership chain, limits job history, suspends the schedule, and uses all three concurrencyPolicy modes.