cgroup（control group，控制组）管"你能用多少"，namespace（命名空间）管"你能看见什么"。这两样东西合起来，才是"容器"这个词的真正含义：容器不是一台小虚拟机，而是宿主机上一组被限了额、遮了视野的普通进程。
打个比方。宿主机是一栋写字楼，namespace 是给每个租户配的门牌、前台和电话簿——租户走进去，只看到自己的房间，以为整层归自己；cgroup 是物业装的电表水表和限额开关——用可以，超了就限流或断电。只有隔离没有限额，一个容器能把整机 CPU 吃干；只有限额没有隔离，容器之间能互看进程、互翻文件，误杀误删随时发生。
具体来说，namespace 常见的有几类：PID namespace 让容器里有自己的 1 号进程；mount namespace 让容器看到自己的一套文件系统挂载；network namespace 给容器独立网卡、IP 和路由表；UTS 隔离主机名；IPC 隔离进程间通信资源；user namespace 让容器里的 root 不等于宿主机的 root——这点是安全上的关键。cgroup 则负责 CPU 配额与权重、内存上限（超了触发 OOM）、块设备 IO 带宽、进程数上限、设备访问白名单等。不同内核版本与 cgroup v1/v2 的具体行为有差异，以官方文档为准。
| namespace | cgroup | |
|---|---|---|
| 管什么 | 看得见什么 | 能用多少 |
| 类比 | 门牌与窗帘 | 电表与限额 |
| 典型项 | PID、mount、network、UTS、IPC、user | CPU、memory、IO、pids、devices |
| 出问题的表现 | 进程、文件、网络互相可见甚至越权 | 一个容器拖垮整机，或被 OOM 杀掉 |
和虚拟机的区别在这儿：虚拟机靠 hypervisor 虚拟出一整套硬件，每台跑自己的内核，启动慢、开销大；容器共享宿主内核，启动是毫秒级、镜像小，但隔离强度天然弱于虚拟机。内核漏洞、共享内核带来的侧信道是真实风险，需要更强隔离时会用 gVisor、Kata Containers 这类折中方案。
对从业者的实际意义有三条。第一，Kubernetes 里的 requests/limits 落到地上就是 cgroup 参数，内存超过 limit 会被 OOMKilled，不是"变慢"，别把它当软限制。第二，容器里 nproc、free 看到的数字可能来自宿主机，因为它们读的是 /proc，未必反映 cgroup 限额，排查性能问题要看 cgroup 记的实际用量。第三，在容器里 ps 只看到本 PID namespace 的进程，宿主机上其实还有一堆兄弟进程——调试时别被"只有几个进程"骗了。
对普通人也一样：手机 App 沙箱、云上的函数计算、CI 里跑一次就销毁的环境，背后都是这套机制。记住一句话就够了——容器里的 root 不是真 root，容器的"独立"是借来的。