What really keeps one container from seeing another?

Two Linux kernel features do the work: namespaces decide what a process can see, and cgroups decide how much it can use. Put simply, cgroups dictate how much of a system's resources a process can use, such as CPU, memory and disk I/O limits, while namespaces dictate what a process is allowed to see and interact with. Together they are the foundational technologies underpinning container platforms such as Docker, Kubernetes, LXC and Podman.

Namespaces partition the kernel's resources so that one set of processes sees one set of resources and another set sees different ones. The result is the illusion that a process is the sole user of the machine: it gets its own process IDs, hostname, user IDs, file names and network interfaces. The first process created in a new process-ID namespace is numbered 1. The host, though, sits in the initial namespace and can see every process in every container, just under different numbers.

cgroups, short for control groups, limit, account for and isolate the resource usage of a collection of processes. Groups can be set not to exceed a memory limit, an I/O bandwidth limit or a CPU quota, and they can measure a group's usage, for example for billing. They began at Google: engineers started the work in 2006 under the name "process containers", then renamed it in late 2007 to avoid confusion over the word "container". It was merged into Linux in January 2008.

So a container is a clever arrangement of limited views and limited budgets. It is not a perfect wall: even chroot, one of its ancestors, offers security that is not perfect.