Linux容器资源隔离效果取决于cgroup v2层级结构、CPU与NUMA绑定、内存防碎片与OOM误杀、网络存储协同隔离四大实操维度，需精细配置而非简单启用机制。
Linux 容器资源隔离效果好不好，关键不在“有没有用 cgroup 或 namespace”，而在于怎么配、怎么调、怎么协同。开销控制也不是单纯压低配额，而是避免无谓争抢和内核路径损耗。下面从四个实操维度说清楚。
用对 cgroup v2 的层级结构
cgroup v2 比 v1 更干净、更可控，尤其适合多租户场景。必须启用 unified hierarchy，并把租户、服务、容器按逻辑组织成树状结构，比如：
- kubepods.slice 下挂各 namespace 的 pod-xxx.slice
- 每个 pod slice 内再分 container-runtime.slice（runtime 进程）和 app.slice（业务进程）
- 关键服务（如数据库）单独设 db-guaranteed.slice，绑定 cpu.weight=1000 + memory.max
这样既能统一管控，又能避免不同租户容器在同一个 cgroup level 上直接竞争 CPU 带宽或内存回收压力。
精细化配置 CPU 与 NUMA 绑定
CPU 资源不是只设 cpu.shares 或 cpu.cfs_quota_us 就完事。高负载推理或实时任务需进一步收敛：
- 用 cpuset.cpus 锁定物理 core，避免跨 NUMA 节点调度带来的 cache miss 和延迟抖动
- 配合 numactl --cpunodebind --membind 启动容器进程，确保内存分配靠近 CPU
- 对 burst 型负载（如 LLM 推理），启用 cpu.weight 动态调节（v2），而非硬限频，保留弹性空间
例如：一个租户的向量检索服务分配到 node1 的 cores 0–3，同时限定其内存只从 node1 的内存池分配，就能显著降低延迟方差。
内存隔离要防碎片+防 OOM 误杀
内存限制不能只靠 memory.limit_in_bytes。LLM 类容器容易触发 page reclaim 和 swap-in/out，反而放大开销：
- 设 memory.low 保底水位，让内核优先回收其他 cgroup 的内存，保护关键容器
- 禁用 swap（memory.swap.max = 0），避免因交换导致 latency 爆增
- 对需要确定性延迟的服务，开启 memory.oom.group = 1，保证同一组内进程被整体 kill，不残留孤儿线程
- 结合 vm.swappiness = 1 全局调低换页倾向
网络与存储隔离别只靠默认命名空间
默认的 netns 和 mountns 提供基础隔离，但生产环境需补强：
- 网络侧：用 tc + eBPF 在 ingress/egress 做 per-pod 流量整形，比单纯 NetworkPolicy 更低延迟
- 存储侧：为每个租户挂载独立的 overlayfs lowerdir + workdir，避免 upperdir 元数据锁争抢；必要时用 io.weight（cgroup v2 blkio）区分读写优先级
- 避免在容器内执行 mount/umount——除非显式启用 MS_SLAVE 或 MS_PRIVATE 传播模式，否则可能污染宿主机挂载表
不复杂但容易忽略。
