Pods Are Not Containers
Pods Are Not Containers
A pod is the schedulable unit: one or more containers sharing a network namespace (single IP, localhost between them), IPC, and mounted volumes. You scale pods, never individual containers.
Phases describe the pod as a whole — Pending, Running, Succeeded, Failed, or Unknown when the node stops reporting — while each container carries its own state: Waiting (image pull), Running, or Terminated with an exit code.
Startup order is explicit: init containers run sequentially to completion before app containers begin. The restart policy (Always by default, plus OnFailure or Never) applies per container, and probes gate traffic and restarts independently of phase.
Init Containers, Probes, Termination
Init Containers, Probes, Termination
initContainers:
- name: wait-for-db
image: busybox:1.36
command: ['sh','-c','until nslookup db; do sleep 2; done']
containers:
- name: app
image: registry.example.com/app:1.4.2
startupProbe: { httpGet: { path: /healthz, port: 8080 }, failureThreshold: 30, periodSeconds: 10 }
livenessProbe: { httpGet: { path: /live, port: 8080 }, periodSeconds: 10 }
readinessProbe:{ httpGet: { path: /ready, port: 8080 }, periodSeconds: 5 }
lifecycle:
preStop: { exec: { command: ['sh','-c','sleep 15'] } }
On deletion, kubelet sends SIGTERM, waits terminationGracePeriodSeconds (default 30), then SIGKILL. A preStop hook plus a slow shutdown lets Service endpoints drain before the process dies.
Pitfalls and Debugging
Pitfalls and Debugging
Pitfall 1 — liveness probes coupled to dependencies. If the database goes away and the liveness probe starts failing, Kubernetes restarts an application that was never broken. Use liveness for hangs and deadlocks, readiness for dependency health, and startup probes to protect slow boot.
Pitfall 2 — guessing at CrashLoopBackOff. Read in order: kubectl logs <pod> --previous for the exit code, describe for probe failures and pull errors, then node events. Exit 137 means the kernel OOM killer fired — usually a workload exceeding an unset or too-small memory limit.
Interview-ready: name the three probe types and their differences, then the termination sequence: preStop, SIGTERM, grace period, SIGKILL — and why init containers exist alongside the shared network namespace that makes sidecars work on localhost.
Quiz
1. Which restart policies are valid on a pod?
2. What does an exit code of 137 usually indicate?
3. Which probe decides whether a pod receives Service traffic?
Flashcards
Question
Pod phases
Click to reveal answer
Answer
Pending → Running → Succeeded/Failed, plus Unknown when the node stops reporting.
Question
init container
Click to reveal answer
Answer
Runs to completion, sequentially, before app containers start; use for migrations or waiting on deps.
Question
liveness vs readiness
Click to reveal answer
Answer
Liveness restarts a hung container; readiness gates traffic — never couple liveness to external deps.
Question
Termination sequence
Click to reveal answer
Answer
preStop → SIGTERM → terminationGracePeriodSeconds (30 default) → SIGKILL.
Revision Notes
Key Takeaways
- 1. Pods share one network namespace and are the unit of scheduling
- 2. Probes and restart policies operate per container, not per pod phase
- 3. Exit codes and --previous logs are the fastest crash diagnosis
Interview Tips
- • Distinguish the three probes with a concrete failure scenario for each
- • Explain how a sidecar reaches the app container via localhost within the pod
Cheat Sheet
Phases: Pending/Running/Succeeded/Failed/Unknown. Probes: startup → liveness → readiness. Exit 137 = OOM. Grace: preStop + SIGTERM + 30s + SIGKILL.
Continue Learning
Before You Start
- No prerequisites listed.