Podman

「Podman: A tool for managing OCI containers and pods.」
这是「一天一个开源项目」系列今天的项目：Podman（the POD MANager）。

在 CI 里跑容器的人，大概率都撞过同一堵墙：测试要用 Docker，于是给 runner 装 Docker、把 CI 用户加进 docker 组——而 docker 组的权限，等价于 root；想避开，就得挂载 /var/run/docker.sock，或者开 privileged 跑 Docker-in-Docker，安全评审一句「这等于把宿主机交出去」就打回。另一头，Kubernetes 用户想在本地验证一份 Pod 的 YAML，得先起 kind 或 minikube，为一个命名空间语义拉起半套集群。而守护进程本身还是个单点：dockerd 重启或 OOM，默认配置下容器会跟着停掉，日志、网络规则也要重新对齐（live-restore 只能缓解一部分），「容器还在不在」变成一件需要额外确认的事。

Podman 的答案是把「守护进程」这一步直接删掉：没有常驻的 manager daemon，每条命令都是普通进程，跑完就退出；容器交给每个容器一个的 conmon 监护；root 权限用 user namespace 换，而不是给 Podman 加 setuid。它还把 Pod 做成一等公民，podman kube play 直接吃 Kubernetes YAML。这篇文章想讲清楚三件事：去掉守护进程之后，容器靠什么活着；rootless 能走到哪一步、边界在哪；以及这样一套设计，为什么在 2026 年随 6.0 版本迁进了 CNCF 名下的新组织。

项目速览

⭐ 33.2k Stars ｜ 🍴 3.4k Forks ｜ 📄 Apache-2.0 协议 ｜ 🔧 28,765 次提交 ｜ 🐛 863 个 Open Issues（另有 130 个未合并 PR）

420 位贡献者、256 个 GitHub Release（280 个 tag）。2017-11-01 建仓：第一条提交是 rhatdan 的「Initial commit」，当天的第二条提交信息才是「Initial checkin from CRI-O repo」——Podman 的代码起点是从 CRI-O 里分出来的。发布节奏稳定到近乎刻板：README 写明每年 2、5、8、11 月第二周各发一个 major 或 minor 特性版本（v6.0 实际落在 6 月——惯例不等于承诺）；大版本约两年一跳（v4.0 → v5.0 隔 25 个月，v5.0 → v6.0 隔 27 个月），中间由 minor 与补丁填满，近 100 个 release 覆盖 2023-02 至今。

数据截至 2026-11-02，以 GitHub API 与仓库 main 分支为准；最新稳定版 v6.1.4（2026-10-12），预发布 v6.2.0-rc1（2026-10-26）。Star、Fork 等动态数字均为该日快照。

阅读价值与前置说明

你将学到什么

无守护进程模型的完整链条：conmon 承担了 containerd-shim 那一层的哪些活，podman run 退出后容器为什么还活着，--restart 到底由哪个进程执行；
rootless 的真实边界：user namespace + /etc/subuid + pause 进程 + pasta 网络怎样拼起来，官方在 rootless.md 里承认了哪些限制、哪些是内核给的；
Quadlet 的设计取舍：为什么「把容器声明交给 systemd generator」比再写一个编排器更合理，代价又是什么；
一个成熟项目的工程细节：v6.0 的破坏性变更、CI 测试矩阵、CNCF 治理与 PGP 签名发布。

前置知识

了解容器基本概念：镜像、容器、namespace、cgroup；
熟悉 Linux 命令行与 systemd 的基本用法；
可选：用过 Docker 或 Kubernetes，读「深度设计剖析」会更容易对照两者差异。

项目背景与完整档案

项目简介

Podman 是一个管理 OCI 容器与 Pod 的工具，底层是同一仓库里的 libpod 库——负责容器、Pod、镜像、卷的完整生命周期 API。官方定位写得很直接：daemonless、rootless、Docker 兼容。它长期由红帽团队主导——约 41% 的提交（11,764 / 28,765）来自 redhat.com 邮箱。

