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
Intro
Kubernetes Workloads
A workload is an application running on Kubernetes. Whether it's one component or several working together, it runs inside a set of Pods — and because Pods are deliberately disposable, Kubernetes gives you workload management objects whose controllers create, replace, and update Pods on your behalf. Choosing the right workload object for each component is one of the most consequential day-one decisions you make on Kubernetes: it determines how your application scales, updates, recovers, and (for stateful systems) whether it keeps its identity across restarts.
The mental model: 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 the work ever finishes — and a controller enforces those rules continuously against reality.
Why workload objects exist
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
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)