Skip to content
beginner Phase 3 · Core Workloads

Pods Deep Dive

Master Kubernetes Pods, their lifecycle, init containers, and sidecar patterns.

1h 15m
0 problems
Topic Progress 0%

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?

Question 1 options

2. What does an exit code of 137 usually indicate?

Question 2 options

3. Which probe decides whether a pod receives Service traffic?

Question 3 options

Flashcards

Question

Pod phases

Answer

Pending → Running → Succeeded/Failed, plus Unknown when the node stops reporting.

Question

init container

Answer

Runs to completion, sequentially, before app containers start; use for migrations or waiting on deps.

Question

liveness vs readiness

Answer

Liveness restarts a hung container; readiness gates traffic — never couple liveness to external deps.

Question

Termination sequence

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.

Next Topics