Understanding Docker Containers: Namespaces, Control Groups, and UnionFS

With the rapid development of the Internet, cloud computing, cloud‑native architectures, and micro‑service patterns have become widely adopted; cloud‑native applications built on these technologies offer superior security, scalability, rapid iteration, and operational efficiency compared to traditional monolithic apps.

Docker, an open‑source container engine written in Go and launched in 2013, isolates applications using namespaces (process, network, filesystem, etc.) and control groups (CPU, memory, I/O, etc.), turning each container into a lightweight, stateless service.

# docker run -it -d centos 0245401a4fa0... # docker exec -it 0245401a4fa0 /bin/bash [root@0245401a4fa0 /]# ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 06:35 pts/0 00:00:00 /bin/bash ...

Namespaces achieve isolation by assigning each container its own PID namespace (via clone_newpid ) and other namespaces such as network, mount, and user, ensuring processes inside a container cannot see or affect those on the host.

Control Groups (cgroups) limit resource usage per container; each subsystem (cpu, memory, blkio, etc.) provides configuration files under /sys/fs/cgroup that define quotas, periods, and task assignments.

# cd /sys/fs/cgroup/cpu # mkdir container # echo 20000 > container/cpu.cfs_quota_us # echo > container/tasks

Docker images are built as layered UnionFS (AUFS, overlay2, etc.) stacks where each layer represents an incremental root filesystem; at runtime, these layers are merged into a single view for the container.

# docker images REPOSITORY TAG IMAGE ID CREATED SIZE apisix-gateway v1 ccee202f 3 days 560MB ...

Inspecting an image reveals its RootFS layers, each a read‑only snapshot that is combined with the writable top layer when a container starts.

Overall, Docker leverages Linux namespaces for isolation, cgroups for resource control, and UnionFS‑based layered images to provide a portable, efficient cloud‑native runtime environment.