mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
2351 字
7 分钟
容器全景:从 chroot 到 OCI
2026-04-05

1979 年,UNIX V7 引入了 chroot 系统调用,允许进程看到一个与根目录不同的文件系统视图——这是容器隔离思想的起点。四十多年后的今天,容器技术已经从简单的目录切换发展为包含 Namespace、Cgroup、OverlayFS、OCI 规范、多层运行时架构的完整体系。docker run 一条命令背后,是四个进程、三个抽象层、两个规范的精密协作。

本章将建立容器运行时的全景认知。在后续章节深入 Namespace、Cgroup、OverlayFS 的细节之前,你需要先看到完整的地图:容器技术是怎么一步步演进的?三大内核基石各自解决什么问题?OCI 规范定义了什么?Docker、containerd、runc 之间是什么关系?

一、容器技术演进:从 chroot 到 OCI#

1.1 早期隔离:chroot(1979)#

chroot 是 UNIX 系统中最古老的隔离机制。它的核心思想极其简单:改变进程的根目录视图,让进程无法访问根目录之外的文件。

# 创建一个最小 rootfs
mkdir -p /tmp/myroot/bin /tmp/myroot/lib64
cp /bin/bash /tmp/myroot/bin/
# 复制 bash 需要的动态链接库
ldd /bin/bash | grep -o '/lib64/.*' | xargs -I{} cp {} /tmp/myroot/lib64/
# 使用 chroot 切换根目录
sudo chroot /tmp/myroot /bin/bash
# 此时进程的根目录是 /tmp/myroot,无法访问原系统的文件

chroot 的隔离极其有限:

隔离维度chroot 是否隔离说明
文件系统视图改变根目录视图
进程可见性仍能看到所有 PID
网络栈共享宿主机网络
用户身份仍是同一个 UID
资源使用无资源限制
设备访问可访问 /dev 下设备
Warning

chroot 不提供安全隔离。root 用户可以轻松逃逸 chroot 环境——通过 mknod 创建内存设备、通过 ptrace 附加外部进程、通过 /proc 访问宿主文件系统。chroot 的设计目标是”便利”而非”安全”。

1.2 FreeBSD Jail(2000)与 Solaris Zones(2004)#

chroot 的局限性催生了更完善的隔离方案。FreeBSD Jail 在 chroot 基础上增加了进程隔离、网络隔离和资源限制,Solaris Zones 则提供了更完整的操作系统级虚拟化。

这些方案虽然强大,但都是特定操作系统的实现,无法在 Linux 上使用。Linux 需要自己的容器隔离方案。

1.3 Linux 容器的萌芽:LXC(2008)#

Linux 容器技术的真正起点是 2008 年合并入内核的 Namespace 和 Cgroup。LXC(Linux Containers)是第一个将这些内核特性组合使用的项目:

# LXC 创建容器
sudo lxc-create -n mycontainer -t ubuntu
sudo lxc-start -n mycontainer
sudo lxc-attach -n mycontainer
# LXC 底层使用的就是 Namespace + Cgroup
# 查看 LXC 容器的 Namespace
ls -la /proc/$(pgrep -f "lxc mycontainer")/ns/

LXC 证明了 Namespace + Cgroup 的组合可以创建轻量级隔离环境,但它仍然是一个”系统容器”方案——用户需要管理完整的 init 系统,体验更像轻量级虚拟机而非现代容器。

1.4 Docker 革命(2013)#

Docker 的贡献不在于发明新技术,而在于重新定义了容器的使用体验

  1. 镜像(Image):将应用及其依赖打包为不可变的分层镜像,取代了 LXC 的模板机制
  2. Dockerfile:用声明式语法定义镜像构建步骤,实现了”基础设施即代码”
  3. 分层存储:基于 OverlayFS 的分层文件系统,镜像层可以共享复用
  4. 一键运行docker run 一条命令完成所有操作,极大降低了使用门槛
# Docker 之前的 LXC 工作流
sudo lxc-create -n myapp -t ubuntu # 创建容器
sudo lxc-start -n myapp # 启动容器
sudo lxc-attach -n myapp # 进入容器
# 在容器内手动安装依赖、配置应用...
# Docker 的工作流
docker run -d nginx # 一条命令搞定

