深入剖析 Linux 容器原理：Namespace、Cgroups 与容器运行时全链路解析

1 阅读 0 评论 0 点赞

前言

容器技术已经成为现代云计算和 DevOps 的基石。从 Docker 到 Kubernetes，容器编排无处不在。但容器的本质是什么？它是如何实现资源隔离与限制的？本文将深入 Linux 内核层面，系统剖析容器技术的三大基石——Namespace、Cgroups 和 UnionFS，并带你从零构建一个最小容器运行时。

一、容器不是轻量级虚拟机

最常见的误解是把容器等同于轻量级虚拟机。实际上，容器本质上是宿主机上的普通进程，通过内核提供的 Namespace 机制实现视图隔离，通过 Cgroups 实现资源限制。它们共享宿主机的内核，不需要硬件虚拟化开销。这意味着：

容器启动是毫秒级，虚拟机是分钟级
容器没有 guest OS 开销，内存占用极低
容器进程在宿主机上可见（通过 ps），只是被 namespace 隔离了视图

二、Namespace —— 让你看到什么

Linux Namespace 是内核级别的环境隔离机制。每个 Namespace 中的进程只能看到属于该 Namespace 的资源视图。Linux 提供了 7 种 Namespace：

Namespace	隔离资源	系统调用标志
PID	进程 ID 编号空间	CLONE_NEWPID
NET	网络设备、协议栈、路由表	CLONE_NEWNET
MNT	文件系统挂载点	CLONE_NEWNS
UTS	主机名和域名	CLONE_NEWUTS
IPC	System V IPC、POSIX 消息队列	CLONE_NEWIPC
USER	用户和组 ID	CLONE_NEWUSER
CGROUP	Cgroup 根目录	CLONE_NEWCGROUP

2.1 PID Namespace 深度解析

PID Namespace 建立了进程编号的层级树。容器内的第一个进程在其 PID Namespace 中 PID 为 1，拥有特殊职责：它会像 init 进程一样收养孤儿进程，并负责进程的 reaping（回收僵尸进程）。如果我们 kill 了容器内的 PID 1 进程，整个容器内所有进程都会被内核清理。

# 创建新的 PID Namespace 并运行 shell
sudo unshare --pid --fork --mount-proc /bin/bash

# 在容器内部：ps aux 只能看到 Namespace 内的进程
ps aux
# 输出只有一两个进程，仿佛在一个全新的系统中

2.2 NET Namespace 实战

NET Namespace 给容器提供了独立的网络栈。Docker 的 bridge 模式本质上是在宿主机上创建 docker0 网桥，然后通过 veth pair（虚拟以太网对）将容器的网络 Namespace 与宿主机连接起来。

# 创建网络 Namespace
ip netns add container1
ip netns exec container1 ip link show
# 只看到一个状态为 DOWN 的 lo 接口

# 创建 veth pair 连接宿主机和容器
ip link add veth-host type veth peer name veth-container
ip link set veth-container netns container1
ip netns exec container1 ip addr add 10.0.0.1/24 dev veth-container
ip netns exec container1 ip link set veth-container up

三、Cgroups —— 限制你能使用什么

Container 解决了「看到什么」的问题，Cgroups（Control Groups）解决的是「能用多少」的问题。通过 Cgroups 子系统，我们可以限制容器的 CPU、内存、IO 和网络带宽。

3.1 CPU 限制

Cgroups v1 通过 cpu 子系统提供两种调度策略：CFS（完全公平调度器）带宽控制和实时调度。在 Docker 中，--cpus 参数最终映射为 cpu.cfs_period_us 和 cpu.cfs_quota_us：

# 限制容器最多使用 1 个 CPU 核心（100%）
mkdir /sys/fs/cgroup/cpu/mycontainer
echo 100000 > /sys/fs/cgroup/cpu/mycontainer/cpu.cfs_period_us
echo 100000 > /sys/fs/cgroup/cpu/mycontainer/cpu.cfs_quota_us
echo $PID > /sys/fs/cgroup/cpu/mycontainer/tasks

# 限制最多使用半个 CPU 核心（50%）
echo 50000 > /sys/fs/cgroup/cpu/mycontainer/cpu.cfs_quota_us

3.2 内存限制

Cgroups 内存限制包括物理内存和 swap 的总和。当容器内存使用超过限制，内核会触发 OOM Killer 杀死进程：

# 限制内存为 512MB
mkdir /sys/fs/cgroup/memory/mycontainer
echo 536870912 > /sys/fs/cgroup/memory/mycontainer/memory.limit_in_bytes
echo 0 > /sys/fs/cgroup/memory/mycontainer/memory.swappiness
echo $PID > /sys/fs/cgroup/memory/mycontainer/tasks

3.3 Cgroups v2 统一层次结构

Cgroups v2 重新设计了 API，将所有控制器统一到单一层次结构中，更好地支持 Delegation。Cgroups v2 的关键改进包括：统一资源控制、压力阻塞信息（PSI）、更精确的内存最低保障（memory.min）。

四、UnionFS —— 为什么不臃肿

联合文件系统是容器镜像的核心。Docker 默认使用 overlay2 存储驱动，它通过将多个只读层和一个可写层联合挂载，实现了镜像的分层共享。这意味着：

100 个使用同一 base image 的容器不需要复制 100 份操作系统文件
构建镜像时每一层都有缓存，修改某一层只重建该层及以上层
Copy-on-Write 让容器启动时的磁盘开销极小

# overlay2 目录结构
/var/lib/docker/overlay2/
├── l/                        # 硬链接层（缩短目录层长度）
├── lower_id/                 # lowerdir 的 ID
├── merged/                   # 合并后的视图（容器的 rootfs）
├── lower/                    # 下层目录（只读层）
├── upper/                    # 上层目录（容器可写层）
└── work/                     # overlayfs 工作目录

五、进程 1 号问题：一个经典的坑

容器内的 PID 1 进程有特殊的进程管理职责。很多传统程序（如 nginx、node.js）并不会处理孤儿进程的收割，也不会正确转发信号。这会导致僵尸进程堆积，以及 docker stop 发送 SIGTERM 后进程无响应，最终被 SIGKILL 强制杀死。

解决方案是使用轻量级 init 进程如 tini 或 dumb-init 作为 ENTRYPOINT：

# Dockerfile
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["nginx", "-g", "daemon off;"]

六、User Namespace 与安全

User Namespace 允许容器内的 root 用户映射到宿主机的普通非特权用户，是实现安全多层级的关键。启用 User Namespace 后：

容器内 root（UID 0）在宿主机上是一个普通用户
容器内的 CAP_SYS_ADMIN 等能力只在本 Namespace 内有效
即使容器内进程逃逸，攻击者在宿主机上也只是普通用户

# Docker 启用 User Namespace
dockerd --userns-remap="default"
# 容器内 root 映射到宿主机 dockremap 用户（UID 65534）

七、Capabilities：细粒度权限

Linux 将传统的 root 权限拆分为多个独立的 capabilities，容器运行时默认只保留必要的能力集，大幅缩小了攻击面。Docker 默认保留 14 个 Capabilities（CAP_CHOWN、CAP_DAC_OVERRIDE、CAP_NET_BIND_SERVICE 等）。

# 添加特定 Capabilities
docker run --cap-add=SYS_PTRACE --cap-add=NET_ADMIN image_name

# 赋予所有 Capabilities（极度危险，避免使用）
docker run --privileged image_name

八、seccomp：系统调用过滤器

seccomp 允许通过 BPF 过滤器限制容器内进程可以调用的系统调用。Docker 默认的 seccomp profile 会禁止大约 44 个高危险系统调用，包括 kexec_load、open_by_handle_at、init_module、clone 等。

