Yewolf
Kubernetes, one idea at a time
Lesson 14 / 19 • 12 min • workloads, recap

Picking a workload

Seven objects that all end in pods, side by side, and how to tell which one you want.

That was a lot of objects for one phase, and nearly all of them end up doing the same thing, which is making pods. This lesson just puts them next to each other.

How they stack

Deployment    ->  ReplicaSet  ->  Pod
CronJob       ->  Job         ->  Pod
DaemonSet     ->  Pod
StatefulSet   ->  Pod

Every arrow is a controller reading the object on its left and writing the one on its right, with an owner reference pointing back. Delete something on the left and everything to its right goes with it. At the bottom it’s always a pod, and the node running it has no idea which of these asked for it.

Side by side

ObjectWhat it keepsWhen one of its pods goes
PodOne set of containers, on one nodeNothing replaces it
ReplicaSetA number of identical podsA new pod, with a new name
DeploymentOne ReplicaSet per version of the templateA new pod, with a new name
JobPods running until enough have exited 0A new pod, starting the work over
CronJobA Job every time the schedule firesThe Job deals with it
DaemonSetOne pod per nodeA new pod on the same node
StatefulSetNumbered pods, each with its own diskThe same name, with the same disk

Two of those you’ll basically never write yourself. A bare pod has nothing looking after it, and a ReplicaSet is what a Deployment writes for you. The other five are real choices.

Which one

Six things the team needs running. Pick what you'd write for each one. A wrong pick tells you what it would actually do, so go ahead and try the tempting ones.

That’s workloads done. Every one of those pods got an IP address, and none of them get to keep it, which is where the next phase starts.