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 until the publication of a service into an Orchestration Platform. The general idea is to detail as much as possible (without being massive) about how things are working under the hood.

In this 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 basically process running into Bastion. This image helps to illustrate this explanation:

Containers vs VMs

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 namespaces. 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.

#linux #kubernetes #serverless #container #cloud native #kernel

The Anatomy of a Container: The Kernel
1.25 GEEK