beginner~4h

Pods: Lifecycle, Init Containers & Sidecars

A Pod is the smallest deployable unit in Kubernetes -- not a container. A Pod wraps one or more containers that share the same network namespace (same IP, same localhost) and can share storage volumes. Kubernetes 1.29+ distinguishes three container roles: init containers (run to completion before anything else), native sidecar containers (restartPolicy: Always on an init container entry, running the full Pod lifetime), and regular app containers.

All containers in a Pod share the same network namespace -- same IP address, reachable via localhost.
Pod phase (Pending, Running, Succeeded, Failed, Unknown) is coarse. Pod conditions (PodScheduled, Initialized, ContainersReady, Ready) give the precise picture automation should check.
Init containers run strictly sequentially, each must exit with code 0 before the next starts, and all must complete before any app container or native sidecar starts.
Native sidecar containers (restartPolicy: Always on an init container entry) start before app containers, run for the Pod's whole lifetime, and receive SIGTERM only after app containers -- solving the 'sidecar exits first' shutdown problem.

Pod scheduled to node. kubelet sets up shared network namespace via CNI.
Init containers run one at a time; each must exit 0 before the next starts.
Native sidecar containers start, then regular app containers start.
kubelet runs liveness, readiness, and startup probes on all containers.
Pod marked Ready once all required containers pass readiness probes.
On termination, app containers receive SIGTERM first; native sidecars receive it after.

Init container waiting for a DB or running a migration before the main app starts.
Native sidecar implementing a service mesh proxy (Envoy) that must start before the app sends requests.
Logging sidecar tailing app log files from a shared emptyDir volume.
Init container downloading static assets into a shared volume the app then serves.

Use init containers for setup that must fully complete before the app starts.
Prefer the native sidecar feature (restartPolicy: Always) over the older convention-based pattern.
Keep init containers small, fast, and idempotent -- they run on every Pod restart.
Define readiness probes on sidecars too if they affect whether the Pod can serve traffic.

Using convention-based sidecar (in containers:) and being surprised when it terminates before the app.
Slow init containers -- they run on every Pod restart, adding startup latency each time.
Assuming phase 'Running' means the app is ready -- check the Ready condition instead.
Two containers in the same Pod cannot both bind the same port.

Minimize init container count and runtime -- they execute serially adding to startup latency.
Right-size sidecar resource requests independently from the main container.

Standardize on the native sidecar feature for new mesh, logging, or proxy sidecar patterns.
Use ephemeral debug containers (kubectl debug) for production troubleshooting.

Create a Pod with a failing init container and observe how the status reflects the failure.
Convert a convention-based sidecar to a native sidecar and compare startup/shutdown behavior.
Create a multi-container Pod with shared emptyDir and confirm data sharing between containers.

A Pod shares one network namespace (one IP, localhost between containers) across all its containers.
Init containers run sequentially and must all succeed before any app container or native sidecar starts.
Native sidecars (restartPolicy: Always) start first and stop last -- correct lifecycle ordering.
Pod phase is coarse; the Ready condition is what automation should check.
All containers share one IP and port space -- port conflicts in the same Pod are a real constraint.

Want a visual for this concept?

Generate a diagram tailored to “Pods: Lifecycle, Init Containers & Sidecars” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.

Practice quiz

Next Step

Continue to Workloads I: Deployment & ReplicaSet →← Back to all Kubernetes chapters