当我们在谈论容器时，常常会提到“轻量”、“快速”和“隔离”。容器的魔力在于，它能让一个应用进程觉得自己运行在一个独立的操作系统环境中，同时又不会像虚拟机那样带来沉重的性能开销。这种看似矛盾的特性，其实现并非魔法，而是深深植根于现代Linux内核的两项基础技术：Namespace和Cgroups。理解这两者，你就掌握了容器技术的灵魂。
从“沙箱”到“牢笼”：两种不同的隔离需求
很多团队在初期接触容器时，容易产生一个误解：认为容器通过某种单一技术实现了一个完美的“隔离环境”。实际上，容器的隔离性是由两种不同维度、解决不同问题的机制共同构建的。
- 视图隔离（Namespace）：目标是制造“幻觉”。它让容器内的进程只能看到一份经过裁剪的系统资源“视图”，比如独立的进程树、网络接口、主机名和文件系统挂载点。这解决了“你是谁、你在哪”的问题。
- 资源隔离（Cgroups）：目标是设定“边界”。它从物理上限制一组进程能够使用的CPU、内存、磁盘I/O等硬件资源的上限。这解决了“你能用多少”的问题。
一个常见的工程场景是：一个微服务被部署在容器中，它以为自己独占网络端口（Namespace的功劳），同时它疯狂的计算行为又被限制在指定的CPU核和内存大小内，不会拖垮宿主机上的其他服务（Cgroups的功劳）。两者缺一不可。
Namespace：为进程打造独立的“世界视图”
Namespace的本质是内核级的环境隔离。你可以把它想象成给进程戴上了一副特制的眼镜，这副眼镜过滤掉了宿主机上其他进程和资源，让容器进程只能看到属于自己的那部分。
Linux内核提供了多种类型的Namespace，每种负责隔离一种特定的全局系统资源：
| Namespace 类型 | 隔离内容 | 工程意义与常见场景 |
|---|---|---|
| PID | 进程ID | 容器内进程ID可以从1开始（如init进程），与宿主机PID独立。这简化了容器内进程管理，也避免了与宿主进程ID冲突。 |
| Mount | 文件系统挂载点 | 容器可以拥有独立的根文件系统（rootfs）视图。这是容器镜像（如Docker镜像）能够生效的基础，容器内的文件操作不会影响宿主。 |
| Network | 网络设备、协议栈、端口等 | 每个容器可以有自己的虚拟网卡、IP地址、路由表和防火墙规则。这是实现容器网络模型（如bridge、host）的底层支持。 |
| UTS | 主机名与域名 | 容器可以设置自己的hostname，这在微服务架构中用于服务标识非常有用。 |
| IPC | 进程间通信（信号量、消息队列等） | 防止容器内的进程通过共享内存等方式与宿主机或其他容器进程通信，提升安全性。 |
| User | 用户和用户组ID | 允许在容器内使用非特权用户（如root），而映射到宿主机上的一个普通用户。这是实现“非root用户运行容器”安全实践的关键。 |
在实践中，创建一个新容器，本质上就是通过clone()或unshare()等系统调用，为新进程申请一组上述Namespace。一个简单的命令行示例可以让我们窥见其原理：
# 使用 unshare 命令创建一个新的 PID 和 Mount namespace，并运行一个 shell
sudo unshare --pid --mount --fork /bin/bash
# 此时在这个新的bash中，'ps aux' 看到的进程列表将与宿主机不同
# 并且文件系统的挂载操作（mount）也仅在此namespace内生效这里隐藏着一个关键点：Namespace提供的是“视图”隔离，而非“能力”隔离。一个进程在容器内以root身份运行，它依然拥有root权限，只是这个权限的作用范围被限制在了当前的Namespace视图内。如果该进程利用内核漏洞逃逸出Namespace，它将看到真实的宿主机环境。这就是为什么需要结合SELinux、AppArmor等安全模块来加固容器。
Cgroups：为进程组划定资源“硬边界”
如果说Namespace是“软”隔离，那么Cgroups就是“硬”限制。它的全称是“Control Groups”，即控制组。其核心思想是将进程分组，并对整个组进行统一的资源分配和限制。
Cgroups通过一个虚拟文件系统（通常挂载在/sys/fs/cgroup）进行管理。其架构主要包括：
- 子系统（Subsystem）：负责具体资源控制的模块，如
cpu、memory、blkio（块设备I/O）。 - 层级结构（Hierarchy）：将子系统挂载到一棵Cgroup树（目录树）上，树上的每个节点（目录）就是一个控制组。
- 控制组（Cgroup）：树上的一个节点，包含一组进程和一组针对挂载子系统的参数设置。
一个常见的误区是认为Cgroups只能做“限制”。实际上，它同样可以用于“保障”和“统计”。例如，你可以为一个高优先级的服务保障最低的CPU份额，或者统计某个容器在一段时间内的内存使用总量。
下面是一个使用Cgroups手动限制进程CPU使用的例子：
# 1. 创建一个新的cgroup（在cpu子系统下）
sudo mkdir /sys/fs/cgroup/cpu/container_demo
# 2. 设置该cgroup的CPU配额：每100ms周期内，只能使用20ms的CPU时间（即20%的CPU）
echo 20000 > /sys/fs/cgroup/cpu/container_demo/cpu.cfs_quota_us
echo 100000 > /sys/fs/cgroup/cpu/container_demo/cpu.cfs_period_us
# 3. 将当前shell进程的PID加入这个cgroup
echo $$ > /sys/fs/cgroup/cpu/container_demo/tasks
# 4. 此时，在这个shell中运行任何CPU密集型任务，其CPU使用率都会被限制在20%左右Docker等容器运行时在启动容器时，会自动在对应的子系统下创建以容器ID命名的Cgroup，并根据用户指定的--cpus、--memory等参数写入这些控制文件，最后将容器主进程的PID加入tasks文件，从而完成资源限制。
资源限制的实战权衡
在实际生产环境中，为容器设置Cgroups限制并非简单地填几个数字。这里有几个容易踩坑的地方：
- 内存限制的“杀手”机制：当容器进程使用内存超过
memory.limit_in_bytes设置的限制时，Linux内核的OOM Killer可能会被触发，直接杀死容器内占用内存最多的进程。对于Java这类使用堆内存的应用，需要将限制值设置得比Xmx更大，以容纳堆外内存。 - CPU份额与核的区分：
cpu.cfs_quota_us和cpu.cfs_period_us配合可以实现硬上限，而cpu.shares则是在CPU资源紧张时，用于在多个容器间按比例分配剩余资源的相对权重。两者用途不同。 - I/O限制的复杂性：通过
blkio子系统限制磁盘读写带宽或IOPS相对复杂，需要指定具体设备号。在云原生环境中，更常见的做法是直接使用具备QoS能力的云盘或分布式存储。
Namespace与Cgroups如何协同工作
容器运行时（如containerd、runc）在启动一个容器的典型流程中，清晰地展示了两者的协同：
- 准备容器根文件系统（rootfs）。
- 创建一系列新的Namespace（通过
clone系统调用）。 - 在对应的Cgroup子系统目录下创建子目录，并写入资源限制参数。
- 在新的Namespace和Cgroup上下文中，启动容器初始化进程。
- 将容器进程的PID写入Cgroup的
tasks文件。
至此，这个进程既生活在一个被精心构造的、独立的系统视图（Namespace）中，又被关在了一个资源使用的牢笼（Cgroups）里。它以为自己是一台独立的服务器，实际上只是宿主机上一个被严格管控的普通进程。
总结：理解基础，方能驾驭复杂
Namespace和Cgroups是Linux内核提供的原语，它们本身并不等同于容器。Docker等容器技术是在此基础上，增加了镜像打包、分发、生命周期管理等上层建筑，从而形成了完整的容器生态。
对于开发者和运维人员而言，深入理解这两块基石的价值在于：
- 精准排障：当容器出现网络不通、文件访问错误或资源不足时，你能清晰地判断问题是出在Namespace的视图隔离上，还是Cgroups的资源限制上。
- 安全加固：明白默认配置的局限性，从而更有针对性地结合Seccomp、Capabilities等机制进行安全加固。
- 性能调优：能够根据应用特性，合理配置Cgroups参数，避免因限制不当导致的性能瓶颈或OOM崩溃。
- 技术选型：理解容器与虚拟机的根本区别（内核共享 vs 内核隔离），从而在架构设计时做出更合适的选择。
容器技术的优雅，正在于它最大程度地利用了操作系统已有的能力。下次当你运行docker run时，不妨想一想，背后正是Namespace和Cgroups在默默支撑着这个轻巧而强大的“沙箱”。
原创文章，作者：，如若转载，请注明出处：https://fczx.net/wiki/233