Kubernetes Workloads
Kubernetes workloads are the resource types that run containerized applications: Deployments for stateless services, StatefulSets for ordered stateful apps, DaemonSets for per-node agents, Jobs for batch tasks, and CronJobs for scheduled work.
itCloud native tools and technologies | OpenSkills.info
Recommended first:kubernetes-fundamentals
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic - Kubernetes Workloads
A workload is an application running on Kubernetes. It runs inside Pods, and because Pods are disposable, workload objects create, replace, and update Pods for you. Choosing the right object determines how the application scales, updates, recovers, and whether it keeps identity across restarts.
Every workload object is a Pod factory with a policy. You supply a Pod template plus rules (how many copies, how to roll out changes, whether Pods need stable names, whether work finishes) and a controller enforces those rules. Bare Pods on a dead node are gone; controllers recreate replacements.
Deployment is the workhorse for stateless applications. It manages ReplicaSets and progressive rollouts with pause, resume, and rollback. StatefulSet exists when Pods are not interchangeable: stable ordinal names, stable network identity via a headless Service, and per-Pod storage. Rollouts and scaling are ordered. DaemonSet runs one Pod per matching node for node-level agents. Job runs Pods until a completion count succeeds, with retries; CronJob creates Jobs on a schedule.
Pods move through Pending, Running, Succeeded, or Failed. Restart policy governs in-place container restarts; replacing a lost Pod is the controller's job. Init containers run first; sidecars run alongside.
Scale manually or with HorizontalPodAutoscaler. Workload objects automate mechanics, not application semantics: a StatefulSet does not know how to back up a database. Jobs are at-least-once under retries, so make work idempotent. Rolling updates need readiness and dual-version tolerance.
Read the Intro for the object map. Use the Cheatsheet when you need selection rules. Updates tracks Kubernetes releases that change workload APIs.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://kubernetes.io/docs/concepts/workloads/
Supports
- Definition of workload as an application running on Kubernetes inside Pods
- Taxonomy of built-in workload management objects and their intended uses
- Rationale for managing Pods via controllers rather than directly
- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
Supports
- Deployment manages ReplicaSets which manage Pods
- Rolling updates, maxSurge/maxUnavailable, Recreate strategy
- Revision history, rollout status/history/undo, progressDeadlineSeconds
- https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
Supports
- ReplicaSet maintains a stable set of replica Pods
- Recommendation to use Deployments rather than ReplicaSets directly
- https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
Supports
- Stable ordinal names, stable network identity via headless Service
- volumeClaimTemplates and per-Pod PVCs retained across rescheduling, scale-down, and deletion
- Ordered deployment/scaling/updates; podManagementPolicy; RollingUpdate partition; OnDelete
- https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
Supports
- One Pod per (matching) node, Pods added/removed with node membership
- Typical uses — log collection, node monitoring, cluster storage/network daemons
- Update strategies
- https://kubernetes.io/docs/concepts/workloads/controllers/job/
Supports
- completions, parallelism, backoffLimit, activeDeadlineSeconds, ttlSecondsAfterFinished
- Indexed completion mode
- At-least-once semantics and the need for idempotent handling of repeated execution
- https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/
Supports
- Cron schedule syntax, concurrencyPolicy (Allow/Forbid/Replace)
- startingDeadlineSeconds and missed-run behavior, timeZone field
- https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
Supports
- Pod phases and container states
- restartPolicy semantics (in-place, same node); controllers replace lost Pods
- Graceful termination — SIGTERM, grace period (default 30s), SIGKILL, preStop hooks
- https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
Supports
- Init containers run sequentially to completion before app containers
- Sidecar containers implemented as restartable init containers
- https://kubernetes.io/docs/concepts/workloads/autoscaling/
Supports
- Manual scaling, HorizontalPodAutoscaler (replica count from metrics), VerticalPodAutoscaler (resource requests, separate add-on)