1.5 OCI 标准化(2015)#

Docker 的成功带来了生态碎片化——CoreOS 推出了 rkt,Google 推出了 lmctfy,各家运行时不兼容。2015 年,Docker、CoreOS、Google 等公司共同成立了 OCI(Open Container Initiative),定义容器格式的开放标准:

timeline title 容器技术演进时间线 1979 : chroot — UNIX V7 引入目录隔离 2000 : FreeBSD Jail — 增强隔离方案 2004 : Solaris Zones — OS 级虚拟化 2006 : Linux Cgroup — 进程资源控制 2008 : LXC — Linux 容器工具 2013 : Docker — 容器革命 2014 : Kubernetes — 容器编排 2015 : OCI 成立 — 容器标准化 2016 : CRI-O — K8s 专用运行时 2017 : containerd 独立 — 运行时解耦 2018 : gVisor/Kata — 沙箱运行时 2019 : Cgroup v2 — 统一层级设计 2021 : Wasm 容器 — 新运行时方向 2023 : OCI v1.1 — 规范持续演进

二、容器三大基石#

容器的本质是一组 Linux 内核特性的组合使用。其中三个特性最为核心:Namespace 提供视图隔离,Cgroup 提供资源限制,OverlayFS 提供分层文件系统。

2.1 Namespace:视图隔离#

Namespace 让进程看到一个”缩小”的系统视图——只看到自己的 PID、自己的网络栈、自己的挂载点。Linux 内核提供了 8 种 Namespace:

Namespace隔离内容系统调用内核版本
Mount文件系统挂载点CLONE_NEWNS2.4.19
PID进程 IDCLONE_NEWPID2.6.24
Network网络栈CLONE_NEWNET2.6.29
IPCSystem V IPC/POSIX 消息队列CLONE_NEWIPC2.6.30
UTS主机名和域名CLONE_NEWUTS2.6.19
User用户和组 IDCLONE_NEWUSER3.8
CgroupCgroup 根目录视图CLONE_NEWCGROUP4.6
Time系统时钟CLONE_NEWTIME5.6
# 查看当前进程的所有 Namespace
ls -la /proc/self/ns/
# 输出示例:
# cgroup -> 'cgroup:[4026531835]'
# ipc -> 'ipc:[4026531839]'
# mnt -> 'mnt:[4026531840]'
# net -> 'net:[4026531992]'
# pid -> 'pid:[4026531836]'
# user -> 'user:[4026531837]'
# uts -> 'uts:[4026531838]'
Note

Namespace 提供的是视图隔离而非安全隔离。它让进程”看不到”其他进程,但不阻止进程在获得特权后突破隔离边界。容器安全需要 Namespace + Cgroup + seccomp + AppArmor 的组合使用,详见 Ch10 容器安全

2.2 Cgroup:资源限制#

如果说 Namespace 是”你看不到别人”,那 Cgroup 就是”你不能用太多”。Cgroup 限制进程组可以使用的系统资源:

# 查看容器的 Cgroup 路径(Cgroup v2)
cat /proc/$(pgrep -f "nginx")/cgroup
# 输出示例(Cgroup v2 统一层级):
# 0::/system.slice/docker-abc123.scope
# 查看容器的 CPU 限制
cat /sys/fs/cgroup/system.slice/docker-abc123.scope/cpu.max
# 查看容器的内存限制
cat /sys/fs/cgroup/system.slice/docker-abc123.scope/memory.max

Cgroup v2 的关键控制器:

控制器功能关键文件
cpuCPU 时间分配cpu.max, cpu.weight
memory内存使用限制memory.max, memory.current
io块设备 IO 限制io.max, io.stat
pids进程数限制pids.max, pids.current
cpusetCPU 亲和性cpuset.cpus, cpuset.mems
hugetlb大页内存限制hugetlb.2MB.max

2.3 OverlayFS:分层文件系统#

OverlayFS 将多个目录”叠加”为一个统一的文件系统视图。容器镜像的每一层对应一个目录,最上层是可写的容器层:

