Podman 是一款开源的容器引擎，核心功能与 Docker 兼容，主打无守护进程（daemonless）架构和更强的安全性。
Podman 由红帽主导开发，目标是成为 Docker 的直接替代方案，支持 OCI 容器标准，可无缝运行 Docker 镜像，迁移成本极低。
OCI（Open Container Initiative，开放容器倡议）容器标准是由 Linux 基金会主导、多家技术公司（如红帽、谷歌、微软等）共同制定的一套开放的容器规范，旨在统一容器的格式和运行时行为，避免容器技术碎片化，确保不同容器引擎之间的兼容性。
OCI 标准主要包含两个关键规范，它们共同定义了容器的生命周期和交互方式：
（1）OCI 镜像规范（Image Specification）
规定了容器镜像的文件格式、目录结构和元数据标准。定义了镜像如何被打包（如分层存储、Manifest 清单文件、配置文件等）。确保不同工具（如 Docker、Podman、Buildah 等）构建的镜像可以互相兼容，例如 Docker 构建的镜像可被 Podman 直接运行。
（2）OCI 运行时规范（Runtime Specification）
规定了容器运行时的行为标准，包括容器的创建、启动、停止、销毁等生命周期管理。定义了容器进程的隔离方式（如命名空间、控制组）、资源限制、挂载点等底层细节。确保不同运行时（如 runc、crun、kata-runtime 等）对容器的操作逻辑一致，上层引擎（如 Kubernetes）可无缝调用。
主要有下面几点：
兼容性：只要遵循 OCI 标准，不同厂商的容器引擎（如 Docker、Podman）、镜像仓库（如 Docker Hub、Harbor）、运行时（如 runc）就能互相兼容，用户无需担心 “锁定效应”。
开放性：避免了某一厂商垄断容器标准，推动容器技术在开源生态中健康发展。
可移植性：容器可以在不同环境（开发、测试、生产）和不同平台（Linux、云服务）之间无缝迁移，降低了跨环境部署的复杂度。
容器引擎：Docker、Podman、CRI-O（Kubernetes 容器运行时接口实现）。
镜像构建工具：Buildah、Docker Build、Kaniko。
运行时：runc（Docker 默认运行时）、crun（轻量替代方案）、kata-runtime（安全隔离型运行时）。
Podman 是由红帽公司领导开发的容器管理工具，其发展历程如下：
项目启动：2017 年，Podman 项目在 GitHub 上进行了首次提交，最初它被称为 kpod，后来改名为 Podman，即 “Pod Manager” 的缩写。
首次公开版本发布：2018 年，Podman 发布了第一个公开版本 0.2。
1.0 版本发布：2019 年 1 月 16 日，Podman 1.0.0 版本正式发布，标志着该工具在功能和稳定性上达到了一个新的里程碑。
仓库重命名：2020 年 7 月，随着 Podman 2.0 版本的发布，其在 GitHub 上的仓库从github.com/containers/libpod 重命名为 github.com/containers/podman，以更好地反映项目的实际使用情况和重点。
支持 Docker Compose：2022 年，Podman 4.1 版本增加了对 Docker Compose v2.0 的支持，使用户能够更方便地在 Podman 环境中使用现有的 Compose YAML 文件。
Podman Desktop 发布：2023 年 5 月 23 日，Podman Desktop 1.0 版本发布，为用户提供了一个图形化的界面来管理 Podman 容器。
捐赠给 CNCF：2024 年，红帽公司在 Kubecon 上宣布将 Podman 和 Podman Desktop 捐赠给云原生计算基金会（CNCF），2025 年 1 月 21 日，这两个项目被 CNCF 正式接受。
下面是 Podman 的主要特性：
（1）无守护进程设计：无需后台运行 dockerd 服务，容器进程直接由用户进程启动，减少系统资源占用。
（2）原生 rootless 支持：默认可在非 root 用户下运行容器，避免 root 权限泄露风险，安全性更优。
（3）与 Docker 兼容：支持 docker build、docker run 等常用命令，可通过 alias docker=podman 直接替换使用。
（4）内置 Pod 支持：原生支持 Pod（容器组）概念，可一次性管理多个关联容器，无需依赖 Kubernetes。
（5）轻量灵活：体积更小，启动更快，同时支持 Linux、macOS、Windows 等多平台。
Podman 和 Docker 都是主流的容器引擎，均遵循 OCI 标准（兼容容器镜像和运行时），但在架构设计、安全性、功能特性等方面存在显著差异。主要区别如下：
特性 | Docker | Podman |
架构模式 | 客户端 / 服务器（C/S）架构，依赖守护进程 dockerd。所有容器操作（如 run、build）都需通过客户端与 dockerd 通信，由守护进程统一管理容器。 | 无守护进程（daemonless）架构，直接通过命令行工具与容器运行时（如 runc）交互。容器进程由用户进程直接启动，无需中间守护进程。 |
进程关系 | 容器是 dockerd 的子进程，依赖守护进程存活。 | 容器是 podman 命令的子进程，与用户进程直接关联，不依赖后台服务。 |
故障影响 | 若 dockerd 崩溃，所有运行中的容器会受影响（甚至终止）。 | 无守护进程单点故障，即使 podman 命令退出，容器仍可正常运行。 |
Root 权限依赖 | 传统上默认需要 root 权限运行 dockerd（虽然后续支持 rootless，但配置较复杂）。 root 权限下，容器漏洞可能直接影响主机系统。 | 原生支持 rootless 模式（非 root 用户运行），且配置简单。 默认推荐非 root 运行，通过 Linux 用户命名空间隔离，降低权限泄露风险。 |
安全隔离 | 依赖 dockerd 权限控制，root 模式下隔离边界较薄弱。 | 基于用户命名空间（user namespace）实现更严格的隔离，非 root 容器无法访问主机敏感资源。 |
Pod 支持 | 不原生支持 Pod（容器组），需依赖 Kubernetes 管理。 | 原生支持 Pod 概念，可通过 podman pod 命令创建包含多个容器的 Pod，适合本地模拟 Kubernetes 环境。 |
到这里，你已经对 Podman 有粗浅的认识了，更多 Podman 的知识请阅读后续章节……
川公网安备51010802032098
