我到底应该使用哪个 CRI 替换 kubernetes 集群的 Docker?
前一段时间 kubernetes 对 docker 的弃用引起了不小的讨论，但其实 docker 并不是 kubernetes 中的 CRI 唯一实现。那么除了 docker 之外，我们还可以使用其他什么 CRI 呢？
下面是我已经测试的几个 CRI，并进行一些基准测试来对他们进行了简单的对比，希望对你有所帮助：
dockershim containerd crio
对于 cri-o，已经测试了2个后端：runc 和 crun，以测试对 cgroupsv2 的影响。
测试环境
我这里的测试环境是一个 1.19.4 版本的 kubernetes 集群，使用 ansible 进行创建（https://gitlab.com/incubateur-pe）。集群运行在 kvm 上，配置如下：
master：Centos/7, 2vcpus/2G内存。 crio-crun 节点：Fedora-32, 2vcpus/4G内存。 其他节点：Centos/7, 2vcpus/4G内存.
底层是 i7-9700K ，64G的内存和一个 mp510 nvme 硬盘。
创建集群
这里我直接使用 molecule 创建一个集群，并配置了它在每个 worker 节点上使用不同的 cri，对应的 ansible 源码位于：https://gitlab.com/incubateur-pe/kubernetes-bare-metal/-/tree/dev/molecule/criBench
使用上面的脚本，执行 molecule converge 命令后，大概10分钟左右，我们就可以得到一个如下所示的 kubernetes 集群。
接下来我们就可以进行一些简单的基准测试了。
测试
1. bucketbench 测试
Bucketbench (https://github.com/estesp/bucketbench) 是一个可以对容器引擎执行一系列操作的测试工具，它非常适合于了解之前每个节点的性能。
这里我们的测试参数很简单：
3个线程 15次循环 run/stop/delete 操作
对应的结果如下所示（ms 为单位）：
我们可以看到在性能上还是有相当大的差异的。但是需要注意的是我们这里为什么测试了5个实例呢？上面不是只有4个 worker 节点吗？
这里其实是因为这里我们使用的 docker 客户端并不是 kubernetes 使用的，事实上 docker 实现了 CRI，并提供了一个 socket，这个 socket 和其他 cri socket 一样可以调用。所以这里的区别是：
docker-shim：是通过 cri 的 socket 来做测试 docker-cli：是通过 docker 客户端来做测试
但是实际上 docker 并没有想象中那么差，在这个测试中我们可以看到他比 cri-o 要快点，当然这个测试中很明显 dockerd 是表现最好的。
2. kubernetes 测试
上面的测试并不能完整说明这几个 cri 之间的差距，当它们被 kubernetes 使用的时候，它们表现又如何呢？是否不止 run/stop/delete 这些操作？性能上的差异在真正的集群上又有什么意义吗?
下面我们就来深入了解下，这次我们使用集群中的 Prometheus、Grafana 来可视化监控指标，对应的自定义 dashboard 数据可以在 https://gitlab.com/ulrich.giraud/bench-cri/-/blob/master/dashboard/dashboard_bench.json 这里获取。由于只是测试容器运行时，不是工作负载，所以这里我们只是简单的在集群中部署的一个 busybox 镜像并一直 sleep 的 DaemonSet 应用。
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: benchds-replaceme
namespace: benchds
labels:
k8s-app: benchds
spec:
selector:
matchLabels:
name: benchds
template:
metadata:
labels:
name: benchds
spec:
containers:
- name: benchds
image: busybox:latest
command:
- sleep
- infinity
resources:
limits:
memory: 20Mi
requests:
cpu: 10m
memory: 20Mi
该 DamonSet 将用唯一的名称进行部署：
100次（两次创建之间有一定延迟） 批量 100次 批量 1000次
对应的 Grafana 展示图表信息如下所示：
缓慢创建数百个 DaemonSets
快速创建数百个 DaemonSets
快速创建数千个 DaemonSets
现在我们来分析下上面的测试结果。
Cri-o/runc：令人惊讶的是，在所有 create/delete 中是最慢的，但在其他方面处于中等水平。 Cri-o/crun：在 create/delete 方面不是很好，但是在其他方面表现是最好的。 Containerd：表现非常好，几乎在所有情况下都可以快速响应。 Docker：在 create/delete 方面比 cri-o 快，但在 status/list 请求方面是最慢的。
status/list 请求是 cri 上最频繁的请求，所以这也是性能最重要的地方，cri-o 在这里似乎是更好的选择，其次就是 containerd。
containerd 在所有指标上的表现都比较好，应该是最均衡的一个选择了。另外一方面，docker 并没有得到很好的测试结果，但是无论负载情况如何，它的表现基本上都是一致的。
总结
从纯性能角度来说，确实有比 docker 更好的替代品，我们的集群也不会替换 docker 产生什么影响。从另外一个角度来看，kubernetes 这次废弃 docker 的事情也算是一件好事，让更多的人意识到 docker 并不是唯一可用的 CRI，甚至不是唯一的构建镜像工具。
在我看来，docker 仍然是让整个容器化向前发展的一个伟大工具。但是好像我还没有回答我最初的问题，那就是：我应该为我的k8s集群使用什么CRI？
从我个人角度考虑的话，我个人的选择是：containerd，他速度快，配置方便，相当可靠和安全，不过 cri-o 已经支持 cgroupsv2 了，所以如果我使用 fedora 或者 centos/8 的话我会优先选择 cri-o。
“原文链接：https://ulrich-giraud.medium.com/which-cri-should-i-use-to-replace-docker-for-my-kubernetes-cluster-14a45c080004
”
进阶训练营第二期
本次训练营采用线上直播的形式，基于1.19.x版本，根据第1期课程的打磨，我们总结出了 Docker 基础 + Kubernetes 基础 + 原理 + 基本使用 + 进阶技能 + 完整项目实践 的课程体系。加强系统知识吸收、夯实基础的同时，并在实际操作过程中去了解排查问题的方式方法，更为重要的是我们的老师非常负责任，随时帮你答疑解惑，我们认为不只是课堂上讲授知识，更重要的是售后支持，完全不用担心学习不到知识。
点击屏末 | 阅读原文 | 即刻学习