Add section numbers to ecosystem headings

17_ecosystem/17.6_containerd.md

@@ -2,7 +2,7 @@
 
 本节介绍 containerd，它是现代容器技术栈中最为核心的基础组件之一。了解 containerd 有助于更深入地理解 Docker 和 Kubernetes 的底层运行机制。
 
-### containerd 简介
+### 17.6.1 containerd 简介
 
 [containerd](https://containerd.io/) 是一个行业标准的容器运行时，它最初是由 Docker 引擎中剥离出来的一个核心组件，后来 Docker 将其捐赠给了云原生计算基金会（CNCF），目前已经是一个 CNCF 毕业（Graduated）项目。
 
@@ -13,7 +13,7 @@
 
 简单来说，当你在使用 Docker 或者 Kubernetes 时，真正去底层调用操作系统接口（如 Linux 的 Namespace 和 Cgroups）来启动和管理容器进程的，往往是 containerd（及它所调用的 runc 组件）。
 
-### 与 Docker 和 Kubernetes 的关系
+### 17.6.2 与 Docker 和 Kubernetes 的关系
 
 理解 containerd，首先要理清它与用户日常操作的 Docker 以及 Kubernetes 的关系。
 
@@ -37,14 +37,14 @@ Kubernetes 作为一个容器编排系统，为了屏蔽底层不同容器运行
 - 随着 containerd 原生支持了 CRI 插件，Kubernetes 开始直接与 containerd 通信，去掉了 `dockershim` 和 `dockerd` 的中间层。这就是为什么从 Kubernetes v1.24 开始”弃用 Docker”引发了广泛关注，实际上 Kubernetes 只是弃用 `dockershim`，底层依然在使用从 Docker 基因中诞生的 containerd。
 - containerd 2.0 移除了已弃用的 CRI v1alpha2 接口，仅保留 CRI v1（Kubernetes 自 v1.26 起仅支持 CRI v1）。如果集群中仍有依赖 CRI v1alpha2 的组件，升级 containerd 2.x 前需先完成迁移。containerd 2.3（2026 年 4 月）是首个 LTS 版本，支持从 1.7 LTS 直接升级，生产环境推荐使用。
 
-### 为什么直接使用 containerd？
+### 17.6.3 为什么直接使用 containerd？
 
 对普通应用开发者来说，Docker 依然是本地开发和测试的首选。但对于构建云平台、自动化流水线或深度管理 Kubernetes 集群的系统工程师来说，直接使用 containerd 可以带来：
 - **更高的性能与更少的开销**：去掉了 Docker Daemon 等附加组件的资源占用，链路更短。
 - **更强的稳定性**：作为专注于运行时的底层组件，它的核心功能极为稳定且更新受控。
 - **直接符合 Kubernetes CRI 标准**：在生产级 Kubernetes 集群中作为标准配置。
 
-### 基础用法与工具介绍
+### 17.6.4 基础用法与工具介绍
 
 不同于 `docker` 命令行工具，containerd 提供了不同的客户端来满足不同的使用场景：