From Chroot to Kubernetes: How Container Technology Evolved Over 20 Years

Container technology is a generic concept, not tied to a specific product. The rise of Docker popularized containers, but many other solutions exist such as rkt, LXC, and Podman.

Before Docker, container concepts already existed. The development timeline can be visualized with the following image:

1979 – Unix V7 adds chroot for isolated filesystem views. 1999 – FreeBSD 4.0 introduces jail , the first commercial OS virtualization. 2004 – Solaris 10 supports Solaris Zones. 2005 – OpenVZ released, an early Linux OS virtualization. 2004‑2007 – Google internally uses cgroups and OS virtualization. 2006 – Google open‑sources its process container system, later renamed cgroup. 2008 – cgroups merged into the Linux kernel; LXC prototype appears. 2011 – CloudFoundry develops Warden, an early container manager. 2013 – Google releases LMCTFY; Docker project launched, spreading Linux containers. 2014 – Kubernetes released, advancing container orchestration. 2015 – CNCF founded, starting the cloud‑native wave. 2016‑2017 – Container ecosystem becomes modular and standardized; OCI specifications released. 2017‑2018 – Container services commercialized (ECS, EKS, ACK, etc.). 2017‑2019 – Rapid engine development (Kata Containers, gVisor, Firecracker, Alibaba Sandbox). 2020‑present – Continued engine upgrades (Kata 2.0, Sandbox 2.0).

The development can be divided into four stages:

Technical Embryonic Phase

Starting with Unix V7 chroot, the focus was on solving resource isolation. Isolation types include language runtime, process, OS virtualization, hardware virtualization, and hardware partitioning.

Language runtime isolation : Java, Node.js, etc., often still use containers or VMs.

Process isolation : OS provides separate address space and CPU context, but shares filesystem, network, IPC.

OS virtualization : Uses namespaces and cgroups for independent views, access control, and security.

Hardware virtualization : Full VM isolation with hypervisors, offering strong security at the cost of overhead.

Hardware partitioning : Traditional mainframe approach, high security but low flexibility.

Technical Burst Phase

Docker introduced the revolutionary container image concept, packaging code, dependencies, tools, and metadata into an immutable artifact. This enabled "build once, run anywhere" and spurred the creation of orchestration platforms like Kubernetes.

Key milestones:

2013 – Docker released, popularizing Linux containers.

2014 – Kubernetes released, becoming the de‑facto orchestration standard.

2015 – Docker helped form OCI, defining image and runtime specifications.

2015 – CNCF founded to promote cloud‑native computing.

Commercial Exploration Phase

From 2017, major cloud providers offered container services, categorized as:

General container orchestration services (AWS, Azure, Alibaba, etc.).

Kubernetes‑based services (Google GKE, AWS EKS, Alibaba ACK, etc.).

Serverless container instances (Google Cloud Run, etc.).

Key observations:

High adoption of containerization.

Kubernetes dominates orchestration.

Serverless containers gain market traction.

Both managed orchestration and serverless will coexist.

Commercial Expansion Phase

Two architectural models emerged:

Container on VM : IaaS + PaaS stack, lifting‑and‑shifting containers onto VMs.

Container with hardware virtualization : Direct container execution on bare metal for performance, isolation, security, and cost.

Docker Overview

Docker builds on Linux cgroups, namespaces, and UnionFS. It provides a daemon ( dockerd) that exposes high‑level APIs, a containerd service for low‑level container management, and runc for OCI‑compliant runtime execution.

Dockerd : User‑facing daemon.

Containerd : gRPC API, monitoring, multi‑tenant support.

RunC : Implements OCI runtime.

Containerd‑shim : Handles signal forwarding to containers.

Linux Namespaces

Namespaces provide isolation for resources. Types include:

cgroup (CLONE_NEWCGROUP)

ipc (CLONE_NEWIPC)

network (CLONE_NEWNET)

mount (CLONE_NEWNS)

pid (CLONE_NEWPID)

time (CLONE_NEWTIME)

user (CLONE_NEWUSER)

Each namespace isolates specific aspects such as process IDs, network stacks, filesystems, and user IDs.

Cgroups

Cgroups limit physical resources like CPU and memory. Important files include cpu.shares (soft limit), cpu.cfs_quota_us and cpu.cfs_period_us (hard limits), and memory control files such as memory.limit_in_bytes.

UnionFS and OverlayFS

Docker uses OverlayFS (a UnionFS implementation) to build layered images. Lower layers are read‑only; the upper layer records changes via copy‑on‑write, enabling efficient image construction and container read‑write layers.

Docker Common Commands

Typical client commands include docker build, docker run, docker ps, docker exec, docker logs, and docker push. Best practices involve minimizing build context, leveraging cache, reducing image size, and using multi‑stage builds.

Containerd

Containerd is a lightweight runtime extracted from Docker, used by Kubernetes as a CRI. It manages image lifecycle and container execution with commands like crictl images, crictl runp, and crictl exec.

Conclusion

Docker played a pivotal role in the cloud‑native era, offering immutable images, rapid startup, and environment consistency. However, its reliance on shared host kernels limits isolation, and emerging runtimes are reducing Docker’s dominance in modern orchestration stacks.

References

https://developer.aliyun.com/article/775778

https://blog.csdn.net/crazymakercircle/article/details/120747767

https://github.com/krallin/tini