Fix heading hierarchy

2026-03-11 04:14:38 +00:00 · 2026-03-05 19:24:01 -08:00
parent f5cfa4140a
commit 70ef2cba58
14 changed files with 231 additions and 61 deletions
--- a/02_basic_concept/README.md
+++ b/02_basic_concept/README.md
@@ -7,3 +7,9 @@
 * **仓库** (`Repository`)：镜像构建完成后，可以很容易的在当前宿主机上运行，但是，如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，Docker Registry 就是这样的服务。

 理解了这三个概念，就理解了 **Docker** 的整个生命周期。
+
+## 本章内容
+
+* [Docker 镜像](2.1_image.md)
+* [Docker 容器](2.2_container.md)
+* [Docker 仓库](2.3_repository.md)
--- a/07_dockerfile/7.17_multistage_builds.md
+++ b/07_dockerfile/7.17_multistage_builds.md
@@ -118,7 +118,7 @@ go/helloworld   2      f7cf3465432c    22 seconds ago  6.47MB
 go/helloworld   1      f55d3e16affc    2 minutes ago   295MB
 ```

-## 7.17 使用多阶段构建
+### 7.17.3 使用多阶段构建

 为解决以上问题，Docker v17.05 开始支持多阶段构建 (`multistage builds`)。使用多阶段构建我们就可以很容易解决前面提到的问题，并且只需要编写一个 `Dockerfile`：

@@ -167,7 +167,7 @@ go/helloworld     1     f55d3e16affc     2 minutes ago      295MB

 很明显使用多阶段构建的镜像体积小，同时也完美解决了上边提到的问题。

-### 7.17.1 只构建某一阶段的镜像
+### 7.17.4 只构建某一阶段的镜像

 我们可以使用 `as` 来为某一阶段命名，例如

@@ -181,7 +181,7 @@ FROM golang:alpine as builder
 $ docker build --target builder -t username/imagename:tag .
 ```

-### 7.17.2 构建时从其他镜像复制文件
+### 7.17.5 构建时从其他镜像复制文件

 上面例子中我们使用 `COPY --from=0 /go/src/github.com/go/helloworld/app .` 从上一阶段的镜像中复制文件，我们也可以复制任意镜像中的文件。

--- a/09_network/9.3_custom_network.md
+++ b/09_network/9.3_custom_network.md
@@ -2,7 +2,7 @@

 在生产环境中，推荐使用用户自定义网络代替默认的 bridge 网络。自定义网络提供了更好的隔离性和服务发现能力。

-### 9.4.1 为什么要用自定义网络
+### 9.3.1 为什么要用自定义网络

 默认 bridge 网络存在以下局限，而自定义网络可以很好地解决这些问题：

@@ -12,7 +12,7 @@
 | 所有容器在同一网络 | 更好的隔离性 |
 | 需要 --link (已废弃)| 原生支持服务发现 |

-### 9.4.2 创建自定义网络
+### 9.3.2 创建自定义网络

 使用 `docker network create` 命令可以创建自定义网络：

@@ -26,7 +26,7 @@ $ docker network create mynet
 $ docker network inspect mynet
 ```

-### 9.4.3 使用自定义网络
+### 9.3.3 使用自定义网络

 启动容器时通过 `--network` 参数指定连接的网络：

@@ -43,7 +43,7 @@ PING db (172.18.0.3): 56 data bytes
 64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.083 ms
 ```

-### 9.4.4 容器名 DNS 解析
+### 9.3.4 容器名 DNS 解析

 自定义网络自动提供 DNS 服务。Docker 守护进程在 `127.0.0.11` 运行了一个嵌入式 DNS 服务器，容器内的 DNS 请求会被转发到这里：

@@ -58,7 +58,7 @@ flowchart LR
    end
 ```

-### 9.4.5 常用网络命令
+### 9.3.5 常用网络命令

 以下是 Docker 网络管理中常用的命令：

--- a/09_network/9.4_container_linking.md
+++ b/09_network/9.4_container_linking.md
@@ -2,7 +2,7 @@

 容器之间的网络通信是 Docker 网络的核心功能之一。本节介绍容器互联的几种方式。

-### 9.5.1 同一网络内的容器
+### 9.4.1 同一网络内的容器

 同一自定义网络内的容器可以直接通过容器名通信，这是推荐的容器互联方式：

@@ -21,7 +21,7 @@ $ docker run -d --name app --network app-net myapp
 ...
 ```

