From LXC to Kubernetes: The Evolution and Core Mechanics of Containers

Container History and Development

The concept of containers dates back to 2008 when LXC (Linux Container) was merged into the Linux kernel, establishing the fundamentals of cgroups and Linux namespaces. In 2009 Cloud Foundry built Warden on LXC, and in 2010 dotCloud created Docker using Go, initially struggling for adoption.

Docker was open‑sourced in 2013, quickly gaining popularity thanks to its "Build once, Run Anywhere" promise, which simplified packaging applications and their dependencies into images. Docker’s success led to the company’s rebranding and the displacement of competing runtimes like CoreOS’s rkt and Google’s lmctfy.

By 2014 Docker introduced Swarm, and in 2015 the Open Container Initiative (OCI) was formed under the Linux Foundation to standardize container formats and runtimes. Docker contributed its libcontainer module, which became the runC implementation of the OCI runtime specification.

Kubernetes, now the de‑facto standard for container orchestration, originally supported Docker via the dockershim layer. As the ecosystem matured, Kubernetes shifted to the CRI (Container Runtime Interface) and favoured runtimes such as containerd, reducing direct reliance on Docker while still supporting OCI‑compliant runtimes.

What Is a Container

A container can be thought of as a lightweight, isolated process that packages an application together with all its required libraries and files, similar to a fish tank holding fish (the app) and water (its dependencies). The container image is essentially a compressed bundle of these components.

From the host’s viewpoint, a running container is just a process with its own PID, cgroup limits, and namespace isolation. Example commands illustrate how to start a container, retrieve its ID, and inspect it:

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

The long hexadecimal string returned is the container ID; a shortened prefix can be used for subsequent commands. Using docker exec -it <container-id> /bin/bash opens an interactive shell inside the container, where processes appear with their own PID namespace (often PID 1).

Inside the container, ps shows only the processes that belong to that namespace, demonstrating complete isolation from host‑level processes and from other containers.

Summary

Containers are isolated processes that leverage Linux cgroups for resource limiting and namespaces for isolation, especially PID namespaces that give each container its own process ID space. The OCI standards (runC, containerd) provide a vendor‑neutral runtime layer, while Kubernetes orchestrates containers using the CRI, allowing any OCI‑compliant runtime to be swapped in.