✦ For everyone, free.

Practical knowledge for real and everyday life

Home

2.2.2.3 Runc Namespace Setup

A focused guide to Runc Namespace Setup, connecting core concepts with practical Docker and container operations.

Runc namespace setup is the part of container creation where runc requests the Linux kernel create a distinct set of namespaces for the container, each isolating a particular kind of system resource so the container has its own private view of it.

What Namespaces Isolate

Linux provides several kinds of namespaces, and a typical container uses most of them together: a PID namespace gives the container its own process numbering starting from 1, a network namespace gives it its own network interfaces and routing table, a mount namespace gives it its own filesystem mount points, and a UTS namespace gives it its own hostname.

{
  "linux": {
    "namespaces": [
      { "type": "pid" },
      { "type": "network" },
      { "type": "mount" },
      { "type": "uts" }
    ]
  }
}

This section of an OCI runtime configuration tells runc exactly which namespaces to create for the container.

Observing Namespace Isolation From Inside

Once these namespaces are active, a process inside the container observes a system that looks substantially different from the host, even though it is running on the same kernel.

docker run --rm alpine hostname
docker run --rm alpine ps aux

The hostname and process list reported here belong entirely to the container's own UTS and PID namespaces, distinct from the host's.

Namespaces Are Created, Not Simulated

It is worth emphasizing that namespace isolation is a real kernel feature, not something runc or Docker simulate in software — the kernel itself maintains separate process trees, network configurations, and mount tables per namespace, which is what gives container isolation its actual enforcement, rather than being a convention that well-behaved software follows.

ls -la /proc/self/ns/

Run on the host versus inside a container, this reveals distinct namespace identifiers, confirming that the isolation is backed by genuinely separate kernel-tracked namespace objects.

Sharing Namespaces Deliberately

Namespaces can also be deliberately shared between containers when needed — for example, two containers can share a network namespace so they appear to have the same network interfaces, which is the underlying mechanism behind a "pod" of containers in Kubernetes.

docker run -d --name app1 --network container:app2 myapp:1.0
Why Namespace Setup Is Foundational

Namespace setup is the single most fundamental mechanism behind container isolation; nearly every other isolation property a container has — its process list, its network identity, its filesystem view — ultimately traces back to which namespaces were created for it at this stage.