Linux 服务器资源隔离依靠 cgroups v2 与命名空间协同实现：cgroups 限制 CPU、内存等资源，命名空间提供 PID、网络、挂载等视图隔离，二者结合构成容器底层核心；可手动创建控制组、启用命名空间并组合使用构建轻量隔离环境。
Linux 服务器资源隔离主要靠 cgroups（控制组）和命名空间（namespaces）两大机制配合实现：cgroups 负责限制、统计、隔离进程组的资源使用（CPU、内存、IO 等），命名空间则提供视图隔离（如 PID、网络、挂载点等），让进程“看不见”其他进程或系统资源。两者结合，就是容器底层最核心的隔离基础。
用 cgroups v2 统一管理 CPU 和内存资源
cgroups v2 已取代 v1 成为主流，支持层级化、统一接口和更精细的资源控制。启用前需确认内核支持（5.0+ 默认开启）并挂载 cgroup2 文件系统：
mount -t cgroup2 none /sys/fs/cgroup
创建一个名为 webapp 的控制组，限制其最多使用 2 个 CPU 核心（以 CPU 配额方式）和 1GB 内存：
mkdir /sys/fs/cgroup/webapp
echo “200000 100000” > /sys/fs/cgroup/webapp/cpu.max # 200ms/100ms 周期，即 2 核等效
echo “1073741824” > /sys/fs/cgroup/webapp/memory.max
把某个进程（如 PID 1234）加入该组：
echo 1234 > /sys/fs/cgroup/webapp/cgroup.procs
后续启动的子进程自动继承该限制。也可用 systemd 定义。slice 单位实现持久化配置，适合服务级隔离。
用命名空间隔离进程视角（PID、网络、挂载）
命名空间不直接限制资源，而是让进程拥有独立的系统视图。常用组合包括：
- PID namespace：进程在内部看到自己是 PID 1，无法看到宿主机其他进程
- Network namespace：独立网卡、IP、路由 表、iptables 规则
- MNT namespace：独立挂载点，可 chroot 或 bind mount 定制根文件系统
手动创建带 PID+ 网络隔离的命名空间示例：
unshare –pid –net –fork –mount-proc /bin/bash
进入后执行 ip link 会发现只有 lo；用 nsenter 可跨命名空间调试，比如用宿主机网络命名空间查容器内进程网络连接：
nsenter -t $PID -n ss -tuln
组合使用：运行一个轻量隔离环境（无 Docker）
不依赖容器引擎，也能用 cgroups + 命名空间搭出最小隔离环境。步骤如下：
- 创建 cgroup v2 路径并设好 CPU/ 内存上限
- 用 unshare 启动新命名空间（含 pid、net、mnt、uts）
- 在新命名空间中执行 mount –make-rslave / 避免挂载传播影响宿主机
- 用 pivot_root 或chroot切换到精简根目录（如 Alpine 的 tar解压 目录）
- 将当前 shell PID 写入 cgroup.procs 完成资源绑定
这样就获得了一个有独立进程树、网络 栈、文件系统视图，且受 CPU/ 内存硬限制的轻量运行环境——本质就是 Docker run 的简化版实现逻辑。
监控与排错关键命令
隔离生效后，及时验证是否按预期工作：
- cat /sys/fs/cgroup/webapp/cpu.stat 查看 CPU 节流次数（throttled_time > 0 说明被限频）
- cat /sys/fs/cgroup/webapp/memory.current 实时 内存占用，对比 memory.max 判断是否触发 OOM
- ls -l /proc/$PID/ns/ 看进程所属哪些命名空间（inode号相同表示共享同一 namespace）
- ps –no-headers -o pid,comm,cgroup $PID 快速查看进程归属的 cgroup 路径
常见问题 ：进程未被限制？检查是否写入cgroup.procs 而非 cgroup.threads；网络不通？确认 netns 内已配置 IP 并启用 lo；OOM 被杀？查dmesg | grep -i “out of memory” 定位触发进程。