-### 9.5.2 连接到多个网络
+### 9.4.2 连接到多个网络

 一个容器可以同时连接到多个网络，这对于需要跨网络通信的中间件容器特别有用：

@@ -39,7 +39,7 @@ $ docker network connect backend multi-net-container
 $ docker inspect multi-net-container --format '{{json .NetworkSettings.Networks}}'
 ```

-### 9.5.3 ⚠️ --link 已废弃
+### 9.4.3 ⚠️ --link 已废弃

 `--link` 是 Docker 早期用于容器互联的方式，**已经被废弃**，不建议在新项目中使用。请使用自定义网络替代：

--- a/09_network/9.5_port_mapping.md
+++ b/09_network/9.5_port_mapping.md
@@ -2,7 +2,7 @@

 容器运行在自己的隔离网络环境中 (通常是 Bridge 模式)。为了让外部网络访问容器内的服务，我们需要将容器的端口映射到宿主机的端口。

-### 9.6.1 为什么要映射端口
+### 9.5.1 为什么要映射端口

 容器的网络访问规则如下：

@@ -21,7 +21,7 @@ flowchart TD

 ---

-### 9.6.2 端口映射方式
+### 9.5.2 端口映射方式

 Docker 提供了多种方式来指定端口映射。

@@ -66,7 +66,7 @@ abc123456      0.0.0.0:49153->80/tcp

 ---

-### 9.6.3 查看端口映射
+### 9.5.3 查看端口映射

 可以使用以下命令查看容器的端口映射：

@@ -92,7 +92,7 @@ abc123456      nginx     0.0.0.0:8080->80/tcp   web

 ---

-### 9.6.4 最佳实践与安全
+### 9.5.4 最佳实践与安全

 在配置端口映射时，需要注意以下安全事项：

@@ -127,7 +127,7 @@ $ docker run -d -p 53:53/udp dns-server

 ---

-### 9.6.5 实现原理
+### 9.5.5 实现原理

 Docker 使用 `docker-proxy` 进程 (用户态) 或 `iptables` DNAT 规则 (内核态) 来实现端口转发。

--- a/09_network/9.6_network_isolation.md
+++ b/09_network/9.6_network_isolation.md
@@ -2,7 +2,7 @@

 Docker 网络提供了天然的隔离能力，不同网络之间的容器默认无法通信。这是 Docker 网络安全的重要基础。

-### 9.7.1 网络隔离原理
+### 9.6.1 网络隔离原理

 不同网络之间默认隔离，容器只能与同一网络中的容器直接通信：

@@ -26,7 +26,7 @@ $ docker exec web ping db
 ping: db: Name or service not known
 ```

-### 9.7.2 安全优势
+### 9.6.2 安全优势

 这种隔离机制带来以下安全优势：

@@ -37,7 +37,7 @@ ping: db: Name or service not known
 | **多租户** | 不同租户的容器在不同网络中完全隔离 |
 | **最小权限** | 容器只能访问必要的网络资源 |

-### 9.7.3 跨网络通信
+### 9.6.3 跨网络通信

 如果确实需要某个容器跨网络通信，可以将其同时连接到多个网络：

@@ -52,7 +52,7 @@ $ docker network connect backend api

 这种方式让你可以精确控制哪些容器可以跨网络通信，遵循最小权限原则。

-### 9.7.4 典型网络架构
+### 9.6.4 典型网络架构

 一个典型的多层应用网络架构如下：

--- a/11_compose/11.9_lnmp.md
+++ b/11_compose/11.9_lnmp.md
@@ -1,3 +1,38 @@
 ## 11.9 实战 LNMP