# 自定义 seccomp profile（JSON 格式）
{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["read", "write", "open", "close"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

九、从零实现一个最小容器运行时

让我们用 Python 和 Linux 原语实现一个最小容器，综合应用前面介绍的所有技术：

#!/usr/bin/env python3
import os
import ctypes

CONTAINER_STACK_SIZE = 1024 * 1024  # 1MB 栈
ROOTFS = "/path/to/alpine-rootfs"

def container_main():
    """容器内执行的主函数"""
    libc = ctypes.CDLL("libc.so.6")
    libc.sethostname(b"mycontainer", 10)
    os.system("mount -t proc proc /proc")
    os.chroot(ROOTFS)
    os.chdir("/")
    print("=== 容器已启动 ===")
    os.execv("/bin/sh", ["/bin/sh"])

# clone 标志：新 Namespace + 新 PID Namespace + 新 UTS
CLONE_FLAGS = 0x20000000 | 0x40000000 | 0x10000000

stack = bytearray(CONTAINER_STACK_SIZE)
stack_top = ctypes.c_void_p(id(stack) + CONTAINER_STACK_SIZE)

container_pid = ctypes.CDLL("libc.so.6").clone(
    ctypes.CFUNCTYPE(ctypes.c_int)(container_main),
    stack_top,
    CLONE_FLAGS,
    None
)
os.waitpid(container_pid, 0)
print("=== 容器已退出 ===")

十、性能优化与最佳实践

10.1 镜像构建优化

使用多阶段构建，分离构建环境和运行环境
将不常变化的层放在 Dockerfile 前面以利用缓存
使用 .dockerignore 排除不必要的文件
优先选择 Alpine Linux 或 Distroless 作为 base image

10.2 存储驱动选择

驱动	优点	适用场景
overlay2	性能好，支持多层	通用场景
btrfs	支持子卷和快照	需要频繁快照
zfs	压缩去重	大量相似容器
devicemapper	块级复制	写密集场景

10.3 网络性能优化

使用 host 网络模式消除 NAT 开销（高吞吐场景）
开启 TCP BBR 拥塞控制算法
避免 iptables 规则过多导致性能下降
使用 eBPF + Cilium 替代传统 kube-proxy

十一、容器安全加固清单

不以 root 用户运行容器进程（USER 指令）
使用只读文件系统（--read-only）
限制 capabilities，按需添加
降低 seccomp 配置限制系统调用
设置资源限制（CPU/内存/进程数）
定期扫描镜像漏洞（Trivy、Grype）
使用 Pod Security Standards 策略
启用 AppArmor 或 SELinux 的强制访问控制

十二、未来：eBPF 重塑容器可观测性

eBPF 是近年来 Linux 内核最重要的创新之一。它允许在虚拟机中安全运行沙盒程序，无需修改内核源码。在容器领域，eBPF 正在带来：

Cilium：基于 eBPF 的 CNI，提供 L7 网络策略
Pixie / Hubble：零侵入的容器网络流量观测
Falco：运行时安全检测
Tetragon：实时内核级可观测性

结语

容器技术并非魔法，它是 Linux 内核数十年积累的系统编程精华的集大成者。Namespace 提供隔离、Cgroups 提供资源管理、UnionFS 提供分层存储，三者协同构建了我们今天所依赖的容器生态。理解这些底层原理，不仅能帮助我们在生产环境中排查问题，更能让我们在技术选型和架构设计时做出明智决策。

「看见本质，而后驾驭工具」——这就是学习底层原理的意义。

点赞(0) 打赏

本文分类：系统编程
本文标签：容器命名空间控制组存储驱动 eBPF 安全
浏览次数：1 次浏览
发布日期：2026-10-11 05:34:06
本文链接：https://www.ybb.press/system-prog/16782.html

深入剖析 Linux 容器原理：Namespace、Cgroups 与容器运行时全链路解析

前言

一、容器不是轻量级虚拟机

二、Namespace —— 让你看到什么

2.1 PID Namespace 深度解析

2.2 NET Namespace 实战

三、Cgroups —— 限制你能使用什么

3.1 CPU 限制

3.2 内存限制

3.3 Cgroups v2 统一层次结构

四、UnionFS —— 为什么不臃肿

五、进程 1 号问题：一个经典的坑

六、User Namespace 与安全

七、Capabilities：细粒度权限

八、seccomp：系统调用过滤器

九、从零实现一个最小容器运行时

十、性能优化与最佳实践

10.1 镜像构建优化

10.2 存储驱动选择

10.3 网络性能优化

十一、容器安全加固清单

十二、未来：eBPF 重塑容器可观测性

结语

评论列表共有 0 条评论

发表评论取消回复

深入剖析 Linux 容器原理：Namespace、Cgroups 与容器运行时全链路解析

前言

一、容器不是轻量级虚拟机

二、Namespace —— 让你看到什么

2.1 PID Namespace 深度解析

2.2 NET Namespace 实战

三、Cgroups —— 限制你能使用什么

3.1 CPU 限制

3.2 内存限制

3.3 Cgroups v2 统一层次结构

四、UnionFS —— 为什么不臃肿

五、进程 1 号问题：一个经典的坑

六、User Namespace 与安全

七、Capabilities：细粒度权限

八、seccomp：系统调用过滤器

九、从零实现一个最小容器运行时

十、性能优化与最佳实践

10.1 镜像构建优化

10.2 存储驱动选择

10.3 网络性能优化

十一、容器安全加固清单

十二、未来：eBPF 重塑容器可观测性

结语

Linux eBPF 深度工程实战：从内核探针到可观测性革命

深入剖析 Linux 容器原理：Namespace、Cgroups 与容器运行时全链路解析

Linux内核eBPF与XDP高性能网络数据包处理深度实战

Linux 网络栈深度实战：从 sk_buff 到内核旁路的完整架构剖析

评论列表 共有 0 条评论

发表评论 取消回复

评论列表共有 0 条评论

发表评论取消回复