# Workload Management

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

---

Kubernetes provides several built-in APIs for declarative management of your
<a class='glossary-tooltip' title='A workload is an application running on Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/workloads/' target='_blank' aria-label='workloads'>workloads</a>
and the components of those workloads.

Ultimately, your applications run as containers inside
<a class='glossary-tooltip' title='A Pod represents a set of running containers in your cluster.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/workloads/pods/' target='_blank' aria-label='Pods'>Pods</a>; however, managing individual
Pods would be a lot of effort. For example, if a Pod fails, you probably want to
run a new Pod to replace it. Kubernetes can do that for you.

You use the Kubernetes API to create a workload
<a class='glossary-tooltip' title='An entity in the Kubernetes system, representing part of the state of your cluster.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/overview/working-with-objects/#kubernetes-objects' target='_blank' aria-label='object'>object</a> that represents a higher abstraction level
than a Pod, and then the Kubernetes
<a class='glossary-tooltip' title='The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/reference/glossary/?all=true#term-control-plane' target='_blank' aria-label='control plane'>control plane</a> automatically manages
Pod objects on your behalf, based on the specification for the workload object you defined.

The built-in APIs for managing workloads are:

[Deployment](/docs/concepts/workloads/controllers/deployment/) (and, indirectly, [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)),
the most common way to run an application on your cluster.
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.
(Deployments are a replacement for the legacy
<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> API).

A [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) lets you
manage one or more Pods – all running the same application code – where the Pods rely
on having a distinct identity. This is different from a Deployment where the Pods are
expected to be interchangeable.
The most common use for a StatefulSet is to be able to make a link between its Pods and
their persistent storage. For example, you can run a StatefulSet that associates each Pod
with a [PersistentVolume](/docs/concepts/storage/persistent-volumes/). If one of the Pods
in the StatefulSet fails, Kubernetes makes a replacement Pod that is connected to the
same PersistentVolume.

A [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) defines Pods that provide
facilities that are local to a specific <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>;
for example, a driver that lets containers on that node access a storage system. You use a DaemonSet
when the driver, or other node-level service, has to run on the node where it's useful.
Each Pod in a DaemonSet performs a role 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 let that node access
[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 less essential facilities that enhance the container platform you are running.
You can run DaemonSets (and their pods) across every node in your cluster, or across just a subset (for example,
only install the GPU accelerator driver on nodes that have a GPU installed).

You can use a [Job](/docs/concepts/workloads/controllers/job/) and / or
a [CronJob](/docs/concepts/workloads/controllers/cron-jobs/) to
define tasks that run to completion and then stop. A Job represents a one-off task,
whereas each CronJob repeats according to a schedule.

Other topics in this section:
<!-- relies on simple_list: true in the front matter -->

---

Section pages:

- [Deployments](/docs/concepts/workloads/controllers/deployment/): A Deployment manages a set of Pods to run an application workload, usually one that doesn't maintain state.
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/): A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. Usually, you define a Deployment and let that Deployment manage ReplicaSets automatically.
- [StatefulSets](/docs/concepts/workloads/controllers/statefulset/): A StatefulSet runs a group of Pods, and maintains a sticky identity for each of those Pods. This is useful for managing applications that need persistent storage or a stable, unique network identity.
- [DaemonSet](/docs/concepts/workloads/controllers/daemonset/): A DaemonSet defines Pods that provide node-local facilities. These might be fundamental to the operation of your cluster, such as a networking helper tool, or be part of an add-on.
- [Jobs](/docs/concepts/workloads/controllers/job/): Jobs represent one-off tasks that run to completion and then stop.
- [Automatic Cleanup for Finished Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/): A time-to-live mechanism to clean up old Jobs that have finished execution.
- [CronJob](/docs/concepts/workloads/controllers/cron-jobs/): A CronJob starts one-time Jobs on a repeating schedule.
- [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/): Legacy API for managing workloads that can scale horizontally. Superseded by the Deployment and ReplicaSet APIs.