# 查看 Docker 容器的 OverlayFS 挂载
mount | grep overlay
# 输出示例:
# overlay on /var/lib/docker/overlay2/abc123/merged type overlay
# (rw,relatime,
# lowerdir=/var/lib/docker/overlay2/layer1:/var/lib/docker/overlay2/layer2,
# upperdir=/var/lib/docker/overlay2/abc123/diff,
# workdir=/var/lib/docker/overlay2/abc123/work)
# 手动创建 OverlayFS
mkdir -p /tmp/overlay/{lower1,lower2,upper,work,merged}
echo "base layer" > /tmp/overlay/lower1/file1.txt
echo "app layer" > /tmp/overlay/lower2/file2.txt
sudo mount -t overlay overlay /tmp/overlay/merged \
-o lowerdir=/tmp/overlay/lower2:/tmp/overlay/lower1,\
upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/work
# 查看合并后的文件系统
ls /tmp/overlay/merged/
# file1.txt file2.txt

2.4 三大基石的协作关系#

graph TB subgraph 容器进程["容器进程看到的视图"] PID["PID 1<br/>init 进程"] FS["/ 根文件系统<br/>Ubuntu + App"] NET["eth0<br/>独立 IP 地址"] USER["root (UID 0)<br/>映射到宿主普通用户"] LIMIT["CPU 2 核<br/>内存 512MB"] end subgraph 内核机制["Linux 内核机制"] NS["Namespace<br/>视图隔离"] CG["Cgroup<br/>资源限制"] OVL["OverlayFS<br/>分层文件系统"] end subgraph 宿主机["宿主机实际状态"] HPID["PID 12345<br/>普通进程"] HFS["/var/lib/docker/overlay2/...<br/>多层目录叠加"] HNET["vethabc123<br/>虚拟网卡对"] HUSER["UID 100000<br/>普通用户"] HRES["CPU 0-3<br/>内存 16GB"] end PID -.->|"PID Namespace"| NS FS -.->|"Mount Namespace + OverlayFS"| OVL NET -.->|"Network Namespace"| NS USER -.->|"User Namespace"| NS LIMIT -.->|"Cgroup"| CG NS --> HPID OVL --> HFS NS --> HNET NS --> HUSER CG --> HRES style 容器进程 fill:#e3f2fd,stroke:#1565c0 style 内核机制 fill:#e8f5e9,stroke:#2e7d32 style 宿主机 fill:#fce4ec,stroke:#c62828

三、容器运行时架构#

3.1 Docker 的架构演进#

Docker 的架构经历了从”大而全”到”分层解耦”的演进:

早期架构(Docker 1.11 之前):docker daemon 直接管理容器生命周期,所有功能(镜像、网络、存储、运行时)集成在一个进程中。

现代架构(Docker 1.11+):Docker 将容器运行时拆分为三层:

flowchart TB subgraph 用户层["用户层"] CLI["docker CLI"] end subgraph Daemon层["Daemon 层"] DOCKERD["dockerd<br/>镜像管理/网络/Volume"] end subgraph 运行时层["运行时层"] CTNRD["containerd<br/>容器生命周期管理"] SHIM["containerd-shim<br/>进程监督/解耦"] RUNC["runc<br/>OCI 运行时实现"] end subgraph 内核层["内核层"] KERNEL["Linux Kernel<br/>Namespace/Cgroup/OverlayFS"] end CLI -->|"gRPC"| DOCKERD DOCKERD -->|"gRPC (containerd.sock)"| CTNRD CTNRD -->|"启动 shim 进程"| SHIM SHIM -->|"exec runc"| RUNC RUNC -->|"系统调用"| KERNEL RUNC -->|"容器进程"| CONTAINER["容器进程"] SHIM -->|"监督"| CONTAINER style CLI fill:#bbdefb,stroke:#1565c0 style DOCKERD fill:#c8e6c9,stroke:#2e7d32 style CTNRD fill:#ffe0b2,stroke:#e65100 style RUNC fill:#ffcdd2,stroke:#c62828 style KERNEL fill:#e1bee7,stroke:#6a1b9a

3.2 为什么需要三层运行时?#

很多人会问:为什么不能让 Docker 直接调用 runc?为什么要引入 containerd 和 shim?

问题没有分层有分层
Docker 升级升级 dockerd 会杀掉所有容器containerd 独立升级,容器不受影响
运行时替换只能用 Docker 内置运行时containerd 支持多种运行时(runc/kata/gvisor)
容器进程管理dockerd 是容器进程的父进程,daemon 崩溃影响所有容器shim 是容器进程的父进程,containerd 重启不影响容器
Kubernetes 集成K8s 需要对接 Docker APIK8s 通过 CRI 直接对接 containerd

