Linux 面试：容器如何隔离进程与资源？

题干与适用场景

一台使用 cgroup v2 的 Linux 主机上，容器 A 有以下练习约束：

| 约束 | 对应的 cgroup v2 值 | |---|---| | 内存 | memory.max = 536870912 字节，即 512 MiB | | CPU | cpu.max = 50000 100000，即每 100ms 最多使用 50ms | | task 数 | pids.max = 128 |

容器内的应用把自己看到的 PID 显示为 1，看到容器自己的 hostname、挂载表和网络接口。请说明 runtime 怎样创建这个环境、隔离分别来自哪里、触及限制后怎样失败，并解释共享内核的安全边界。最后要用可观察的内核状态证明配置生效，不能只用一次成功的 docker run 当证据。

这道题适用于 Linux、平台工程、SRE、DevOps、基础设施、云、安全和后端岗位。题中数值只是练习条件，不是推荐默认值。这里的“容器”指 Linux 上的 OCI 风格进程容器；由虚拟机承载的容器产品还会多一层不同的隔离。

面试官考察点

第一层是能否用准确的进程模型替换“轻量虚拟机”这个模糊说法。Linux 容器本质上是主机上的一棵进程树。namespace 改变这组进程能看到的全局资源实例，包括 PID、挂载、网络对象、IPC 对象、主机标识、用户 ID、cgroup 路径，以及可选的时钟。rootfs 和独立挂载视图提供用户空间文件。这些机制都没有创建第二个内核。

第二层是区分可见性与资源控制。namespace 回答“进程能看到或修改哪个资源实例”，cgroup 回答“这组进程能消耗多少，以及怎样计量”。PID namespace 不限制 task 数；cgroup 的 PID 限制也不会隐藏主机进程。mount namespace 改变挂载视图，rootfs 提供文件内容；单独使用 chroot 既不是完整容器，也不是安全边界。

第三层是根据具体 cgroup v2 文件推导结果。memory.max 是内存硬边界，回收失败后可能触发 cgroup 内的 OOM kill；cpu.max 是带宽控制，50ms 配额在 100ms 周期内耗尽后会 throttle，进程不会因此被杀；pids.max 会让违反限制的 fork() 或 clone() 以 EAGAIN 失败。强回答还会给出区分这三种结果的事件计数器。

第四层是安全判断。容器共享主机内核，所以 namespace 加 cgroup 不等于虚拟机边界。用户 ID 映射、最小 capability 集、nonewprivs、seccomp、AppArmor 或 SELinux 这类 LSM、只读或 masked mount，以及受限设备会缩小攻击面。privileged 容器、host PID 或 network namespace、容器引擎 socket、宽泛的主机目录挂载，都可能主动拆掉重要边界。

最后是验证能力。回答应从边界两侧比较 namespace inode 标识、UID/GID 映射、cgroup 归属与 controller 文件、进程 capability、seccomp 状态、挂载传播、网络接口和故障计数，而不只复述配置参数。

回答前需要澄清的问题

• 目标 runtime 和容器模式是什么？ 本题假定 Linux 上的 OCI runtime。rootless、user namespace remap、privileged 和虚拟机沙箱会改变信任边界。
• “0.5 CPU”指 quota 还是相对权重？ 本题指每 100,000 微秒最多运行 50,000 微秒的带宽上限；cpu.weight 只在竞争时调整相对份额。
• 512 MiB 包含哪些内存？ cgroup v2 会计量匿名内存、page cache、部分内核结构和 socket buffer 等主要项目，但单个文件不可能控制所有主机资源。
• 128 指进程还是内核 task？ pids controller 使用内核 task ID，线程也消耗预算；高线程数 runtime 必须考虑这一点。
• 是否启用 swap，并单独限制了吗？ memory.max 与 memory.swap.max 是不同控制项。本题只固定内存上限，swap 策略必须实查，不能假设。
• 到底配置了哪些 namespace？ OCI 配置可以新建、按路径加入已有 namespace，也可以省略某一类型并继承 runtime 的 namespace。漏掉一个就会真实改变边界。
• 威胁模型是什么？ 运行恶意代码的多租户平台可能还需要 VM 或 microVM；可信内部任务可以接受另一种取舍。

