Podman 项目路线图深度解读季度治理机制、2025 里程碑与未来技术方向【免费下载链接】podmanPodman: A tool for managing OCI containers and pods.项目地址: https://gitcode.com/gh_mirrors/po/podmanPodman 作为管理 OCI 容器与 Pod 的守护进程无架构工具其发展方向由社区季度评审机制驱动维护者按季度收集利益相关方的功能请求并排序再将优先级最高的功能分配给工程师实施。本文以仓库根目录的 ROADMAP.md 为骨架逐项解读未来功能候选清单与 2025 年 Q1~Q3 的发行与功能承诺并结合当前仓库源码、手册页与设计文档帮助读者理解各技术方向的实际落地状态、核心能力所在位置以及如何跟踪与参与 Podman 的演进。一、路线图的来源与治理机制Podman 的路线图并非固定不变的年度计划而是一个持续运转的**季度评审quarterly review**流程。根据 ROADMAP.md 开篇的说明其工作机制可以概括为三个步骤收集开发团队每季度收集来自各利益相关方用户、发行版维护者、上游容器生态项目、Podman Desktop 等周边工具链的功能请求排序Podman 维护者maintainers根据影响面、技术可行性、社区需求等维度对这些功能进行优先级排序执行被列为最高优先级的功能会被指派给一名或多名工程师实施。每个季度的结果会在季度初1 月、4 月、7 月、10 月追加到 ROADMAP 的Milestones and commitments by quarter章节中。也就是说该章节是一份历史账本既记录了已完成[x]的承诺也记录了仍在进行中[ ]的工作。这一治理机制的落地还体现在仓库的其他文档中仓库根目录的 GOVERNANCE.md 定义了项目治理模型MAINTAINERS.md 维护维护者名单CONTRIBUTING.md 说明社区如何提交功能请求与补丁。这与 ROADMAP 中 2025 Q1创建 Maintainers 文件、2025 Q2建立并遵守治理模型的承诺一一对应说明路线图不只是愿望清单其背后的组织建设也被纳入里程碑管理。二、未来功能候选清单无时间线但很可能进入后续季度里程碑ROADMAP 列出了 7 项对 Podman 具有普遍重要性的未来功能考虑。这些项目尚未绑定时间线但很可能出现在未来的季度里程碑中。下面逐项解读并结合当前仓库给出可以验证的实现痕迹。1.podman machine的进一步改进podman machine是 Podman 在 macOS、Windows 上运行 Linux 虚拟机的核心入口也是 Podman Desktop 等图形化前端依赖的底座。候选清单中包含两个具体方向更平滑的 Podman machine 操作系统OS镜像升级流程即podman machine所依托的 VM 镜像如 Fedora CoreOS 类镜像在版本演进时升级过程应更顺畅、更少人工干预WSL 技术与其他 Provider 的收敛包括其 OS 在内将 Windows Subsystem for LinuxWSL的实现方式与其他 provider如 Hyper-V、QEMU、AppleHV逐步统一。仓库中 pkg/machine 目录集中了该功能的实现包含 machine_common.go、machine_unix.go、machine_windows.go 等平台相关文件以及 qemu、hyperv、applehv、wsl、libkrun 等各 provider 子包pkg/machine/vmconfigs 存放 VM 配置结构。CLI 层面对应 cmd/podman/machine 下的 24 个命令文件教程见 docs/tutorials/mac_win_client.md。收敛 WSL 技术这一方向从 pkg/machine/wsl 子包与 pkg/machine/provider 的 provider 抽象并存可以推断项目正以统一的 provider 接口来容纳多后端实现。2. OCI 工件artifact的远程客户端支持与 RESTFUL APIOCI artifactsOCI 工件是与 OCI 镜像、容器相关联的通用文件分发方式。ROADMAP 明确把Remote client support for OCI artifacts and its RESTFUL API列为候选而实际上这一方向在 2025 Q1、Q2 已大规模落地见第三节未来候选中的表述可理解为对已有能力的持续完善。当前仓库中该功能已经非常完整CLI 侧 cmd/podman/artifact/artifact.go 定义了podman artifact命令组其下包含 7 个子命令实现文件——add.go、extract.go、inspect.go、list.go、pull.go、push.go、rm.go。手册页位于 docs/source/markdown/podman-artifact.1.md 及同目录下的podman-artifact-*.1.md(.in)系列。3. composefs 集成composefs 是一种只读、按内容寻址的文件系统可将镜像层以共享、去重的方式挂载从而降低存储开销并提升启动性能。ROADMAP 将其列为候选功能。需要说明的是从当前仓库的源码结构看尚未发现composefs相关实现痕迹这符合其未来考虑、无时间线的定位——读者在评估该能力时应以后续版本的 ROADMAP 更新与发行说明为准。4. 部分拉取partial pullzstd:chunked的持续推进zstd:chunked 是一种基于 zstd 压缩的镜像分层格式支持按需on-demand拉取部分块从而显著减少大镜像的下载流量与首启时间。ROADMAP 将ongoing work around partial pull support列为长期工作说明该项目处于持续演进而非一次性交付的状态。这与 Podman 底层复用 containers 生态image 层、存储驱动层的技术路线一致属于存储与分发链路的系统性优化。5. 对 BuildKit API 的改进支持BuildKit API 是 Docker 生态中广泛使用的镜像构建协议。ROADMAP 表示要改进对 BuildKit API 的支持方向是提升与既有构建工具链的互操作性。从仓库结构看pkg/api 目录下的 gRPCpkg/api/grpcpb、REST 服务端pkg/api/server与处理函数pkg/api/handlers共同构成了 Podman 的 API 服务层test/apiv2 与 pkg/bindings 则分别从协议测试与客户端绑定两个方向验证 API 兼容性这些基础设施是承接 BuildKit API 改进的载体。6. 性能与稳定性改进这是一项持续的、不设截止的工程承诺。仓库中与之呼应的有 contrib/perf 下的性能测试脚本run.sh、create.sh、ps.sh、rm.sh、system-df.sh等用于在真实容器生命周期中度量命令耗时hack/perf若存在与 CI 中的 hack/ci 脚本则负责把性能与稳定性回归纳入自动化检查。7. 缩减 Podman 二进制体积Podman 的 CLI 客户端体积直接影响下载与安装体验。这一目标在 2025 Q2 已被标记为完成[x] Reduce binary size of Podman但Reductions to the size of the Podman binary仍保留在未来候选清单中说明体积优化是持续性的工程投入而非一次性目标。三、2025 年季度里程碑与承诺逐季解读2025 Q3进行中2025 Q3 是 ROADMAP 中结果将在季度初追加的进行时条目多数任务以[ ]标记Releases发行[ ]Podman 5.6[ ]Podman 62026 年春季High Level Design仓库中的 contrib/design-docs/podman6hld.md 正是这份高级设计文档它系统梳理了 Podman 6 的破坏性变更、新功能、对 netavark 等组件的冲击与弃用项。其中值得关注的内容包括将 slirp4netns 的弃用正式化Pasta 自 Podman 5.0 起成为 rootless 默认网络方案、移除 CNI 插件代码、不再支持 cgroupsv1 并移除相关代码等。该文档对读者理解 Podman 6 的迁移路径具有直接参考价值。Features功能[ ]RESTFUL 服务持续升级以支持更新的 Docker API 版本保证podman作为 drop-in 的 Docker 兼容运行时pkg/api 与 test/apiv2 是这一工作的主战场[ ]Quadlet 文档改进Quadlet 允许用 systemd unit 文件声明容器、Pod、镜像与卷。其 unit 文件格式手册位于 docs/source/markdown/podman-quadlet-basic-usage.7.md 以及podman-*.unit.5.md.in系列如 podman-container.unit.5.md.in、podman-pod.unit.5.md.in、podman-kube.unit.5.md.in实现位于 pkg/systemd/quadlet[ ]系统级 rootless 用户配置Systemwide rootless user configuration面向系统管理员为多用户环境集中配置 rootless Podman 行为[ ]Windows 安装器改进仓库中的 contrib/win-installerWIX 工程与 PowerShell 脚本与 contrib/pkginstaller 是 Windows 与 macOS 安装包构建的所在地构建说明见 build_windows.md 与 build_osx.md。CNCF[ ]继续推进 CNCF incubation孵化Podman 已加入 CNCF下一步目标是进入 incubation 阶段需要满足更严格的中立治理、安全审计与社区健康度要求。2025 Q2已完成2025 Q2 的所有条目均已勾选完成[x]Podman 5.5 发布Podman 发布流程全自动化与 2025 Q1 的release automation一脉相承hack/ci 与 Makefile 中的发布目标支撑了自动化发布Windows ARM64 安装器在 x86_64 之外补齐 ARM64 支持RESTFUL 服务支持 artifacts即 OCI 工件可通过 API 服务管理减少 Podman 二进制体积为 artifacts 增加远程客户端支持RESTFUL 服务支持更新的 Docker API 版本用 rootfs 取代 Podman pause 镜像传统上podman依赖一个极小的 pause 镜像infra 镜像来持有 Pod 的网络命名空间改用 rootfs 后无需再为每个 Pod 拉取 pause 镜像减少下载与存储开销。这一点从 pkg/infra基础设施镜像相关逻辑与 libpod 中 infra 容器的处理逻辑可见其实现载体CNCF建立并遵守治理模型对应 GOVERNANCE.md。2025 Q1已完成2025 Q1 的里程碑聚焦于 OCI artifacts 的能力建设Podman 5.4 发布、发布自动化起步artifact add --append向已有 artifact 追加文件。源码位于 cmd/podman/artifact/add.go对应--append短选项-a标志artifact extract将 artifact 的 blob 解出到本地文件或目录实现见 cmd/podman/artifact/extract.go支持--digest、--title按需提取单个 blobartifact add --options为 artifact 设置注解、MIME 类型等元数据在容器内挂载 OCI artifacts使容器运行时可直接访问挂载的 artifact 内容确定远程场景下的配置文件策略解决使用远程客户端时containers.conf等配置文件的解析位置问题CNCF创建 Maintainers 文件、创建治理文档即 MAINTAINERS.md 与 GOVERNANCE.md。四、已落地能力的实战速查以 OCI artifact 为例由于 2025 Q1/Q2 的多数承诺围绕 OCI artifacts 展开这里结合源码给出最小可用示例帮助读者直接验证该能力。从 cmd/podman/artifact/artifact.go 可知命令组定义为Manage OCI artifacts其子命令集add / extract / inspect / ls / pull / push / rm的完整说明见 docs/source/markdown/podman-artifact.1.md。创建 artifact将本地文件写入本地 artifact store 并关联到镜像引用示例取自 add.go 的Example字段# 基础用法把 /tmp/foobar.txt 作为 artifact 存入本地 store podman artifact add quay.io/myimage/myartifact:latest /tmp/foobar.txt # 指定文件层的 MIME 类型 podman artifact add --file-type text/yaml quay.io/myimage/myartifact:latest /tmp/foobar.yaml # 追加文件到已有 artifact podman artifact add --append quay.io/myimage/myartifact:latest /tmp/foobar.tar.gzadd还支持--type描述 artifact 的 MIME 类型、--annotation为指定文件设置注解、--replace替换已有 artifact等标志均定义于 cmd/podman/artifact/add.go。提取 artifact示例取自 extract.go# 提取到单个文件 podman artifact extract quay.io/myimage/myartifact:latest /tmp/foobar.txt # 提取到目录 podman artifact extract quay.io/myimage/myartifact:latest /home/paul/mydirextract的--digest、--title标志允许只提取指定 blobcmd/podman/artifact/extract.go。此外podman artifact pull/push负责与镜像仓库同步 artifactls别名list与rm负责本地 artifact store 的查看与清理。这些能力同样以手册页形式沉淀在 docs/source/markdown 目录podman-artifact-pull.1.md.in、podman-artifact-push.1.md.in、podman-artifact-ls.1.md.in、podman-artifact-inspect.1.md、podman-artifact-rm.1.md可作为命令参考的一手资料。五、路线图的落地载体与跟踪方式理解 Podman 路线图时建议将 ROADMAP 与其他仓库文档配合阅读形成目标—设计—实现的完整链路层面仓库位置作用路线图与优先级ROADMAP.md季度承诺与未来方向大版本高级设计contrib/design-docs/podman6hld.mdPodman 6 的破坏性变更、弃用与新增功能其他设计文档contrib/design-docs如 Conmonv3.md、config-file-parsing.md单项功能的深入设计命令手册页docs/source/markdown每个podman子命令的权威参考治理与参与GOVERNANCE.md、MAINTAINERS.md、CONTRIBUTING.md治理模型、维护者名单与贡献流程对于希望贡献的开发者最直接的做法是阅读 CONTRIBUTING.md 了解提交规范对照 ROADMAP 中勾选中的[ ]条目认领工作并在 hack/ci 定义的 CI 检查下提交补丁涉及行为与协作规则的还可以参考 CODE-OF-CONDUCT.md。对于只想跟进状态的用户则可在每个季度初1 月、4 月、7 月、10 月关注 ROADMAP 的Milestones and commitments by quarter章节更新。六、小结Podman 的路线图是一份活的工程承诺文档季度评审机制保证了需求收集与优先级排序的节奏逐季里程碑把抽象方向如 OCI artifacts、发布自动化、Docker API 兼容、pause 镜像 rootfs 化转化为可勾选、可验证的交付物。当前仓库中OCI artifacts 的 CLI 与手册页、Podman 6 高级设计、Quadlet 文档、Windows 安装器、治理文件等均已就位读者既可以把它当作哪些功能已落地、哪些在路上的权威索引也可以依据 ROADMAP.md 中未完成项规划自己的贡献方向——这正是这份文档对开发者和用户的双重价值所在。【免费下载链接】podmanPodman: A tool for managing OCI containers and pods.项目地址: https://gitcode.com/gh_mirrors/po/podman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考