转载自https://zhuanlan.zhihu.com/p/506265757

前言

大家好,我是 Liangdi, podman 4.x 版本已经发布了, 我也从 docker 开始向 podman 迁移, 所以是合适的时候写点 podman 的文章了.

podman 是什么

官方网站: podman.io

官方自己的介绍: 

名称 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 提供了一些轻量化而又灵活的功能特性,满足容器化,以及小批量服务器的场景.

最后聊聊 podman 所在的 https://github.com/containers 组织

查看这个组织的仓库可以看到,他们真的是在做容器工具, 而且写了很多轮子, 包括 buildah 和 skopeo 这两个工具,与 podman 一起被称为下一代容器工具.

runc 是一个有名的 low-level OCI rumtime, 他们就开发了一个 crun . podman 早期版本使用 runc, 最新的版本已经使用 crun 了.

众所周知, golang 是容器生态的主要语言, podman 也是 go 写的,但是在 podman 4 的版本中, podman 增加了非 CNI 的网络栈支持, 这几个工具是 netavark 和 aardvark-dns, 这两个工具是 rust 写的, 而且还有 youki 这个 rust 写的 low-level OCI runtime, 不知道将来某一天 podman 会不会默认使用 youki , 还有好几个 rust 写的容器技术相关的应用和库, 这是要与 golang 分天下的节奏.

如果你也对 podman 以及其生态感兴趣, 关注我吧, 我会给你带来 podman 最新的动态以及实践方案.

 

原文地址:http://www.cnblogs.com/northlander/p/16797530.html

1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长! 2. 分享目的仅供大家学习和交流,请务用于商业用途! 3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入! 4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解! 5. 如有链接无法下载、失效或广告,请联系管理员处理! 6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需! 7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员! 8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性