3.3 高层运行时 vs 低层运行时#

容器运行时分为两层:

层级代表职责类比
高层运行时(High-level Runtime)containerd, CRI-O镜像管理、容器生命周期、API 服务操作系统
低层运行时(Low-level Runtime)runc, kata, gVisor创建/启动容器进程、配置内核隔离引导加载程序
# 高层运行时:containerd 管理容器生命周期
ctr containers list
ctr tasks list
# 低层运行时:runc 直接操作容器
runc list
runc spec # 生成 OCI Bundle 规范文件

3.4 容器运行时生态全景#

graph TB subgraph 编排层["编排层"] K8S["Kubernetes"] SWARM["Docker Swarm"] NOMAD["Nomad"] end subgraph CRI接口["CRI 接口"] CRI["CRI (Container Runtime Interface)"] end subgraph 高层运行时["高层运行时"] CTNRD["containerd"] CRIO["CRI-O"] DOCKERD["dockerd (via cri-dockerd)"] end subgraph 低层运行时["低层运行时"] RUNC["runc"] KATA["Kata Containers"] GVISOR["gVisor (runsc)"] WASM["WasmEdge"] end subgraph 内核["Linux 内核"] NS["Namespace"] CG["Cgroup"] OVL["OverlayFS"] SEC["seccomp/AppArmor"] end K8S --> CRI SWARM --> DOCKERD NOMAD --> CTNRD CRI --> CTNRD CRI --> CRIO CRI --> DOCKERD CTNRD --> RUNC CTNRD --> KATA CTNRD --> GVISOR CTNRD --> WASM CRIO --> RUNC CRIO --> KATA DOCKERD --> CTNRD RUNC --> NS RUNC --> CG RUNC --> OVL RUNC --> SEC KATA -.->|"VM 隔离"| NS GVISOR -.->|"用户态内核"| SEC WASM -.->|"WASI 接口"| NS style 编排层 fill:#e8eaf6,stroke:#283593 style 高层运行时 fill:#e0f2f1,stroke:#00695c style 低层运行时 fill:#fff3e0,stroke:#e65100 style 内核 fill:#fce4ec,stroke:#880e4f

四、OCI 规范体系#

4.1 OCI 的三大规范#

OCI 定义了容器生态的三个核心规范:

规范定义内容当前版本
Image Spec镜像格式、manifest、config、layerv1.1
Runtime Spec运行时接口、OCI Bundle、config.jsonv1.2
Distribution Spec镜像分发协议、Registry APIv1.1
# OCI Image Spec:镜像 manifest 示例
{
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"config": {
"mediaType": "application/vnd.oci.image.config.v1+json",
"size": 7023,
"digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7"
},
"layers": [
{
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
"size": 32654,
"digest": "sha256:9834876dcfb05cb167a5c24953eba58c4ac89b1adf57f28f2f9d09af107ee8f0"
}
]
}

4.2 OCI Bundle:运行时的输入#

OCI Runtime Spec 定义了”OCI Bundle”——一个包含 rootfs 和 config.json 的目录,是低层运行时的标准输入:

# 创建 OCI Bundle
mkdir -p /tmp/bundle/rootfs
cd /tmp/bundle
# 导出 rootfs
docker export $(docker create busybox) | tar -C rootfs -xvf -
# 生成 config.json(OCI Runtime Spec 格式)
runc spec
# 查看 config.json 的关键配置
cat config.json | python3 -m json.tool | head -40
{
"ociVersion": "1.0.2",
"process": {
"terminal": true,
"user": { "uid": 0, "gid": 0 },
"args": ["sh"],
"env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],
"cwd": "/"
},
"root": {
"path": "rootfs",
"readonly": true
},
"linux": {
"namespaces": [
{ "type": "pid" },
{ "type": "mount" },
{ "type": "ipc" },
{ "type": "uts" },
{ "type": "network" }
]
}
}

4.3 从镜像到运行:OCI 规范的串联#

