Lesson 2: Pods, Workloads & Controllers

1. Pod — The Smallest Unit

A Pod is a group of one or more containers sharing the same network namespace (same IP, port space) and storage volumes. The Pod is the scheduling unit in Kubernetes.

┌─────────────────────────────────────┐
│              POD                    │
│  IP: 10.244.1.5                     │
│  ┌────────────┐  ┌───────────────┐  │
│  │  Container │  │  Sidecar      │  │
│  │   (app)    │  │  (log-agent)  │  │
│  └────────────┘  └───────────────┘  │
│       Shared Volume: /var/log       │
└─────────────────────────────────────┘

Pod Lifecycle

Phase	Meaning	Debug hint
Pending	Not yet scheduled or image is being pulled	Check events: kubectl describe pod
Running	Running, at least 1 container is active	Normal state
Succeeded	All containers exited with code 0	Job completed
Failed	At least 1 container exited with an error	kubectl logs --previous
Unknown	Cannot contact the node	Node network issue
CrashLoopBackOff	Container keeps crashing and restarting	kubectl logs -p

Exam tip: CrashLoopBackOff is not an official Pod phase — it's a Container state under Waiting. Questions often ask "pod phase" vs "container state".

2. Workload Controllers

Controller	Use when	Key characteristics
Deployment	Stateless apps (web server, API)	Rolling update, rollback, ReplicaSet management
ReplicaSet	Ensuring N replicas (usually used via Deployment)	Label selector, rarely used directly
StatefulSet	Stateful apps (database, Kafka, Elasticsearch)	Stable pod names (web-0, web-1), stable storage, ordered deployment
DaemonSet	Agent running on every node (logging, monitoring, network)	1 Pod/node, auto-deploys when new node joins
Job	Batch task that runs to completion	completions, parallelism, backoffLimit
CronJob	Periodic batch tasks	cron syntax, concurrencyPolicy, schedule

Deployment vs StatefulSet

DEPLOYMENT (Stateless)          STATEFULSET (Stateful)
─────────────────────           ────────────────────────
Pod names: web-a1b2c3            Pod names: web-0, web-1, web-2
Any order scale up/down          Ordered: web-0 first, then web-1...
Shared or no storage             Each Pod gets its own PVC
Pod replaced = new identity      Pod replaced = same identity
Examples: nginx, api-server      Examples: MySQL, MongoDB, Kafka

3. Labels, Selectors & Annotations

Concept	Used for	Example
Labels	Tag resources for selection and grouping	app: frontend, env: prod
Selectors	Query resources by labels	selector: {app: frontend}
Annotations	Metadata not used for selection (build info, contact)	maintainer: [email protected]

Exam tip: Services find Pods via selector matching Pod labels. If the selector doesn't match, the Service will have empty Endpoints → traffic can't reach Pods.

4. DaemonSet Use Cases

NODE 1         NODE 2         NODE 3
┌──────┐       ┌──────┐       ┌──────┐
│fluentd│      │fluentd│      │fluentd│  ← Log collector DaemonSet
│ Pod  │       │ Pod  │       │ Pod  │
├──────┤       ├──────┤       ├──────┤
│calico│       │calico│       │calico│  ← CNI network plugin DaemonSet
│ Pod  │       │ Pod  │       │ Pod  │
└──────┘       └──────┘       └──────┘

DaemonSets are commonly used for: Fluentd/Filebeat (log collection), Prometheus Node Exporter (metrics), kube-proxy (networking), CNI plugins (Calico, Cilium).

5. Cheat Sheet

Exam question	Answer
Stateful app needing stable identity?	StatefulSet
1 Pod per node (monitoring agent)?	DaemonSet
Stateless app with rolling update?	Deployment
One-time batch processing?	Job
Scheduled batch (nightly backup)?	CronJob
Pod naming pattern for StatefulSet?	name-0, name-1, name-2

6. Practice Questions

Q1: A company needs to deploy a MySQL database on Kubernetes with stable network identity and dedicated storage per replica. Which workload type should they use?

• A) Deployment with PersistentVolumeClaim
• B) StatefulSet ✓
• C) DaemonSet
• D) ReplicaSet

Explanation: StatefulSet provides stable Pod names (mysql-0, mysql-1), ordered deployment/scaling, and each Pod gets its own PVC via volumeClaimTemplates. These properties are essential for databases.

Q2: Which workload ensures exactly one Pod runs on every node in the cluster, including future nodes that join?

• A) Deployment with replicas matching node count
• B) ReplicaSet with nodeSelector
• C) DaemonSet ✓
• D) StatefulSet

Explanation: DaemonSet automatically deploys one Pod per node and watches cluster membership — when a new node joins, the DaemonSet controller immediately creates a Pod on it.

Q3: A Pod is in 'Pending' state. What is the MOST likely cause?

• A) The container application crashed
• B) No node satisfies the scheduling requirements ✓
• C) The liveness probe failed
• D) The container image is corrupted

Explanation: Pending means the Pod has been accepted but hasn't started. Most common reasons: insufficient CPU/memory on nodes, unsatisfied node affinity/taints, or PVC not bound. Check kubectl describe pod events.