From chroot to Kubernetes: The Evolution of Containerization

Recently I started working with containerization and compiled a collection of knowledge to share.

Stage 1: File Isolation – chroot Command

In 1979 Unix introduced a revolutionary command that locked a process’s root directory to a specific location, effectively limiting the file system scope the process could access. This command became the foundation of early container technology by providing basic file system isolation.

This isolation is crucial for security, allowing administrators to run and monitor suspicious code in a confined "black‑box" environment.

Stage 2: Isolation of Access – Linux Namespaces

In 2002 the Linux community added namespace support. Namespaces are lightweight virtualization techniques that give each process its own view of resources such as the file system, PID, UID, and network interfaces.

Changes made inside one namespace (e.g., file system modifications or network configuration) do not affect other namespaces, enabling multiple applications to run on the same physical server without interference.

In containerization, namespaces provide the key technology for container isolation, as a container is essentially a collection of different namespaces plus other resources.

Stage 3: Resource Isolation – cgroups

Control groups (cgroups) were proposed by Google engineers in 2006. They group processes and enforce resource limits such as CPU time, memory, network bandwidth, or disk I/O, preventing a single misbehaving process from exhausting system resources.

Thus, Linux cgroups are an indispensable part of modern container technology, offering core mechanisms for resource isolation and limitation.

Stage 4: System Packaging – LXC (Linux Containers)

LXC provides system‑level virtualization on Linux, allowing multiple isolated Linux system instances to run on the same host. Each container has its own file system, network configuration, and process space while sharing the host kernel, making it lightweight and efficient.

The LXC philosophy is to "package the entire system," meaning each container runs a full operating system with all services and processes.

However, LXC containers are relatively large and can be cumbersome to modify and maintain.

Stage 5: Application Packaging – Docker

Docker’s container capabilities originated from LXC, but Docker developers later created libcontainer in Go to reduce the dependency on LXC.

Docker’s core idea is to package applications. Containers contain only the minimal environment required to run a single application, making them lightweight and fast. Updating an application or its dependencies only requires rebuilding the relevant container.

Docker’s advantages over LXC include:

Cross‑machine "green" deployment: all environment dependencies are bundled together.

Automated builds: no need to manage target machine specifics.

Versioning similar to Git for containers.

Image reuse: build specialized images on top of base images.

Public image registries for sharing.

Extensible tooling ecosystem.

Docker’s focus on the application layer also introduces challenges: developers and operators must deeply understand application dependencies to ensure consistency and security across environments.

Stage 6: Cluster Orchestration – Kubernetes

Kubernetes (k8s) is a container orchestration framework that virtualizes the cluster environment, enabling cross‑data‑center deployment and automatic scaling.

An analogy: Kubernetes acts like a restaurant manager, coordinating the preparation and delivery of dishes (containers) based on demand, scaling up popular dishes and reallocating work when a stove (node) fails.

Technically, Kubernetes manages collections of containers, handling deployment, replacement of failed containers, service discovery, load balancing, scaling, and more.

Initially tightly coupled with Docker, Kubernetes now supports multiple runtimes via the Container Runtime Interface (CRI), such as CRI‑O and containerd, allowing it to focus on cluster‑level orchestration.

Stage 7: Cloud‑Native Container Services – CCE

Building a self‑managed Kubernetes cluster on‑premises incurs high cost, complexity, maintenance burden, and scaling difficulty.

With the rise of cloud computing, providers offer managed container services such as Huawei Cloud’s CCE (Cloud Container Engine). These services simplify management, enable rapid deployment (often within minutes), and provide automatic scaling.

Using cloud‑native container services allows developers to focus on building applications while the platform handles infrastructure concerns, and they can also support big‑data or AI workloads that require massive, elastic resources.

Conclusion

The containerization journey—from simple file isolation to cloud‑native orchestration—has profoundly impacted the IT industry, continuously responding to market demands. As technology advances, containerization will keep driving software innovation and the emergence of new applications.