sequenceDiagram participant Registry as OCI Registry participant Containerd as containerd participant Runc as runc participant Kernel as Linux Kernel Note over Registry,Kernel: OCI 规范串联:Image Spec → Runtime Spec Registry->>Containerd: 1. 拉取镜像(Distribution Spec) Note right of Containerd: 解析 manifest(Image Spec)<br/>下载 config + layers Containerd->>Containerd: 2. 解压 layers 到 OverlayFS Note right of Containerd: lowerdir = 镜像层<br/>upperdir = 容器可写层 Containerd->>Containerd: 3. 生成 OCI Bundle Note right of Containerd: rootfs = merged OverlayFS<br/>config.json = Runtime Spec Containerd->>Runc: 4. 调用 runc create/run Note right of Runc: 读取 config.json<br/>配置 Namespace/Cgroup/安全 Runc->>Kernel: 5. 系统调用创建容器 Note right of Kernel: clone(CLONE_NEWPID|CLONE_NEWNS|...)<br/>mount overlay<br/>write cgroup files Kernel-->>Runc: 容器进程启动 Runc-->>Containerd: 返回容器 PID

五、关键概念辨析#

5.1 容器 vs 虚拟机#

维度容器虚拟机
隔离级别进程级(Namespace)硬件级(VT-x/AMD-V)
内核共享共享宿主内核独立内核
启动速度毫秒级秒级
资源开销MB 级GB 级
镜像大小MB~百 MBGB 级
密度单机数百~数千单机数十
安全边界较弱(内核漏洞可逃逸)较强(硬件虚拟化隔离)
性能损耗接近原生5%~15% 虚拟化开销

5.2 容器进程 vs 普通进程#

容器进程本质上就是一个带有特殊 Namespace/Cgroup/OverlayFS 配置的 Linux 进程

# 在宿主机上,容器进程就是一个普通进程
ps aux | grep nginx
# root 12345 0.0 0.1 ... nginx: master process
# 查看容器进程的 Namespace
ls -la /proc/12345/ns/
# 与宿主进程不同,容器进程的 Namespace 是独立的
# 查看容器进程的 Cgroup
cat /proc/12345/cgroup
# 容器进程在独立的 Cgroup 子树中
# 容器进程看到的文件系统
sudo nsenter -t 12345 -m -- ls /
# 看到的是 OverlayFS 合并后的 rootfs

5.3 镜像 vs 容器 vs Bundle#

概念定义格式生命周期
镜像(Image)不可变的应用打包格式OCI Image Spec持久化存储
容器(Container)镜像的运行实例OCI Runtime Spec临时的
Bundle运行时输入(rootfs + config.json)OCI Runtime Spec临时的
# 镜像 → 容器 → Bundle 的关系
docker pull nginx # 拉取镜像(OCI Image Spec 格式)
docker create nginx # 创建容器(生成 OCI Bundle)
docker start <id> # 启动容器(runc 读取 Bundle)
# 等价的底层操作
ctr image pull docker.io/library/nginx:latest
ctr container create docker.io/library/nginx:latest mynginx
ctr task start mynginx

六、动手实践:用 runc 手动创建容器#

这个实践让你绕过 Docker 和 containerd,直接用 runc 体验 OCI Runtime Spec 的工作方式:

#!/bin/bash
# 手动创建 OCI Bundle 并运行容器
# 1. 创建 Bundle 目录
mkdir -p /tmp/mycontainer/rootfs
cd /tmp/mycontainer
# 2. 导出 rootfs(从 busybox 镜像)
docker export $(docker create busybox) | tar -C rootfs -xvf -
# 3. 生成 OCI Runtime Spec 配置
runc spec
# 4. 修改 config.json(可选)
# 例如:修改 process.args 改变启动命令
# 修改 linux.namespaces 添加/删除 Namespace
# 5. 用 runc 运行容器
sudo runc run mycontainer
# 在另一个终端查看容器状态
sudo runc list
# 查看容器的 Namespace
sudo ls -la /proc/$(pgrep -f "mycontainer")/ns/
// 用 Go 代码创建 OCI Bundle
package main
import (
"encoding/json"
"fmt"
"os"
"os/exec"
specs "github.com/opencontainers/runtime-spec/specs-go"
)
func main() {
// 创建 OCI Runtime Spec
spec := &specs.Spec{
Version: "1.0.2",
Process: &specs.Process{
Terminal: true,
User: specs.User{UID: 0, GID: 0},
Args: []string{"sh"},
Env: []string{"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"},
Cwd: "/",
},
Root: &specs.Root{
Path: "rootfs",
Readonly: true,
},
Linux: &specs.Linux{
Namespaces: []specs.LinuxNamespace{
{Type: specs.PIDNamespace},
{Type: specs.MountNamespace},
{Type: specs.IPCNamespace},
{Type: specs.UTSNamespace},
{Type: specs.NetworkNamespace},
},
},
}
// 写入 config.json
data, _ := json.MarshalIndent(spec, "", " ")
os.WriteFile("config.json", data, 0644)
// 调用 runc 运行
cmd := exec.Command("runc", "run", "my-container")
cmd.Stdin = os.Stdin
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
if err := cmd.Run(); err != nil {
fmt.Fprintf(os.Stderr, "runc run failed: %v\n", err)
os.Exit(1)
}
}

