Pods and containers

A Pod is one or more containers sharing network and volumes — the atom the scheduler places. Almost everything else exists to create and replace Pods safely.

Ephemeral by default

Pods die when nodes die, when OOMKilled, when evicted, or when a controller rolls them. Store state elsewhere (PVC, external DB, object storage). Designing for sticky local disk without a StatefulSet story is a future outage.

Containers in a Pod

• app containers — the workload
• init containers — run to completion before apps start (migrations lite, dependency waits — use carefully)
• sidecars — helpers in the same network namespace (proxies, log shippers)

Sidecars share fate with the app: resource requests add up; a wedged sidecar can block readiness if you wire probes poorly.

Lifecycle hooks and signals

preStop and graceful SIGTERM handling let connections drain. Align grace period with real shutdown time. Ignoring signals turns every deploy into dropped requests.

Probes (again, because they matter)

Startup, liveness, and readiness are Pod-level contracts with kubelet. Mis-set liveness that calls a dependency creates restart storms. Readiness that never becomes true removes you from Services forever.

Image pull and runtime class

ImagePullSecrets, pull policies, and RuntimeClass (sandbox/gVisor where used) are Pod template concerns. Prefer digests in production templates so “what runs” is unambiguous.