命名空间和控制组是Linux容器技术的两大核心机制：命名空间实现进程视角隔离（如PID、网络、文件系统等七类隔离），控制组实现资源用量约束（如CPU、内存、IO限制），二者协同构成轻量、高效、可控的进程虚拟化基础。
命名空间和控制组是 Linux 进程虚拟化的两个底层支柱。它们不提供完整操作系统，而是让普通进程“感觉”自己独占系统资源——前者负责隔离视角，后者负责约束用量。理解它们，就抓住了容器轻量、高效、可控的本质。
Namespaces：给每个进程划出独立的“小世界”
Namespaces 不是创建新系统，而是为一组进程重新定义它所“看见”的系统资源范围。内核通过七种主要类型实现不同维度的隔离：
- PID namespace：容器里 PID=1 的进程，在宿主机上可能是 12847；子进程只看到本 namespace 内的进程树
- Network namespace：拥有独立的 lo 接口、IP 地址、端口、路由表和 netfilter 规则；跨 namespace 通信需显式配置 veth 对或 bridge
- Mount namespace：支持独立挂载/卸载文件系统，配合 chroot 或 pivot_root 实现根目录切换；容器镜像层正是靠它叠加呈现
-
UTS namespace：允许设置独立 hostname 和 domainname，比如运行
hostnamectl set-hostname myapp不影响宿主机 - User namespace：把容器内 UID 0（root）映射到宿主机非特权 UID（如 100000），大幅降低提权风险
- IPC namespace：隔离 System V 信号量、消息队列、共享内存等，避免不同应用间 IPC 冲突
- Cgroup namespace：让容器内看到的 cgroup 路径和资源视图仅限于自身，增强抽象一致性
Cgroups：为进程组装上资源“计量表”和“限流阀”
cgroups 不关心进程“看到什么”，只管它“能用多少”。它把进程组织成层级化分组（cgroup），在每个层级对资源施加硬性或软性限制：
-
CPU 控制：可用
cpu.max（cgroup v2）设定 CPU 时间配额，或用cpu.shares（v1）做权重分配；一个 2 核限制的容器，即使空闲也不会抢占其他容器的 CPU 周期 -
内存管控：设
memory.max可防止 OOM 杀死关键进程；配合memory.swap.max禁用交换，避免磁盘抖动 -
IO 限速：按设备（如
/dev/sda）限制读写 IOPS 或带宽，防止某个容器刷盘拖垮整机存储性能 -
进程数量限制：通过
pids.max防止 fork 炸弹类攻击，尤其在多租户环境中非常关键
协同工作：隔离 + 限流 = 安全可控的进程环境
单独使用 namespace，进程仍可能耗尽宿主机 CPU 或内存；只用 cgroup，则不同应用进程仍能看到彼此 PID、网络端口甚至用户 ID。二者必须配合：
- Docker 启动容器时，自动创建对应 PID、network、mount 等 namespace，并将该容器所有进程加入一个专属 cgroup 子树
- Kubernetes Pod 中的多个容器共享 network 和 UTS namespace（共用 IP 和 hostname），但各自有独立的 PID、mount 和 cgroup，实现“网络互通、资源分治”
- 调试时可用
nsenter -t <pid> -n ip a进入某进程的 network namespace 查看其网络配置；用cat /sys/fs/cgroup/memory/myapp/memory.usage_in_bytes查看内存实时用量
它们不是 Docker 专有技术，而是 Linux 内核原生能力。任何进程都可以通过 clone() 系统调用传入 CLONE_NEW* 标志启用 namespace，再通过写入 cgroup 文件系统来受控运行。这正是容器比虚拟机更贴近内核、更少开销的根本原因。