七、本章小结#

主题核心要点关键词
演进脉络从 chroot 的目录隔离到 OCI 的标准化,容器技术走过了 40 年chroot, OCI
三大基石Namespace(视图隔离)+ Cgroup(资源限制)+ OverlayFS(分层文件系统)Namespace, Cgroup, OverlayFS
分层架构Docker(CLI)→ containerd(高层运行时)→ shim(进程监督)→ runc(低层运行时)containerd, shim, runc
OCI 规范Image Spec(镜像格式)+ Runtime Spec(运行时接口)+ Distribution Spec(分发协议)Image Spec, Runtime Spec
核心认知容器进程 = 普通 Linux 进程 + 特殊的 Namespace/Cgroup/OverlayFS 配置容器即进程

支持与分享

如果这篇文章对你有帮助,欢迎支持作者或分享给更多人

容器全景:从 chroot 到 OCI
https://blog.souloss.com/posts/container-runtime/container-overview/
作者
Souloss
发布于
2026-04-05
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

相关文章 智能推荐
1
容器完整流程:docker run 背后
容器运行时 当你执行 docker run nginx 时,背后发生了什么?本章完整追踪从 Docker CLI 到容器进程启动的每一步——镜像拉取、OCI Bundle 生成、shim 启动、runc 创建、Namespace/Cgroup/OverlayFS 配置、容器进程执行,让你对 docker run 的每一步都了如指掌。
2
系列导读
容器运行时 本系列从 Linux 内核的 Namespace、Cgroup、OverlayFS 出发,深入 OCI 规范、runc 源码、containerd 架构,再到容器安全、沙箱运行时、网络、存储、镜像构建、Wasm 容器,最后综合实战构建一个迷你容器运行时——从「会用 Docker」到「理解容器运行时的每一行代码」,每章配有可运行的代码示例与架构图,让你从容器用户进阶到容器运行时工程师。
3
Wasm 容器:WasmEdge/WASI
容器运行时 WebAssembly(Wasm)正在从浏览器走向服务器——WASI(WebAssembly System Interface)定义了 Wasm 访问操作系统的标准接口,WasmEdge/runwasi 等运行时让 Wasm 模块可以作为容器运行。详细解读 Wasm 容器的架构、WASI 接口、与 OCI 的集成、与 Linux 容器的对比——从「Wasm 只能在浏览器运行」到「Wasm 是下一代容器运行时」。
4
容器存储
容器运行时 容器的可写层随容器删除而丢失,数据持久化需要 Volume。一网打尽容器存储的完整方案——Volume(绑定挂载/命名卷/tmpfs)、存储驱动(overlay2/devicemapper/btrfs)、CSI(容器存储接口)插件机制,以及 Kubernetes 的 PV/PVC/StorageClass 体系——从「docker run -v」到「理解容器存储的每一条挂载规则」。
5
容器网络
容器运行时 容器网络的核心问题是——隔离的 Network Namespace 如何与外部通信?详细解读 veth pair(虚拟网卡对)、bridge(虚拟网桥)、iptables/NAT(地址转换)、CNI(容器网络接口)的完整链路,以及 Docker 的四种网络模式和 Kubernetes 的 Pod 网络模型——从「容器能 ping 通外网」到「理解每一条网络规则」。