Podman 深度解读：无守护进程的容器引擎，凭什么替代 Docker？

Tue, 16 Jun 2026 22:00:00 +0800

如果你在 2020 年之前问一个运维工程师"用什么跑容器"，答案 99% 是 Docker。

但如果你在 2026 年问同样的问题，越来越多的回答变成了 Podman。

不是 Docker 不好用了，而是容器技术成熟后，人们开始反思 Docker 架构中的历史包袱——而 Podman 恰好给出了一套更优雅、更安全的答案。

一、Docker 架构的问题在哪

在深入 Podman 之前，先理解 Docker 为什么"有问题"。

Docker 的架构是这样的：

1

用户 → docker CLI → docker.sock → dockerd 守护进程 → containerd → runc → 容器

这个架构在 2013 年是革命性的，但到了今天，暴露出几个核心问题：

问题一：守护进程 = 单点故障

dockerd 是一个长期运行的 root 进程。如果它挂了，所有容器都受影响。更糟的是，所有 docker 命令都必须通过它，它成了一个性能瓶颈和可用性风险。

问题二：root 权限过大

默认情况下，dockerd 以 root 身份运行。任何能访问 docker.sock 的用户，实际上拥有了宿主机的 root 权限。这不是假设——历史上已经有大量通过 docker.sock 提权的攻击案例。

问题三：客户端-服务端模型不适合所有场景

在 CI/CD 管道、边缘计算、嵌入式设备等场景中，启动一个守护进程来跑容器，既浪费资源又增加复杂度。

二、Podman 是什么

Podman（Pod Manager）是 Red Hat 开发的开源容器引擎。它的核心理念很简单：

不需要守护进程，不需要 root 权限，就能管理容器。

用一句话概括：Podman 是 Docker 的 drop-in 替代品，但从架构上做了根本性的改进。

Podman vs Docker：架构对比

1
2


Docker: CLI → daemon(dockerd) → containerd → runc → 容器
Podman: CLI → conmon → runc/crun → 容器（直接 fork-exec）

关键区别：

维度	Docker	Podman
守护进程	有（dockerd，长期运行）	无（fork-exec 模型）
默认权限	root	rootless（普通用户）
进程模型	客户端-服务端	传统父子进程
容器监控	dockerd 统一监控	每个容器独立 conmon 进程
Socket 依赖	必须 docker.sock	不需要
系统服务集成	弱（需要额外配置）	原生 systemd 集成
Pod 支持	通过 Kubernetes	原生支持

Fork-Exec 模型：Podman 的核心创新

Docker 的 dockerd 像一个"中间人"——所有操作都要经过它。Podman 采用的是 fork-exec 模型：

1

podman run → fork 子进程 → exec runc → 容器进程

这意味着：

没有中间人：podman 命令直接启动容器，不经过任何守护进程
进程隔离更好：每个容器都是 podman 的子进程，天然享受操作系统的进程隔离
更轻量：没有守护进程的内存和 CPU 开销
更安全：不需要 docker.sock，消除了提权攻击面

三、Rootless 容器：安全性的质变

Rootless 是 Podman 最具革命性的特性。

什么是 Rootless 容器

普通用户（非 root）可以拉取镜像、创建容器、管理网络——完全不需要 sudo。

1
2


# 普通用户直接运行
$ podman run -d --name web -p 8080:80 nginx

Rootless 为什么重要

传统 Docker Rootless 的问题：

Docker 后来也加入了 rootless 模式（dockerd-rootless.sh），但本质上是一个"补丁"——它启动了一个 user namespace 内的 dockerd，增加了复杂度和维护成本。

Podman 的 Rootless 是原生设计：

Podman 从第一天就为 rootless 而设计。它利用 Linux 内核的几个关键特性：

User Namespaces：容器内的 root 映射到宿主机的普通用户
Mount Namespaces：容器有独立的文件系统视图
Network Namespaces：容器有独立的网络栈
cgroups v2：资源限制（CPU、内存等）不再需要 root 权限

