Welcome to this tutorial series, where we will evolve from the anatomy of a container inside the Linux Kernel, and will keep building pieces and evolving till the publication of a service into an Orchestration Platform. The general idea is to detail as much as possible (without being massive) how is things working under the hood. In this very first article, we will start to understand what is a container, to create the proper mindset when working with it. This is important for troubleshooting and architecture principles, where you need to understand well how something works, and in this context, container. It's always a good idea to remember how the evolution of virtualization came into the business. In virtualization (Generally speaking), we have an Operational System (Let's use a common word to describe this one, Bastion) that operates the hardware directly, and exposes the hardware to its virtual machines, that are basically processes running into Bastion. This image helps to illustrate this explanation: This exposure enables these processes, virtual machines, to operate the hardware in different ways (bypassing instructions and so on),  so virtual machines can do the work. The Virtual Machines perspective comes from the Bastion vision, each process by itself has an Operational System to run their applications, and this is what we call full virtualization. When we talk about containers, the general idea is the same: Process that runs in Bastion, but with a big difference: The Bastion doesn't expose the underlying hardware and the process doesn't need another Operational System on top of it to runs it's applications. This is done using a very ancient and rock-stable kernel feature called . The namespaces are an abstraction layer that runs inside kernel space and exposes the kernel subsystems by separating their runtime, the namespaces expose vital kernel functions to processes "pretending" they are running in their own kernel, but they are all sharing the same kernel in the underlying host. namespaces During the write of this article, we have 6 kernel namespaces, each exposing they own kernel subsystem: IPC ( Inter Process communication) - Introduced in kernel 2.6.19, Isolate the communication of certain System V IPC objects and since 2.6.30 POSIX queues messages; Network - Introduced in Kernel 2.6.24 and finished in 2.6.29, Isolate the logical resources used to network communication, like network interfaces, routing tables, IP address and so; Mount - Introduced in kernel  2.6.19, Isolate the mount point seen by the process.PID - ( Process identifier ) - Introduced in kernel 2.6.24, Isolates the Process identified space. It means inside the namespace, each process can have their own process number without conflicting with bastion PID Namespace. PID namespace can be migrated to different Bastion while maintaining the same PID's; User - Introduced in kernel 2.6.23 and completed in 3.8, Isolate the users and groups ID space, in other words, it means the user and group ID inside the container can be different from the same user and group in Bastion UTS - Introduced in kernel 2.6.19, Isolate the host global identifiers and , returned by syscall. In the context of containers, it allows each container to have it's own hostname and domain nodename domainname uname() Basically, when we create a container, the container engine talks with kernel namespaces asking for a new "table" in each namespace where this container will run. To Bastion, it looks like a very simple process, to process, it looks like a brand new dedicated OS, but it's not. And this is the main difference from virtual machines, they are more light, fast and generally quick than a Virtual Machine, this is why we can spin containers in less than a second and the disk space is very reduced when compared to a virtual machine. Doing some hands-on, is possible to understand this theory: If we run in any Linux system this command, you will be able to check-in each namespaces, a given process runs: ipc -> mnt -> net -> pid -> pid_for_children -> user -> uts -> # ls -lai /proc/1/ns 'ipc:[4026531839]' 'mnt:[4026531840]' 'net:[4026531992]' 'pid:[4026531836]' 'pid:[4026531836]' 'user:[4026531837]' 'uts:[4026531838]' Inside the virtual filesystem, lives the runtime of Kernel. During the boot process, the very first process that boots is the init system used by Kernel. In Enterprise Linux 6 was the System V and for Enterprise Linux 7 and above, Systemd. Systemd is responsible for initiate the other boot time processes and setup the baseline to kernel space and user space interact. The namespaces used by Init System /proc When we run command with option, we are requesting the number of each file (Remember, everything inside Linux is a file !) that represents a different namespace. If  this same in a different process returns different number, that means this given process is running in a different namespace (What happens with containers): ls -i inode ls inode 565a6681bf8c [...Output Ommited...] ecstatic_nightingale 10494, /ecstatic_nightingale 10494 cgroup -> ipc -> mnt -> net -> pid -> pid_for_children -> user -> uts -> # docker container ps # docker container inspect --format '{{.State.Pid}}, {{.Name}}' ecstatic_nightingale # ls /proc | grep -i 10494 # ls -lai /proc/10494/ns/ 'cgroup:[4026531835]' 'ipc:[4026532611]' 'mnt:[4026532609]' 'net:[4026532614]' 'pid:[4026532612]' 'pid:[4026532612]' 'user:[4026531837]' 'uts:[4026532610]' Namespaces used by a container process Above, I've got the docker container PID using a filter based in container name, then I've checked for namespaces used by that container. Conclusion: To Bastion, a container is a simple process attached to different namespaces. Inside the container, we can operate everything (within its limitation) as a very different host, but lightweight and secure. In the next article, we will start our very first container and will lookup for points we learned in this one. About the author - Sudip is a Solution Architect with more than 15 years of working experience and likes sharing his knowledge by regularly writing for Hackernoon , DZone , Appfleet and many more. And while he is not doing that, he must be fishing or playing chess. Previously posted at https://appfleet.com/ .

Different

Keep

How To Manage Infrastructure With Terraform

The Container Anatomy: A Kernel Introduction

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

14 Steps to Debugging a Node.js Application Running in a Docker Container

10 VSCode Extensions To Make Your Life Easier

10 Ways Stand Out as a Java Developer and Land that Dream Job

10 Tips For Junior Developers To Succeed in Code

10 Things Every Beginner Should Know When Learning Javascript And React

14 Steps to Debugging a Node.js Application Running in a Docker Container

10 VSCode Extensions To Make Your Life Easier

10 Ways Stand Out as a Java Developer and Land that Dream Job

10 Tips For Junior Developers To Succeed in Code

10 Things Every Beginner Should Know When Learning Javascript And React

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps