Namespaces和Cgroups是什么？容器隔离解析

Namespaces和Cgroups是什么，是理解容器技术时最核心的问题之一。很多人第一次接触 Docker 或 Kubernetes 时，会把容器理解成一种“轻量级虚拟机”，但这个说法只适合帮助入门，并不适合解释生产环境中的资源限制、权限边界和故障排查。容器之所以看起来像一个独立系统，主要依赖 Linux Namespace 隔离进程可见范围；容器之所以能限制 CPU、内存、IO 等资源，主要依赖 Cgroups 进行资源控制。两者共同构成容器运行时的基础，但它们解决的问题并不相同。

如果用一句话概括：Namespace 负责“看见什么”，Cgroups 负责“能用多少”。前者让进程看到独立的 PID、网络、挂载点、主机名、用户等视图；后者限制和统计进程组消耗的资源。理解这一区别，才能避免把容器隔离误解成完整虚拟化，也才能在部署、调度和安全加固时做出正确判断。

容器隔离要解决的三个实际问题

容器隔离不是为了“制造一个小系统”这么简单，而是为了在同一台 Linux 主机上安全、稳定地运行多个应用实例。落到工程场景，至少要解决三类问题。

第一，进程之间不能相互干扰。一个容器内的应用不应该随意看到宿主机上其他业务进程，也不应该通过普通进程操作影响其他容器。PID Namespace 就是在这个方向上发挥作用，它让容器内进程看到自己的进程编号空间。

第二，资源不能无限争抢。没有资源控制时，一个异常 Java 进程、批处理任务或内存泄漏服务可能把整台机器拖垮。Cgroups 可以为进程组设置 CPU 权重、CPU quota、内存上限、块设备 IO 限制等，使资源争用变得可治理。

第三，运行环境要可复制。容器内应有自己的文件系统视图、网络接口、主机名和环境变量。Mount Namespace、Network Namespace、UTS Namespace 等机制让同一台宿主机承载多个相互独立的应用运行环境。

这些能力组合起来，才形成 Docker、containerd、CRI-O 等容器运行时向上提供的“容器”抽象。更多容器基础概念可以放在 Docker与容器基础 目录下理解，安全边界相关内容则更适合与 容器安全 联动阅读。

Namespace：把进程能看到的世界切开

Namespace 是 Linux 内核提供的一组隔离机制。它不是复制一套内核，也不是启动一台虚拟机，而是在同一个内核上为不同进程提供不同的资源视图。常见 Namespace 类型包括：

• PID Namespace：隔离进程编号，容器内可以看到自己的 1 号进程。
• Network Namespace：隔离网络设备、IP 地址、路由表、端口和防火墙规则视图。
• Mount Namespace：隔离挂载点，让容器看到自己的根文件系统和挂载结构。
• UTS Namespace：隔离 hostname 和 domain name。
• IPC Namespace：隔离 System V IPC、POSIX message queue 等进程间通信对象。
• User Namespace：隔离用户与用户组 ID，可把容器内 root 映射为宿主机上的非特权用户。
• Cgroup Namespace：隔离进程看到的 cgroup 路径，减少宿主机资源层级暴露。

其中最容易被误解的是 PID Namespace。容器内看到的 1 号进程并不等同于宿主机真正的 init 进程，它只是该 PID Namespace 内的第一个进程。在宿主机上观察时，这个进程仍然有宿主机维度下的真实 PID。也就是说，Namespace 改变的是可见范围，不是让进程脱离宿主机内核。

Network Namespace 也是容器网络的基础。Docker 默认会为容器创建独立网络命名空间，再通过 veth pair、bridge、iptables 或其他网络插件完成连通。Kubernetes 中的 Pod 网络同样建立在类似机制之上，只是网络模型由 CNI 插件统一实现。对于需要深入理解 Pod 网络、Service 转发和容器端口冲突的读者，Namespace 是绕不开的基础。

Cgroups：限制和统计进程能使用的资源

Cgroups 的全称是 Control Groups，核心作用是把一组进程放到同一个资源控制层级中，然后限制、统计和隔离它们的资源使用。与 Namespace 不同，Cgroups 不解决“看见什么”的问题，而是解决“最多能消耗多少资源”的问题。

在容器环境中，Cgroups 常用于以下控制：

• CPU：设置 CPU shares、quota、period，控制容器在竞争时的权重和上限。
• 内存：设置 memory limit，防止单个容器占用过多内存。
• IO：限制块设备读写速率或权重，降低重 IO 任务对其他服务的影响。
• PIDs：限制进程数量，避免 fork bomb 或异常进程膨胀。
• 设备访问：控制进程组可访问的设备节点。

Cgroups 有 v1 和 v2 两套体系。Cgroups v1 中不同资源控制器可以挂载在不同层级，灵活但容易出现层级不一致；Cgroups v2 使用统一层级模型，更利于一致的资源管理。现代 Linux 发行版和 Kubernetes 环境正在逐步增强对 Cgroups v2 的支持，但迁移时需要关注容器运行时、内核版本、监控采集和资源语义是否兼容。

Docker 启动容器时二者如何配合

当执行 docker run 或 Kubernetes 通过 CRI 创建容器时，运行时并不是简单地启动一个普通进程，而是围绕该进程完成一组隔离与限制动作。简化后可以理解为：

1. 准备镜像层和可写层，形成容器根文件系统。
2. 为容器进程创建所需 Namespace，如 PID、Mount、Network、UTS、IPC 等。
3. 配置 Cgroups 层级，把容器进程加入对应控制组。
4. 根据参数设置 CPU、内存、进程数、设备等资源限制。
5. 设置网络设备、路由、DNS、端口映射或 CNI 网络。
6. 启动容器主进程，并由运行时跟踪其生命周期。

