A Podman pod is a group of containers that share network namespaces, IPC namespaces, and potentially other Linux namespaces, allowing them to communicate and be managed as a single unit, much like Kubernetes pods.
Let’s see this in action. Imagine you have a web application that requires both a frontend and a backend service, and they need to talk to each other. Instead of running them as separate, independent containers, we can group them into a pod.
First, let’s create a pod. We’ll name it my-app-pod and specify the podman network create --subnet 10.89.0.0/24 my-app-net first if it doesn’t exist.
podman pod create --name my-app-pod --network my-app-net
Now, we’ll run our frontend container, let’s say an Nginx server serving static files, and tell Podman to add it to our my-app-pod. We’ll expose port 8080 on the host to port 80 in the container.
podman run -d --pod my-app-pod --name my-app-frontend -p 8080:80 nginx
Next, we run our backend container, perhaps a simple Python Flask app. This container doesn’t need to be directly exposed to the host network; it only needs to communicate with the frontend within the pod.
podman run -d --pod my-app-pod --name my-app-backend -e BACKEND_URL=http://localhost:5000 my-app-backend-image:latest
Notice how we didn’t explicitly map ports for the backend. Within the pod, the frontend can directly reach the backend using localhost:5000 (assuming the backend app listens on port 5000).
To verify, let’s inspect the pod:
podman pod inspect my-app-pod
You’ll see output detailing the pod’s configuration, including its shared network namespace and the containers within it. You can also see the containers belonging to the pod:
podman ps --pod my-app-pod
This shows both my-app-frontend and my-app-backend running.
The fundamental problem Podman pods solve is managing closely related containers that need to collaborate. Without pods, you’d typically manage network configurations, port mappings, and inter-container communication manually. This can become complex quickly, especially with multiple containers. Pods abstract this complexity away by providing a unified network namespace. All containers within a pod share the same IP address and port space. This means they can communicate with each other using localhost and port numbers, just as if they were processes on the same machine.
Internally, Podman creates a "infra" container for each pod. This infra container is minimal (often k8s.gcr.io/pause or a similar lightweight image) and its sole purpose is to hold the shared namespaces for the pod. When you add other containers to the pod, they are configured to join these existing namespaces rather than creating new ones. This is the mechanism that enables the shared network and IPC.
The key levers you control are:
- Pod Name:
podman pod create --name <pod-name> ...- Identifies your pod. - Network Configuration:
--network <network-name>or--network bridge(default). This defines how the pod’s network namespace interacts with the host and other networks. - Shared Namespaces: By default, pods share network, IPC, and UTS namespaces. You can fine-tune this with
--share-net,--share-ipc,--share-utsflags when creating containers and adding them to a pod (thoughpodman run --podhandles this implicitly). - Port Mapping: While containers within a pod can talk via
localhost, you’ll still map ports from the pod to the host if you need external access.podman run -p 8080:80 --pod my-app-pod ...maps host port 8080 to container port 80 within the pod’s network namespace.
When you add a container to an existing pod using podman run --pod <pod-name> ..., the container doesn’t just get added to a list. Podman configures the new container’s process to join the network namespace (and other specified namespaces like IPC) already established by the pod’s infra container. This means the new container inherits the IP address and port bindings of the pod, allowing direct localhost communication with other containers already within that same pod.
The next step in managing multi-container applications with Podman is exploring how to define these pod structures declaratively using YAML files, similar to Kubernetes’ Pod definitions, which leads to Podman Compose.