它的社区属性经历过一次重要变化：2024 年 11 月，红帽在 KubeCon NA 2024 宣布把 Podman、Buildah、Skopeo 等容器工具捐给 CNCF，CNCF 于 2025-01-21 接受 Podman Container Tools 进入 Sandbox；2025 年补齐治理文件与 Maintainers 清单（ROADMAP.md 的 2025 Q1–Q2 CNCF 事项已勾选，Q3 的「Continue towards incubation」仍未勾）；2026 年 6 月 6.0 发布，仓库随之迁入 CNCF 拥有的 podman-container-tools 组织。官方博客 Podman Container Tools Grows 写得很清楚：已迁走的 Podman、Buildah、Skopeo 等仓库，旧 github.com/containers/... 地址现在 301 跳到新组织；podman-machine-os、container-libs 也已并入，podman-py、podman.io 等还在迁移路上；crun、conmon、netavark 仍留在 containers/ 下。

所以，如果你手里还是 github.com/containers/podman 这个地址，它不会失效，但唯一事实源已经换了。本文所有数据都取自新地址。

基础信息

项目	信息
仓库	podman-container-tools/podman（旧地址 `containers/podman` 301 跳转至此）
开源协议	Apache-2.0
命令 / 包名	`podman`、`podman-remote`；各发行版包名统一为 `podman`（Fedora 的 machine 功能拆在 `podman-machine` 包）
当前版本	v6.1.4（2026-10-12）；预发布 v6.2.0-rc1（2026-10-26）
主语言	Go（9.37 MB），辅以 Shell（1.59 MB）、Perl、Python、C
构建	Go 1.26.8（`go.mod` 口径）；`make` + `make install`
支持平台	Linux 原生；macOS（ARM64）与 Windows（WSL2 或 Hyper-V，需 Windows 11+）经 podman machine；FreeBSD 实验性（14.3+）
外部依赖	conmon、crun 或 runc、netavark + aardvark-dns、pasta、buildah、containers-common
生态定位	Docker 兼容 CLI + 双 REST API；构建交给 Buildah，镜像搬运交给 Skopeo，Kubernetes CRI 交给 CRI-O

项目数据

⭐ Stars：33,159
🍴 Forks：3,434
🔨 Commits：28,765（默认分支可达历史，其中 11,798 次是合并提交，约 41%）
🐛 Open Issues：863（GitHub 的 open_issues_count 是 993，其中含 130 个未合并 PR）
👥 Contributors：420（GitHub 口径，含 openshift-merge-robot 等机器人账号）；人类贡献榜前三：Luap99 2,038、mheon 2,022、rhatdan 1,571
📦 Releases：256 个 GitHub Release、280 个 tag。大版本时间线：v1.0.0（2019-01-11）→ v2.0.0（2020-06-19）→ v3.0.0（2021-02-11）→ v4.0.0（2022-02-17）→ v5.0.0（2024-03-19）→ v6.0.0（2026-06-24）
📅 创建于 2017-11-01，最近一次推送 2026-11-01
📈 提交节奏：2020 年峰值 4,436 次；2026 年截至 10-30 已提交 2,252 次，没有降温迹象

数据截至 2026-11-02 16:40（UTC+8）；版本日期与 pushed_at 为 UTC 口径。Commits 为默认分支可达历史（含合并提交）；Contributors 为 GitHub 统计口径；Open Issues 为当日快照，不是历史总量。

它解决什么问题

解决什么问题

容器引擎这个领域，普遍的卡点有四类：