因此，容器不是一个单一内核功能，而是 Namespace、Cgroups、文件系统分层、能力控制、seccomp、AppArmor 或 SELinux 等机制组合出的运行单元。只理解其中一个点，很容易在排查问题时误判。

容器隔离不是安全边界的全部

很多生产事故来自一个错误假设：容器已经隔离，所以容器内 root 就一定安全。事实上，容器共享宿主机内核，如果内核漏洞、特权容器、危险挂载、过宽 capability 或宿主机 socket 暴露同时存在，容器逃逸风险会显著上升。

实践中应重点关注以下边界：

• 避免默认使用 privileged 容器，除非非常明确其必要性。
• 不要把 Docker socket 直接挂载进普通业务容器。
• 谨慎挂载宿主机敏感目录，如 /、/proc、/sys、/var/run。
• 减少 Linux capabilities，只保留应用真正需要的能力。
• 为关键工作负载配置 seccomp、AppArmor 或 SELinux 策略。
• 使用只读根文件系统、非 root 用户和最小基础镜像降低攻击面。

这些内容与 容器安全 高度相关。Namespace 和 Cgroups 提供基础隔离，但企业级安全还需要镜像治理、运行时策略、网络策略、审计和漏洞管理共同完成。

在 Kubernetes 中如何映射到资源配置

Kubernetes 并不会绕开 Namespace 和 Cgroups，而是在更高层面封装它们。Pod 是 Kubernetes 的基本调度单元，Pod 内多个容器通常共享 Network Namespace，因此它们看到同一个 Pod IP，也可以通过 localhost 互相访问。不同 Pod 则处于不同网络命名空间，依赖 CNI 插件实现跨节点连通。

资源限制方面，Pod 和 Container 的 requests、limits 最终会转化为运行时和内核层面的资源控制。例如 CPU request 影响调度和资源权重，CPU limit 通常对应 quota 限制；memory limit 则会让容器在超过上限时面临 OOMKill。理解 Cgroups 后，再看 Kubernetes 中的 Guaranteed、Burstable、BestEffort QoS 等级，就会更容易明白为什么某些 Pod 更容易被驱逐。

常见排查思路：从症状回到内核机制

当容器出现“看不到进程”“端口不通”“内存被杀”“CPU 使用异常”等问题时，可以按以下思路定位：

1. 判断问题属于可见性还是资源限制。看不到网络接口、进程或挂载点，多半与 Namespace 相关；被限速、OOM 或进程数受限，多半与 Cgroups 相关。
2. 在容器内外分别观察。容器内看到的是命名空间视图，宿主机看到的是全局视图，两边结果不同是正常现象。
3. 检查运行参数和编排配置。Docker 参数、Kubernetes resources、securityContext、volumeMounts 都可能改变隔离效果。
4. 查看内核和运行时版本。Cgroups v2、rootless 容器、不同 runtime 在行为上可能存在差异。
5. 结合日志和事件判断。Kubernetes 中尤其要关注 Pod events、container status、OOMKilled、Evicted 等状态。

一个实用判断是：如果问题表现为“容器里看不到或看起来不一样”，优先查 Namespace；如果问题表现为“容器能看到但不能用、用到一半被限制”，优先查 Cgroups 和资源配置。

FAQ：关于 Namespaces 和 Cgroups 的深入问题

1. Namespace 和 Cgroups 哪个更重要？

二者没有谁替代谁。Namespace 让容器具备独立环境的外观，Cgroups 让容器具备可控资源边界。没有 Namespace，容器进程会直接暴露在宿主机视图中；没有 Cgroups，容器就难以限制资源消耗。生产环境中的容器隔离通常必须同时依赖二者。

2. 容器和虚拟机最大的隔离差异是什么？

虚拟机通常有独立内核，隔离边界位于虚拟硬件和 Hypervisor 层；容器共享宿主机内核，隔离边界主要来自 Linux 内核能力的组合。因此容器启动更快、资源开销更低，但内核共享也意味着安全边界需要额外加固，不能把容器等同于虚拟机。

3. 为什么容器内的 root 不一定等于宿主机 root？

如果启用了 User Namespace，容器内 root 可以映射为宿主机上的非特权用户，这会显著降低风险。但并非所有环境默认启用 User Namespace。若容器以特权模式运行，或挂载了敏感宿主机路径，容器内 root 仍可能造成较大影响。

4. OOMKilled 一定是应用内存泄漏吗？

不一定。OOMKilled 只说明容器进程触达了内存控制边界或节点内存压力下被内核处理。原因可能是应用泄漏、limit 设置过低、启动峰值被低估、缓存占用、JVM 参数与容器限制不匹配等。排查时要同时看应用指标、容器 memory limit、节点内存压力和 Kubernetes 事件。

5. Cgroups v2 是否一定比 v1 更好？

Cgroups v2 的统一层级模型更清晰，也更利于长期演进，但是否适合立即启用取决于操作系统、内核、容器运行时、监控组件和业务兼容性。企业环境更建议通过测试集群验证资源语义、指标采集和异常场景，再逐步切换。

总结：把“容器像机器”还原成“进程被隔离和限制”

理解 Namespaces和Cgroups是什么，本质上是把容器从“像一台小机器”的表象还原为 Linux 进程管理模型。Namespace 决定容器进程能看到什么，Cgroups 决定容器进程能使用多少资源。Docker 和 Kubernetes 在此基础上叠加镜像、网络、存储、安全策略和调度能力，最终形成现代容器平台。对研发和平台团队来说，掌握这两类机制不仅有助于学习容器原理，更能直接提升资源配置、故障定位和安全治理能力。