你有没有想过，为什么Docker能像魔法一样隔离进程？答案藏在Linux内核的Namespace和Cgroup这两个黑科技里，它们才是云原生时代的真正基石。
2013年，当Docker刚在GitHub上开源时，没人能预见它会彻底改写应用部署的规则。但正是那年，Namespace和Cgroup的组合拳，为容器技术埋下了革命的种子。
先说Namespace——这玩意儿本质上是Linux内核的"沙箱"机制。你可能用过chroot，但Namespace更狠。它能让一个进程看到完全不同的文件系统、网络栈、UTS名空间（hostname/域名），甚至PID命名空间（进程ID独立）。比如在容器里运行的nginx，它的PID是1，但实际可能运行在宿主机的12345进程里。这种"视而不见"的隔离能力，让容器像沙盒一样安全。
但光有隔离还不够，Cgroup才是控制资源的杀手锏。想象你给每个容器配发一个"资源腰带"，CPU、内存、磁盘IO都能精准管控。Kubernetes的Pod资源限制，本质就是Cgroup的高级封装。
有意思的是，这两个机制原本是为虚拟化设计的。Namespace解决"看起来像独立系统"的问题，Cgroup解决"行为上被限制"的问题。容器技术反过来让它们焕发新生，现在连云厂商都在用Cgroup实现更细粒度的QoS策略。
别急着写脚本，先看看你的系统有没有cgroup v2支持。用mount | grep cgroup确认，如果看到cgroup2，说明你正在用最新版的资源控制方案。
试试这个实战命令：
sudo mount -t cgroup2 none /sys/fs/cgroup
如果报错，说明你的内核版本可能太旧。
Namespace的实现其实很朴素，它不过是通过clone(2)系统调用，复制内核数据结构。但这种复制不是简单的内存拷贝，而是精心设计的引用计数。比如创建一个新PID命名空间时，内核会为进程表建立独立的视图，就像给每个容器都配了专属的进程身份证。
Cgroup的进化史更值得玩味。从最初的cgroups到现在的cgroup v2，API简化了70%以上。但别被表面的简洁骗了——它的资源控制逻辑依然复杂到让人头皮发麻。
说到底，Namespace和Cgroup就像Linux系统的"双子星"，一个负责隔离，一个负责限制。它们的组合，让容器技术从实验室走向生产，也迫使我们重新思考"系统资源"的定义。
你敢在生产环境直接操作cgroup的blkio控制器吗？
DevOps, Linux内核, Namespace, Cgroup, Shell脚本, 文件系统, CI/CD, IaC, Terraform, 云原生