Kubernetes pods - System Design Guide

Overview

A pod is the smallest deployable unit in Kubernetes: one or more containers that share a network namespace (same IP and port space), storage volumes, and lifecycle. Most pods run a single application container, sometimes with helper containers (sidecars) for logging, proxies, or config reloading, and init containers that run before the app starts.

Pods are ephemeral: they are created, scheduled onto a node, run, and eventually die, and they are replaced rather than repaired. That is why you rarely create pods directly; Deployments, StatefulSets, Jobs, and DaemonSets manage them. Probes, resource requests and limits, and graceful shutdown determine how well pods behave in production.

A shared apartment

Containers in a pod are roommates: they share an address (IP), can talk through the hallway (localhost), and share storage rooms (volumes). When the lease ends, everyone moves out together.

When to use it

Understanding how Kubernetes runs any workload.
Designing sidecars (service mesh proxies, log shippers).
Configuring health checks and graceful shutdown.
Debugging crashes, OOM kills, and scheduling issues.

Where it shows up in interviews

Sidecar pattern

Recognize it when: add cross-cutting features without changing app code.

Design a service mesh
Design log collection in Kubernetes

Graceful lifecycle

Recognize it when: no dropped requests during deploys.

Design zero-downtime deployments on Kubernetes

Where it is used in real software

Istio / Envoy sidecars

Service meshes inject an Envoy proxy container into each pod for mTLS, retries, and telemetry.

Init containers

Commonly run database migrations or wait for dependencies before the app starts.

Native sidecars

Kubernetes 1.28+ supports sidecar containers that start before and stop after the main container.

Key terms

Pod phase: Pending, Running, Succeeded, Failed, Unknown.
Init container: Runs to completion before app containers start.
Sidecar: Helper container running alongside the app.
Probes: Startup, readiness, liveness health checks.
OOMKilled: Container exceeded its memory limit and was killed.

How it works, step by step

1
Scheduled
Scheduler assigns a node (Pending).
2
Init containers run
In order, each must succeed.
3
App containers start
Startup probe, then readiness and liveness.
4
Ready
Added to Service endpoints; receives traffic.
5
Termination
SIGTERM, removed from endpoints, grace period, then SIGKILL.

Common pod problems

kubectl describe / logs diagnosis

Status	Likely cause	Fix
Pending	No node has requested resources	Lower requests or add nodes
ImagePullBackOff	Wrong image or registry credentials	Fix tag or pull secret
CrashLoopBackOff	App exits on start	Check logs, config, dependencies
OOMKilled	Memory above limit	Fix leak or raise limit
Running but not Ready	Readiness probe failing	Check the endpoint and dependencies

NOWStatus: Pending | Likely cause: No node has requested resources | Fix: Lower requests or add nodes

kubectl describe pod shows events; kubectl logs --previous shows the crashed container's last output.

Implementation

1apiVersion: v12kind: Pod3metadata: { name: api, labels: { app: api } }4spec:5  terminationGracePeriodSeconds: 306  initContainers:7    - name: migrate8      image: containers.artifactory.tools.bestbuy.com/team/api:abc12349      command: ["node", "dist/migrate.js"]10  containers:11    - name: api12      image: containers.artifactory.tools.bestbuy.com/team/api:abc123413      resources:14        requests: { cpu: 250m, memory: 256Mi }15        limits: { memory: 512Mi }16      startupProbe: { httpGet: { path: /health, port: 3000 }, failureThreshold: 30, periodSeconds: 2 }17      readinessProbe: { httpGet: { path: /ready, port: 3000 }, periodSeconds: 5 }18      livenessProbe: { httpGet: { path: /health, port: 3000 }, periodSeconds: 10 }19      lifecycle:20        preStop: { exec: { command: ["sleep", "5"] } } # let load balancers stop sending traffic21      securityContext: { runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false }

Complexity and performance

Pod startupSeconds

Image pull dominates when uncached.

Default grace period30 s

Then SIGKILL.

Trade-offs

Sidecars vs libraries

Sidecars add features without code changes but consume resources in every pod.

Memory limits

Tight limits protect nodes but risk OOM kills; loose limits risk noisy neighbors.

Variants and related techniques

Jobs and CronJobs

Pods that run to completion, once or on schedule.

DaemonSets

One pod per node, for agents like log collectors.

Common mistakes

Ignoring SIGTERM.
Fix: Requests drop during deploys; handle SIGTERM and drain.
Liveness probe too aggressive.
Fix: Slow startups get killed repeatedly; use startup probes.
Running migrations in every replica's init container.
Fix: Use a single Job or a migration lock.

Interview questions

Why do containers in a pod share a network namespace?

So tightly coupled containers, like an app and its proxy sidecar, can communicate over localhost and appear as one network endpoint with a single IP.

How do you avoid dropped requests during pod termination?

Fail readiness on SIGTERM, add a short preStop delay so endpoints update, stop accepting new connections, finish in-flight requests, and exit before the grace period ends.

Practice problems

Problem	Difficulty	What it trains
Debug a CrashLoopBackOff	Easy	describe and logs.
Implement graceful shutdown for an API	Medium	Signals and probes.