8 Kubernetes Pods and Containers

Kubernetes Pods and Containers is the foundational execution unit model of Kubernetes, describing how one or more containers are grouped together into a Pod, the smallest deployable object in the platform, and how that grouping shapes networking, storage, and lifecycle behavior for the applications running inside it.

What a Pod Is

The Smallest Deployable Unit

Kubernetes does not schedule individual containers directly. Instead, it schedules Pods, and every container runs inside the context of exactly one Pod. Even a single-container application is still represented as a Pod containing one container.

Shared Context

All containers within a Pod share the same network namespace, meaning they share an IP address and port space, and can communicate with each other over localhost. They can also share storage volumes mounted into the Pod, allowing data to be exchanged between containers without going over the network.

Single-Container vs. Multi-Container Pods

Single-Container Pods

The most common pattern is a Pod containing exactly one application container, which is the simplest way to run a workload and is appropriate when there is no need for tightly coupled helper processes.

Multi-Container Pods

Multi-container Pods group an application container with one or more helper containers that need to share its network and storage, such as a sidecar that handles logging, a proxy that manages traffic, or an adapter that translates data formats.

Sidecars and Init Containers

Init containers run to completion before the main containers of a Pod start, typically used to perform setup tasks. Sidecar containers, by contrast, run alongside the main container for the Pod's entire lifetime, extending or supporting its behavior.

Pod Lifecycle

Phases

A Pod progresses through a defined set of phases: Pending while it awaits scheduling and image pulls, Running once at least one container is executing, Succeeded or Failed once all containers have terminated, depending on their exit status.

Restart Policies

A Pod's restart policy determines how the kubelet responds when a container inside it exits, ranging from always restarting, to only restarting on failure, to never restarting, which is chosen based on whether the workload is a long-running service or a run-to-completion task.

Networking Within a Pod

Shared IP Address

Every Pod is assigned a single IP address shared by all its containers. Containers within the same Pod communicate with each other directly over localhost using distinct ports, avoiding the need for any network abstraction between them.

Pod-to-Pod Communication

Communication between different Pods happens over the cluster's Pod network, in which every Pod IP is routable from every other Pod without network address translation, regardless of which node they are scheduled on.

Storage Within a Pod

Volumes

A Pod can declare volumes, which are storage locations that exist for the lifetime of the Pod and can be mounted into one or more of its containers, enabling data sharing between containers or persistence across container restarts within the same Pod.

Ephemeral vs. Persistent Storage

Some volume types are ephemeral, existing only as long as the Pod does, while others reference persistent storage backed by external systems, surviving even if the Pod is deleted and recreated elsewhere.

Pod Ephemerality

Pods in Kubernetes are treated as disposable: they are not expected to survive rescheduling, node failure, or rolling updates. Higher-level controllers such as Deployments and StatefulSets manage the creation and replacement of Pods, meaning applications must be designed to tolerate their individual Pods being terminated and recreated at any time.