-本项目的维护者 [khs1994](https://github.com/khs1994) 的开源项目 [khs1994-docker/lnmp](https://github.com/khs1994-docker/lnmp) 使用 Docker Compose 搭建了一套 LNMP 环境，各位开发者可以参考该项目在 Docker 或 Kubernetes 中运行 LNMP。
+### 什么是 LNMP
+
+LNMP 是一个经典的 Web 应用栈，由以下四个开源软件组合而成：
+
+- **L**：Linux（操作系统）
+- **N**：Nginx（Web 服务器）
+- **M**：MySQL（数据库服务器）
+- **P**：PHP（脚本语言）
+
+这个组合被广泛用于构建高性能的 Web 应用。
+
+### 使用 Docker Compose 部署 LNMP
+
+本项目的维护者 [khs1994](https://github.com/khs1994) 的开源项目 [khs1994-docker/lnmp](https://github.com/khs1994-docker/lnmp) 使用 Docker Compose 搭建了一套完整的 LNMP 环境。
+
+### 参考项目
+
+该项目中包含的服务：
+
+- **Nginx**：Web 服务器，用于处理 HTTP 请求
+- **MySQL/MariaDB**：关系型数据库服务
+- **PHP-FPM**：PHP 处理器，与 Nginx 通过 Fast CGI 协议通信
+- **Redis**：可选的内存缓存服务（用于会话或缓存）
+
+### 学习资源
+
+各位开发者可以参考该项目在以下场景中运行 LNMP：
+
+- Docker 容器化部署
+- Kubernetes 集群编排
+- 开发环境快速搭建
+- 生产环境配置参考
+
+项目地址：https://github.com/khs1994-docker/lnmp
+
+通过该项目，你可以学习到如何使用 Docker Compose 定义多个相互关联的服务，以及如何在容器化环境中管理应用的生命周期。
--- a/12_implementation/12.2_namespace.md
+++ b/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 提供了隔离但不是安全边界：

--- a/12_implementation/12.5_container_format.md
+++ b/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. 支持多种容器运行时选择
--- a/14_kubernetes_setup/14.1_kubeadm.md
+++ b/14_kubernetes_setup/14.1_kubeadm.md
@@ -1,4 +1,4 @@
-## 14.1 使用 kubeadm 部署 Kubernetes (CRI 使用 containerd)
+## 14.1 使用 kubeadm 部署 Kubernetes

 `kubeadm` 提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令，作为快速创建 `Kubernetes` 集群的最佳实践。

--- a/14_kubernetes_setup/14.6_systemd.md
+++ b/14_kubernetes_setup/14.6_systemd.md
@@ -1,3 +1,67 @@
 ## 14.6 一步步部署 Kubernetes 集群

-可以参考 [opsnull/follow-me-install-kubernetes-cluster](https://github.com/opsnull/follow-me-install-kubernetes-cluster) 项目一步步部署 Kubernetes 集群。
+### 概述
+
+部署 Kubernetes 集群涉及多个组件的安装和配置，包括 Master 节点和 Worker 节点。本章介绍如何使用 systemd 管理这些服务的生命周期。
+
+### Kubernetes 主要组件
+
+#### Master 节点组件
+
+- **kube-apiserver**：API 服务器，Kubernetes 集群的中心
+- **kube-controller-manager**：控制器管理器
+- **kube-scheduler**：调度器，负责 Pod 调度
+- **etcd**：分布式键值存储，存储集群数据
+
+#### Worker 节点组件
+
+- **kubelet**：节点代理，管理容器生命周期
+- **kube-proxy**：网络代理，处理服务网络
+- **Container Runtime**：容器运行时（Docker、containerd 等）
+
+### 使用 systemd 管理 Kubernetes 服务
+
+#### 服务单元文件
+
+为了让 systemd 管理 Kubernetes 服务，需要创建相应的 `.service` 文件，例如：
+
+```
+/etc/systemd/system/kubelet.service
+/etc/systemd/system/kube-proxy.service
+/etc/systemd/system/kube-apiserver.service
+```
+
+#### 常用命令
+
+```bash
+# 启动服务
+sudo systemctl start kubelet
+
+# 停止服务
+sudo systemctl stop kubelet
+
+# 重启服务
+sudo systemctl restart kubelet
+
+# 查看服务状态
+sudo systemctl status kubelet
+
+# 设置开机自启
+sudo systemctl enable kubelet
+```
+
+### 参考资源
+
+详细的部署步骤和配置说明，可以参考以下项目：
+
+- [opsnull/follow-me-install-kubernetes-cluster](https://github.com/opsnull/follow-me-install-kubernetes-cluster)：一个完整的 Kubernetes 集群部署指南项目
+
+该项目提供了详细的步骤说明，涵盖 Master 节点、Worker 节点的安装配置，以及如何使用 systemd 管理这些组件的生命周期。
+
+### 推荐学习路径
+
+1. 理解 Kubernetes 架构和各组件的作用
+2. 准备所需的系统环境（Linux 主机、网络配置等）
+3. 按步骤安装各个 Kubernetes 组件
+4. 配置 systemd 服务单元文件
+5. 验证集群健康状态
--- a/14_kubernetes_setup/14.8_kubectl.md
+++ b/14_kubernetes_setup/14.8_kubectl.md
@@ -8,74 +8,74 @@ kubectl [flags]
 kubectl [command]
 ```

-## 14.8 get
+### 14.8.1 get

 显示一个或多个资源

-## 14.8 describe
+### 14.8.2 describe

 显示资源详情

-## 14.8 create
+### 14.8.3 create

 从文件或标准输入创建资源

-## 14.8 update
+### 14.8.4 update

 从文件或标准输入更新资源

-## 14.8 delete
+### 14.8.5 delete

 通过文件名、标准输入、资源名或者 label selector 删除资源

-## 14.8 logs
+### 14.8.6 logs

 输出 pod 中一个容器的日志

-## 14.8 rollout
+### 14.8.7 rollout

 对 Deployment 等资源执行滚动更新/回滚

-## 14.8 exec
+### 14.8.8 exec

 在容器内部执行命令

-## 14.8 port-forward
+### 14.8.9 port-forward

 将本地端口转发到 Pod

-## 14.8 proxy
+### 14.8.10 proxy

 为 Kubernetes API server 启动代理服务器

-## 14.8 run
+### 14.8.11 run

 在集群中使用指定镜像启动容器

-## 14.8 expose
+### 14.8.12 expose

 将 replication controller service 或 pod 暴露为新的 Kubernetes service

-## 14.8 label
+### 14.8.13 label

 更新资源的 label

-## 14.8 config
+### 14.8.14 config

 修改 Kubernetes 配置文件

-## 14.8 cluster-info
+### 14.8.15 cluster-info

 显示集群信息

-## 14.8 api-versions
+### 14.8.16 api-versions

 以 “组/版本” 的格式输出服务端支持的 API 版本

-## 14.8 version
+### 14.8.17 version

 输出服务端和客户端的版本信息

-## 14.8 help
+### 14.8.18 help

 显示各个命令的帮助信息
--- a/17_ecosystem/README.md
+++ b/17_ecosystem/README.md
@@ -2,10 +2,28 @@

 本章将介绍 Docker 和 Kubernetes 之外的容器生态技术。

- **Fedora CoreOS**：专为容器化工作负载设计的操作系统。
- **Podman**：兼容 Docker CLI 的下一代无守护进程容器引擎。
- **Buildah**：无需守护进程的 OCI 容器镜像构建工具。
- **Skopeo**：远程检查和管理容器镜像的利器。
- **containerd**：作为现代容器生态基石的核心容器运行时。
- **安全容器运行时**：通过提供更强隔离性来保证安全的技术方案（如 Kata Containers、gVisor）。
- **WebAssembly**：一种极具潜力的轻量级跨平台二进制指令格式。
+## 本章内容
+
+* [Fedora CoreOS 简介](17.1_coreos_intro.md)
+  * 专为容器化工作负载设计的操作系统。
+
+* [Fedora CoreOS 安装与配置](17.2_coreos_install.md)
+  * CoreOS 的安装方式与基本配置。
+
+* [Podman](17.3_podman.md)
+  * 兼容 Docker CLI 的下一代无守护进程容器引擎。
+
+* [Buildah](17.4_buildah.md)
+  * 无需守护进程的 OCI 容器镜像构建工具。
+
+* [Skopeo](17.5_skopeo.md)
+  * 远程检查和管理容器镜像的利器。
+
+* [containerd](17.6_containerd.md)
+  * 作为现代容器生态基石的核心容器运行时。
+
+* [安全容器运行时](17.7_secure_runtime.md)
+  * 通过提供更强隔离性来保证安全的技术方案（如 Kata Containers、gVisor）。
+
+* [WebAssembly](17.8_wasm.md)
+  * 一种极具潜力的轻量级跨平台二进制指令格式。
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,4 +1,4 @@
-# 如何贡献
+## 如何贡献

 领取或创建新的 [Issue](https://github.com/yeasy/docker_practice/issues)，如 [issue 235](https://github.com/yeasy/docker_practice/issues/235)，添加自己为 `Assignee`。