权限与审计：传统模型需要一个 root 守护进程，用户只能通过 socket 或 docker 组接入——后者事实上是把 root 权限外包出去，审计上很难解释。
单点与状态：容器状态、日志、网络规则集中在 daemon 里，daemon 挂了或重启，容器与外部世界的关系要重新建立。
语义断层：Kubernetes 的核心抽象是 Pod，而本地工具链接管的是单个容器；本地验证 K8s YAML 往往要拉起半个集群。
跨平台成本：在 macOS / Windows 上跑 Linux 容器，必须付出一层虚拟机的代价，这层虚拟机由谁管理、能不能被脚本化，直接决定开发体验。

Podman 的解法是递进的：先删掉守护进程（fork-exec + conmon），让「运行容器」回到普通进程的语义；再把 root 权限装进命名空间（user namespace + /etc/subuid），让安全边界等于「这个用户本来就有的权限」；然后把 Pod 做成一等公民（infra 容器 + kube play / generate kube），让 K8s 语义在本地可复现；最后把生产化交给 systemd（Quadlet），不另造一个编排器。四步走完，才有资格说「Docker 的替代品」——注意是替代工具链，不是替代每一个字节的行为。

使用场景

场景 1：共享 CI runner。 不需要 privileged，不需要 DinD，也不需要把宿主 socket 交给构建脚本；每个 runner 用户以 rootless 方式跑自己的容器，安全边界清晰。
场景 2：开发机上的 Docker 替代。 用 podman machine 起一台受管虚拟机，同时监听 Docker API，DOCKER_HOST 指过去，原来的 docker build / docker compose 工作流可以继续用。
场景 3：Kubernetes 本地调试。 一份 Pod YAML，podman kube play 直接在本机跑起来；反向用 podman generate kube 把本机跑着的容器导出成 YAML，带回集群。
场景 4：边缘与不可变系统。 Fedora CoreOS / Silverblue 内置 Podman；配合 Quadlet，容器作为 systemd 服务开机自启，不需要额外运行时。

快速上手

前提：Linux 上需要内核支持 user namespace（现代发行版默认开启），rootless 还需要管理员为你配置 /etc/subuid 与 /etc/subgid；macOS / Windows 需要可用的虚拟化后端。

macOS（推荐官方安装包）

从 podman.io 安装页给出的链接，到 GitHub Release 下载 podman-installer-macos-arm64.pkg（仅 ARM64）并安装（官方明确说明 Homebrew 是社区维护包，不保证稳定性）。
podman machine init 创建虚拟机。
podman machine start，然后 podman info 验证。

Linux（以 Fedora / Ubuntu / Arch 为例）

# Fedora
sudo dnf -y install podman
# Ubuntu 20.10+
sudo apt-get update && sudo apt-get -y install podman
# Arch
sudo pacman -S podman

rootless 用户还需要管理员做一次映射（每个用户 65,536 个 UID/GID）；若该用户已经跑过 Podman，需要以该用户身份执行 podman system migrate 让新映射生效（初次配置无需额外操作）：

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 johndoe
grep johndoe /etc/subuid /etc/subgid

跑第一个容器

podman run --rm -d -p 8080:80/tcp docker.io/library/nginx

其他安装方式：Windows 用 MSI 安装器（6.0+，默认用户级安装，安装时选择 WSL 或 Hyper-V provider，系统里需先有 WSL2 或 Hyper-V）；FreeBSD 用 pkg install podman（14.3+，官方标注实验性）；源码安装按官方四步：git clone https://github.com/podman-container-tools/podman && cd podman && make PREFIX=/usr && sudo env PATH=$PATH make install PREFIX=/usr。图形界面可以配 Podman Desktop。

核心特性拆解

1. Docker 兼容 CLI。 大部分命令与 Docker 同名同参，alias docker=podman 能覆盖大多数日常命令（compose、buildx 等仍需额外工具）；REST API 同时提供 Docker 兼容层与 Podman 原生层，6.0 起支持到 Docker API v1.44，6.1 继续修补 v1.44 并开始准备 v1.45。

2. 无守护进程（daemonless）。 空闲时没有常驻的管理进程，没有 socket 权限模型，也没有 daemon 崩溃后的状态修复问题——唯一的例外是 rootless 模式的 pause 进程，它只负责挂住命名空间，不调度容器。

