diff --git a/17_ecosystem/17.4_buildah.md b/17_ecosystem/17.4_buildah.md index ed7df2d..2a42b41 100644 --- a/17_ecosystem/17.4_buildah.md +++ b/17_ecosystem/17.4_buildah.md @@ -2,20 +2,20 @@ 本节介绍 Buildah，包括其基础概念、应用场景以及基本指令。 -### Buildah 简介 +### 17.4.1 Buildah 简介 Buildah 是一个用于构建 OCI（Open Container Initiative）兼容格式容器镜像的开源命令行工具。与 Docker 需要一直运行的守护进程（daemon）不同，Buildah 的设计初衷是无需守护进程（daemonless）即可工作，并且也不强制要求 root 权限（rootless）。这使得在持续集成/持续部署（CI/CD）环境中构建镜像时能够更加轻量且安全。 Buildah 由 Red Hat 主导开发，通常和 Podman、Skopeo 一起使用，被认为是构建、运行和管理容器的一套现代化工具链。在很多需要增强安全性和无需依赖守护进程的场景中，Buildah 是 `docker build` 命令的最佳替代方案。 -### 核心特性 +### 17.4.2 核心特性 - **无守护进程（Daemonless）**：Buildah 直接通过系统调用拉取、构建和推送镜像，减少了单点故障的风险和资源开销。 - **构建效率高**：可以挂载镜像的根文件系统到本地，并直接利用宿主机的工具对其进行操作，非常灵活。 - **兼容性**：不仅支持处理传统的 Dockerfile，还能完全兼容 OCI（Open Container Initiative）标准和 Docker 格式。 - **与 Podman 集成**：Podman 自身构建镜像的命令 `podman build` 底层实际上也是依赖 Buildah 库来实现的。 -### 安装 Buildah +### 17.4.3 安装 Buildah 在许多主流的 Linux 发行版中都可以通过包管理器直接安装 Buildah。 @@ -31,7 +31,7 @@ $ sudo apt-get update $ sudo apt-get -y install buildah ``` -### 基础用法示例 +### 17.4.4 基础用法示例 #### 1. 从现有的 Dockerfile 构建镜像 diff --git a/17_ecosystem/17.5_skopeo.md b/17_ecosystem/17.5_skopeo.md index 20c2df8..fcbfd00 100644 --- a/17_ecosystem/17.5_skopeo.md +++ b/17_ecosystem/17.5_skopeo.md @@ -2,20 +2,20 @@ 本节介绍 Skopeo，包括其基础概念、应用场景以及基本指令。 -### Skopeo 简介 +### 17.5.1 Skopeo 简介 Skopeo 是一个由 Red Hat 赞助开源的命令行工具，它可以在不需要运行容器守护进程（如 Docker Daemon）的前提下，对容器镜像进行极其高效的操作和管理，包括：检查、复制、删除和签名等操作。 -Skopeo 最大的特点是其可以在“不将镜像拉取到本地”的情况下，直接在远端 Registry（镜像仓库）之间完成检查和搬运，从而大幅度节省带宽和磁盘空间。这也是它在容器运维和分发领域非常受欢迎的原因。 +Skopeo 最大的特点是其可以在”不将镜像拉取到本地”的情况下，直接在远端 Registry（镜像仓库）之间完成检查和搬运，从而大幅度节省带宽和磁盘空间。这也是它在容器运维和分发领域非常受欢迎的原因。 -### 核心特性 +### 17.5.2 核心特性 - **远程巡检**：通过 `skopeo inspect` 可以查看远端仓库中镜像的元数据（例如包含哪些层、环境变量信息、入口命令等），而完全无需拉取该镜像。 - **镜像复制与同步**：支持各种格式之间的相互传输，如在不同的容器仓库之间、或者从仓库拉取到本地的目录、或者存储为 OCI 布局结构等。 - **镜像删除**：可以远程删除仓库中的镜像（需要拥有权限）。 - **签名验证**：支持在分发镜像前进行数字签名以保障安全性。 -### 安装 Skopeo +### 17.5.3 安装 Skopeo 类似于 Buildah，Skopeo 也直接包含在大部分主流的 Linux 源中。 @@ -36,7 +36,7 @@ $ sudo apt-get -y install skopeo $ brew install skopeo ``` -### 基础用法示例 +### 17.5.4 基础用法示例 #### 1. 远程检查镜像 diff --git a/17_ecosystem/17.6_containerd.md b/17_ecosystem/17.6_containerd.md index ee7edd3..066194f 100644 --- a/17_ecosystem/17.6_containerd.md +++ b/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 提供了不同的客户端来满足不同的使用场景： diff --git a/17_ecosystem/17.7_secure_runtime.md b/17_ecosystem/17.7_secure_runtime.md index af2563c..4fe1270 100644 --- a/17_ecosystem/17.7_secure_runtime.md +++ b/17_ecosystem/17.7_secure_runtime.md @@ -2,15 +2,15 @@ 本节介绍容器技术生态中的安全运行时机制，主要探讨在隔离性和安全性上比标准 Linux 容器更进一步的方案，重点介绍 Kata Containers 和 gVisor。 -### 为什么需要安全容器？ +### 17.7.1 为什么需要安全容器？ 标准的 Linux 容器（如 Docker、Podman 或基础的 containerd/runc 所提供的）依赖于 Linux 内核的 **Namespace（命名空间）** 和 **Cgroups（控制组）** 来实现进程级别的隔离与资源限制。这种轻量级的虚拟化方式共享同一个宿主机的内核。 尽管这种方式在性能和启动速度上拥有巨大优势，但也带来了一个显著的缺点：**隔离性（Isolation）不足**。如果某个容器内的恶意进程利用了宿主机内核的漏洞完成了越狱（Privilege Escalation），它将对整个宿主机以及其上运行的所有其他容器造成毁灭性威胁。 -如果在公有云环境（多租户场景）或运行不可信的第三方代码时，共享内核显然是不够安全的。为了解决这一问题，社区推出了“安全容器（Secure Containers/Sandboxed Containers）”的概念。安全容器的核心理念是：提供类似虚拟机的强隔离性，同时保持类似容器的轻量、快速启动和标准化管理。 +如果在公有云环境（多租户场景）或运行不可信的第三方代码时，共享内核显然是不够安全的。为了解决这一问题，社区推出了”安全容器（Secure Containers/Sandboxed Containers）”的概念。安全容器的核心理念是：提供类似虚拟机的强隔离性，同时保持类似容器的轻量、快速启动和标准化管理。 -### 什么是 Kata Containers？ +### 17.7.2 什么是 Kata Containers？ [Kata Containers](https://katacontainers.io/) 是一个开源项目，由 OpenStack Foundation（现更名为 OpenInfra Foundation）托管。它将早期的两个项目——Intel Clear Containers 和 Hyper runV 结合而成。 @@ -24,7 +24,7 @@ Kata Containers 的核心思路是：**使用轻量级的虚拟机（Lightweight - **兼容性**：Kata Containers 完全实现了 OCI（Open Container Initiative）规范和 CRI（Container Runtime Interface）标准。这意味着它可以作为 `containerd` 或 `Docker` 的底层运行时无缝替换默认的 `runc`。 - **与 Kubernetes 集成**：在 Kubernetes 中，你可以为一个特定的 Pod 指定 `runtimeClassName: kata`，让高敏感的任务自动运行在虚拟机级别的隔离环境中。 -### 什么是 gVisor？ +### 17.7.3 什么是 gVisor？ [gVisor](https://gvisor.dev/) 是由 Google 开发并开源的一种不同流派的沙箱容器运行时方案。 @@ -38,7 +38,7 @@ gVisor 的核心组件是一个名为 **Sentry** 的用户空间进程。Sentry - 因为 Sentry 在用户态实现了一套 Linux 系统调用接口，它极大减少了应用直接接触底层操作系统内核的表面积。这样就有效防御了利用底层内核漏洞突破隔离的攻击方式。 - gVisor 同样兼容 OCI 规范，其核心运行时组件称为 `runsc`，可以作为底层运行时与 Docker 或 Kubernetes 进行集成。 -### 总结与对比 +### 17.7.4 总结与对比 | 特性 | 标准 Linux 容器 (runc) | Kata Containers | gVisor (runsc) | | :--- | :--- | :--- | :--- | diff --git a/17_ecosystem/17.8_wasm.md b/17_ecosystem/17.8_wasm.md index cc7e6b7..7dd6860 100644 --- a/17_ecosystem/17.8_wasm.md +++ b/17_ecosystem/17.8_wasm.md @@ -2,7 +2,7 @@ 本节介绍 WebAssembly (简写为 Wasm) 以及它为何成为现代容器生态中备受瞩目的前沿技术路线。 -### 什么是 WebAssembly？ +### 17.8.1 什么是 WebAssembly？ [WebAssembly (Wasm)](https://webassembly.org/) 最初是由 W3C 主导的一项为了解决网页中 JavaScript 性能瓶颈而发明的技术标准。它是一种小体积的、加载极快的、提供安全沙盒的高效二进制格式的指令集架构。通过将 C/C++、Rust、Go 等高级语言编译成 `.wasm` 格式，这些程序可以直接在所有现代的浏览器中以接近原生代码的速度安全地运行。 @@ -10,7 +10,7 @@ 因为开源社区很快意识到，Wasm 所具备的核心特性完美契合了云原生后端的诉求。人们制定了诸如 **WASI (WebAssembly System Interface)** 这样的标准，将其能力从浏览器扩展到了服务器端操作系统上。 -### Wasm 与容器特性的完美契合 +### 17.8.2 Wasm 与容器特性的完美契合 将 Wasm 应用于服务端时，它展现出了一些可能比传统 Linux 容器更为优异的特性： @@ -27,7 +27,7 @@ 4. **极小的包体积**： Linux 容器需要打包一整套依赖甚至是简化的 OS 根目录结构。而一个编译好的功能完善的 Wasm 模块体积常常不到几兆甚至仅仅几十 Kb，极大地加快了存储及网络利用效率。 -### 当 Docker 遇上 WebAssembly +### 17.8.3 当 Docker 遇上 WebAssembly 在现代的容器生态系统中，Wasm 并不被看作是要被取代传统的 Docker 或者 Kubernetes 的技术，而是成为了一种 **与 Linux 容器互补并且共生** 的全新工作负载类型。 @@ -38,6 +38,6 @@ 如今在 Docker Desktop 或者集成了 `containerd` 的环境中，我们可以十分简易地以类似普通镜像的形式去拉取并运行一个基于 Wasm 编译的后端服务（通过指定相应的 `--platform` 或者是特别的 `--runtime=io.containerd.wasmedge.v1` 设置），将其如同对待一个标准应用进程一样让 Docker 为其接管日志、配置相关的网络端口映射，甚至通过 Docker Compose 将一个普通的数据库容器实例与一个 Wasm 微服务实例协同起来混布。 -### 总结 +### 17.8.4 总结 随着技术底座如 WASI 规范不断的成熟完善（例如提供完备的套接字网络支持以及系统资源访问支持），我们有理由相信不仅是边缘计算与无服务器调用，会有越来越多对于速度和安全性有极高指标要求的云原生后端微服务开始采用这一颠覆传统边界的轻量级“微型智能体”架构。在可见的将来，Wasm 势必成为云原生与 Docker 生态的重要拼图。