Workloads Overview

The Pod: Kubernetes' Atomic Workload Unit

Every workload in Kubernetes runs as one or more Pods. A Pod is a co-scheduled group of one or more containers sharing a network namespace (same IP, same port space) and optionally sharing storage volumes. Pods are ephemeral by design — they are created, run, and eventually terminate. Controllers give pods durability, scale, and update semantics.

The Controller Reconciliation Pattern

All Kubernetes workload controllers follow the same fundamental loop: watch the actual state of the cluster, compare it to the desired state declared in the spec, and take actions to reconcile the difference. This pattern makes Kubernetes self-healing — if a pod crashes, the controller notices and creates a replacement.

The controller never talks to kubelet directly. It writes Pod objects to the API server. The scheduler picks them up and assigns spec.nodeName. Kubelet on the assigned node watches for pods with its node name and starts the containers.

Workload Controller Kinds

Workload Decision Matrix

Owner References and Garbage Collection

Every pod created by a controller carries an ownerReferences entry pointing back to the controller (or its ReplicaSet). When the owner is deleted, the garbage collector cascades deletion to all owned objects — by default, this includes pods.

# Pod created by a Deployment has two owner refs (pod → ReplicaSet → Deployment):
metadata:
  ownerReferences:
  - apiVersion: apps/v1
    kind: ReplicaSet
    name: nginx-7d9c8f8b6
    uid: abc123...
    controller: true          # only one ownerRef can be the controller
    blockOwnerDeletion: true  # prevents owner deletion until this object is deleted first

# Cascade modes when deleting a Deployment:
# --cascade=foreground  → owner marked for deletion, GC deletes pods first (default UI)
# --cascade=background  → owner deleted immediately, GC cleans up pods asynchronously
# --cascade=orphan      → owner deleted, pods left running (useful for StatefulSet migration)

Pod Template Propagation

All controllers embed a spec.template which is a complete PodSpec (minus apiVersion, kind, and metadata.name). The controller stamps this template onto every pod it creates, injecting a generated name and the controller's ownerReference.

apiVersion: apps/v1
kind: Deployment
spec:
  selector:
    matchLabels:
      app: nginx          # must match template labels
  template:               # ← PodTemplateSpec: everything below becomes the Pod spec
    metadata:
      labels:
        app: nginx        # must satisfy selector.matchLabels
        version: v1.2.3   # additional labels allowed
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        # ... full PodSpec here

Autoscaling Landscape

Resource Model Summary

Every container specifies CPU and memory requests (scheduling guarantee) and limits (enforcement ceiling). The combination determines the pod's Quality of Service (QoS) class, which governs eviction priority under node pressure.

# Guaranteed QoS — both resources, requests == limits in every container
resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

# Burstable QoS — requests set, limits higher or absent
resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

# BestEffort QoS — no resources specified (dev/test only)
resources: {}

Scheduling Primitives Summary

Pod Lifecycle Summary

Graceful Termination Sequence

# Termination flow when pod is deleted:
# 1. Pod marked Terminating; removed from Service Endpoints immediately
# 2. preStop hook executed (if defined) — blocks until hook exits or timeout
# 3. SIGTERM sent to PID 1 of each container
# 4. Wait up to terminationGracePeriodSeconds (default: 30s)
# 5. SIGKILL sent if still running after grace period

spec:
  terminationGracePeriodSeconds: 60   # override default 30s
  containers:
  - name: app
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 5"]   # drain in-flight requests
        # OR
        httpGet:
          path: /drain
          port: 8080

Init Containers and Sidecar Containers

Workload Identity and Service Accounts

Every pod runs under a ServiceAccount. The mounted service account token (projected volume at /var/run/secrets/kubernetes.io/serviceaccount/token) allows the pod to authenticate to the Kubernetes API server. With IRSA (AWS), Workload Identity (GCP/Azure), or SPIFFE/SPIRE, the same token is exchanged for cloud credentials without long-lived secrets.

spec:
  serviceAccountName: my-app-sa      # default: "default" SA in namespace
  automountServiceAccountToken: false # disable if pod doesn't need API access

# Best practice: create a dedicated SA per workload, not share "default"
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: production
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/my-app-role  # IRSA

Cross-Cutting Concerns per Workload Kind

Section Roadmap

This section covers 11 additional files, each a deep dive into a specific workload topic: