Linux Containers: what they are and why all modern software is packaged in containers
In today’s IT world, containers are far beyond the stage of buzzword – they are the foundation of how modern software is built, shipped, and operated. Whether you’re browsing your favorite app, processing transactions in a banking platform, or managing infrastructure in the cloud, there’s a very good chance that Linux containers are quietly doing the heavy lifting in the background.
But what exactly is a container? Why has this technology become central to cloud computing, system engineering, DevOps, and modern software architectures? And how do platforms like Kubernetes and solutions like our very own c12n leverage containers to unlock new levels of efficiency?
In this article, we’ll dive deep into the world of Linux containers and discover how they work, why they matter, and the role they play in modern infrastructures.
Let’s unpack the container magic 🪄
What is a Linux container?
A container is a standardized unit of software that packages up code along with all the dependencies it needs to run – libraries, binaries, dependencies, configuration files, and more – into an isolated environment. Imagine you’re moving into a new house. You could throw your stuff loose into the truck, or you could pack everything into labeled boxes, sealed and stackable. Containers are those boxes, but for software. It is a form of operating-system-level virtualization that allows you to run multiple isolated applications on a single Linux kernel.
Containers are smaller and faster than traditional virtual machines (VMs), because they do not require a full guest operating system (OS). Instead, containers run as isolated processes on top of the host OS. They share the host system’s Linux kernel while remaining fully sandboxed from other processes which makes them incredibly efficient, portable, and perfect for cloud-native workloads.
You might remember from our previous blog post about hypervisors that traditional virtualization adds an extra layer called a hypervisor, which manages virtual machines and can be either Type 1 (bare-metal) or Type 2 (hosted). Like virtualization, containers rely on an extra layer of software to manage isolation, however, instead of a hypervisor, they use Linux kernel features like namespaces (which provide process and network isolation) and Control Groups (aka cgroups, which control resource allocation like CPU and memory) to achieve lightweight, process-level isolation.
Together, these mechanisms create lightweight, fast-starting environments that can be deployed consistently across different infrastructures – whether on a developer’s laptop, a testing environment, or a production cluster in the cloud. It works even if kernel versions or Linux distributions are different. The developer could run Fedora, and the test or production environment could be using Ubuntu.
TL/DR
A Linux container is a lightweight, standalone unit that bundles:
- Your application
- All its dependencies (libraries, binaries, etc.)
And containers share the host OS Linux kernel to run stuff.
The result? You can run your app anywhere – from a developer’s laptop to a cloud data center – without the “but it worked on my machine!” headache.
Why Containers Matter
Before containers, software was often deployed in a “works on my machine” style. Developers would build applications on their local machines with specific libraries or configurations, only to see them break in staging or production environments due to slight discrepancies. A common example would be that a developer would have a newer version of a required library locally where production runs an older version, which is incompatible. So, things work, unit tests pass, but production breaks right after new deployment.
Containers solve this by making environments portable and predictable. A container runs the same, no matter where you launch it. That consistency accelerates development cycles, simplifies testing, and greatly reduces deployment risks.
Moreover, containers are incredibly lightweight compared to VMs. They consume fewer resources because they share the host OS kernel and don’t need to run their own kernel at all. They launch in seconds, and are easy to duplicate (clone), scale, or discard. This efficiency translates directly into reduced infrastructure costs and faster delivery pipelines.
So... how do Linux containers actually work?
Linux containers create isolated environments for applications to run in, without needing a full operating system for each app. This is achieved by combining several key features built into the Linux kernel.
1. Containers Use the Host’s Linux Kernel
Unlike virtual machines (VMs), which emulate hardware and run a separate OS, containers don’t need to bring their own operating system. They use the Linux kernel of the host machine but isolate everything else – filesystems, processes, networking, etc.
That’s what makes them fast and lightweight. You’re not booting up a whole OS for each container – you’re running isolated processes on the same kernel which has no idea that it runs in a container.
2. Linux Namespaces: the Illusion of Separation?
Containers rely on Linux namespaces to make them feel like self-contained environments.
Namespaces create isolated views of:
- Processes (PID namespace) – each container sees only its own processes with ids.
- File systems (Mount namespace) – eProvides an isolated view of the file system for each container.
- Networking (Net namespace) – containers can have their own virtual interfaces and IPs and are not aware of the underlying hardware NICs.
- Users (User namespace) – containers can map users differently from the host and have their own UIDs (user ids).
- IPC Namespace – Separates shared memory and message queues to prevent cross-container communication.
- Mount Namespace – UTS Namespace – Lets containers set their own hostname and domain name.
- Cgroup Namespace – Isolates access to cgroups, which control and limit system resource usage.
This feature gives containers the illusion that they’re completely running in their own separate OS, when in fact they’re sharing the host OS with 30 other containers.
3. Control Groups (cgroups): Resource Management
Namespaces isolate, where cgroups control.
Control groups are another Linux kernel feature that lets you limit and monitor the resources of the host. Cgroups control how much CPU, memory, disk I/O, and network bandwidth a process inside a container can use. This ensures one container doesn’t take over the entire system resources.
What is considered a resource:
- CPU time
- RAM
- Disk I/O
- Network bandwidth
So if one container tries to eat all your RAM during a memory leak, cgroups can limit the “blast radius” and kill the process when going over a configured RAM limit (e.g. 1Gb) without letting the whole host OS freeze if RAM runs out.
Such functionality is essential in multi-tenant environments, or when you’re running lots of containers side-by-side. You don’t want one container hogging all the resources and impairing neighbor containers or the host OS itself.
The image below shows how the host CPU and RAM hierarchy has two groups with their own tasks. Tasks refer to the processes that are members of a specific control group. In the below example that is crond with its fork in case of /cg1 group and httpd in case of /cg2 group. We can also see that the httpd process is a part of /cg3 group on the right. The net_cls hierarchy allows tagging network packets with a class identifier, allowing to identify and manage traffic originating from specific cgroups. This handy mechanism provides us a way to manage network traffic based on the cgroup the process belongs to.
4. Layered Storage
Containers typically use UnionFS (or OverlayFS), which stacks filesystem layers. This means they can share common filesystem layers (like the OS or libraries), while each container has its own read/write layer on top. This is essential as it allows sharing a base container image while providing each container with its own readable and (optionally) writable filesystem layer.
Here’s how it works:
- A base image (for example, ubuntu:22.04) forms the bottom layer
- Your app and its dependencies go on top of it in a new layer
- Any changes during runtime are stored in a separate write layer
- The write layer can be ephemeral and discarded automatically when container exits
- Or, the write layer can be persistent if the data has to survive container restart
Such a layer-based model is super efficient because:
- Base images can be shared between multiple containers
- Only the differences need to be saved
- Start-up times are fast as we don’t need to copy all data all over
That’s why when you first pull a container image from Docker Hub it might take a minute or two depending on your connection. But after, when you start another container with the same base image – it is already cached and started instantaneously! This saves space, makes containers faster to pull and deploy and allows to do version control via image tags.
5. Container Runtimes: the engine that runs the show
To create, run, and manage containers, you’ll need a container runtime installed.
Some of the popular container runtime examples:
- runc – the low-level container runtime (used by Podman, Docker, containerd, etc.)
- containerd – a higher-level runtime used by Kubernetes
- CRI-O – a lightweight alternative runtime optimized for Kubernetes
The runtime is the piece of software that actually uses Linux features (namespaces and cgroups) to spin up and manage containers under the hood. Sometimes, container runtimes are categorized as “high-level” and “low-level”, based on their abstraction and complexity levels. In a nutshell, high-level runtimes build upon low-level runtimes and they provide an easier API or additional features.
This way, a high-level containerd uses low-level runc as its container runtime. Runc provides the necessary functionality to create and manage containers according to the so-called Open Container Initiative (OCI) standards. In fact, one can use a low-level runtime directly to spawn and run containers, but this is rarely the case as using high-level runtime is much more convenient and user-friendly.
6. Images and Registries: Building Blocks of Containers
We already learned that a container image is a snapshot of everything your application needs: the code, libraries, environment variables, configuration files, etc. You can think of it as a blueprint or a read-only recipe for how to run your app. Now the image above mentions container registry. This is a home where container images live.
Some popular container registries today include:
Let’s imagine you have Docker as a popular high-level runtime installed on your system and you want to start an Nginx web server in a container. To do so, you’d execute docker run nginx docker run nginx. The runtime will pull the nginx image from the registry, create a container based on it, and start the nginx process inside:
$ docker run nginx
Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
8a628cdd7ccc: Downloading 20.9MB/28.23MB
b0c073cda91f: Downloading 31.55MB/44.15MB
e6557c42ebea: Download complete
ec74683520b9: Download complete
6c95adab80c5: Download complete
ad8a0171f43e: Download complete
32ef64864ec3: Download complete
Shortly after the image download is finished you’ll see Nginx running:
…
Digest: sha256:5ed8fcc66f4ed123c1b2560ed708dc148755b6e4cbd8b943fab094f2c6bfa91e
Status: Downloaded newer image for nginx:latest
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2025/04/22 12:06:02 [notice] 1#1: using the "epoll" event method
2025/04/22 12:06:02 [notice] 1#1: nginx/1.27.5
2025/04/22 12:06:02 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14)
2025/04/22 12:06:02 [notice] 1#1: OS: Linux 5.10.47-linuxkit
2025/04/22 12:06:02 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2025/04/22 12:06:02 [notice] 1#1: start worker processes
TL;DR
Linux containers work by:
-
- Sharing the host OS kernel
- Isolating each container using namespaces
- Managing resources with cgroups
- Using efficient layered file systems
- Running apps through a container runtime
- The runtime pulls container image from a registry (if it’s not cached locally) and spawns the container with its processes
All of this happens without launching a full virtual machine. The container launches in milliseconds, uses fewer resources, and is isolated from other system processes.
Containers in the Cloud
The rise of containers goes hand-in-hand with the evolution of cloud-native computing – a modern model where applications are designed to scale, recover, and evolve rapidly in distributed (cloud) environments. The ability to run isolated workloads in containers is a natural fit for cloud architectures, especially those embracing microservices.
In such systems, each application component – such as an authentication service, a billing engine, or a recommendation engine – can be deployed in its own container, communicating with others through well-defined REST APIs. This model fosters independent development, testing, and scaling of individual services.
At Cloudification, we see this pattern regularly in customer environments that aim to modernize legacy applications, break down monoliths, or build scalable software solutions. Containers are not just a development tool – today they became a foundational layer for a modern infrastructure. Containers changed the infrastructure game because they are:
- ⚡ Fast – Boot in milliseconds
- 📦 Portable – Run anywhere with a container runtime
- 🧪 Consistent – No more environment mismatch
- 🧩 Composable – Break big apps into smaller, reusable microservices
- 💪 Efficient – Use fewer resources than VMs
This makes them ideal for today’s cloud-native, microservice-based apps.
Orchestration with Kubernetes
Of course, managing a handful of containers is nothing special. How about managing hundreds or thousands of containers across multiple machines? That’s a different story. This is where Kubernetes comes in.
Kubernetes (often abbreviated as k8s) is an open-source container orchestration system for automating the deployment, scaling, and management of containerized applications. It handles everything from service discovery and load balancing to automated rollouts and resource scheduling.
Kubernetes ensures that your containers run reliably and remain healthy. If a container crashes, Kubernetes will restart it. If traffic increases, it can scale up your workloads. If you need to update your software, Kubernetes can roll out changes with minimal downtime. In short, Kubernetes is the operating system of the cloud-native world.
Kubernetes automates:
- Deployment
- Scaling
- Load balancing
- Self-healing and more
It’s like having a robot army managing your container infrastructure with high precision.
Learn more about Kubernetes and why we love it so much in our previous blog post here.
c12n: private cloud with container power ⚡
Our own solution, c12n, brings together the best of open-source tools — including OpenStack, Ceph, and Kubernetes – to deliver a secure, scalable private cloud tailored for modern workloads.
Containers are first-class citizens in c12n. Whether you’re deploying microservices, batch jobs, or hybrid workloads across edge and core locations, c12n provides the tools, visibility, and automation you need to make the most of containerized applications.
With container support built-in, c12n is perfect for:
- Cloud-native app hosting
- Private, hybrid and edge cloud deployments
- Companies looking to modernize their IT infrastructure
And yes, it runs containers like a charm! ✨
Closing Thoughts
Linux containers are the unsung heroes behind the scenes of today’s digital landscapes – powering your favorite apps, cloud platforms, search engines and even our c12n solution. They are lightweight, fast, and incredibly flexible.
Whether you’re just starting your container journey or planning your next cloud-native transformation, we’d love to talk. At Cloudification, we specialize in helping businesses modernize their infrastructure using open-source tools and scalable cloud architectures.