30 秒回答框架

“Linux 容器是以 rootfs 启动、放入指定 namespace 与 cgroup 的主机进程树，主机内核仍然共享。namespace 隔离视图，cgroup 计量并限制消耗。本题中，memory.max=536870912 在回收失败后可能触发 cgroup OOM；cpu.max=50000 100000 让 fair-class 工作每 100ms 最多运行 50ms，之后 throttle；pids.max=128 让违反限制的 fork 或 clone 返回 EAGAIN。

我会在适用时加入 UID 映射、最小 capability、nonewprivs、seccomp、AppArmor 或 SELinux、安全 mount 与受限设备。验证时从边界两侧比较 namespace 标识、UID map、mount、接口、有效 cgroup 文件、capability 与安全状态，再做有界故障测试，并要求看到对应的 memory.events、cpu.stat 与 pids.events 证据。”

分步骤深入解答

第一步：从主机进程模型出发

runtime 接收包含 rootfs 与配置的 OCI bundle。一条有代表性的创建流程是：

1. 校验 bundle、可执行文件、mount、namespace 选择、凭据与资源配置；
2. 创建或选择 cgroup 子树并写入 controller 值；
3. 新建 namespace，或加入配置指定的已有 namespace；
4. 使用 user namespace 时建立 UID/GID 映射；
5. 设置安全的 mount propagation，挂载 rootfs 与特殊文件系统，再切换进程根目录；
6. 新建 network namespace 时创建或移动网络设备并配置路由；
7. 设置凭据、capability、nonewprivs、seccomp 与 LSM label/profile；
8. 把进程加入 cgroup，并 exec 配置的应用。

不同 runtime 的精确顺序和辅助进程会不同，稳定不变的是可观察的内核状态：应用仍是由主机调度的进程，带有 namespace 归属、凭据、mount、filter 与 cgroup 路径。若 runtime 在设置中途崩溃，清理逻辑必须移除 mount、接口、namespace pin 和 cgroup；内核里没有一个名为“container”的对象自动包办这些清理。

第二步：给每种 namespace 分配清晰职责

常用 namespace 互相补充：

| Namespace | 隔离的视图 | 重要边界 | |---|---|---| | PID | 进程 ID 空间与可见性 | 同一 task 同时有容器内 PID 和主机 PID；容器 PID 1 要正确回收子进程和处理信号 | | Mount | 挂载点与传播关系 | 改变的是挂载表，不会自动隔离底层存储或内核 | | Network | 接口、路由、端口、socket 与网络栈 | 通过 veth、bridge、路由或其他 driver 有意恢复连通性 | | UTS | hostname 与 NIS domain name | 只呈现身份，不提供认证 | | IPC | System V IPC 与 POSIX message queue | 通过 mount 显式共享的文件或 socket 仍可连接 workload | | User | UID/GID 映射与 namespace 范围内的 capability | 容器内 UID 0 可映射到主机普通 UID | | Cgroup | cgroup 层级的视图 | 资源执行来自 controller，不来自 cgroup namespace 的视图 | | Time | boot 与 monotonic clock offset | 不等于拥有任意独立的硬件墙钟 |

OCI namespace 列表若省略某一类型，容器就继承 runtime 的对应 namespace。--pid=host、host network 或加入另一容器的 namespace 可以是明确需求，但回答必须指出失去了哪层隔离，不能继续把它描述成全私有边界。

文件系统边界同时需要 mount namespace 与 rootfs。private 或 slave propagation 能阻止容器 mount 事件意外传播回主机；只读 mount、masked path、最小 /dev 和明确的 bind mount 继续收窄访问。若把主机根目录可写挂入，或把容器引擎 socket 暴露进去，即使 hostname 私有，也已经形成高风险直达路径。

