⌂ Home

Workloads and Pod Concepts

Interactive overview of the main workload controllers and the Pod-centric concepts they build upon.

Pods are the runtime unit, and controllers exist to manage Pods for specific workload patterns. This page gives the big-picture map that ties those concepts together.

Core Model

Understand the Concept First

Pod is the runtime unit

Nearly every workload eventually becomes Pods scheduled and run on nodes.

Controllers add behavior

Deployments, Jobs, StatefulSets, and DaemonSets each manage Pods differently.

Supporting concepts shape behavior

Services, init containers, probes, and resource settings all influence Pod behavior.

Lifecycle Flow

Workload Mental Model

1

Choose workload type

Pick the controller that matches the application’s lifecycle needs.

2

Controller creates Pods

The workload abstraction turns desired state into running Pods.

3

Expose and observe

Services, probes, and metrics make Pods reachable and manageable.

4

Operate through controllers

Scaling, updates, and policy are applied through the controller layer.

A strong mental model starts with Pods, but daily operations usually happen through controllers and supporting abstractions.
Visual Diagrams

Workload Decision Tree & Controller Hierarchy

Workload Type Decision Tree

Choose Workload Type Does it need to finish? Yes Scheduled or one-time? One-time Job Run to completion Migrations, batch tasks Scheduled CronJob Time-based execution Backups, reports No (runs continuously) One per node? Yes DaemonSet One pod per node Logs, monitoring agents No Needs stable identity? Yes StatefulSet Ordered, stable pods Databases, queues No Deployment Stateless replicas Web apps, APIs Decision Path: Completion → Scheduling → Distribution → Identity Each workload type optimizes for different operational characteristics

Controller Hierarchy: Deployment → ReplicaSet → Pod

Deployment nginx-deployment replicas: 3, strategy: RollingUpdate Deployment manages ReplicaSets Manages Old (scaling down) ReplicaSet (current) nginx-deployment-abc123 desired: 3, current: 3, ready: 3 Active ReplicaSet managing current pods ReplicaSet (old) nginx-deployment-xyz789 desired: 0, current: 0, ready: 0 Previous ReplicaSet (rollback capability) Creates & Maintains Pod 1 nginx-abc123-p1 Running on node-1 Pod 2 nginx-abc123-p2 Running on node-2 Pod 3 nginx-abc123-p3 Running on node-3 3-Layer Abstraction Deployment: rollout strategy ReplicaSet: replica management Pod: actual workload execution
Understanding workload controllers helps you choose the right abstraction for your application's lifecycle requirements. Deployments are most common, but each controller type serves specific patterns.
YAML and Commands

Examples You Can Recognize Quickly

Core Workload Types
Pod
Deployment
StatefulSet
DaemonSet
Job
CronJob
Supporting Concepts
Services
Init Containers
Probes
Requests and Limits
Decision Guide

Workload Categories

Workload Primary goal Best fit
Deployment Replicated stateless workloads Web apps and APIs
StatefulSet Stable identity and ordered behavior Databases and clustered stateful apps
DaemonSet One Pod per eligible node Node agents and platform services
Job / CronJob Completion-based work Batch and scheduled processing
Once you know the workload goal, picking the right controller becomes much easier.
Use It Well

Practice and Real-World Thinking

Team onboarding

Use this as a concept map before diving into specific workload explainers.

Exam revision

Connect object purpose to expected behavior and management model.

Architecture reviews

Ask whether the chosen controller matches the real workload lifecycle.