3. Rootless。 普通用户即可运行，容器内的 root 映射为调用者，容器永远拿不到用户本身没有的权限；网络默认走 pasta，端口转发由 rootlessport 负责。

4. Pod 与 Kubernetes YAML。 Pod 有真正的 infra 容器与共享 namespace；podman kube play 吃 YAML，podman generate kube 反向导出，6.1 起还能把容器健康检查导出为 livenessProbe。

5. Quadlet / systemd 集成。 把 .container、.pod、.kube、.image、.build、.network、.volume、.artifact 等声明式文件放进 ~/.config/containers/systemd/ 或 /etc/containers/systemd/，systemd 在开机或 daemon-reload 时生成对应 .service，容器因此拥有开机自启、崩溃重启、日志进 journald 的能力。

6. 双 REST API 与远程客户端。 Docker 兼容 API 让现有工具直接接入，libpod 原生 API 暴露 Pod、kube、artifact 等高级能力；podman --remote 可通过 SSH 操作远端，本地只需一个客户端二进制。

7. Podman machine。 在 macOS（AppleHV / Libkrun）与 Windows（WSL2 / Hyper-V）上管理 Linux 虚拟机，init / start / restart / os upgrade 全流程脚本化。

8. 生态复用而非重写。 构建交给 Buildah，镜像搬运与签名交给 Skopeo，OCI 运行时用 crun 或 runc，网络用 netavark + aardvark-dns，存储与镜像解析复用 go.podman.io/storage、go.podman.io/image/v5（来自 container-libs）。Podman 自己主要解决「编排这些轮子」的那一层。

深度设计剖析

这一节不按功能讲，只挑三条最能体现「无守护进程」主线的设计决策。机制梳理参考了 DeepWiki 的架构导读——它把 libpod、SpecGen、REST API、machine、Quadlet、Networking 列为六个核心子系统——但下面每条结论都回源码核对过。

设计亮点一：把「守护进程」换成一个每容器进程——conmon

常规方案。 dockerd 常驻，containerd 管生命周期，每个容器再挂一个 shim。好处是状态集中、API 统一；代价是宿主机永远有一个高权限常驻进程，容器进程是 daemon 的「孙进程」，daemon 出问题，容器与外部世界的关系就要重建。

Podman 的设计。 podman run 本身是普通进程。启动容器时，它 fork 出一个 conmon（container monitor）作为每个容器的监护人。conmon 不在这个仓库里——它是 containers/conmon 的一个小 C 程序，Podman 用 exec 把它拉起来，两者之间只靠管道、unix socket 和文件通信：容器退出码不是通过 IPC 传回的，而是由 conmon 写进 --exit-dir/<容器ID> 文件，Podman 读到后 Atoi 成 state.ExitCode；OOM 则留下一个 persist-dir/<id>/oom 文件。conmon 自己会 set_subreaper(true)，它的注释原话是「so we can wait for container process and return its exit code」——容器进程的收尸人是 conmon，不是 Podman。源码里能直接看到这套参数：libpod/oci_conmon_common.go:1344 的 sharedConmonArgs 传 --exit-dir、--persist-dir、--full-attach，日志按 k8s-file:<path> 落盘，最后再传一条 --exit-command——它指向 podman 自己。前台 attach 时连的也是 conmon 在容器 bundle 里建的 socket，pty 和 stdin 都由 conmon 持有。

为什么这么做。 conmon 退出前会执行那条 exit command：podman container cleanup --stopped-only [--rm]。pkg/specgenutil/util.go:303 的注释写得很坦白：「We need a cleanup process for containers in the current model」——在无守护进程模型里，回收必须由某个进程负责，而最自然的回收者就是容器退出时还活着的那一个。这条清理路径同时承担了重启策略：libpod/container_internal.go:2179 的 fullCleanup 会先调用 handleRestartPolicy（调用点在 :2196），命中策略就重新拉起容器。重启不是某个常驻循环干的，而是一次退出钩子的副作用。