第三步：推导三种资源限制的结果

内存。 memory.max=536870912 是该 cgroup 及后代的主要硬上限。接近限制时内核先尝试回收；达到限制且无法降低使用量时，会进入 cgroup OOM 处理。默认模式可能选择该 cgroup 内的一个 task，memory.oom.group=1 可要求把 workload 当作不可分割整体。瞬时读数可能短暂高于限制。应检查 memory.current、memory.peak，以及 memory.events 中的 max、oom、oomkill、oomgroup_kill。没有这些计数和内核或 runtime 证据，不能把每次 SIGKILL 都诊断成 cgroup OOM。

CPU。 cpu.max=50000 100000 表示 fair-class task 在每个 100,000 微秒周期内最多消耗 50,000 微秒，即平均 0.5 CPU。多个线程可以并行花掉这份 quota，于是更早进入本周期的 throttle；runnable task 会等下一份 quota，不会被杀。应查看 cpu.stat 的 usageusec、nrperiods、nrthrottled 与 throttledusec。因此，即使主机还有空闲 CPU，周期边界附近的延迟尖峰也可能来自 quota throttle。

Task。 pids.max=128 是内核 task 数的层级硬限制，线程也计数。若创建新 task 会违反策略，fork() 或 clone() 会以 EAGAIN 失败，已有 task 继续运行。应查看 pids.current、pids.peak 与 pids.events 中的 max。移动已有 task 或把上限调到当前值以下，可以暂时出现 pids.current > pids.max；创建路径仍不能继续违反策略。

父 cgroup 同样约束子 cgroup，子级无法获得祖先没有允许的 CPU、内存或 task 容量。反过来，这三项配置也不会自动限制全部资源；磁盘空间、I/O、文件描述符、网络带宽、设备和全局内核对象还需要各自的控制与操作上限。

第四步：围绕共享内核叠加安全机制

user namespace 允许进程在容器内为 UID 0，同时在外部映射为普通 UID。这样可以减轻 namespace escape 或错误访问主机文件的影响，但 ID mapping 与文件所有权必须一起设计。没有 user namespace 时，容器 root 仍是主机 UID 0，只是被 capability 与可访问对象等机制约束。

capability 把传统 root 权限拆分。应从最小集合开始，而不是授予全部 capability。删除 capability 还要防止进程通过 file capability、set-user-ID 程序或其他路径重新获得；bounding set 配合 nonewprivs 才更容易审计。

seccomp 按 syscall 与参数执行 allow、deny、trap、kill、log 或 notify，减少能触达的内核攻击面，但它不理解应用级授权。AppArmor、SELinux 等 LSM 对文件、进程、socket 与其他对象施加策略。只读文件系统、masked /proc 路径与最小设备集又提供彼此独立的约束。

这些机制是叠加关系，不能互相替代。cgroup 主要负责计量与资源型拒绝服务，不能阻止容器读取另一个容器的数据；namespace 主要隔离视图，也不会修补共享内核漏洞。面对恶意租户，内核逃逸风险或合规要求可能需要 VM、microVM 或沙箱内核边界。

第五步：从边界两侧验证内核状态

先在主机上找到容器 init 的 host PID 与 cgroup 路径，再做通用检查：

pid=<host-pid-of-container-init>
cg=/sys/fs/cgroup/<container-cgroup>

readlink /proc/$pid/ns/{pid,mnt,net,uts,ipc,user,cgroup}
cat /proc/$pid/uid_map
cat /proc/$pid/gid_map
cat /proc/$pid/cgroup

cat "$cg/memory.current" "$cg/memory.max" "$cg/memory.events"
cat "$cg/cpu.max" "$cg/cpu.stat"
cat "$cg/pids.current" "$cg/pids.max" "$cg/pids.events"

grep -E '^(CapPrm|CapEff|CapBnd|NoNewPrivs|Seccomp):' /proc/$pid/status

