深度解析：为什么 Podman 和 containerd 2.0 正在取代 Docker 于 2026 年

Source: Dev.to

容器化格局（2024 年末 – 2026 年初）

容器化格局始终充满活力，在 2024 年末至 2025 年期间出现了一系列实用且坚实的进展。作为资深开发者，我们已经走出 炒作周期，深入实际，评估那些能够带来切实运营收益并解决真实约束的特性。虽然 Docker 仍是无可争议的巨头，但其架构选择——尤其是无处不在的 daemon——仍然促使人们寻找更注重安全、系统集成以及对容器生命周期进行更细粒度控制的替代方案。这一转变呼应了更广泛的行业趋势，例如在 Cloudflare vs. Deno: The Truth About Edge Computing in 2025 中讨论的专用运行时的兴起。

下面我们剖析 Podman、Buildah 和 containerd 的最新发展，去除营销噱头，揭示真正有效的功能、仍显笨拙的地方，以及在 2026 年初这个不断变化的生态系统中你不可避免要面对的权衡。

Source: …

Podman

Daemonless Architecture

Podman’s primary allure has always been its daemonless architecture, a stark contrast to Docker’s client‑server model. The marketing touts “daemonless means more secure,” but the reality is more nuanced; it fundamentally alters how containers integrate with the host OS.

• No central privileged daemon – Podman runs containers as child processes of the user who invokes the podman command.
• Security implication – If the Podman process is compromised, the blast radius is theoretically contained to the invoking user’s privileges.

Operational Quirks

The “daemonless” advantage isn’t without its operational quirks. Managing container lifecycles in the background, persistent logging, and automatic restarts—traditionally handled by a daemon—now require alternative mechanisms.

Podman addresses this through deep integration with systemd on Linux systems:

• Generate systemd unit files for individual containers or entire pods with podman generate systemd.
• Leverage systemd’s robust process‑supervision capabilities to manage containers like any other system service.

Note: While this approach offers excellent native integration, it shifts complexity from a single daemon to managing multiple systemd units, potentially increasing operational overhead for those unfamiliar with systemd internals.

Example: Generate a systemd unit for a simple Nginx container

# Run the container
podman run -d --name my-nginx -p 8080:80 nginx:latest

# Generate a systemd unit file
podman generate systemd --name my-nginx > ~/.config/systemd/user/container-my-nginx.service

# Enable and start it as a user service
systemctl --user enable container-my-nginx.service
systemctl --user start container-my-nginx.service

This systemd integration is a practical, sturdy solution for production deployments on Linux, but it demands familiarity with a different paradigm than docker‑compose up -d.

Rootless Containers

Podman’s standout feature, rootless containers, reached significant maturity throughout 2024 – 2025. This capability allows unprivileged users to build, run, and manage containers without requiring sudo, drastically reducing the attack surface.

• User namespaces – The internal root user (UID 0) is mapped to an unprivileged host UID, defined in /etc/subuid and /etc/subgid.
• Storage – Rootless containers typically rely on fuse‑overlayfs, a FUSE‑based implementation of the overlayfs filesystem. It enables unprivileged layered filesystems but incurs a modest performance penalty compared to the kernel module.
• Networking – Handled by slirp4netns, a user‑mode networking stack that creates a virtual network interface and routes traffic through the host’s network namespace. It avoids privileged network manipulation but often exhibits higher latency and lower throughput than CNI‑based networking used by rootful containers.

Podman Desktop (v1.22, October 2025) introduced the ability to switch Podman machines between rootless and rootful modes on macOS and Windows, acknowledging the need for flexibility.

Recent Developments

Buildah

Buildah 常常被 Podman 所掩盖，但它是那些需要对容器镜像创建进行细粒度控制的用户的无名英雄。它不仅是 Docker‑build 的替代品；它是一个无守护进程的 OCI 镜像构建工具套件。

