Shared PID, IPC, and volumes across Pod containers

Containers in a Pod share a sandbox that holds several Linux namespaces. The network namespace is always shared. The IPC namespace is shared by default. The PID namespace is per-container unless explicitly shared. Volumes are always available to declare at the Pod level. This lesson covers the sharing options and when each is the right choice.

The Linux namespace model

A Linux namespace is a kernel primitive that isolates a set of resources so that processes in different namespaces see different instances of those resources. Kubernetes uses namespaces extensively:

• Mount namespace: each container has its own; the Pod’s volumes are mounted into the container’s namespace.
• PID namespace: each container has its own by default; processes in container A don’t see processes in container B.
• Network namespace: shared across all containers in the Pod.
• IPC namespace: shared across all containers by default.
• UTS namespace: shared across all containers by default (the Pod’s hostname is the same for every container).
• User namespace: per-container (Linux 5.x); maps UIDs inside the container to UIDs on the host.
• Cgroup namespace: per-container.

The Pod’s sandbox holds the namespaces. Each container is started inside the sandbox via the CRI and inherits the namespaces the container is configured to inherit.

flowchart LR
    Sandbox --> MountA["Mount ns A"]
    Sandbox --> MountB["Mount ns B"]
    Sandbox --> Net["Network ns (shared)"]
    Sandbox --> IPC["IPC ns (shared)"]
    Sandbox --> UTS["UTS ns (shared)"]
    Sandbox --> PID1["PID ns A"]
    Sandbox --> PID2["PID ns B"]

The defaults:

shareProcessNamespace — sharing the PID namespace

spec:
  shareProcessNamespace: true

Setting this to true makes all containers in the Pod share the same PID namespace. Container A can see container B’s processes in ps, send signals, etc.

Use cases:

• A sidecar that monitors the main container’s processes (e.g., a process exporter that walks the process tree).
• A debug sidecar that needs to attach to the main container’s processes (rare; usually kubectl debug is better).
• Coordinated startup/shutdown where one container needs to signal the other.

kubectl exec web-7c8 -c sidecar -- ps aux
# sees processes from both containers

kubectl exec web-7c8 -c sidecar -- kill -TERM 1
# can send signals to processes in the main container

Risks:

• A bug in one container can kill another container’s processes. The signal goes to PID 1 in the namespace, which is the main container’s PID 1 by default.
• A compromised sidecar can read the main container’s environment (via /proc/<pid>/environ).

IPC namespace sharing

The IPC namespace is shared by default; there is no opt-in. Containers in a Pod can use System V IPC (semaphores, shared memory) and POSIX message queues to communicate.

// Container A creates a shared memory segment
shmget(key, size, IPC_CREAT);

// Container B attaches to the same segment
shmat(shmid, NULL, 0);

Use cases:

• High-performance shared memory between processes (rare in Kubernetes; usually a sign the workload should be in one container).
• Coordination via semaphores across containers.

In practice, IPC sharing is rarely the right choice for Kubernetes sidecars. Network namespace sharing covers most needs.

Shared volumes across containers

spec:
  containers:
  - name: app
    volumeMounts:
    - name: shared-data
      mountPath: /data
  - name: sidecar
    volumeMounts:
    - name: shared-data
      mountPath: /var/log/app
  volumes:
  - name: shared-data
    emptyDir: {}

Volumes declared in spec.volumes are mounted into any container that lists them in spec.containers[*].volumeMounts. The mount path can differ across containers, but the underlying volume is shared.

The standard pattern:

• Log sidecar: the main container writes logs to a shared emptyDir; a sidecar tails the log file and ships it to a log aggregator.
• Config hot-reload: a config sidecar watches a ConfigMap mounted as a volume and signals the main container on change.
• Cache warming: an init container pre-fills a shared emptyDir; the main container reads the cache at startup.
• Service mesh / proxy: a proxy sidecar reads the main container’s traffic (via shared network namespace) and writes access logs to a shared volume.

flowchart LR
    App[Main container] -->|"writes /var/log/app.log"| Vol["emptyDir /shared-data"]
    Vol -->|"reads via tail -f"| Side[Sidecar]
    Side --> Log[Log aggregator]

hostPID, hostIPC, hostUsers — escaping the sandbox

Three flags lift the Pod out of the sandbox isolation:

spec:
  hostPID: true
  hostIPC: true
  hostUsers: false  # 1.28+

• hostPID: true: the Pod shares the host’s PID namespace. The Pod can see all processes on the node.
• hostIPC: true: the Pod shares the host’s IPC namespace. The Pod can access System V IPC primitives of host processes.
• hostUsers: false (the default in 1.28+): the Pod’s containers run in a user namespace where the container’s root user maps to a non-root host user. Setting to true breaks this — the container’s root user is the host’s root.

Use cases:

• hostPID: process monitoring agents (e.g., node exporter) that need to walk the host’s process tree.
• hostIPC: rarely used; some database engines require it.
• hostUsers: false (default): every Pod. The mapping is what makes running as non-root in the container safe.

The sharing decision matrix

Production discipline: share only what the sidecar pattern needs. Most sidecars work over the network namespace alone; volume sharing for log shipping or config hot-reload; PID sharing for the rare process monitor.

Cross-course references

• The Linux course part I-Linux-Foundations covers Linux namespaces (man 7 namespaces); the Pod’s namespace sharing is the same primitive at the cluster level.
• The Docker course part XXXI-Docker-Networking covers container networking; Pod-level namespace sharing extends this to multi-container Pods.
• The Ansible course part XXXV-Ansible-Scripting covers process management discipline; PID sharing in Pods is the same idea.

Quiz

Production discipline

• Share only what the sidecar needs. Most sidecars work over localhost and shared volumes.
• Avoid shareProcessNamespace unless required. A compromised sidecar with shared PIDs can signal the main container or read its environment via /proc/<pid>/environ.
• Never use hostPID: true for application Pods. It is reserved for node agents that genuinely need host-wide process visibility.
• Use shared emptyDir for log shipping and config hot-reload. The standard sidecar pattern.
• Inspect the Pod spec for namespace sharing during security reviews. hostPID, hostIPC, hostUsers: true are red flags for application Pods.