Inside each container, you see a filesystem, network interfaces, disks and other resources that all appear to be unique to the container despite sharing the kernel with all the other processes o the system. The network interface on the actual machine, for example, is a single shared resource. But to your container it looks like it has the run of an entire network interface to itself. This is a really useful abstraction: It’s what makes your container feel like a machine all by itself. The way this is implemented in the kernel is with namespaces. Namespaces take a single global resource and make it appear as a single owned resource to the container.
Rather than just having a single namespace, however, container have a namespace on each of the six types of resources that are currently namespaced in the kernel: mounts, UTS, IPS, PID, network and user namespaces. Will see about that below. But essentially when you talk about a container, you are talking about number of different namespaces that docker sets up on your behalf. So, what do they all do???
Mount namespaces
Docker uses these primarily to make the container look like it has its entire own filesystem namespace. If you’ve ever used a chroot jail, this is its tougher cousin. It looks a lot like a chroot jail but goes all the way down to the kernel so that even mount and unmount system calls are namespaced. If you use docker exec or nsenter to get into a container, you’ll see a filesystem rooted on “/ “. but we know this isn’t the actual root partition of the system. It’s the mount namespaces that make that possible.
UTS namespaces
Named for the kernel structure the namespaces, ultimately from the “Unix time-sharing system,” UTS namespaced give your container its own hostname and domain name. This is also used by older systems like NIS to identify which domain a host belongs to. When you enter a container, and see a host name that is not the same as the machine on which it runs, it’s this namespace that makes that happen.
IPC namespaces
These isolate your container’s system V IPC and POSIX message queue system from those of the host. Some IPC mechanisms use filesystem resources like named pipes, and those are covers by the mount namespace. The IPC namespace covers things like shared memory and semaphores that aren’t filesystem resources but which really should not cross the container well.
PID namespaces
We already showed you that you can see all of the processes in containers in the Linux ps output on the host Docker server. But inside the container, processes have a totally different PID. This is the PID namespace in action. A process has a unique PID in each namespace to which it belongs. If you look in /proc inside a container, or run ps. You will only see the process inside the container’s PID namespace.
Network Namespaces
This is what allows your container to have its own network devices, ports, etc. When you run docker ps and see the bound posts for your container, you are seeing ports from both namespaces. Inside the container your nginx might be bound to port 80, but that’s on the namespace network interface. This namespace makes it possible to have what seems to be a completely separate network stack for your container.
User Namespaces
These provides isolation between the users and group IDs inside a container and those on the docker host. Earlier when we looked at ps output outside container and inside and saw different user’s ID. This is how it happened. A User inside a container is not a new user on the docker host’s main namespace and vice versa. There are some subtleties here, though. For example, root in a user namespace is not necessarily root on the main system. Some of this work is reasonably new to the Linux kernel and there are concerns about security leakage which we will talk about in a bit.
So namespace provides the visual, and in many cases functional, isolation that makes a container look like a virtual machine even though its in the same kernel.
To Explore more about Namespace Refer https://foxutech.com/how-to-enter-a-docker-container/