还有一个衔接细节值得说：容器启动时，Podman 会把 MAINPID=<conmon PID> 写给 systemd（--sdnotify=conmon 时还负责发 READY=1；默认的 container 模式则让运行时把 NOTIFY_SOCKET 代理进容器）。于是 systemd 眼里，这个 unit 的主进程就是 conmon——「容器活着」与「unit 活着」在 init 系统里被对齐了。这也是后面 Quadlet 能成立的前提。

工程价值与代价。 价值是安全与资源：空闲时零常驻管理进程（rootless 的 pause 进程除外），攻击面小；CI 里直接跑命令，不需要 socket，也不需要特权。代价是「没有中心大脑」：容器退出后的清理、重启、自愈都依赖一次性进程的副作用和外部 supervisor。所以官方在 --restart 的文档里直接建议——在 systemd 服务里跑容器时，请用 systemd 的 Restart=，不要用 Podman 自己的重启策略；机器重启后，podman-restart.service 负责把容器叫回来。

更具体地数，代价至少有四条：其一，进程数线性增长，N 个容器就是 N 个常驻 conmon，每次退出还额外拉一个短命的 podman container cleanup；其二，健康检查其实也不是 Podman 在轮询——启动时它用 systemd-run 注册一个 transient timer（--on-unit-inactive=<interval> 触发 podman healthcheck run --ignore-result），没有 systemd 就没有自动健康检查；其三，状态必须落盘，v6 起只剩 SQLite（BoltDB 被移除，旧库会在下次运行时自动迁移，也可用 podman system migrate --migrate-db），并发靠共享内存锁与文件锁；其四，需要 API 时得另起服务。如果确实要 REST 接口，就显式启动 podman system service：它支持 systemd socket activation，空闲超过 --time 自动退出，回到「零常驻」。

设计亮点二：rootless 不是「模拟 root」，而是把 root 装进命名空间

常规方案。 守护进程以 root 运行，用户通过 docker 组或 socket 获得等同 root 的力量；rootless 方案要么依赖 setuid 二进制，要么干脆没有。

Podman 的设计。 Podman 主二进制从来不是 setuid。官方 rootless 教程的原话是：「Rootless Podman is not, and will never be, root; it's not a setuid binary, and gains no privileges when it runs.」它把「变成 root」拆成两步：新建 user namespace 不需要特权，Podman 自己 re-exec 进去；写 uid_map 需要特权，交给 newuidmap / newgidmap 这两个 setuid 工具，映射区间从 /etc/subuid 读——每个用户预留 65,536 个 UID/GID 供给容器内的其他用户。Podman 甚至会检查这两个工具是否真的有 setuid/filecaps 位，出错信息就是「should have setuid or have filecaps setuid」。提权点因此被压缩到两个职责单一的小工具上，而不是一个长期运行的守护进程。

网络方面，rootless 默认走 pasta（从 Podman 5.0 起取代 slirp4netns），它把主机的 IP 直接搬进容器网络，端口转发由 rootlessport 或 pasta 的 pesto 完成。2026 年的增量是：slirp4netns 后端已经从代码里删掉了，只剩 pasta，旧容器要执行 podman system migrate（6.0.0 的 release notes 有明确公告，源码里遇到 slirp4netns 会直接报错并提示迁移）。存储方面，内核 ≥ 5.12 时可直接用 native overlayfs，否则退回 fuse-overlayfs；rootless 只支持 overlay 与 VFS 两种驱动。

还有一个容易被忽略的细节：rootless Podman 会留一个 pause 进程「挂住」用户与挂载命名空间——因为命名空间会随最后一个进程退出而消失，pause 进程保证后续 podman 命令能加入同一套命名空间。注意这个 pause 进程和 Pod 里的 infra 容器不是一回事，只是英文同名。

