Create a workload

In a Kubernetes cluster, a workload is an application or service instance running on the cluster. Deploy, scale, update, and restore workloads to maintain pod stability and service continuity. This topic describes common workload types, including Deployments, StatefulSets, DaemonSets, Jobs, and CronJobs.

Pod

A pod is the smallest deployable unit in Kubernetes, encapsulating one or more containers with shared storage (volumes), networking, and configuration. You rarely create pods directly; use controllers such as Deployments and StatefulSets to manage them.

Deployments and StatefulSets

Deployment

Kubernetes originally used ReplicaSets to define replica count, label selectors, and pod templates. Deployments now manage ReplicaSets, which manage pods and add enhanced control.

Use Deployments for applications that need no data persistence or ordered operations, such as web servers and microservices.

Scenario	Description
Stateless web services	Frontend web services scale dynamically with fluctuating traffic. Deployments support horizontal scaling, updates, and rollbacks.
Microservices architecture services	In a microservices system, deploy and manage each service independently with Deployments.

StatefulSet

Deployment pods are independent and stateless, but some applications need state and dependencies. For example, in a primary-replica database, pods hold state and depend on each other. Use a StatefulSet for these stateful, interconnected pods.

Use StatefulSets for applications that need persistent storage and ordered instance deployment, such as databases and distributed storage systems.

Scenario	Description
Stateful databases	Stateful databases need persistent storage and stable network identity after pod rescheduling. For example, each MySQL instance keeps data and configurations across restarts.
Distributed message queue services	Distributed messaging systems rely on ordered state and persistent logs on each node. For example, Apache Kafka requires each broker to maintain data consistency and store logs on a persistent volume to prevent data loss.

Differences between Deployments and StatefulSets

Choose a workload type based on Deployment and StatefulSet differences.

Item	Deployment	StatefulSet
Use cases	Stateless applications such as web servers and API services that need rapid scaling and rolling updates.	Stateful applications such as databases and distributed file systems that need stable persistent storage and ordered deployment.
Persistent storage	All replica pods share one persistent volume claim (PVC). When rescheduled or updated, a pod reattaches to the same PVC and data.	Each pod has its own persistent volume claim for data persistence and consistency. Storage persists across pod restarts and rescheduling.
Network identifier	Pods lack stable identifiers. Names and IP addresses change each time a pod is recreated.	Each pod has a stable identifier in the format `<StatefulSet name>-<ordinal>`, such as `web-0` and `web-1`, retained across restarts.
Update strategy	Rolling Update: Rolling updates gradually replace old pods with new ones while maintaining service availability. Recreate: Recreate terminates all old pods before creating new ones, causing brief service interruption when old and new versions cannot coexist.	Rolling Update: Updates apply sequentially by ordinal index. The next pod updates only after the current pod is ready. OnDelete: Manually delete a pod to trigger its update when you need strict update control.
Service discovery	A Service provides service discovery and load-balances inbound traffic to pods. See Service management.	Each pod has a unique, stable DNS name. A StatefulSet-managed headless service enables stable discovery and direct pod access.

DaemonSet

A DaemonSet runs one pod replica on every cluster node for background services such as log collection, monitoring, and network plug-ins. When nodes join or leave the cluster, the DaemonSet creates or deletes the corresponding pod.

Use a DaemonSet to run the same daemon process on every cluster node.

Scenario	Description
Log collection	DaemonSets suit log collection tools such as the log collection add-on in ACK clusters component in ACK clusters, which run on every node to collect log files and forward them to a centralized log management system.
Monitoring agent	Deploy a monitoring agent such as Prometheus Node Exporter or Datadog Agent on each node to collect resource metrics and monitor node status in real time.

Jobs and CronJobs

Jobs and CronJobs run one-off and scheduled tasks for workloads that do not run continuously, such as batch processing and data jobs.

A Job runs a task to completion and terminates its pods when finished. Use Jobs for one-off tasks such as data processing and backups.
A CronJob schedules Jobs using a cron expression with minute, hour, day, month, and weekday fields for periodic tasks such as database backups and log cleanup.

Manage workload objects

Manage workloads in ACK through the console, kubectl, or the Kubernetes API to deploy, monitor, and scale application services.

Console

Use the ACK console to create, manage, and monitor workloads visually. The following topics cover console management for each workload type.

CLI

Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster to deploy applications, manage resources, and monitor the cluster.

Kubernetes API

Use the Kubernetes API to create, update, delete, and monitor workloads.

FAQ

See the Workload FAQ to troubleshoot workload issues.

References

See Recommended workload configurations.
See Auto scaling to scale pods automatically.
See Scheduling for pod scheduling methods.
See Service management for service discovery and load balancing.
See Ingress management to route external traffic to in-cluster services.
See Storage basics to persist pod data.
See Pull images from an instance in the same account to pull container images without a secret in an ACK cluster.
See Accelerating cross-region container image pulls with Global Accelerator (GA) to speed up overseas image pulls in ACK clusters.