Docker containers are very similar to LXC containers and provide similar security features. When using docker runstart a container in the background Docker create a separate name space and the control group a collection container.
The name space provides the most basic and most direct isolation, and the process running in the container will not be discovered and affected by the process running on the host and other containers.
Each container has its own unique network stack, which means that they cannot access the sockets or interfaces of other containers. However, if the corresponding settings are made on the host system, the container can interact with other containers just like interacting with the host. When you specify a public port or use links to connect two containers, the containers can communicate with each other (the communication strategy can be restricted according to the configuration).
From the perspective of network architecture, all containers communicate with each other through the bridge interface of the local host, just like physical machines communicate through physical switches.
So, is the code that implements the name space and private network in the kernel mature enough?
The kernel name space was introduced after version 2.6.15 (released in July 2008). Over the years, the reliability of these mechanisms has been verified in practice in many large-scale production systems.
In fact, the idea and design of the name space were proposed earlier, initially in order to introduce a mechanism in the kernel to realize the features of OpenVZ . The OpenVZ project was released as early as 2005, and its design and implementation are already very mature.