安全收益

1
2
3
4
5
6


攻击场景 Docker Podman Rootless
─────────────────────────────────────────────────────────────────
容器逃逸获取宿主机权限 root 普通用户（危害有限）
docker.sock 被泄露 完全控制宿主机 不存在 socket
CI/CD 中恶意镜像提权 可能获取 root 权限受限
多租户环境隔离 需要额外配置 默认隔离

四、Pod 概念：Kubernetes 的思维下沉

Podman 原生支持 Pod（容器组），这是直接借鉴了 Kubernetes 的概念。

什么是 Pod

一个 Pod 是一个或多个容器的组合，它们共享：

网络命名空间（同一个 IP，可以互相用 localhost 通信）
IPC 命名空间
UTS 命名空间（主机名）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 创建一个 Pod
$ podman pod create --name myapp -p 8080:80

# 在 Pod 中运行 Web 服务
$ podman run -d --pod myapp nginx

# 在同一个 Pod 中运行日志收集
$ podman run -d --pod myapp fluentd

# 查看 Pod 状态
$ podman pod ps

为什么 Pod 有用

在没有 Kubernetes 的单机环境中，Pod 让你可以：

组合微服务：Web + 缓存 + 日志收集，共享网络
简化部署：一个 Pod 一个端口映射，内部容器用 localhost 通信
无缝迁移：Podman Pod 可以直接导出为 Kubernetes YAML

Podman 生成 Kubernetes YAML

这是 Podman 的杀手级功能之一：

1
2
3
4
5


# 将运行中的容器/Pod 导出为 K8s YAML
$ podman kube generate myapp > myapp.yaml

# 直接用 YAML 启动（本地或 K8s 集群）
$ podman kube play myapp.yaml

这实现了"本地开发 → 生产部署"的无缝衔接。开发者在本地用 Podman 开发和测试，生产环境直接部署到 Kubernetes，不需要重写配置文件。

五、Podman 实战指南

安装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Ubuntu/Debian
$ sudo apt install podman

# CentOS/RHEL/Fedora
$ sudo dnf install podman

# macOS（通过虚拟机）
$ brew install podman
$ podman machine init
$ podman machine start

基础操作：和 Docker 几乎一样

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 拉取镜像
$ podman pull nginx:latest

# 运行容器
$ podman run -d --name web -p 8080:80 nginx

# 查看运行中的容器
$ podman ps

# 查看容器日志
$ podman logs web

# 进入容器
$ podman exec -it web /bin/bash

# 停止并删除
$ podman stop web
$ podman rm web

小技巧： 如果你习惯了 docker 命令，可以直接设置别名：

1
2


# 在 .bashrc 或 .zshrc 中添加
alias docker=podman

Podman 的 CLI 设计目标就是和 Docker 兼容，大部分命令可以直接替换。

构建镜像

Podman 支持标准的 Dockerfile：

1
2
3
4
5


# 构建镜像
$ podman build -t myapp:v1 .

# 也可以用 Buildah（Podman 生态的专用构建工具）
$ buildah build -t myapp:v1 .

Buildah vs Podman build：

podman build：兼容 Dockerfile，适合快速迁移
buildah：更灵活，支持无 Dockerfile 构建，更适合 CI/CD

Buildah 示例（无 Dockerfile）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 从基础镜像开始
$ ctr=$(buildah from ubuntu:22.04)

# 安装软件
$ buildah run $ctr -- apt-get update && apt-get install -y nginx

# 配置启动命令
$ buildah config --cmd "nginx -g 'daemon off;'" $ctr

# 提交为新镜像
$ buildah commit $ctr my-nginx:latest

Systemd 集成

Podman 和 systemd 深度集成，这是它相比 Docker 的一大优势。

在容器内运行 systemd：

1

