Docker kernel namespace

Docker containers are similar to LXC containers and offer similar security features. When you start a container with docker run Docker creates a separate namespace and control group collection for the container in the background.

Namespaces provide the most basic and direct isolation, and processes running in containers are not discovered and acted upon by processes and other containers running on the host.

Each container has its own unique network stack, which means that they cannot access the sockets or interfaces of other containers. H owever, if the host system is set up accordingly, containers can interact with other containers as if they were hosts. When you specify a common port or use links to connect 2 containers, the containers can communicate with each other (policies that restrict communication based on configuration).

From a network architecture perspective, all containers communicate with each other through the bridge interface of the local host, just as physical machines communicate through physical switches.

So is the code in the kernel that implements namespace and private networks mature enough?

The kernel namespace was introduced after version 2.6.15 (released in July 2008) and the reliability of these mechanisms has been proven over the years in many large production systems.

In fact, the idea and design of the namespace were proposed earlier, initially to introduce a mechanism in the kernel to implement the features of OpenVZ. The OpenVZ project was released as early as 2005 and has matured in design and implementation.