Solutions
Audit & Optimization Platform Design Automation Team Structure
Documentation Blog
Get Started

Workloads & Scheduling

Workloads are the applications and tasks that run on your Kubernetes cluster. They define what containers should run, how many replicas you need, how they should be updated, and how Kubernetes should schedule them onto nodes. The workloads section covers everything from stateless applications to databases, from one-time batch jobs to continuously running services.

What Are Workloads?

In Kubernetes, a workload is any resource that creates and manages pods—the basic execution unit in Kubernetes. Workloads handle the lifecycle of pods: creating them, ensuring the right number are running, replacing failed pods, and updating them when you deploy new versions.

graph TB A[Workload Resources] --> B[Deployments] A --> C[StatefulSets] A --> D[DaemonSets] A --> E[Jobs] A --> F[CronJobs] B --> G[Creates & Manages Pods] C --> G D --> G E --> G F --> G G --> H[Pods Run on Nodes] style A fill:#e1f5ff style G fill:#fff4e1 style H fill:#e8f5e9

Types of Workloads

Kubernetes provides different workload types for different use cases:

Stateless Workloads

Deployments - The most common workload for stateless applications. They manage pod replicas and handle rolling updates automatically. Perfect for web servers, APIs, and most microservices.

ReplicaSets - The underlying mechanism that Deployments use to ensure a specific number of pod replicas are running. You typically use Deployments, which manage ReplicaSets for you.

Stateful Workloads

StatefulSets - Designed for stateful applications that need stable network identity, stable storage, and ordered deployment. Used for databases, message queues, and distributed systems with state.

Node-Level Workloads

DaemonSets - Ensures that one pod runs on every node (or specific nodes). Perfect for logging agents, monitoring tools, and cluster-wide utilities.

Batch Workloads

Jobs - Run a task to completion. Used for one-time work like data processing, backups, or migrations. Jobs can run in parallel and retry on failure.

CronJobs - Schedule Jobs to run at specific times. Useful for periodic tasks like backups, reports, or cleanup jobs.

Configuration and Data

Workloads often need configuration and sensitive data:

ConfigMaps - Store non-sensitive configuration data. Decouple configuration from container images, making it easier to manage environment-specific settings.

Secrets - Store sensitive data like passwords, tokens, and keys. Similar to ConfigMaps but designed for sensitive information with additional security considerations.

Autoscaling

Kubernetes can automatically adjust the number of pods based on demand:

  • Horizontal Pod Autoscaler (HPA) - Scales the number of pod replicas based on CPU, memory, or custom metrics
  • Vertical Pod Autoscaler (VPA) - Adjusts CPU and memory requests for pods based on actual usage

Resilience

Applications need to handle failures gracefully:

  • Health Probes - Liveness, readiness, and startup probes ensure pods are healthy and ready to serve traffic
  • Pod Disruption Budgets - Control how many pods can be disrupted during voluntary operations like node maintenance

Scheduling

The Kubernetes scheduler places pods onto nodes based on:

  • Resource Requests and Limits - CPU and memory requirements
  • Affinity and Anti-Affinity - Rules for placing pods together or apart
  • Taints and Tolerations - Node-level restrictions and exceptions
  • Topology Spread Constraints - Distribute pods across zones and nodes
  • Priority and Preemption - Important pods can evict less important ones
graph LR A[Pod Created] --> B[Scheduler Evaluates] B --> C{Meets Constraints?} C -->|Yes| D[Assigns to Node] C -->|No| E[Waits or Preempts] D --> F[Kubelet Starts Pod] style A fill:#e1f5ff style B fill:#fff4e1 style D fill:#e8f5e9 style F fill:#e8f5e9

Workload Lifecycle

Every workload follows a lifecycle:

graph TD A[Workload Created] --> B[Controller Watches] B --> C[Desired State vs Current State] C --> D{State Match?} D -->|No| E[Controller Creates/Updates Pods] D -->|Yes| F[Maintains State] E --> G[Scheduler Assigns Nodes] G --> H[Pods Running] H --> I{Change Needed?} I -->|Update| C I -->|Delete| J[Cleanup Pods] style A fill:#e1f5ff style E fill:#fff4e1 style H fill:#e8f5e9 style J fill:#ffe1e1

Choosing the Right Workload

Selecting the appropriate workload type depends on your application’s characteristics:

Use Deployments when:

  • ✅ Application is stateless
  • ✅ Pods are interchangeable
  • ✅ You need rolling updates
  • ✅ Simple scaling requirements

Use StatefulSets when:

  • ✅ Application requires stable network identity
  • ✅ Each pod needs unique, persistent storage
  • ✅ Pods must start/stop in order
  • ✅ Application is a database or distributed system with state

Use DaemonSets when:

  • ✅ You need one pod per node
  • ✅ Cluster-wide utility (logging, monitoring)
  • ✅ Node-level operations

Use Jobs when:

  • ✅ Task runs to completion
  • ✅ One-time or batch processing
  • ✅ Retry on failure needed

Use CronJobs when:

  • ✅ Scheduled, recurring tasks
  • ✅ Periodic maintenance
  • ✅ Regular reports or backups

Topics

Workload Resources

Configuration

Autoscaling

Resilience

Scheduling

See Also

  • Pod Basics - Understanding the basic pod resource
  • Services - Exposing workloads via network services
  • Storage - Persistent storage for stateful workloads
  • RBAC - Security and access control for workloads