Learn Podman - Pods

#Introduction

In episode 5 you ran containers rootless and daemonless. Now it's time to discuss the feature that most sets Podman apart from Docker: pods. This concept comes from Kubernetes, and Podman adopts it fully — a pod is a group of containers that share a network namespace, so they can communicate over localhost as if they were one machine. Episode 6 teaches you how to create pods, place containers inside them, and start thinking in the pod mindset.

#From a Single Container to a Group of Containers

Throughout the previous five episodes you worked with a single container as a separate unit. Every podman run creates a container with its own network namespace, and two containers must be connected via networking if they want to talk to each other. Docker treats the container as the basic unit; Podman adds a layer on top: the pod.

A pod is the smallest scheduling unit, Kubernetes-style. One pod contains one or more containers that share:

• Network namespace — all containers in a pod use the same IP and ports.
• IPC namespace — enables inter-process communication.
• UTS namespace — the same hostname for the whole pod.
• PID namespace (optional) — containers can see each other's processes.

Because they share a network namespace, two containers in one pod can call each other via localhost. This is what makes the sidecar pattern — a companion container attached to a main container — feel natural in Podman.

#Docker vs Pod: A Mental Model Shift

This shift in thinking matters more than the commands:

In Docker, a web app and its log shipper are two separate containers communicating over the network. In Podman, both can be a single pod that talks over localhost — and when moved to Kubernetes later, the pod structure is immediately recognized.

#Creating a Pod: podman pod create

The command is simple:

podman pod create --name webpod
podman pod ps

podman pod create --name webpod creates an empty pod, and podman pod ps lists pods along with their status and container count. By default a new pod shares network, IPC, and UTS namespaces — behavior that can be changed with the --share option.

A created pod can be inspected in detail:

podman pod inspect webpod

podman pod inspect shows the pod's full configuration, including which namespaces are shared, the network in use, and the status of its containers. This JSON output is useful for debugging when communication between containers isn't behaving as expected.

#Placing Containers Into a Pod

Containers are placed into a pod via the --pod option on podman run:

podman run -d --pod webpod --name nginx nginx:latest
podman run -d --pod webpod --name logger alpine sleep 3600
podman pod ps

Both containers join the webpod pod. The nginx and logger containers now share a network namespace — from inside the logger container, nginx is reachable at localhost:80 without needing to know its IP. Because they share the same namespace, a port published on one pod member is forwarded for the whole pod, so port mapping only needs to be done once.

#Considerations When Using Pods

• Ports must not collide — because they share a network namespace, two containers in one pod can't use the same TCP port at the same time.
• Lifecycle is managed together — podman pod start, podman pod stop, and podman pod kill work on all members.
• Clean removal in one command — podman pod rm removes the pod along with its containers (with the --force flag if still running).

#Shifting Mindset From Docker to Kubernetes

Why bother with pods? The answer lies in the direction of the industry. Kubernetes — the de facto orchestration standard — treats the pod as the smallest unit. Applications built with a pod structure from the start can:

• Be mapped directly to a Kubernetes deployment without architectural changes.
• Use the sidecar pattern for logging, monitoring, or proxy in the same pod.
• Leverage a single shared network address, making service configuration simpler.

You don't need to replace all your Docker habits at once. Start with the pattern with the clearest payoff: applications made of several processes that must talk to each other over localhost, for example a web app with a database proxy alongside it.

#Pod Lifecycle

The pod lifecycle follows the same pattern as containers:

podman pod stop webpod
podman pod rm webpod

Notice that the pod lifecycle manages the containers inside it as a single unit — this is what makes the pod a good unit of work in Kubernetes later.

#Closing

Episode 6 introduces pods as a new unit of work in Podman: the concept of a group of containers sharing network, IPC, and UTS namespaces; creating pods with podman pod create; placing containers with podman run --pod; managing them with podman pod ps and podman pod inspect; and how to shift the Docker mindset to the Kubernetes-style pod mindset.

The key points to take home:

• The pod is the basic Kubernetes-style unit — a group of containers sharing a network namespace.
• Members of a pod communicate over localhost — this is the power of the sidecar pattern.
• Ports only need to be published once — the network namespace is shared, so port mapping applies to the whole pod.
• podman pod create and podman run --pod are the two key commands to get started.

In the next episode, Episode 7, you'll learn how data is stored and shared between containers: volumes and mounts — named volumes, bind mounts, tmpfs, all the way to the podman volume rename feature that arrived in Podman 6.1. Volumes are what bridge the short container lifecycle with data that must survive.