选择 podman 的理由, 以及它和 Kubernetes , Docker 的区别 podman 是什么官方网站: podman.io官方自己的介绍: https://podman.io/whatis.html名称 podman ,官方说明是 Pod Manager , 所以它不仅可以管理 OCI 容器,还可以管理 pod , 这也是和 docker 的最大差别吧.和 kubernetes 的区别kubernetes(k8s) 是目前最流行的容器编排工具, 集群管理工具, 生态很完善, 也很"重", pod 的概念就来自 k8s , 虽然 podman 也是管理 pod, 但是远远不及 k8s 的编排功能, 同时 podman 也没有集群管理功能,如果需要管理集群, 需要第三方工具完成.所以 podman 定位也不是编排和集群管理工具, 紧紧是一个 pod 和容器的管理工具. 所以不是一个级别的东西, 这里不做太多的比较.和 docker 的区别如果仅仅从 docker 和 podman 两个命令提供的功能来讲,它们功能交集很大, podman 官方甚至推荐 alias docker=podman 来过渡.docker 文档更齐全, podman 可以借用一下 docker 的文档docker 生态更加完善, podman 一时半会赶不上,但是如果你只是去跑容器, 那这是一样的docker 有 docker-compose, podman 早期没有对应工具,后面也出了 podman-compose, 但是这个功能是否必须? 值得考虑,因为 podman 支持 pod 管理.docker 有 machine , 让 windows 和 mac 支持 linux 容器, podman 也支持,而且已经比较完善.docker 有 docker-desktop , podman-desktop 目前还比较简单.docker 支持 rest api , podman 也支持 rest api, 这使得开发生态工具会比较简单.docker 有 swarm 支持集群部署, podman 没有对应工具, 不过支持 remote , 调用远程机器上的 podman service 执行对应的功能 , 这样能满足很多轻量化的场景.k8s 之前支持使用 docker-shim 和 docker 集成, 不过新版本也放弃这一层, 直接通过 CRI 调用 contained , podman 也不支持 CRI. 并且也没有什么计划.docker 商业/开源并行, podman 只有开源版本, 目前没有哪家公司提供商业支持(不清楚 redhat 有没有对应的服务,可能集成在订阅里面了).为什么选 podman上面讲了不少 docker 比 podman 有优势的方面, 这里开始讲 podman 的另外的东西, 这也是我选择 podman 主要原因.先罗列一下 podman 适合的场景没有很强的集群管理需求(或者说,已经有 overlay network 方案, podman 也是适用的)仅仅为了容器化一些应用团队内部轻量级使用,比如 ci/cd , 开发,测试环境等.喜欢命令行或者脚本运维感兴趣 podman 的生态建设(坑)那么 podman 比 docker 好的方面有哪些呢?更加 rootless , 尽管 docker 也可以 rootless, 但是 podman 设计之初就开始支持没有 daemon , 这使得 podman 在结合 namespace 和 cgroup 一起使用会更加灵活pod , 和 k8s 基本一样的 pod , 一样支持 infra 容器. 这使得一些简单的容器编排 工作, podman 也可以简单实现.systemd service 集成, 由于没有 deamon , podman 通过 generate 子命令, 可以生成 systemd service 配置, 来管理容器和 pod 的作为服务启动.k8s 关联, podman 可以生成 kubectl 的 yaml 配置文件, 也通过 podman play kube 来运行 k8s 的配置, 也可以作为 k8s 的一个过渡吧, 而且 podman 也没有去实现 CRI 的计划, 这应该也是官方的态度, 不会参和到 k8s 生态中, 保持自己的轻量化工具的定位吧.remote , podman 通过 ssh 隧道或者 tcp 端口, 可以连接到远程机器上的 podman service, 从而实现远程机器上的容器和 pod 管理.所以 podman 提供了一些轻量化而又灵活的功能特性,满足容器化,以及小批量服务器的场景.https://zhuanlan.zhihu.com/p/506265757