Crictl VS Podman

Kubernetes已经使用CRI-O作为容器运行时。自然的它也推出了相应的命令行工具Crictl来调试CRI-O，管理Images, ps等。

具体使用介绍，请参考Crictl的文档介绍以及Kubernetes文档中的使用Crictl调试节点。

似乎Critcl 可以做跟Podman, Docker同样的事情，它们有什么区别吗？本文以Podman为例，介绍它与Crictl的根本区别。记住一句话：Crictl 检查前端，Podman检查后端基础。见下图：

CRI-O 是一个轻量级的Kubernetes容器运行时，它符合OCI（开放容器倡议）规范。它旨在运行任何基于OCI的容器，并针对Kuberentes做了优化。当然，它也完全支持OpenShift, 您可以访问cri-o官网来了解更多。

Crictl是用来开发，测试，诊断容器运行时，同时也可以诊断Kubernetes的CRI-O的配置的工具。

Podman是一个无需容器守护进程(container daemon)即可管理Pod，容器的工具。Pod, Container 作为Podman的子进程被创建。

Podman不跟CRI交互，也不直接跟CRI-O交互。然而，Podman像Buildah一样与CRI-O共享相同的后端数据存储。

Podman可以做一些Crictl不能做的事：

• 已经停止的容器的重启 CRI 没有包含重启stopped容器的功能，因此CRI-O, Crictl 也没有
• 容器镜像的管理和创建 (push, commit, configure, build)

如果您已经读过上一篇文章中的课程（免费），就会发现Podman的CLI 跟Docker 基本一样，所以用过Docker的小伙伴儿去使用Podman毫无压力。

因为Podman的运行不依赖守护进程，但是Crictl需要CRI-O守护进程（类似Docker需要Docker daemon），所以如果CRI-O挂了，Podman依然可以检查image, container 的状态。

⚠️注意，Podman还没有和CRI-O共享用于识别container 的库，这也意味着，Podman并不能列出通过CRI-O创建的容器。同理，CRI-O/Crictl 也不能列出Podman创建的容器。如下：

sh-4.4# crictl ps 
CONTAINER           IMAGE                                                                                                                    CREATED              STATE               NAME                                          ATTEMPT             POD ID
6761d39266652       xxx.io/rhel7/xxx@sha256:3ff8ccee8f2d705ce8e3275f28646618573039012ed7162fd6553da330196f99           About a minute ago   Running             container-00                                  0                   5d0dfc1e8565b
...
...
sh-4.4# podman ps
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES

但是，Podman使用 containers/storage 来管理容器主机磁盘上的Image. 这跟CRI-O使用的库一样，因此CRI-O可以使用Podman拉取的容器镜像。

sh-4.4# crictl images |wc -l
42
sh-4.4# podman images |wc -l
42