Fix heading hierarchy

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)

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 .` 从上一阶段的镜像中复制文件，我们也可以复制任意镜像中的文件。
 

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 网络管理中常用的命令：
 

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 早期用于容器互联的方式，**已经被废弃**，不建议在新项目中使用。请使用自定义网络替代：
 

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 规则 (内核态) 来实现端口转发。
 

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 典型网络架构
 
 一个典型的多层应用网络架构如下：
 

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 定义多个相互关联的服务，以及如何在容器化环境中管理应用的生命周期。

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. 支持多种容器运行时选择

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` 集群的最佳实践。
 

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. 验证集群健康状态

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
 
 显示各个命令的帮助信息

17_ecosystem/README.md

@@ -2,10 +2,28 @@
 
 本章将介绍 Docker 和 Kubernetes 之外的容器生态技术。
 
-- **Fedora CoreOS**：专为容器化工作负载设计的操作系统。
+## 本章内容
-- **Podman**：兼容 Docker CLI 的下一代无守护进程容器引擎。
+
-- **Buildah**：无需守护进程的 OCI 容器镜像构建工具。
+* [Fedora CoreOS 简介](17.1_coreos_intro.md)
-- **Skopeo**：远程检查和管理容器镜像的利器。
+  * 专为容器化工作负载设计的操作系统。
-- **containerd**：作为现代容器生态基石的核心容器运行时。
+
-- **安全容器运行时**：通过提供更强隔离性来保证安全的技术方案（如 Kata Containers、gVisor）。
+* [Fedora CoreOS 安装与配置](17.2_coreos_install.md)
-- **WebAssembly**：一种极具潜力的轻量级跨平台二进制指令格式。
+  * 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)
+  * 一种极具潜力的轻量级跨平台二进制指令格式。

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`。