Kubernetes
Intermediate 15 min read Kubernetes

Workloads, Deployments & Pods

The workload taxonomy and the rollout contract

Pods are atomic groups of containers with a shared network namespace; Deployments manage rollout/rollback via ReplicaSets; StatefulSets, DaemonSets, Jobs, CronJobs cover stateful, node-scoped and ephemeral work.

PodDeploymentReplicaSetStatefulSetDaemonSetJobrolloutprobes
Prerequisites: Kubernetes Architecture
Before we start

What you will learn

  • Classify workloads: Deployment, StatefulSet, DaemonSet, Job, CronJob
  • Explain rolling update, rollback, and update strategies
  • Use probes to gate readiness and health
In 60 seconds

Deployment = desired replica count + image + update strategy; it rolls via ReplicaSets. StatefulSet gives stable identity + ordering; DaemonSet one pod per node; Job runs-to-completion; CronJob schedules jobs. Probes (liveness/readiness/startup) gate traffic and restarts.

Introduction

What is this?

Pod: 1+ containers in one netNS/IP, scheduling atom, volumes shared. Workload controllers: Deployment/RS (stateless), StatefulSet (stable identity, ordered scaling, per-pod PVC), DaemonSet (per-node daemons), Job (run to completion, backoffLimit), CronJob (schedule), plus Replicas and PodAutoScaling later. Update strategies: rolling (maxSurge/maxUnavailable), Recreate, blue/green via weight. Probe types: startup (boot gate), readiness (traffic eligibility), liveness (restart trigger) with httpGet/exec/grpc/tcpCheck. Pod lifecycle: Pending → Running → Succeeded/Failed; Terminating; PodDisruptionBudget governs voluntary evictions.

Motivation

Why do you need it?

  • The deployment model is where 'I told you 3 replicas' becomes real — everything else is pod plumbing.
  • Rollout configuration decides your deploy risk (surge vs downtime).
  • Stateful workloads need stable network identity + stable volumes; Deployments can't express that.
  • Jobs/cron make batch work primitive without bespoke scheduling infra.
Think about it

Mental model

Imagine

A theater company: actors (pods), understudies (RS), the play (workload), and stage managers (controllers)

Think of

Kubernetes workloads

Understudies keep the play going when an actor (pod) fails; directed sets (DaemonSet) put one stage manager on each venue (node); the show (Job) runs a script and exits.

Mechanics

How it works

  • Deployment controller creates a new RS per image change; rollout advances surge/unavailable bounds.
  • Each Pod schedule attaches kubelet liveness/readiness probes → container runs, TS ready, traffic attached.
  • On rollout failure, controller pauses; you can rollout undo to the prior RS.
  • StatefulSet preserves ordering (0→N) and per-index PVC/identity so state follows the pod stable hostname.
  • Jobs count completions; CronJob creates Jobs on schedule; backoff/budget logic decides retries.

Deployment → RS → Pods.

Deployment
Rolling update
ReplicaSet v1
ReplicaSet v2
Rollback
Hands-on

Examples

A production-grade Deployment

A production-grade Deployment
apiVersion: apps/v1
kind: Deployment
metadata: { name: api, namespace: prod }
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
  template:
    spec:
      containers:
        - name: api
          image: ghcr.io/acme/api@sha256:6f01d8... # pinned
          readinessProbe: { httpGet: { path: /readyz, port: 8080 }, periodSeconds: 5 }
          livenessProbe:  { httpGet: { path: /healthz, port: 8080 }, periodSeconds: 10 }
          resources: { requests: { cpu: 100m, memory: 128Mi }, limits: { cpu: 1, memory: 512Mi } }

Replicas, rollout budget, pinned image, probes, resources — the whole operational contract in one manifest.

Real world

In production

  • Happy-path HTTP services behind Deployments with surge rollouts.
  • Postgres-primary: StatefulSet per-PVC + stable identity; replicas as headless service.
  • Node telemetry/log-shippers as DaemonSets with hostPath mount.
  • Nightly ETL as CronJob with Job backoff, TTL, and cleanup hooks.
Guidelines

Best practices

  • Pin images by digest; keep tags for humans, digests for machines.
  • Set both readiness and liveness; make them hit real health endpoints, not '/200'.
  • Choose maxUnavailable/maxSurge to match your drain tolerance.
  • Record rollouts well when you scale deployment replicas (git or annotation); avoid kubectl edit-only.
  • For StatefulSets, provide a PodDisruptionBudget and ordered termination plan.
Watch out

Common mistakes

  • Liveness probe that fails on transient slowness → restart loops ('I just deploy, it crashes').
  • RollingUpdate with maxUnavailable:3 on a 3-replica service = full downtime window.
  • Deployments pretending to be Stateful or vice versa (identity assumptions break).
  • No startupProbe: slow JVM workers get killed before they ever become Ready.
When things break

Debugging tips

  • Rollout stuck: kubectl describe deployment → status.observedGeneration/conditions lie less than logs.
  • Pod CrashLoopBackOff: look at the last terminated container's exit reason first.
  • Readiness never true → curl your endpoint from inside; often firewall or wrong port.
  • Terminating pods forever → finalizers or the kubelet can't unmount volume.
Interviews

Interview checkpoint

Practice

Hands-on lab

Rollout, Rollback, and Probe Gating
40 min · intermediate
In progress
Objectives
  • Redeploy a Deployment with a surge rollout
  • Watch readiness gate traffic
  • Trigger and execute a rollback

Rollout, Rollback, and Probe Gating

40 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which workload runs exactly one pod per node by design?

2

A liveness probe failure causes:

Go deeper

Official documentation

Workloads (Pods)
docs
Deployments
docs
Probes
docs