From LXC to Kubernetes: The Untold Evolution of Container Technology

Container History and Development

Before 2008 the concept of containers was already forming in the Linux kernel. LXC (Linux Containers) merged into the mainline in 2008, establishing the two fundamental mechanisms: cgroups for resource limitation and namespaces for isolation.

Cgroups: focus on limiting CPU, memory, and disk usage.

Namespace: focus on isolating the view of processes, ensuring containers do not affect each other or the host.

In 2009 Cloud Foundry built Warden on LXC, and in 2010 dotCloud created Docker, a Go‑based container engine built on LXC. Docker remained obscure until it was open‑sourced in 2013, popularized by the slogan “Build once, Run Anywhere”. This allowed developers to package an application and its dependencies into an image that runs identically across environments.

Docker quickly became the de‑facto standard, surpassing competitors such as CoreOS’s rkt and Google’s lmctfy. Its success hinged on Docker images that encapsulate applications and all required libraries, solving environment‑consistency problems and boosting productivity.

In 2014 Docker launched the Swarm container‑cloud product, expanding its ambitions. In 2015 the Linux Foundation created the Open Container Initiative (OCI) to define open standards for container formats and runtimes. Docker contributed its libcontainer (now runC) to the CNCF, and the OCI runtime implementation runC emerged.

Kubernetes, originally supporting Docker via the dockershim, later adopted the Container Runtime Interface (CRI). As the OCI‑compliant containerd runtime matured, Kubernetes deprecated dockershim in version 1.20, encouraging direct integration with containerd.

Docker contributed both containerd and runC. runC implements the OCI runtime, while containerd provides a higher‑level daemon that manages runC.

What Is a Container?

A container can be likened to a cup or a fish tank: it holds something—in this case, an application and all its dependencies. The host OS is the sea, Docker is the whale, and the container is the cargo hold where the application lives.

Container images are essentially compressed packages containing the executable and its required files.

Viewing Containers from the Host Perspective

Start a container:

docker run -d --name="aimar-1-container" euleros_arm:2.0SP8SPC306 /bin/sh -c "while true; do echo aimar-1-container; sleep 1; done"

This command creates a container named “aimar-1-container” from the specified image and runs a loop that prints a message every second.

Key options:

-d: run in detached (background) mode and return the container ID.

--name: assign a human‑readable name to the container.

docker run -d --name="aimar-1-container" euleros_arm:2.0SP8SPC306 /bin/sh -c "while true; do echo aimar-1-container; sleep 1; done"  
207b7c0cbd811791f7006cd56e17033eb430ec656f05b6cd172c77cf45ad093c

The long string is the container ID; a short prefix is sufficient for most commands.

From the host, the container appears as a regular process (e.g., PID 12280). Launching additional containers creates additional host processes.

Entering a Container

docker exec -it 207b7c0cbd81 /bin/bash

The -it flags allocate an interactive terminal, allowing direct interaction with the container’s shell.

Inside the container you can start new processes, which from the host’s view are still just processes.

[root@207b7c0cbd81]# /bin/sh -c "while true; do echo aimar-1-container-embed; sleep 1; done" &

Viewing Containers from Inside

Running ps inside a container shows only the processes that belong to that container’s PID namespace, typically the init process (PID 1) and any child processes you started.

From the host, those same processes have different PIDs (e.g., 12280 and 9775), demonstrating the isolation provided by PID namespaces.

Summary

A container is essentially an isolated process that runs on the host OS, with isolation achieved through Linux namespaces (especially PID namespaces). The container’s view of the system is limited to its own namespace, while the host sees it as a regular process.

Linux namespaces provide resource isolation; each namespace is represented as a file under /proc/[pid]/ns. Different containers have distinct PID namespaces, allowing them to have identical PID numbers (e.g., each container can have a PID 1).

Thus, containers are processes isolated from the rest of the system by Linux namespaces, implementing the OCI runtime standards.