上周接到了一项紧急预研任务：kubernetes各项属性采集。目前我手里已经存在二进制部署的一套kubernetes（v1.23版本+CRI：dockershim）集群；为了适配的广泛性，决定使用kuberadm工具部署最新（v1.30版本）版本的kubernetes，并适配各种CRI。

关于CRI

容器运行时接口（CRI）是一个用来扩展容器运行时的接口，它基于 gPRC，用户不需要关心内部通信逻辑，而只需要实现定义的接口就可以，包括 RuntimeService 和 ImageService。

通过官方资料（https://kubernetes.io/docs/setup/production-environment/container-runtimes/），目前kubernetes支持的CRI：containerd、CRI-O、cri-dockerd、MCR。此外，Podman、rkt、Kata等也是CRI运行时。我们对其中几个非主流，较为陌生的简要说明一下：

1、MCR（Mirantis Container Runtime）就是Docker EE，同Docker CE，且是收费的；

2、Podman不能直接作为CRI被kubernetes调用，需要配合CRI-O；

3、CoreOS家的rkt，在 2020 年宣布 rkt 停止维护。随着社区和资源的转移，rkt 的使用逐渐减少；

4、Kata Containers属于轻量级的虚拟化容器运行时； 提供了一种将容器的轻量级和快速启动与虚拟机的安全性和隔离性结合的解决方案。与传统的容器引擎相比，它最大的特点：提供的是虚拟机，使用了不同的虚拟化技术：

》传统容器使用操作系统级虚拟化技术：基于Linux kernel的 namespaces 和 cgroups；

》Kata Containers使用的是Hypervisor虚拟化技术。

剩下的containerd、CRI-O、cri-dockerd的异同，一图以蔽之（只需要将Dockershim替换成cri-dockerd）：

Kubelet架构

Kubelet的架构图一：红框标注的部分已经在新版本中去除了。

Kubelet架构图二：红框标注的部分已经在新版本中去除了。

通过上面两张图，可以直观了解到kubernetes的kubelet组件如何同容器运行时进行交互的。

具体到kubelet的启动参数，上体现为：--container-runtime-endpoint=unix:///run/cri-dockerd.sock。

早期版本，无需配置，默认调用/var/run/dockershim.sock，这是kubelet里硬编码进去的；

中期版本，需要配置--container-runtime=remote才能设置dockershim意外的CRI，如：

 --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock

现在版本，--container-runtime参数废弃了（也就是说只有remote一种情况，您也别配置了），通过--container-runtime-endpoint设置。

多说一嘴哈，除了CRI如此，CNI也如此，例如：--network-plugin=cni --cni-conf-dir=/etc/cni/net.d这些配置，目前都已经废弃了。相同的配置，需要配置到CRI，例如：如果CRI使用的是Containerd，那么配置/etc/containerd/config.toml （后面会介绍到）。

最后，像一些概念性的东西，例如：OCI、CNI、CRI、CSI、CNCF，有很多。用到或者需要了解的时候，自行查询吧。

下一篇：《kubernetes集群部署：环境准备及master节点部署（二）》