摘要在云原生Cloud Native技术席卷全球的今天Docker、Kubernetes 等容器技术已经成为应用部署的标准范式。许多人将容器俗称为“轻量级虚拟机”但从 Linux 操作系统的底层视角来看容器并不是虚拟机它既没有独立的内核也没有虚拟的硬件层。容器的本质只是 Linux 内核中一个被隔离的普通进程。本文将深入拆解支撑容器技术的三大内核基石Namespace、Cgroups 以及 OverlayFS 联合文件系统。一、 视线的障眼法Linux Namespace 隔离机制虚拟机VM是通过 Hypervisor 技术虚拟出整套硬件并在其上运行一个完整的客户操作系统Guest OS。而容器则是直接共享宿主机的内核利用 Linux 内核提供的Namespace命名空间机制对进程的系统资源进行视图隔离。当一个进程被放入特定的 Namespace 后它所能看到的系统资源如进程列表、网络设备、文件挂载点等就会被局限在该 Namespace 内部从而产生了“独立操作系统”的错觉。Linux 内核目前主要提供了以下 8 种关键的 NamespaceNamespace 类型内核常量标识隔离的核心资源PID NamespaceCLONE_NEWPID进程编号。使得容器内的初始化进程拥有独立的 PID1。NET NamespaceCLONE_NEWNET网络设备、IP 路由表、防火墙规则iptables/nftables、端口。MNT NamespaceCLONE_NEWNS文件系统挂载点。使得容器拥有独立的目录树。IPC NamespaceCLONE_NEWIPC进程间通信资源如 System V IPC 和 POSIX 消息队列。UTS NamespaceCLONE_NEWUTS主机名与域名Hostname / Domainname。USER NamespaceCLONE_NEWUSER用户与用户组 ID。容器内的 root 用户在宿主机上只是普通用户。底层视角在 Linux C 语言编程中通过调用clone()系统调用并传入对应的CLONE_NEW*掩码标志系统就会创建一个全新的进程并为其分配独立的命名空间。容器的启动本质上就是这个系统调用的工程化封装。二、 资源的紧箍咒CgroupsControl Groups控制组Namespace 仅仅解决了“让进程只能看到什么”的问题隔离但并没有解决“进程能够使用多少资源”的问题限制。如果一个容器内的进程疯狂消耗 CPU 或发生内存泄漏将会直接导致宿主机及其他容器崩溃。为了打破这一局限Linux 内核引入了Cgroups控制组。Cgroups 的核心职责是限制、记录和隔离进程组所使用的物理资源如 CPU、内存、磁盘 I/O、网络带宽。1. Cgroups 的层级结构Cgroups 在 Linux 中是以虚拟文件系统的形式呈现的通常挂载在/sys/fs/cgroup/目录下。该目录下包含了多个子系统Subsystems/Controllerscpu子系统限制进程的 CPU 使用时间片通过cpu.cfs_quota_us和cpu.cfs_period_us调节。memory子系统限制进程的内存使用上限如memory.limit_in_bytes一旦进程超过该阈值就会触发OOM Killer将其直接终止。blkio子系统限制块设备的输入输出I/O速度及 IOPS。当你启动一个 Docker 容器并指定参数-m 512m --cpus2时Docker 引擎实际上就是在/sys/fs/cgroup/memory/docker/和/sys/fs/cgroup/cpu/docker/下创建一个以该容器 ID 命名的子目录然后将容器的进程 PID 写入该目录下的tasks文件中并通过配置文件向内核下达限额指令。三、 镜像的积木美学OverlayFS 联合文件系统既然容器共享宿主机的内核那为什么每个容器又可以拥有自己独立的 CentOS、Ubuntu 根文件系统rootfs和不同的软件依赖呢这归功于联合文件系统UnionFS在现代 Linux 中通常表现为OverlayFS。OverlayFS 允许将不同的目录层/Layers组合挂载到同一个视口下呈现出一个统一的文件系统结构。Docker 镜像的多层分层构建与“写时复制Copy-on-Write”正是基于此实现的。OverlayFS 主要分为以下四个核心层Lowerdir底层只读层。对应 Docker 镜像中的各个只读 Layer如基础操作系统、运行环境、依赖库。它们是不可变资产。Upperdir顶层可读写层Container Layer。当容器启动时整个镜像最上面会被盖上一层空白的可写层。所有在容器内部创建的新文件、修改的文件全部实际存储在 Upperdir 中。Mergedir合并层展示层。这是容器内部进程真正看到的统一视口。它是 Lowerdir 和 Upperdir 融合后的结果。Workdir工作层内核内部使用的临时中转层用于实现原子性的文件写入操作。核心机制写时复制Copy-on-Write当你在容器内部尝试修改一个来自于底层Lowerdir的只读文件例如/etc/hosts时内核拦截到写请求。内核触发Copy-up操作将该文件从只读的 Lowerdir 完整拷贝一份到可读写的 Upperdir 中。随后的修改操作全部作用在 Upperdir 的副本上。在合并层Mergedir中由于 Upperdir 的同名文件具有更高的优先级它会“遮挡”住底层原有的只读文件。这种机制确保了容器在不破坏公共镜像的前提下具备了独立的写操作能力。四、 总结容器技术不是黑魔法它并没有引入任何虚拟化硬件层而是巧用了 Linux 内核成熟的 Namespace 和 Cgroups 机制实现了进程层面的视图隔离与资源配额。OverlayFS 联合文件系统通过多层只读镜像与顶层可写层的组合配合写时复制CoW机制构建了容器镜像极速启动与极低空间占用的存储美学。深刻理解容器的底层原理能够帮助我们在面对容器性能调优如 CPU 节流/Throttling、K8s 容器排错如 OOMKilled以及容器安全边界防护时具备直击操作系统底层的技术直觉。
深度拆解:从 Linux 内核 Namespace 与 Cgroups 洞察容器技术的底层本质
发布时间:2026/5/31 1:55:27
摘要在云原生Cloud Native技术席卷全球的今天Docker、Kubernetes 等容器技术已经成为应用部署的标准范式。许多人将容器俗称为“轻量级虚拟机”但从 Linux 操作系统的底层视角来看容器并不是虚拟机它既没有独立的内核也没有虚拟的硬件层。容器的本质只是 Linux 内核中一个被隔离的普通进程。本文将深入拆解支撑容器技术的三大内核基石Namespace、Cgroups 以及 OverlayFS 联合文件系统。一、 视线的障眼法Linux Namespace 隔离机制虚拟机VM是通过 Hypervisor 技术虚拟出整套硬件并在其上运行一个完整的客户操作系统Guest OS。而容器则是直接共享宿主机的内核利用 Linux 内核提供的Namespace命名空间机制对进程的系统资源进行视图隔离。当一个进程被放入特定的 Namespace 后它所能看到的系统资源如进程列表、网络设备、文件挂载点等就会被局限在该 Namespace 内部从而产生了“独立操作系统”的错觉。Linux 内核目前主要提供了以下 8 种关键的 NamespaceNamespace 类型内核常量标识隔离的核心资源PID NamespaceCLONE_NEWPID进程编号。使得容器内的初始化进程拥有独立的 PID1。NET NamespaceCLONE_NEWNET网络设备、IP 路由表、防火墙规则iptables/nftables、端口。MNT NamespaceCLONE_NEWNS文件系统挂载点。使得容器拥有独立的目录树。IPC NamespaceCLONE_NEWIPC进程间通信资源如 System V IPC 和 POSIX 消息队列。UTS NamespaceCLONE_NEWUTS主机名与域名Hostname / Domainname。USER NamespaceCLONE_NEWUSER用户与用户组 ID。容器内的 root 用户在宿主机上只是普通用户。底层视角在 Linux C 语言编程中通过调用clone()系统调用并传入对应的CLONE_NEW*掩码标志系统就会创建一个全新的进程并为其分配独立的命名空间。容器的启动本质上就是这个系统调用的工程化封装。二、 资源的紧箍咒CgroupsControl Groups控制组Namespace 仅仅解决了“让进程只能看到什么”的问题隔离但并没有解决“进程能够使用多少资源”的问题限制。如果一个容器内的进程疯狂消耗 CPU 或发生内存泄漏将会直接导致宿主机及其他容器崩溃。为了打破这一局限Linux 内核引入了Cgroups控制组。Cgroups 的核心职责是限制、记录和隔离进程组所使用的物理资源如 CPU、内存、磁盘 I/O、网络带宽。1. Cgroups 的层级结构Cgroups 在 Linux 中是以虚拟文件系统的形式呈现的通常挂载在/sys/fs/cgroup/目录下。该目录下包含了多个子系统Subsystems/Controllerscpu子系统限制进程的 CPU 使用时间片通过cpu.cfs_quota_us和cpu.cfs_period_us调节。memory子系统限制进程的内存使用上限如memory.limit_in_bytes一旦进程超过该阈值就会触发OOM Killer将其直接终止。blkio子系统限制块设备的输入输出I/O速度及 IOPS。当你启动一个 Docker 容器并指定参数-m 512m --cpus2时Docker 引擎实际上就是在/sys/fs/cgroup/memory/docker/和/sys/fs/cgroup/cpu/docker/下创建一个以该容器 ID 命名的子目录然后将容器的进程 PID 写入该目录下的tasks文件中并通过配置文件向内核下达限额指令。三、 镜像的积木美学OverlayFS 联合文件系统既然容器共享宿主机的内核那为什么每个容器又可以拥有自己独立的 CentOS、Ubuntu 根文件系统rootfs和不同的软件依赖呢这归功于联合文件系统UnionFS在现代 Linux 中通常表现为OverlayFS。OverlayFS 允许将不同的目录层/Layers组合挂载到同一个视口下呈现出一个统一的文件系统结构。Docker 镜像的多层分层构建与“写时复制Copy-on-Write”正是基于此实现的。OverlayFS 主要分为以下四个核心层Lowerdir底层只读层。对应 Docker 镜像中的各个只读 Layer如基础操作系统、运行环境、依赖库。它们是不可变资产。Upperdir顶层可读写层Container Layer。当容器启动时整个镜像最上面会被盖上一层空白的可写层。所有在容器内部创建的新文件、修改的文件全部实际存储在 Upperdir 中。Mergedir合并层展示层。这是容器内部进程真正看到的统一视口。它是 Lowerdir 和 Upperdir 融合后的结果。Workdir工作层内核内部使用的临时中转层用于实现原子性的文件写入操作。核心机制写时复制Copy-on-Write当你在容器内部尝试修改一个来自于底层Lowerdir的只读文件例如/etc/hosts时内核拦截到写请求。内核触发Copy-up操作将该文件从只读的 Lowerdir 完整拷贝一份到可读写的 Upperdir 中。随后的修改操作全部作用在 Upperdir 的副本上。在合并层Mergedir中由于 Upperdir 的同名文件具有更高的优先级它会“遮挡”住底层原有的只读文件。这种机制确保了容器在不破坏公共镜像的前提下具备了独立的写操作能力。四、 总结容器技术不是黑魔法它并没有引入任何虚拟化硬件层而是巧用了 Linux 内核成熟的 Namespace 和 Cgroups 机制实现了进程层面的视图隔离与资源配额。OverlayFS 联合文件系统通过多层只读镜像与顶层可写层的组合配合写时复制CoW机制构建了容器镜像极速启动与极低空间占用的存储美学。深刻理解容器的底层原理能够帮助我们在面对容器性能调优如 CPU 节流/Throttling、K8s 容器排错如 OOMKilled以及容器安全边界防护时具备直击操作系统底层的技术直觉。