Podman 深度解读：无守护进程的容器引擎，凭什么替代 Docker？
如果你在 2020 年之前问一个运维工程师"用什么跑容器"，答案 99% 是 Docker。
但如果你在 2026 年问同样的问题，越来越多的回答变成了 Podman。
不是 Docker 不好用了，而是容器技术成熟后，人们开始反思 Docker 架构中的历史包袱——而 Podman 恰好给出了一套更优雅、更安全的答案。
一、Docker 架构的问题在哪
在深入 Podman 之前，先理解 Docker 为什么"有问题"。
Docker 的架构是这样的：
用户 → 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：架构对比
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 模型：
podman run → fork 子进程 → exec runc → 容器进程
这意味着：
1. 没有中间人：podman 命令直接启动容器，不经过任何守护进程
2. 进程隔离更好：每个容器都是 podman 的子进程，天然享受操作系统的进程隔离
3. 更轻量：没有守护进程的内存和 CPU 开销
4. 更安全：不需要 docker.sock，消除了提权攻击面
三、Rootless 容器：安全性的质变
Rootless 是 Podman 最具革命性的特性。
什么是 Rootless 容器
普通用户（非 root）可以拉取镜像、创建容器、管理网络——完全不需要 sudo。
# 普通用户直接运行
$ 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 内核的几个关键特性：
安全收益
攻击场景 Docker Podman Rootless
─────────────────────────────────────────────────────────────────
容器逃逸获取宿主机权限 root 普通用户（危害有限）
docker.sock 被泄露 完全控制宿主机 不存在 socket
CI/CD 中恶意镜像提权 可能获取 root 权限受限
多租户环境隔离 需要额外配置 默认隔离
四、Pod 概念：Kubernetes 的思维下沉
Podman 原生支持 Pod（容器组），这是直接借鉴了 Kubernetes 的概念。
什么是 Pod
一个 Pod 是一个或多个容器的组合，它们共享：
# 创建一个 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 让你可以：
1. 组合微服务：Web + 缓存 + 日志收集，共享网络
2. 简化部署：一个 Pod 一个端口映射，内部容器用 localhost 通信
3. 无缝迁移：Podman Pod 可以直接导出为 Kubernetes YAML
Podman 生成 Kubernetes YAML
这是 Podman 的杀手级功能之一：
# 将运行中的容器/Pod 导出为 K8s YAML
$ podman kube generate myapp > myapp.yaml
# 直接用 YAML 启动（本地或 K8s 集群）
$ podman kube play myapp.yaml
这实现了"本地开发 → 生产部署"的无缝衔接。开发者在本地用 Podman 开发和测试，生产环境直接部署到 Kubernetes，不需要重写配置文件。
五、Podman 实战指南
安装
# Ubuntu/Debian
$ sudo apt install podman
# CentOS/RHEL/Fedora
$ sudo dnf install podman
# macOS（通过虚拟机）
$ brew install podman
$ podman machine init
$ podman machine start
基础操作：和 Docker 几乎一样
# 拉取镜像
$ 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 命令，可以直接设置别名：
# 在 .bashrc 或 .zshrc 中添加
alias docker=podman
Podman 的 CLI 设计目标就是和 Docker 兼容，大部分命令可以直接替换。
构建镜像
Podman 支持标准的 Dockerfile：
# 构建镜像
$ podman build -t myapp:v1 .
# 也可以用 Buildah（Podman 生态的专用构建工具）
$ buildah build -t myapp:v1 .
Buildah vs Podman build：
Buildah 示例（无 Dockerfile）：
# 从基础镜像开始
$ 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：
$ podman run -d --name systemd-test --systemd=always ubuntu:22.04 /sbin/init
将容器注册为 systemd 服务：
# 生成 systemd service 文件
$ podman generate systemd --new --name web > ~/.config/systemd/user/web.service
# 启用并启动
$ systemctl --user enable --now web.service
# 开机自启（用户级）
$ loginctl enable-linger $USER
这意味着容器可以像普通系统服务一样管理：自动启动、自动重启、日志收集、依赖管理，全部由 systemd 接管。
网络管理
# 创建自定义网络
$ podman network create mynet
# 容器加入网络
$ podman run -d --network mynet --name app1 myapp
$ podman run -d --network mynet --name app2 myapp
# app1 和 app2 可以通过容器名互相访问
Rootless 网络注意事项：
镜像仓库
Podman 兼容 Docker Hub 和所有 OCI 标准镜像仓库：
# 登录 Docker Hub
$ podman login docker.io
# 推送到私有仓库
$ podman tag myapp:latest registry.example.com/myapp:latest
$ podman push registry.example.com/myapp:latest
多仓库搜索：
Podman 可以同时搜索多个仓库：
# 配置搜索仓库
$ cat /etc/containers/registries.conf
[registries.search]
registries = ['docker.io', 'quay.io', 'ghcr.io']
# 搜索镜像
$ podman search nginx
六、生产环境部署建议
场景一：开发环境替代 Docker
适用场景： 开发者工作站、CI/CD 管道
配置建议：
# 安装
$ sudo apt install podman podman-compose
# 兼容 docker-compose
$ alias docker-compose=podman-compose
# 设置 Docker API 兼容（某些工具需要）
$ systemctl --user enable --now podman.socket
场景二：边缘计算 / IoT
适用场景： 资源受限设备、嵌入式系统
优势：
# 边缘设备上的典型部署
$ podman run -d --name sensor \
--restart=always \
--memory=128m \
--cpus=0.5 \
-v /dev/sensor0:/dev/sensor0:ro \
myapp:sensor-v2
场景三：多租户服务器
适用场景： 共享服务器、内部开发平台
配置建议：
# 每个用户独立运行容器
$ su - user1
$ podman run -d --name user1-app myapp
$ su - user2
$ podman run -d --name user2-app myapp
# 用户之间完全隔离，无法互相访问容器
场景四：Kubernetes 替代（小规模）
适用场景： 单机或小规模集群，不需要完整的 K8s
# 使用 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 不是一个单独的工具，而是一个完整的容器生态：
Podman → 容器运行时（管理、运行、停止容器）
Buildah → 镜像构建（支持 Dockerfile 和无 Dockerfile 构建）
Skopeo → 镜像管理（复制、签名、检查远程镜像）
Conmon → 容器监控（轻量级监控进程，每个容器一个）
Crun/runc → OCI 运行时（实际启动容器的底层组件）
Podman Desktop → GUI 管理工具（类似 Docker Desktop）
Skopeo：镜像管理利器
# 检查远程镜像（不需要拉取）
$ 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
$ sudo apt install podman
第二步：设置别名
echo 'alias docker=podman' >> ~/.bashrc
echo 'alias docker-compose=podman-compose' >> ~/.bashrc
source ~/.bashrc
第三步：迁移镜像
# Docker 镜像可以直接被 Podman 使用
# 因为两者都遵循 OCI 标准
# 导出 Docker 镜像
$ docker save myapp:latest -o myapp.tar
# 导入到 Podman
$ podman load -i myapp.tar
第四步：迁移 docker-compose
# 安装 podman-compose
$ pip install podman-compose
# 直接使用 docker-compose.yml
$ podman-compose up -d
第五步：迁移 CI/CD
大部分 CI/CD 系统（GitLab CI、GitHub Actions、Jenkins）已经原生支持 Podman：
# 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 的简单替代品，而是容器技术的一次架构进化。
核心优势回顾：
1. 无守护进程：消除单点故障，更轻量
2. Rootless 优先：从设计层面解决安全问题
3. Pod 原生支持：Kubernetes 概念下沉到单机
4. Systemd 深度集成：容器即系统服务
5. 完整生态：Buildah + Skopeo + Conmon，各司其职
什么时候用 Podman：
什么时候继续用 Docker：
容器技术的未来，不是 Docker 和 Podman 的二选一，而是 OCI 标准的统一。Podman 证明了：不需要守护进程，不需要 root 权限，容器可以更安全、更优雅地运行。
这不只是技术选型的差异，而是对"容器应该怎么运行"这个问题的不同回答。
Podman 的回答是：简单、安全、标准。
原文链接：https://wenyiblog.top/2026/06/podman-deep-dive/
首发于文艺技术笔记（wenyiblog.top），转载请注明出处。
浙公网安备 33010602011771号