• 无守护进程 – 不需要后台服务；命令直接作用于主机文件系统。
• 原子命令 – buildah from、buildah mount、buildah run、buildah commit 让你对镜像层逐步掌控。
• Dockerfile 兼容性 – buildah bud -t myimage . 提供熟悉的使用体验，同时在需要时仍可降级使用低层命令。

高级镜像优化策略

与仅依赖多阶段 Dockerfile 不同，你可以显式挂载容器文件系统（buildah mount），使用主机工具直接进行修改，然后只提交必要的层（buildah commit）。这种 “从零构建” 或 “挂载后修改” 的方式通过排除构建时的依赖和工具（例如 gcc、包管理器）来创建极其精简的镜像，从而显著降低镜像体积和攻击面。

示例：使用 Buildah 细粒度命令构建极简 Nginx 镜像

# 1. 从 scratch 开始
container=$(buildah from scratch)

# 2. 添加操作系统基础（例如 busybox）
buildah add $container busybox.tar /

# 3. 安装 Nginx（简化示例 – 实际上你会复制预编译的二进制文件）
#    在真实场景中，你可能先从构建镜像开始，安装后再复制。
buildah run $container -- apk add nginx

# 4. 暴露端口并设置入口点（Buildah config）
buildah config --port 80 \
               --entrypoint '["nginx", "-g", "daemon off;"]' \
               $container

# 5. 提交为新镜像
buildah commit $container my-minimal-nginx:latest

这种方法功能强大，但相较于简单的 Dockerfile，需要对镜像分层和文件系统操作有更深入的理解。学习曲线不可避免。

Buildah 中的供应链安全增强

最近的 Buildah 发行版在供应链安全方面投入了大量精力。Buildah 1.35（2024 年 3 月） 引入了关键的 --sbom 标志，允许用户在构建或提交过程中生成 软件物料清单（SBOM）。SBOM 提供容器镜像中所有组件、库和依赖的详细清单——这对于识别漏洞和确保合规性至关重要。

示例：构建镜像并生成 SBOM

buildah bud --sbom --format spdx -t my-app:latest .

--sbom 标志是一个受欢迎的补充，满足了软件供应链透明度的关键需求。然而，生成 SBOM 只是第一步；其真正价值取决于能够消费、分析并基于这些数据采取行动的强大工具链。如果缺乏完整的 SBOM 管理生态系统，它可能沦为另一个形式主义的检查项，而非真正的安全提升。

buildah push 命令在 1.35 版中也加入了 --retry 和 --retry-delay 标志，以实现更稳健的镜像推送，考虑到向注册表推送时网络操作的易失性。

最近的开发动态（Buildah 1.35.0 → 1.42.0）

这些提升了使用体验的改进，既简化了工作流，又凸显了与成熟 Docker 行为保持一致的持续努力。

containerd：Kubernetes 的底层运行时

虽然 Podman 和 Buildah 注重开发者体验，containerd 则工作在更低层次，作为业界标准的核心容器运行时，服务于 Kubernetes 以及其他编排系统。

• containerd 2.0 – 于2024年末发布
• containerd 2.1 – 于2025年5月发布

两个版本都侧重于稳定性、可扩展性和安全性。

containerd 的功能

• 管理完整的容器生命周期：镜像传输、存储和执行。
• 提供 gRPC API。
• 实现 kubelet 所需的 Container Runtime Interface (CRI)，使其成为 Kubernetes 的事实标准。

2.0 版本将 1.7 系列的实验特性合并到稳定通道，并移除已废弃的功能，确保更稳固、可预测的基础。对生产运维而言，这意味着更具弹性和性能的运行时，但仍需关注与 containerd 升级关联的 Kubernetes 版本中 API 的废弃和移除。

注意： 配置格式已更改为 v3，需要对现有安装执行迁移步骤（containerd config migrate）。

containerd 2.0 的新特性

