Fix heading hierarchy

12_implementation/12.2_namespace.md

@@ -2,9 +2,9 @@
 
 命名空间是 Linux 内核一个强大的特性。每个容器都有自己单独的命名空间，运行在其中的应用都像是在独立的操作系统中运行一样。命名空间保证了容器之间彼此互不影响。
 
-## 12.2 什么是 Namespace
+### 12.2.1 什么是 Namespace
 
-> **Namespace 是 Linux 内核提供的资源隔离机制，它让容器内的进程仿佛运行在独立的操作系统中。** Namespace 是容器技术的核心基础之一。它回答了一个关键问题：**如何让一个进程 “以为” 自己独占整个系统？**
+> **Namespace 是 Linux 内核提供的资源隔离机制，它让容器内的进程仿佛运行在独立的操作系统中。**Namespace 是容器技术的核心基础之一。它回答了一个关键问题：**如何让一个进程 “以为” 自己独占整个系统？**
 
 ```mermaid
 flowchart LR
@@ -26,7 +26,7 @@ flowchart LR
     H4 -. "（实际是宿主机的 1234）" .- C1
 ```
 
-### 12.2.1 Namespace 的类型
+### 12.2.2 Namespace 的类型
 
 Linux 内核提供了以下几种 Namespace，Docker 容器使用了全部：
 
@@ -42,7 +42,7 @@ Linux 内核提供了以下几种 Namespace，Docker 容器使用了全部：
 
 ---
 
-### 12.2.2 PID Namespace
+### 12.2.3 PID Namespace
 
 PID Namespace 负责进程 ID 的隔离，使得容器内的进程彼此不可见。
 
@@ -75,7 +75,7 @@ PID   USER     COMMAND
 
 ---
 
-### 12.2.3 NET Namespace
+### 12.2.4 NET Namespace
 
 NET Namespace 负责网络栈的隔离，包括网卡、路由表和 iptables 规则等。
 
@@ -110,7 +110,7 @@ flowchart LR
 
 ---
 
-### 12.2.4 MNT Namespace
+### 12.2.5 MNT Namespace
 
 MNT Namespace 负责文件系统挂载点的隔离，确保容器看到独立的文件系统视图。
 
@@ -143,7 +143,7 @@ MNT Namespace 负责文件系统挂载点的隔离，确保容器看到独立的
 
 ---
 
-### 12.2.5 UTS Namespace
+### 12.2.6 UTS Namespace
 
 UTS Namespace 主要用于隔离主机名和域名。
 
@@ -169,7 +169,7 @@ UTS = “UNIX Time-sharing System”，是历史遗留的名称。
 
 ---
 
-### 12.2.6 IPC Namespace
+### 12.2.7 IPC Namespace
 
 IPC Namespace 用于隔离进程间通信资源，如 System V IPC 和 POSIX 消息队列。
 
@@ -190,7 +190,7 @@ IPC Namespace 用于隔离进程间通信资源，如 System V IPC 和 POSIX 消
 
 ---
 
-### 12.2.7 USER Namespace
+### 12.2.8 USER Namespace
 
 USER Namespace 允许将容器内的用户 ID 映射到宿主机的不同用户 ID。
 
@@ -226,7 +226,7 @@ flowchart LR
 
 ---
 
-### 12.2.8 动手实验：体验 Namespace
+### 12.2.9 动手实验：体验 Namespace
 
 使用 `unshare` 命令可以在不使用 Docker 的情况下体验 Namespace：
 
@@ -285,7 +285,7 @@ $ ip addr
 
 ---
 
-### 12.2.9 Namespace 的局限性
+### 12.2.10 Namespace 的局限性
 
 Namespace 提供了隔离但不是安全边界：
 

12_implementation/12.5_container_format.md

@@ -1,3 +1,50 @@
 ## 12.5 容器格式
 
-最初，Docker 采用了 `LXC` 中的容器格式。从 0.7 版本以后开始去除 LXC，转而使用自行开发的 [libcontainer](https://github.com/docker/libcontainer)，从 1.11 开始，则进一步演进为使用 [runC](https://github.com/opencontainers/runc) 和 [containerd](https://github.com/containerd/containerd)。
+### Docker 容器格式的演进
+
+最初，Docker 采用了 `LXC` 中的容器格式。从 0.7 版本以后开始去除 LXC 的依赖，转而使用自行开发的 [libcontainer](https://github.com/docker/libcontainer)。从 1.11 开始，则进一步演进为使用 [runC](https://github.com/opencontainers/runc) 和 [containerd](https://github.com/containerd/containerd)。
+
+### 关键组件说明
+
+#### LXC（Linux 容器）
+
+Docker 早期版本（0.1-0.7）直接使用 LXC 作为容器运行时，利用 Linux Namespaces 和 Cgroups 实现容器隔离。
+
+#### libcontainer
+
+- Docker 自行开发的容器库
+- 提供了容器的通用接口
+- 不依赖于特定的 Linux 容器实现
+- 更灵活和可控
+
+#### runC
+
+- OCI（Open Container Initiative）标准实现
+- 轻量级的容器运行时
+- 独立的二进制文件，可单独使用
+- 基于 libcontainer 发展而来
+
+#### containerd
+
+- Docker 开源的容器运行时
+- 提供了容器的完整生命周期管理
+- 支持 runC 和其他 OCI 兼容的运行时
+- 在 Kubernetes 等编排系统中广泛使用
+
+### 容器规范标准
+
+Docker 积极参与 Open Container Initiative (OCI) 的制定，推动了以下规范的发展：
+
+- **Image Spec**：容器镜像格式规范
+- **Runtime Spec**：容器运行时接口规范
+- **Distribution Spec**：容器镜像分发规范
+
+### 架构演变的优势
+
+从 LXC → libcontainer → runC/containerd 的演变提供了以下优势：
+
+1. 减少外部依赖
+2. 提高运行效率
+3. 遵循行业标准（OCI）
+4. 增强可移植性和互操作性
+5. 支持多种容器运行时选择