为什么这么做。 这套设计把安全边界变成可陈述的命题：容器能做什么，取决于调用者本来能做什么。它不追求「容器内像 root」，追求的是「容器内最多等于你」。

工程价值与代价。 价值是无需特权即可运行，配合 SELinux/AppArmor 还能再收一层。代价被官方写在 rootless.md 里，且相当坦诚：不能绑定 1024 以下端口（除非改 net.ipv4.ip_unprivileged_port_start）、NFS 家目录不可用、CRIU checkpoint 需要 root、容器内最多 65,536 个 UID、podman mount 只在用户命名空间可见。更隐蔽的一条是：pasta 复制了主机 IP，导致容器之间默认互不可达，要跨容器通信必须显式配置网络。这些不是 bug，是边界——读懂它们，比记住「Podman 支持 rootless」有用得多。

设计亮点三：Quadlet——把「编排」交还给 init

常规方案。 早期做法是 podman generate systemd 生成 unit 文件手动维护——该命令从 4.7 起被标记为 deprecated，官方指向 Quadlet；或者依赖 compose 这类外部编排工具——在 Docker 语境下它背后仍是 dockerd（也就是我们刚刚删掉的那个守护进程），podman-compose 则只是 CLI 包装。

Podman 的设计。 Quadlet 是一个 systemd generator：cmd/quadlet/main.go 的开头注释写明「这是 systemd generator（系统级还是用户级由二进制的名字决定）」，并提醒 generator 运行在极早期环境里（没有 /var、/home、syslog）。它在开机和 systemctl daemon-reload 时，扫描 /run/containers/systemd/、/etc/containers/systemd/、/usr/share/containers/systemd/（rootless 另有 $XDG_RUNTIME_DIR/containers/systemd、~/.config/containers/systemd 与 users/${UID} 目录），把 .container 文件翻译成 $name.service（容器名自动加 systemd- 前缀）。生成出来的 service 是 Type=notify——正好接上前面「conmon 接管 MAINPID」的设计；而 generator 的产物是 transient unit、不能 systemctl enable，所以 Quadlet 在生成时自己实现了 [Install] 的语义，这就是为什么你只写一句 WantedBy=default.target 就能开机自启。

为什么这么做。 没有守护进程，谁来负责「开机自启」和「挂了重拉」？答案是 init 系统。systemd 已经解决了进程监管、依赖顺序、日志收集、重启策略，Podman 要做的只是把容器声明翻译成 systemd 认识的语言——而不是再写一个编排器。

工程价值与代价。 价值是生产可用性：容器不再需要「有人登录着」才活着，也不依赖任何 Podman 常驻进程。代价有三：generator 环境受限，配置写错只能去 /dev/kmsg 或 systemd-analyze --generators=true verify <unit> 里找；改完文件必须 daemon-reload；以及能力上限——Quadlet 不是 compose，更不是 K8s，跨主机、多副本、滚动更新仍然应该交给 Kubernetes。官方对 Quadlet 的定位是：用 systemd unit 在 Linux 上声明式管理容器、Pod、卷、网络和镜像，不需要 Kubernetes 这类完整编排工具——它管的是单机上的服务，不是集群。

项目细节补充

治理与发布。 Podman Container Tools 是 CNCF 沙箱项目，治理、Maintainers、安全披露政策都在 podman-container-tools/community 仓库；CNCF 项目页显示 LFX Insights 健康度 Excellent（85）。所有 release 均 PGP 签名，公钥放在独立的 release-keys 仓库。项目还有一份 LLM_POLICY.md（组织级 AI 开发政策）和 OpenSSF Best Practices 徽章（passing 级，2025-05-06 达成）——这类「元文件」往往比功能列表更能说明一个项目的成熟度。

