在容器世界里，Namespace和Cgroup是左右进程隔离与资源控制的两大支柱，它们如何协同工作决定了系统的稳定与性能。
你有没有想过，为什么在Docker中运行一个简单的echo "Hello"命令，它居然能“隔绝”整个系统？这背后不是魔法，而是Linux内核的Namespace和Cgroup机制在默默起作用。我们今天就来扒一扒这两者的底层逻辑与真实应用。
一、Namespace：让进程“看”得见边界
Namespace 是Linux内核提供的一种虚拟化技术，它允许系统将资源（如PID、网络、IPC、UTS等）隔离到不同的命名空间中。简单来说，每个容器都像是一个独立的“宇宙”，它有自己的PID、网络接口、文件系统和用户空间。
你可能会问：为什么需要Namespace？
答案很直接：为了在同一个主机上运行多个独立的进程环境，而不互相干扰。比如，当你运行一个容器时，它看到的PID 1是它自己的init进程，而不是宿主机的systemd。这就是通过PID Namespace实现的。
但是，Namespace也不是万能的。比如，网络隔离和文件系统隔离就需要Network Namespace和Mount Namespace来配合。如果你在容器中挂载了宿主机的文件系统，那你就失去了真正的隔离——这在生产环境中是大忌。
二、Cgroup：让资源“看得见”边界
如果说 Namespace 是“隔离”，那么 Cgroup（Control Group） 就是“控制”。Cgroup 是Linux内核提供的一种资源限制机制，它可以限制容器的CPU、内存、磁盘I/O、网络带宽等资源使用。
你有没有遇到过这样的场景？一个容器耗尽了主机的内存，导致其他容器无法运行。这就是Cgroup的用武之地。通过将容器分配到特定的Cgroup，你可以精确控制它的资源配额，避免“野蛮生长”。
但Cgroup也有它的局限性。比如，它无法完全阻止容器对系统资源的过度使用，尤其是在CPU和磁盘I/O方面。这时候，你可能需要配合其他机制，比如Linux的内存限制或者使用cgroups v2来获得更精细的控制。
三、Namespace与Cgroup的协同作战
Namespace 和 Cgroup 并不是孤立的，而是相互配合的。Namespace 提供“隔离”，Cgroup 提供“控制”，两者结合才能真正实现容器的“沙盒化”。
举个例子：你使用docker run创建一个容器时，Docker会同时创建一个PID Namespace和一个Cgroup。这样，这个容器的进程就完全隔离在自己的宇宙里，同时它的资源使用也被严格限制。
不过，你也可以手动管理它们。比如，使用unshare命令可以创建一个独立的Namespace，而使用cgcreate、cgset等工具可以手动配置Cgroup。这在某些自定义容器环境中非常有用。
四、实战：如何查看容器的Namespace和Cgroup？
查看 Namespace
我们可以使用ls命令查看当前进程的 Namespace：
ls /proc/self/ns
输出可能包括：
uts
ipc
pid
net
mnt
cgroup
这些就是各种 Namespace 的入口点。你可以通过readlink命令查看具体的 Namespace：
readlink /proc/self/ns/uts
这会返回该 Namespace 的ID，比如/proc/1/ns/uts。
查看 Cgroup
Cgroup 的信息存储在/proc/<pid>/cgroup中。比如，查看当前进程的 Cgroup 信息：
cat /proc/self/cgroup
输出可能类似于：
12:cpu,cpuacct,cpuset /user.slice/user-1000.slice/session-1000.scope
11:hugetlb /user.slice/user-1000.slice/session-1000.scope
10:blkio /user.slice/user-1000.slice/session-1000.scope
9:perf_event /user.slice/user-1000.slice/session-1000.scope
8:memory /user.slice/user-1000.slice/session-1000.scope
7:freezer /user.slice/user-1000.slice/session-1000.scope
6:devices /user.slice/user-1000.slice/session-1000.scope
5:net_cls,net_prio /user.slice/user-1000.slice/session-1000.scope
4:pid /user.slice/user-1000.slice/session-1000.scope
3:ipc /user.slice/user-1000.slice/session-1000.scope
2:mount /user.slice/user-1000.slice/session-1000.scope
1:cpuset /user.slice/user-1000.slice/session-1000.scope
每行代表一个子系统（如cpu、memory、blkio等），而路径表示该进程所在的 Cgroup。
五、Namespace与Cgroup的“边界”之争
你有没有想过，Namespace和Cgroup是否真的完全隔离？
答案是：并不完全。比如，在某些情况下，一个容器可能仍然能访问宿主机的全局资源。这时候，你可能需要进一步配置，比如使用Cgroup v2，它提供了更统一的资源控制机制。
另外，某些高级特性，比如network namespace的配置，需要配合Cgroup才能实现真正的资源隔离。例如，在Kubernetes中，每个Pod都会被分配到一个独立的Network Namespace，同时也会被限制在特定的Cgroup中。
六、内核版本与Cgroup支持
Cgroup v1 和 Cgroup v2 是Linux内核中两种不同的资源控制模型。Cgroup v2 是较新的版本，支持更全面的资源控制，但并不是所有Linux发行版都默认支持。
比如，在Ubuntu 20.04中，默认使用的是 Cgroup v1，而在Ubuntu 22.04及以上版本中，默认已经切换到 Cgroup v2。如果你在使用老版本的内核，可能需要手动配置。
你可以通过以下命令查看当前内核是否支持 Cgroup v2：
grep -E 'cgroup2' /proc/self/mountinfo
如果输出中包含cgroup2，说明你的系统支持它。
七、你的系统是否“够硬”？
你有没有想过，这些机制是否会影响系统的性能？
答案是：会，但影响程度取决于你的使用场景。比如，在高并发、高负载的生产环境中，合理配置Namespace和Cgroup可以显著提升系统的稳定性与安全性。
但如果你只是在本地开发环境中测试容器，那这些机制可能显得“多余”。这时候，你可以选择关闭某些隔离机制，来简化调试过程。
八、我的建议：用好Namespace，别怕Cgroup
Namespace 是隔离，Cgroup 是控制。两者结合，才能真正实现容器的“沙盒化”。
别想着绕过它们，这只会让你陷入更深层的麻烦。用好它们，你才能真正掌控容器的边界。
九、你也可以玩得更“野”一点
比如，你可以用unshare命令创建一个独立的Namespace，并结合cgcreate手动配置Cgroup。这在自定义容器环境中非常有用，比如在Kubernetes或Docker之外的场景。
举个例子，创建一个独立的PID Namespace：
unshare --pid --fork --mount-probind /bin/bash
这会启动一个独立的PID Namespace，同时挂载宿主机的文件系统，并进入一个新的bash会话。你可以在这个会话中运行程序，而它们将看不到宿主机的PID 1（比如systemd）。
十、最后，一个开放性问题
你有没有在某个场景下，因为Namespace或Cgroup的配置不当，导致容器无法正常运行？
欢迎在评论区分享你的经验，我也会随时更新我的“踩坑指南”！
关键字：Linux, Namespace, Cgroup, 容器, 进程隔离, 资源控制, DevOps, Docker, 脚本, 内核, 虚拟化, 云计算