1. 默认启用节点资源接口（NRI）

   • 提供强大的扩展机制，用于自定义底层容器配置。
   • 通过插件实现对资源分配和策略执行的更细粒度控制（类似于变更准入 webhook，但直接在运行时层面工作）。
   • 其影响取决于社区驱动的插件；开箱即用时它只是一个机制，而非完整解决方案。

2. 改进的用户命名空间支持

   • 允许容器在内部以 root 身份运行，但在宿主机上映射为非特权 UID，从而大幅降低容器逃逸的影响范围。
   • 截至2024年末仍被视为“Kubernetes 的 beta”，在 Kubernetes 生态系统中实现完整、稳定的集成仍需时日。
   • 启用通常需要设置内核参数，例如 user.max_user_namespaces=1048576。

容器网络：持续演进

容器网络仍然是最复杂的领域之一，生态系统正不断朝着更灵活、更安全的模型演进。

• Container Network Interface (CNI) 是为 Linux 容器配置网络接口的基础规范。
• Podman（以 rootful 方式运行时）和 containerd 都遵循 CNI，确保网络插件集成的标准化机制。
• 这意味着，rootful Podman 和由 containerd 管理的容器的底层网络拓扑（例如 veth 对、虚拟桥接）在插件之间是一致且可互换的。

容器网络概览

• 符合 CNI 的运行时
  容器的网络模型在符合 CNI 的运行时之间大体保持一致。然而，CNI 的灵活性也可能成为弱点：不同插件（例如 bridge、host‑local，或更高级的 Calico 与 Cilium）提供的功能和复杂度各不相同。

• 调试
  排查网络问题通常需要：

  1. 了解具体插件的配置文件（通常位于 /etc/cni/net.d/）。
  2. 知晓插件如何与主机层面的网络工具（如 iptables 或 nftables）交互。
     这并非“设置后忘记”的情形；它要求具备动手的网络故障排除技能。

Podman的从CNI到Netavark的转变

• 背景
  从 Podman 4.0 开始，默认网络后端已从 CNI 切换为 Netavark。Netavark 是用 Go 编写的新网络栈，旨在与 Podman 的无守护进程架构紧密集成。

• 弃用
  CNI 现已被弃用，并将在未来的主要 Podman 版本（≥ 5.0）中移除。

• 检查后端

  podman info --format {{.Host.NetworkBackend}}

• 影响

  • Netavark 为自定义网络和 DNS 解析提供了更一致的体验。
  • 现有的 CNI 配置——尤其是自定义配置——在升级 Podman 时可能需要重新评估并迁移。

Rootless Networking

• slirp4netns 仍然是无根容器的主要机制，因为非特权用户无法直接操作网络设备。
• 这导致 rootful 与 rootless 部署之间在网络功能和性能上始终存在差距。
• 虽然可以工作，但对于需要高网络 I/O 或低延迟的工作负载，slirp4netns 可能会带来显著的开销。

容器安全趋势

最小特权执行

• Rootless mode (Podman) 和 user‑namespace support (containerd 2.0) 将容器 root 映射到非特权的宿主用户，降低容器逃逸的影响。

• Capability Dropping – 容器通常使用一套宽泛的默认能力（例如 CAP_NET_ADMIN、CAP_SYS_ADMIN）。显式删除不必要的能力可以收紧攻击面：

  podman run --cap-drop ALL --cap-add CHOWN myimage

• Mandatory Access Controls – 与 SELinux 和 AppArmor 的集成提供了另一层防护，但配置它们需要深入的操作系统级别专业知识。

供应链安全

• SBOM Generation – buildah --sbom 生成软件物料清单，提升供应链透明度。

• OCI Image Specification v1.1（2024 年 2月发布）新增：

  • subject 和 artifactType 字段。
  • 用于将外部制品（签名、证明、SBOM）链接到镜像的 referrers API，无需将其嵌入镜像中。

  这使元数据处理标准化，提升可验证的镜像完整性。注册表和工具的采纳仍是最大障碍。

OCI Specification Updates (2024)