支持的边界写得很清楚。 SUPPORT.md 列了自动化测试矩阵：Linux x86_64 只测最新 Fedora 与 Debian；Podman machine 测 Windows 2025 的 WSL/Hyper-V 与 macOS ARM64 的 AppleHV/Libkrun。矩阵之外的组合是「best effort」。6.0 起不再支持 Windows 10 与 Intel Mac。上游原则上只支持最新版本，但 5.8 被特批为 LTS、支持到 2027-06-07——这解释了为什么 2026-10-12 会同时发布 6.1.4 和 5.8.9：同一天两套版本号，是 LTS 在还技术债。

v6.0 的破坏性变更值得单独记一笔。 移除 BoltDB（启动时自动迁移到 SQLite）、移除 cgroups v1、移除 iptables（改用 nftables）、移除 Intel Mac 与 Windows 10 支持，同时升级到 Buildah v1.44、Skopeo v1.23、Netavark/Aardvark v2.0。RELEASE_NOTES 还记录了两个 CVE 修复（CVE-2026-57231 恶意镜像的 Env 条目导致宿主机环境变量泄漏、CVE-2026-19730 Quadlet 文件替换不截断）——大版本敢做减法，通常意味着项目知道自己的维护边界在哪。

一个诚实的瑕疵。 仓库迁移已经完成，但 README 徽章、install.md、部分文档链接仍指向 containers/ 旧组织。301 跳转让它不致命，但说明「搬家」的收尾工作还没做完。不过迁移本身并不只是改链接：v6.0 把 Go 模块路径从 github.com/containers/podman/v5 换成了 go.podman.io/podman/v6——对下游项目来说，这是一次真正的模块身份变更。路线图上还挂着 composefs、zstd:chunked 部分拉取、BuildKit API 兼容和二进制体积优化。

项目资源汇总

官方资源

GitHub：podman-container-tools/podman
开源协议：Apache-2.0
更新日志：仓库内 RELEASE_NOTES.md
贡献指南：CONTRIBUTING.md、REVIEWING.md
安装文档：podman.io/docs/installation
命令手册：podman.readthedocs.io
REST API 文档：docs.podman.io API
桌面端：Podman Desktop

相关资源

Buildah：镜像构建，Podman 的 build 直接复用
Skopeo：镜像搬运与签名；与 podman image scp 共用 containers/image 库
crun：默认 OCI 运行时，性能优先
conmon：每容器一个的监护进程，本文「深度设计剖析」的主角
Netavark / Aardvark-DNS：容器网络与 DNS
passt：pasta 的宿主项目，rootless 网络自 5.0 起默认走 pasta
CRI-O：Kubernetes CRI 实现，与 Podman 共享 conmon

媒体报道与延伸阅读

DeepWiki 架构导读：deepwiki.com/podman-container-tools/podman（第三方自动生成，覆盖 CLI→引擎的数据流、libpod/SpecGen/REST API/machine/Quadlet/Networking 子系统地图；事实仍以源码与官方文档为准）
官方博客：blog.podman.io（含 6.0 破坏性变更详解、CNCF 迁移说明）

核心要点回顾

没有守护进程不是「省了一个进程」：它把状态所有权、回收责任、重启策略都重新分配给 conmon、一次性清理进程和 systemd，换来了更小的攻击面与更清晰的权限边界。
rootless 的价值在边界清晰：容器权限不超过调用者；代价是低端口、NFS、CRIU、UID 上限等一串硬限制，全部写在官方文档里。
生产化路径是 systemd/Quadlet，本地开发路径是 podman machine + Docker API 兼容；两条路都不依赖常驻管理器。

适合谁

想要「Docker 替代」但不想要 root 守护进程的开发者与运维；
需要在共享 CI、边缘设备、不可变系统上跑容器的团队；
想理解「无守护进程容器引擎」如何设计、如何取舍的架构读者。

一句话评价

Podman 用「删掉守护进程」这件事，换来了一套权限可陈述、状态可回收、生产可交给 systemd 的容器工具链——它不是 Docker 的影子，而是另一种答案。