$ podman run -d --name systemd-test --systemd=always ubuntu:22.04 /sbin/init

将容器注册为 systemd 服务：

1
2
3
4
5
6
7
8


# 生成 systemd service 文件
$ podman generate systemd --new --name web > ~/.config/systemd/user/web.service

# 启用并启动
$ systemctl --user enable --now web.service

# 开机自启（用户级）
$ loginctl enable-linger $USER

这意味着容器可以像普通系统服务一样管理：自动启动、自动重启、日志收集、依赖管理，全部由 systemd 接管。

网络管理

1
2
3
4
5
6
7
8


# 创建自定义网络
$ podman network create mynet

# 容器加入网络
$ podman run -d --network mynet --name app1 myapp
$ podman run -d --network mynet --name app2 myapp

# app1 和 app2 可以通过容器名互相访问

Rootless 网络注意事项：

Rootless 容器默认使用 slirp4netns（用户态网络栈），性能不如内核网络
需要高性能网络时，可以用 pasta（Podman 4.x 新增）或配置 rootful 模式
端口映射：rootless 只能映射 1024 以上的端口（除非配置 sysctl）

镜像仓库

Podman 兼容 Docker Hub 和所有 OCI 标准镜像仓库：

1
2
3
4
5
6


# 登录 Docker Hub
$ podman login docker.io

# 推送到私有仓库
$ podman tag myapp:latest registry.example.com/myapp:latest
$ podman push registry.example.com/myapp:latest

多仓库搜索：

Podman 可以同时搜索多个仓库：

1
2
3
4
5
6
7


# 配置搜索仓库
$ cat /etc/containers/registries.conf
[registries.search]
registries = ['docker.io', 'quay.io', 'ghcr.io']

# 搜索镜像
$ podman search nginx

六、生产环境部署建议

场景一：开发环境替代 Docker

适用场景： 开发者工作站、CI/CD 管道

配置建议：

1
2
3
4
5
6
7
8


# 安装
$ sudo apt install podman podman-compose

# 兼容 docker-compose
$ alias docker-compose=podman-compose

# 设置 Docker API 兼容（某些工具需要）
$ systemctl --user enable --now podman.socket

场景二：边缘计算 / IoT

适用场景： 资源受限设备、嵌入式系统

优势：

无守护进程，节省内存
Rootless，降低攻击面
支持 OTA 更新（通过镜像标签切换）

1
2
3
4
5
6
7


# 边缘设备上的典型部署
$ podman run -d --name sensor \
 --restart=always \
 --memory=128m \
 --cpus=0.5 \
 -v /dev/sensor0:/dev/sensor0:ro \
 myapp:sensor-v2

场景三：多租户服务器

适用场景： 共享服务器、内部开发平台

配置建议：

1
2
3
4
5
6
7
8


# 每个用户独立运行容器
$ su - user1
$ podman run -d --name user1-app myapp

$ su - user2
$ podman run -d --name user2-app myapp

# 用户之间完全隔离，无法互相访问容器

场景四：Kubernetes 替代（小规模）

适用场景： 单机或小规模集群，不需要完整的 K8s

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 使用 Podman + Quadlet 管理复杂应用
# /etc/containers/systemd/myapp.container
[Unit]
Description=My Application

[Container]
Image=docker.io/myapp:latest
AutoUpdate=registry
Network=myapp.network
Volume=/data:/app/data:Z
PublishPort=8080:80

[Install]
WantedBy=default.target

Quadlet 是 Podman 4.x 引入的特性，让你用 systemd unit 文件的语法来定义容器，同时享受 systemd 的全部管理能力。

七、Podman 生态工具链

Podman 不是一个单独的工具，而是一个完整的容器生态：

1
2
3
4
5
6