把 namespace symlink 的设备号与 inode 同主机、另一容器比较。标识不同证明是不同 namespace 实例，但不能单独证明 mount、route 或 policy 安全；还要检查真实 mount table 与 propagation、网络 link 与 route、有效 capability、seccomp mode、LSM label 和 device node。

容器内则记录 /proc/1/status、/proc/self/cgroup、mount、hostname、可见进程、接口、路由、UID/GID 与 namespace link。主机上的 nsenter 只应由获授权人员用于诊断；能以高权限进入 namespace 不是隔离失败的证据。

最后在一次性环境做有界故障实验：逐步分配内存并与 memory.events 对齐；运行 CPU workload 并与 nr_throttled 对齐；创建线程或进程，直到下一次创建返回 EAGAIN 且 pids.events 增加。实验要在形成主机级压力前停止，并确认 sibling cgroup 仍然健康。

第六步：把观察结果写成验收标准

一份可辩护的验收记录应包含数值、标识与结果：

• 需要隔离的 namespace ID 不同，只有明确共享的才相同；
• UID 0 mapping、有效 capability、NoNewPrivs、seccomp mode 与 LSM label 符合威胁模型；
• mount propagation、bind mount、masked/read-only path 与 device access 符合 OCI 配置；
• 有效 cgroup 的 memory.max、cpu.max、pids.max 分别为 536870912、50000 100000、128；
• 内存压力改变对应 memory event，CPU 压力增加 throttle 计数但不杀进程，已计入 128 个 task 时第 129 个创建请求被拒绝；
• 每次实验中 parent 与 sibling cgroup 都维持自己的预算；
• restart 与强制失败后，没有意外遗留 mount、接口、namespace pin 或 populated cgroup。

“第 129 个”这个说法有前提：有效层级里正好已有 128 个 task，且没有并发退出。真实测试必须在创建前立刻读取 pids.current，不能假定应用只有一个 task。

高质量示范回答

“我先用主机进程模型回答。runtime 读取 OCI rootfs 与配置，新建或加入 PID、mount、network、UTS、IPC、user、cgroup、time namespace，配置 mount 和网络，把进程树加入 cgroup，应用凭据与安全策略，最后 exec 应用。容器内的 PID 1 仍是主机上的一个进程，只是在外部有另一个 PID；它拥有私有用户空间视图，但主机内核仍然共享。

namespace 与 cgroup 解决不同问题。PID namespace 改变进程可见性；mount namespace 配合 rootfs 改变可见文件系统；network namespace 提供自己的接口、route、port 和 socket；user namespace 可把内部 UID 0 映射为主机普通 UID。cgroup 计量并控制进程树，但不隐藏主机对象。

本题的 memory.max=536870912 是 512 MiB 硬边界。内核先尝试回收，无法降低使用量时可能进入 cgroup OOM；我会读 memory.events 区分 max、oom 与 oomkill。cpu.max=50000 100000 让 fair-class task 每 100ms 最多使用 50ms，quota 用完后 throttle，cpu.stat 的 nrthrottled 与 throttled_usec 会增加，不存在 CPU 限额导致的 kill。pids.max=128 统计包括线程在内的内核 task；违反上限的 fork 或 clone 返回 EAGAIN，pids.events 记录命中。

因为内核共享，我会在适用时叠加 user namespace、最小 capability、nonewprivs、seccomp、AppArmor 或 SELinux、只读或 masked mount 与最小设备集。privileged、host namespace、宽泛主机挂载和引擎 socket 都必须是显式可信需求；恶意多租户还可能需要 VM 或 microVM。

