Port bindings, cgroup-parent values, and kernel namespaces are all assigned to the “infra” container. Most of the attributes that make up the Pod are actually assigned to the "infra" container. The default infra container is based on the /pause image, Unless you explicitly say otherwise, all pods will have container based on the default image. This allows you to start and stop containers within the POD and the pod will stay running, where as if the primary container controlled the pod, this would not be possible. Its purpose is to hold the namespaces associated with the pod and allow podman to connect other containers to the pod. This container does nothing, but go to sleep.
Podman pods are similar to the Kubernetes definition.Įvery Podman pod includes an "infra" container. The Pod concept was introduced by Kubernetes.
Using a pod, you could bind to the localhost address of the pod and all containers in that pod will be able to connect to it because of the shared network name space. But you would prefer to not bind that database to a routable network either in your bridge or further. There are several good reasons to consider using pods locally, other than using pods to naturally group your containers.įor example, suppose you have multiple containers that require the use of a MariaDB container. Most people coming from the Docker world of running single containers do not envision the concept of running pods. And when they run containers in their development runtimes, they do not even think about the role pods could play-even in a localized runtime. People associate running pods with Kubernetes.
0 kommentar(er)