Podman → 容器运行时（管理、运行、停止容器）
Buildah → 镜像构建（支持 Dockerfile 和无 Dockerfile 构建）
Skopeo → 镜像管理（复制、签名、检查远程镜像）
Conmon → 容器监控（轻量级监控进程，每个容器一个）
Crun/runc → OCI 运行时（实际启动容器的底层组件）
Podman Desktop → GUI 管理工具（类似 Docker Desktop）

Skopeo：镜像管理利器

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 检查远程镜像（不需要拉取）
$ skopeo inspect docker://docker.io/library/nginx:latest

# 复制镜像到私有仓库（不需要本地存储）
$ skopeo copy docker://docker.io/library/nginx:latest \
 docker://registry.example.com/nginx:latest

# 镜像签名
$ skopeo copy --sign-by key@company.com \
 containers-storage:myapp:latest \
 docker://registry.example.com/myapp:latest

八、迁移指南：从 Docker 到 Podman

第一步：安装 Podman

1

$ sudo apt install podman

第二步：设置别名

1
2
3


echo 'alias docker=podman' >> ~/.bashrc
echo 'alias docker-compose=podman-compose' >> ~/.bashrc
source ~/.bashrc

第三步：迁移镜像

1
2
3
4
5
6
7
8


# Docker 镜像可以直接被 Podman 使用
# 因为两者都遵循 OCI 标准

# 导出 Docker 镜像
$ docker save myapp:latest -o myapp.tar

# 导入到 Podman
$ podman load -i myapp.tar

第四步：迁移 docker-compose

1
2
3
4
5


# 安装 podman-compose
$ pip install podman-compose

# 直接使用 docker-compose.yml
$ podman-compose up -d

第五步：迁移 CI/CD

大部分 CI/CD 系统（GitLab CI、GitHub Actions、Jenkins）已经原生支持 Podman：

1
2
3
4
5
6


# GitLab CI 示例
build:
 image: quay.io/podman/stable
 script:
 - podman build -t myapp:${CI_COMMIT_SHA} .
 - podman push myapp:${CI_COMMIT_SHA}

九、Podman 的不足与局限

客观地说，Podman 也有一些短板：

1. 生态成熟度

Docker 有十年的生态积累，几乎所有工具都默认支持 Docker。虽然 Podman 兼容 Docker CLI，但某些第三方工具的集成还不够完美。

2. macOS/Windows 体验

Podman Desktop 的体验还不如 Docker Desktop 成熟，特别是在网络配置和文件共享方面。

3. 学习曲线

Rootless 模式虽然安全，但引入了 user namespace、UID/GID 映射等概念，增加了学习成本。新手在遇到权限问题时会比较困惑。

4. 性能差异

Rootless 模式下，网络性能（slirp4netns）和文件系统性能（fuse-overlayfs）不如 root 模式。对于高吞吐量场景，可能需要切换到 rootful 模式。

十、总结

Podman 不是 Docker 的简单替代品，而是容器技术的一次架构进化。

核心优势回顾：

无守护进程：消除单点故障，更轻量
Rootless 优先：从设计层面解决安全问题
Pod 原生支持：Kubernetes 概念下沉到单机
Systemd 深度集成：容器即系统服务
完整生态：Buildah + Skopeo + Conmon，各司其职

什么时候用 Podman：

安全敏感环境（金融、医疗、政府）
多租户共享服务器
CI/CD 管道（不需要守护进程）
边缘计算和 IoT
已经使用 Kubernetes 的团队（概念一致）

什么时候继续用 Docker：

团队已经深度依赖 Docker 生态
需要 Docker Desktop 的图形化体验
某些第三方工具只支持 Docker

容器技术的未来，不是 Docker 和 Podman 的二选一，而是 OCI 标准的统一。Podman 证明了：不需要守护进程，不需要 root 权限，容器可以更安全、更优雅地运行。

这不只是技术选型的差异，而是对"容器应该怎么运行"这个问题的不同回答。

Podman 的回答是：简单、安全、标准。

Linux on 文艺技术笔记