| Workload | Use it when | Creates or represents |
|---|---|---|
| Deployment | Software should keep running | ReplicaSets and pods |
| Job | Work should run to completion | Pods |
| CronJob | Jobs should run on a schedule | Jobs, then pods |
| Sandbox | You need a disposable Linux environment with a required TTL | A Sandbox environment and associated pod status when available |
| Pod | You need to run one pod spec directly | One pod |
| ReplicaSet | A fixed number of identical pods should run | Pods |
How they relate
A Deployment, Job, CronJob, or ReplicaSet describes desired work. Pods are the runtime units created for that work. Builders usually create Deployments and Jobs, then inspect pods to see what is actually running.Shared settings
Every workload haskind, metadata, spec, and read-only status fields. Most workload types also share a pod spec, which is where container images, environment variables, resource requests, restart policy, GPU requirements, and host capability requirements are defined.
| Workload | Pod spec path |
|---|---|
| Deployment | spec.template.spec |
| Job | spec.template.spec |
| CronJob | spec.jobTemplate.spec.template.spec |
| Sandbox | spec.template.spec |
| Pod | spec |
| ReplicaSet | spec.template.spec |
Manifest reference
Deployment reference
YAML fields for replicated, rolling application workloads.
Job reference
YAML fields for run-to-completion workloads.
CronJob reference
YAML fields for scheduled jobs.
Sandbox reference
YAML fields for disposable Linux environments.
Pod reference
YAML fields for direct pod manifests.
ReplicaSet reference
YAML fields for fixed-size pod sets.