# Workloads

> Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them.

---

LLMS index: [llms.txt](/llms.txt)

---

A workload is an application running on Kubernetes.
Whether your workload is a single component or several that work together, on Kubernetes you run
it inside a set of [_pods_](/docs/concepts/workloads/pods).
In Kubernetes, a Pod represents a set of one or more running
<a class='glossary-tooltip' title='A lightweight and portable executable image that contains software and all of its dependencies.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/containers/' target='_blank' aria-label='containers'>containers</a> on your cluster.

Kubernetes pods have a [defined lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
For example, once a pod is running in your cluster then a critical fault on the
<a class='glossary-tooltip' title='A node is a worker machine in Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/architecture/nodes/' target='_blank' aria-label='node'>node</a> where that pod is running means that
all the pods on that node fail. Kubernetes treats that level of failure as final: you
would need to create a new Pod to recover, even if the node later becomes healthy.

However, to make life considerably easier, you don't need to manage each Pod directly.
Instead, you can use _workload resources_ that manage a set of pods on your behalf.
These resources configure <a class='glossary-tooltip' title='A control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/architecture/controller/' target='_blank' aria-label='controllers'>controllers</a>
that make sure the right number of the right kind of pod are running, to match the state
you specified.

Kubernetes provides several built-in workload resources:

* [Deployment](/docs/concepts/workloads/controllers/deployment/) and [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
  (replacing the legacy resource
  <a class='glossary-tooltip' title='A (deprecated) API object that manages a replicated application.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/reference/glossary/?all=true#term-replication-controller' target='_blank' aria-label='ReplicationController'>ReplicationController</a>).
  Deployment is a good fit for managing a stateless application workload on your cluster,
  where any Pod in the Deployment is interchangeable and can be replaced if needed.
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) lets you
  run one or more related Pods that do track state somehow. For example, if your workload
  records data persistently, you can run a StatefulSet that matches each Pod with a
  [PersistentVolume](/docs/concepts/storage/persistent-volumes/). Your code, running in the
  Pods for that StatefulSet, can replicate data to other Pods in the same StatefulSet
  to improve overall resilience.
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) defines Pods that provide
  facilities that are local to nodes.
  Every time you add a node to your cluster that matches the specification in a DaemonSet,
  the control plane schedules a Pod for that DaemonSet onto the new node.
  Each pod in a DaemonSet performs a job similar to a system daemon on a classic Unix / POSIX
  server. A DaemonSet might be fundamental to the operation of your cluster, such as
  a plugin to run [cluster networking](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model),
  it might help you to manage the node,
  or it could provide optional behavior that enhances the container platform you are running.
* [Job](/docs/concepts/workloads/controllers/job/) and
  [CronJob](/docs/concepts/workloads/controllers/cron-jobs/) provide different ways to
  define tasks that run to completion and then stop.
  You can use a [Job](/docs/concepts/workloads/controllers/job/)  to
  define a task that runs to completion, just once. You can use a
  [CronJob](/docs/concepts/workloads/controllers/cron-jobs/) to run
  the same Job multiple times according a schedule.

In the wider Kubernetes ecosystem, you can find third-party workload resources that provide
additional behaviors. Using a
[custom resource definition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/),
you can add in a third-party workload resource if you want a specific behavior that's not part
of Kubernetes' core. For example, if you wanted to run a group of Pods for your application but
stop work unless _all_ the Pods are available (perhaps for some high-throughput distributed task),
then you can implement or install an extension that does provide that feature.

## Workload placement








  <div class="feature-state-notice feature-alpha" title="Feature Gate: GenericWorkload">
              <span class="feature-state-name">FEATURE STATE:</span> 
              <code>Kubernetes v1.35 [alpha]</code>(disabled by default)</div>


While standard workload resources (like Deployments and Jobs) manage the lifecycle of Pods,
you may have complex scheduling requirements where groups of Pods must be treated as a single unit.

The [Workload API](/docs/concepts/workloads/workload-api/) allows you to define `PodGroupTemplates` to group Pods and apply advanced scheduling policies to them, 
such as [gang scheduling](/docs/concepts/scheduling-eviction/gang-scheduling/).
Controllers create [PodGroup](/docs/concepts/workloads/podgroup-api/) objects from these templates at runtime, 
and `Pods` reference their `PodGroup` via the
`spec.schedulingGroup` field. This is particularly useful for batch processing and machine
learning workloads where "all-or-nothing" placement is required.

## What's next

As well as reading about each API kind for workload management, you can read how to
do specific tasks:

* [Run a stateless application using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/)
* Run a stateful application either as a [single instance](/docs/tasks/run-application/run-single-instance-stateful-application/)
  or as a [replicated set](/docs/tasks/run-application/run-replicated-stateful-application/)
* [Run automated tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)

To learn about Kubernetes' mechanisms for separating code from configuration,
visit [Configuration](/docs/concepts/configuration/).

There are two supporting concepts that provide backgrounds about how Kubernetes manages pods
for applications:
* [Garbage collection](/docs/concepts/architecture/garbage-collection/) tidies up objects
  from your cluster after their _owning resource_ has been removed.
* The [_time-to-live after finished_ controller](/docs/concepts/workloads/controllers/ttlafterfinished/)
  removes Jobs once a defined time has passed since they completed.

Once your application is running, you might want to make it available on the internet as
a [Service](/docs/concepts/services-networking/service/) or, for web application only,
using an [Ingress](/docs/concepts/services-networking/ingress).

---

Section pages:

- [Pods](/docs/concepts/workloads/pods/)
- [Workload API](/docs/concepts/workloads/workload-api/)
- [Workload Management](/docs/concepts/workloads/controllers/)
- [PodGroup API](/docs/concepts/workloads/podgroup-api/)
- [Managing Workloads](/docs/concepts/workloads/management/)
- [Autoscaling Workloads](/docs/concepts/workloads/autoscaling/): With autoscaling, you can automatically update your workloads in one way or another. This allows your cluster to react to changes in resource demand more elastically and efficiently.
- [Horizontal Pod Autoscaling](/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/)
- [Resource managers](/docs/concepts/workloads/resource-managers/)
- [Vertical Pod Autoscaling](/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/)