Podman 是一个容器引擎——一个用于开发、管理和运行容器和容器镜像的工具。容器是标准化的、自包含的软件包，其中包含无需定制即可在任何地方运行所需的所有元素，包括应用程序代码和支持库。在过去十年中，基于容器的应用程序彻底改变了软件开发，使分布式和基于云的系统易于部署和维护。
Podman 是 Red Hat 的一个开源项目，可以免费下载。它是容器化领域的一个相对较新的人，1.0 版将于 2019 年发布。此后 Podman 取得了长足的进步，其崛起伴随着 Docker 的逐渐衰落，该项目在许多方面创造了我们今天所知的容器世界。
目录
- Podman 和 Kubernetes
- Podman 与 Docker
- Podman 会取代 Docker 吗？
- 您应该使用哪个容器引擎？
Podman 和 Kubernetes
如果你对基于容器的开发稍微熟悉一点，你就会知道Kubernetes这个名字。随着容器化应用程序变得越来越复杂，开发人员需要能够协调在不同虚拟机甚至不同物理机上运行时相互交互的容器的工具。这样的工具被称为容器编排平台，Kubernetes 是迄今为止最突出的例子。Kubernetes 可以与任何符合开放容器倡议(OCI) 镜像规范的容器一起工作，Podman 的容器可以做到这一点。
[也在 InfoWorld 上：什么是 Kubernetes？您的下一个应用平台]
Kubernetes 的一个重要特性是 Pod 的概念，它是一个或多个容器的临时分组，是 Kubernetes 可以管理的最小计算单元。顾名思义，Podman 也以 Pod 的概念为中心。Podman pod 还包括一个或多个容器，这些容器组合在一个命名空间、网络和安全上下文中。这种相似性使 Podman 和 Kubernetes 天作之合，从一开始，Red Hat 的目标之一就是让 Podman 用户使用 Kubernetes 编排容器。
Podman 与 Docker
您几乎肯定听说过的容器世界的另一个大牌是 Docker。Docker 不是第一个容器引擎，但在许多方面它已经定义了容器化。Docker 的大部分工作方式是基于容器的开发的事实上的标准——足以让许多人使用“Docker”作为容器的简写。
虽然 Docker 和 Podman 在容器生态系统中占据了相似的空间，但它们并不相同，它们在工作方式上有着不同的理念和方法。例如，Docker 是一个包含用于特定任务的工具的一体化平台，而 Podman 则出于某些目的与其他项目协作——例如，它依赖Buildah来构建容器镜像。
还有架构上的差异：例如，Docker 没有原生的 Pod 概念。另一个重要的区别是 Docker 依赖于一个持续运行的后台守护程序来创建镜像和运行容器，而 Podman 将容器和 Pod 作为单独的子进程启动。Docker 设计的这一方面对安全性有重要影响，我们将在稍后讨论。
Podman 上的 Docker 命令
根据设计和必要性，Podman 和 Docker 是整体兼容的。部分兼容性可归因于对开放标准的遵守。因为这两个引擎都使用符合 OCI 标准的容器，所以您可以使用 Docker 创建一个容器并在 Podman 中对其进行修改，反之亦然，然后将任一容器部署到 Kubernetes 上。
当 Podman 于 2019 年推出时，Docker 占据主导地位，以至于其命令行界面已成为许多开发人员编程例程和肌肉记忆的一部分。为了使 Podman 的潜在迁移更加无缝，Podman 的创建者确保其命令和语法尽可能地反映 Docker。他们甚至可以设置一个别名，将 Docker 命令重新路由到 Podman。
使用无根容器提高安全性
Podman 和 Docker 在很多方面都如此相似，您为什么要选择其中一个呢？嗯，一个重要的原因是安全性。还记得 Docker 是如何依赖守护进程来完成大部分正在进行的工作的吗？该守护进程以 root 身份运行，这使其成为攻击者的潜在入口点。这不是安全计算的不可逾越的障碍，但这确实意味着您必须考虑解决 Docker 安全问题。
在某些情况下，您需要在其主机上运行具有 root 权限的容器，而 Podman 允许您这样做。但是，如果您希望将容器安全地限制在用户空间，您也可以通过运行所谓的无根容器来做到这一点。无根容器的权限不超过启动它的用户；在容器中，该用户具有 root 权限。您还可以使用命令行标志以精细的方式向容器添加权限。
性能呢？
至少在某些人看来，Docker 在 Podman 上的优势之一是性能。虽然关于这个主题的具体信息很少，但在Hacker News、Stack Overflow和Reddit上不难找到沮丧的开发人员抱怨 Podman 的性能，尤其是当它无根运行时。一些瑞典大学生在几个不同的容器平台上运行了一个基准套件，发现 Podman 缺少.，尽管这是 Podman 1.0 之前的旧版本。虽然关于这个主题的技术信息并不多，但有趣的是 Podman 因其性能而受到抨击。
Podman 会取代 Docker 吗？
从目前的讨论来看，用 Podman 取代 Docker 听起来可能不会有任何重大的氛围转变。但是一个重大的变化即将到来，它将取代 Docker 从它的长期利基之一：Kubernetes 本身。
Kubernetes 和 Docker 多年来一直是容器世界的双胞胎巨头。但他们的共处总是有些不安。Kubernetes 的兴起是在 Docker 在其利基市场中建立起来之后——事实上，你可以说 Kubernetes 变得流行的部分原因是 Docker 无法胜任管理需要在大型分布式应用程序中协调的所有容器的任务.
Docker（该公司）于 2015 年开发了自己的容器编排平台，称为 Swarm，旨在发挥 Docker 的优势。Swarm大张旗鼓地推出，但从未完全赶上 Kubernetes。虽然 Swarm 仍然有拥护者，但 Kubernetes 已经成为容器编排的事实标准，就像 Docker 成为容器生态系统其他方面的事实标准一样。
Docker 如何一分为二
此外，就容器运行时而言，Docker 与 Kubernetes 的关系并不好，这是容器引擎的低级组件，除其他任务外，它与底层操作系统 (OS) 内核一起工作并挂载单个容器映像。Docker 和 Kubernetes 都符合 OCI 镜像规范，Kubernetes 使用该规范来协调构建到容器的镜像。但 Kubernetes 还依赖于与称为容器运行时接口(CRI)的标准化插件 API 兼容的容器运行时，而 Docker 从未着手实施。
长期以来，Docker 的流行迫使 Kubernetes 使用Dockershim，这是一个符合 CRI 的层，是 Kubernetes 和 Docker 守护程序之间的中介。然而，这总是一种 hack，今年早些时候，Kubernetes放弃了对 Dockershim 的支持。（相比之下，Podman 使用来自云原生计算基金会的兼容 CRI-O 运行时。）
这是关于Docker 尝试和失败成为一家企业公司的更大故事的一部分。简而言之，Docker 从未完全脱离 Kubernetes。与此同时，Kubernetes 不再像以前那样需要 Docker。
Podman 是否会取代 Docker 尚不清楚，但它肯定会是竞争者之一。Podman 不是寻求货币化的旗舰产品，而是来自一家大得多的公司的单一开源技术产品，这很有帮助。我们可以预期 Podman 和 Kubernetes 将在未来一段时间内保持紧密联系。
您应该使用哪个容器引擎？
希望本次讨论能让您了解有助于您在这两个容器引擎之间进行选择的因素。Podman 基于更安全的架构，而 Docker 有着更深的历史。Podman 是 Kubernetes 原生的，而 Docker 也适用于 Docker Swarm。Docker 包含许多与容器相关的任务所需的所有功能。Podman 是模块化的，可让您为不同目的尝试不同的工具。
话虽如此，“Podman 与 Docker”的问题在某种程度上是一个错误的选择。两个平台都创建符合 OCI 规范的图像，并且都由许多相同的命令驱动，因此您可以在两者之间无缝移动。例如，您可能想使用 Docker 进行本地开发，然后使用 Podman部署您在 Kubernetes 中构建的容器。
使 Docker 与众不同的一个特点是它提供了付费支持。但即使这样也有不利的一面：随着 Docker（该公司）试图将其旗舰产品货币化，它已经开始对 Docker 桌面开发环境收费。另一方面，红帽目前似乎满足于暂时让 Podman 免费。
选择合适的比选择最流行技术架构的更重要
