☸️Understanding Kubernetes Workloads
Understanding Kubernetes Workloads (and how this connects to taints, tolerations, upgrades, and PDBs)
This explanation ties together Kubernetes workloads, Pods, controllers, taints & tolerations, upgrades, and PodDisruptionBudgets.
What is a workload in Kubernetes? (plain meaning)
A workload is your application running on Kubernetes.
But Kubernetes never runs an application directly. It always runs Pods.
Workload → Controller → Pods → Containers
What is a Pod (and why it matters)
A Pod is:
- The smallest deployable unit
- One or more containers
- Always scheduled on a single node
Critical rule from the docs:
If the node where a Pod is running fails, that Pod is considered
dead forever.
Even if the node later recovers or the network comes back, Kubernetes will not reuse that Pod.
This is why Pods are disposable by design.
Why you don’t manage Pods directly
Managing Pods directly would be painful because:
- Nodes fail
- Pods die
- Upgrades happen
- Scaling is constant
So Kubernetes gives you controllers (also called workload resources).
Controllers say:
“I don’t care which Pod runs — I care that the right number of Pods is running.”
Built-in workload resources (what they’re really for)
Let’s decode each workload type in simple terms.
Deployment (stateless apps)
Best for:
- Web apps
- APIs
- Frontends
- Anything that can restart safely
Key idea:
Pods are interchangeable. Any Pod can die and be replaced.
This is why Deployments work well with upgrades, evictions, and autoscaling.
StatefulSet (stateful apps)
Best for:
- Databases
- Queues
- Stateful services
Key differences:
- Stable Pod identity (pod-0, pod-1)
- Pod names matter
- Often tied to PersistentVolumes
Node death still kills the Pod — the controller recreates it elsewhere.
DaemonSet (node-level workloads)
Best for:
- System agents
- Networking
- Monitoring
- Logging
- Storage drivers
Key idea:
“Run one Pod per node.”
New node → new Pod. Node removed → Pod disappears.
Job / CronJob (run & stop)
Best for:
- Batch tasks
- One-time jobs
- Scheduled tasks
Key idea:
Run → finish → exit.
Not about availability — about completion.
Why controllers matter during node failure or upgrade
The docs say: Kubernetes treats node-level failure as final.
That sounds scary — but controllers fix this.
- Node fails or is drained
- Pods on that node die
- Controller detects mismatch
- New Pods are created
- Scheduler places them on healthy nodes
How this connects to taints, tolerations, and PDBs
Each concept has a different responsibility:
- Taints & tolerations → decide where Pods may run
- Controllers → decide how many Pods must exist
- PodDisruptionBudgets → control how fast Pods may be disrupted
Why “Workload placement” exists (advanced)
Normally, Pods are scheduled independently.
Some workloads (ML, batch jobs) need:
- All Pods together
- Or none at all
This is where gang scheduling and the Workload API come in (alpha, optional).
The most important mental model
- Pods are disposable
- Controllers care about counts
- Nodes are temporary
- Placement rules apply only while nodes exist
Hence...
Kubernetes workloads are managed through controllers that maintain the desired number of Pods; Pods are treated as disposable units that are recreated when nodes fail or are upgraded, while scheduling, taints, and disruption budgets control where and how fast those Pods move.