What a Pod Represents

Summary

• A Pod is the smallest deployable unit in Kubernetes: one or more containers that share a network identity, storage, and a lifecycle on a single node.
• Insight: Kubernetes does not schedule containers. It schedules Pods. The container is a packaging detail; the Pod is the scheduling and networking boundary.
• Key Concepts: the pause (infra) container, a shared network namespace, shared IPC and optional PID namespace, a single node placement, and an atomic scheduling unit.
• When to Use: almost never author a bare Pod for production. You describe Pods indirectly through a Deployment, StatefulSet, DaemonSet, or Job template.
• Limitations/Trade-offs: Pods are mortal and non-repairable. They are never moved, only replaced, and their IP is ephemeral.
• Related Topics: container specs, probes, sidecars, and why the Pod (not the container) is the unit.

Foundations

A Pod is a group of one or more containers with shared context.

That context is a set of Linux namespaces and cgroups that the containers join together, plus a shared set of volumes.

The mental model: a Pod is a "logical host." Containers in the same Pod behave like processes on the same machine.

They reach each other over localhost, can share memory through IPC, and can pass data through a shared volume.

Every Pod gets its own cluster-routable IP address. All containers in the Pod share that single IP and its port space.

This is why two containers in one Pod cannot both bind port 8080. They are in the same network namespace.

A Pod always runs on exactly one node. Kubernetes never splits a Pod across machines.

The Pod is also the atomic unit of scheduling. The scheduler places the whole Pod or none of it.

Crucially, a Pod is disposable. Its identity, IP, and local state disappear when it dies, and a controller creates a fresh Pod to replace it.

Mechanics & Interactions

When the kubelet starts a Pod, it first creates an infrastructure container commonly called the pause container.

The pause container holds the network namespace open. Application containers then join that namespace rather than each creating their own.

This is what makes localhost communication and a shared IP possible. The pause container owns the namespace; the workload containers borrow it.

On modern clusters the kubelet talks to containerd through the CRI (Container Runtime Interface) to create these containers. Docker Engine is not the in-cluster runtime; dockershim was removed in Kubernetes 1.24.

You build images with Docker or BuildKit, but containerd runs them on the node.

The Pod's declared containers each get their own filesystem, cgroup limits, and process namespace by default, while sharing the network and IPC namespaces.

Volumes are defined at the Pod level and mounted into containers that ask for them.

An emptyDir volume, for example, lives as long as the Pod and lets a sidecar and the main container exchange files.

The lifecycle runs through phases: Pending, Running, Succeeded, Failed, and the catch-all Unknown.

Individual containers have their own states (Waiting, Running, Terminated) and restart independently based on the Pod's restartPolicy.

A minimal Pod makes the shape concrete:

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - name: app
      image: registry.example.com/web@sha256:abc123...
      ports:
        - containerPort: 8080

Restarting a crashed container reuses the same Pod and IP. Deleting and recreating the Pod gives a new IP entirely.

Advanced Considerations & Applications

Because Pods are ephemeral, you never point clients at a Pod IP. You put a Service in front, and the Service tracks healthy Pod endpoints.

Multi-container Pods exist for tightly coupled helpers that must share the Pod's network or storage: a log shipper, a proxy, or a config reloader.

Reach for a second container only when it must be co-located and share Pod resources. Otherwise, use a separate Deployment.

Pod-level settings shape scheduling and safety. nodeSelector, affinity, tolerations, and topologySpreadConstraints all act on the Pod as a whole.

The securityContext can be set at the Pod level (applying to all containers) and refined per container.

Graceful shutdown is a Pod concern. On deletion the kubelet sends SIGTERM, waits up to terminationGracePeriodSeconds (default 30), then sends SIGKILL.

Design your app to catch SIGTERM, stop accepting new work, drain in-flight requests, and exit.

Static Pods are a special case: the kubelet runs them directly from a manifest directory, independent of the API server. Control-plane components often run this way.

For production, enforce the restricted Pod Security Standard: non-root user, no privilege escalation, dropped capabilities, and a read-only root filesystem where possible.

Common Misconceptions

"A Pod is just a container." A single-container Pod is common, but the Pod is still a distinct wrapper with its own IP, volumes, and lifecycle.

"Pods heal themselves." They do not. A controller (Deployment, StatefulSet) replaces a failed Pod. A bare Pod with no controller simply stays dead.

"Docker runs my Pods." On the node, containerd (via CRI) runs them. Docker is for building images and local development.

"Containers in a Pod are isolated from each other." They share network and IPC namespaces and can share volumes. They are intentionally close, not isolated.

"A Pod keeps its IP forever." The IP lasts only for that Pod instance. A replacement Pod gets a new IP, which is why Services exist.

FAQs

Should I create Pods directly? Rarely. Use a Deployment or other controller so failed Pods are recreated and rollouts are managed.

How many containers should a Pod have? Usually one main container plus any sidecars that truly must share its network or storage. Do not co-locate unrelated services.

What happens to a Pod when its node dies? The Pod is marked for deletion and its controller schedules a replacement on a healthy node. The original is gone.

Do all containers in a Pod restart together? No. Each container restarts independently per the Pod restartPolicy. The Pod object persists across container restarts.

Can two Pods share an IP? No. Each Pod gets a unique, cluster-routable IP for its lifetime.

Is the pause container something I manage? No. The kubelet creates and manages it automatically to hold the shared namespaces.

Related

• Pods Basics
• Why the Pod, Not the Container, Is the Unit
• Container Spec
• Init & Sidecar Containers
• Pods Best Practices

Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).