验证时，我会从主机和容器比较 /proc/{PID}/ns/* 的设备号/inode、UID/GID map、mount、接口、cgroup 路径与 controller 文件、capability、seccomp mode 和 LSM label，再做有边界的内存、CPU、task 实验，并要求看到对应内核计数与失败模式。容器能启动，不等于隔离已被证明。”

常见错误与改进建议

• 把容器称为小型 VM → 掩盖共享内核，导致错误安全假设 → 描述主机进程及其 namespace、cgroup、filesystem、credential 和 policy 状态。
• 说 namespace 限制 CPU 与内存 → namespace 隔离的是视图，不是消耗量 → 把资源上限映射到 cgroup controller 与具体文件。
• 说 cgroup 隔离文件与进程 → cgroup 负责分组、计量与约束 → 把可见性映射到 PID 与 mount namespace。
• 把 chroot 当容器 → 改变表面根目录没有增加 PID、network、user 或资源隔离 → 把 rootfs 与所需 namespace 和 policy 组合。
• 声称 CPU 限制会杀进程 → CPU quota 通常 throttle runnable fair-class task → 检查 cpu.stat 的 throttle 证据。
• 期待内存读数严格停在 512 MiB → reclaim、计量时序与瞬时越界会影响某一时刻读数 → 用 memory.max 和 event counter 判断执行结果。
• pids.max 只数进程 → controller 数内核 task，线程也占额度 → 限制实验前读取 pids.current。
• 假定容器 root 天然无害 → 未使用 user namespace 时仍可能是主机 UID 0 → 检查 uid_map 与 capability。
• 把 namespace 分离等同安全租户边界 → 内核漏洞或危险主机挂载可能跨越进程边界 → 先定义威胁模型，再叠加 policy 或 VM。
• 只检查配置，不检查有效状态 → 参数可能被继承、覆盖或部分失败 → 读取 /proc 和 cgroup 文件，并实际触发每种限制。

延伸追问

追问一：为什么容器里的 PID 1 需要特殊处理？

PID namespace 的第一个进程对后代显示为 PID 1，会接管孤儿进程并需要回收子进程，否则 zombie 会累积并消耗 pids 预算。PID 1 还有特殊的 signal 处理语义，不能转发信号的 wrapper 会让优雅终止失败。应验证真实 init、child reaping、signal forwarding 与 shutdown deadline，而不是假定应用框架已经处理。

追问二：cpu.max 与 cpu.weight 有什么区别？

cpu.max 给 fair-class 工作设置每周期最大带宽；本周期 quota 用完后，即使主机还有空闲 CPU，也可能 throttle。cpu.weight 只在 runnable sibling cgroup 竞争时调整比例，本身没有定义硬性的 0.5 CPU 上限。生产策略可能出于不同目的同时使用两者。

追问三：容器 root 能否在主机上是非特权用户？

可以。user namespace 可把容器内 UID 0 映射到外部普通 UID range，应通过 /proc/{PID}/uidmap 与 gidmap 验证。它收窄主机权限，但 bind mount 所有权、subordinate ID 分配、所属 user namespace 内的 capability 与内核攻击面仍需审查。

追问四：为什么 private mount namespace 仍不足以保证文件安全？

它隔离 mount table，但 runtime 决定里面出现哪些底层文件系统和 bind mount。一个 private namespace 若包含主机 / 的可写 bind mount，仍然暴露主机根目录。要把 mount source、propagation、writable flag、masked/read-only path、device node、credential 与 LSM policy 一起检查。

追问五：什么场景应优先 VM 或 microVM？

互不信任的租户执行任意代码、无法接受共享内核逃逸风险、合规要求独立内核，或 workload 需要不同内核版本和 module 时，更强边界通常更合适。代价是额外启动时间、内存、镜像和运维开销。应按威胁模型与平台实测约束决定，而不是只看容器或 VM 标签。

追问六：容器很慢但没有 OOM kill，怎样定位？

把应用延迟与 cpu.stat throttle、memory.events 的 high/max 压力、pressure stall information、I/O controller 统计、主机调度和网络错误对齐。nrthrottled 或 throttledusec 持续增加而 OOM 计数不变，支持 CPU quota 方向；reclaim 或 I/O 压力也可能只造成 stall 不 kill，所以必须用统一时间线和有效 cgroup 祖先关系判断。