k8s和网络插件的调用关系

在Kubernetes v1.20.8中抓取底层事件可以看到是kubelet调用execve事件调用/opt/cni/bin下面的网络插件。

实现了 CRI 接口的容器运行时通常称为 CRI shim，这是一个 gRPC Server，监听在本地的 unix socket 上；而 kubelet 作为 gRPC 的客户端来调用 CRI 接口，来进行 Pod 和容器、镜像的生命周期管理。另外，容器运行时需要自己负责管理容器的网络，推荐使用 CNI。

kubelet 调用下层容器运行时的执行过程，并不会直接调用Docker 的 API，而是通过一组叫作 CRI（Container Runtime Interface，容器运行时接口）的 gRPC 接口来间接执行的，意味着需要使用新的连接方式与 docker 通信，为了兼容以前的版本，k8s 提供了针对 docker 的 CRI 实现，也就是kubelet包下的dockershim包，dockershim是一个 grpc 服务，监听一个端口供 kubelet 连接，dockershim收到 kubelet 的请求后，将其转化为 REST API 请求，再发送给docker daemon。Kubernetes 项目之所以要在 kubelet 中引入这样一层单独的抽象，当然是为了对 Kubernetes 屏蔽下层容器运行时的差异。

2015 年，由 Docker 公司牵头，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司将 Libcontainer 捐出，并改名为 RunC 项目，交由一个完全中立的基金会管理，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范。

这套标准和规范，就是 OCI（ Open Container Initiative ）。OCI 的提出，意在将容器运行时和镜像的实现从 Docker 项目中完全剥离出来。这样做，一方面可以改善 Docker 公司在容器技术上一家独大的现状，另一方面也为其他玩家不依赖于 Docker 项目构建各自的平台层能力提供了可能。
OCI 主要包含两个规范：

运行时规范（runtime-spec）：容器运行时，如何运行指定的文件系统上的包
容器镜像规范（image-spec）：如何创建一个 OCI 运行时可运行的文件系统上的包

2016 年，Kubernetes 发布 CRI （Container Runtime Interface，容器运行时接口），这当中一部分原因是由于 Kubernetes 尝试支持另一个由 CoreOS 领导的容器运行时项目 rkt ，但是需要写很多兼容的代码之类的，为了避免后续兼容其他运行时带来的维护工作，所以发布了统一的 CRI 接口，凡是支持 CRI 的运行时，皆可直接作为 Kubernetes 的底层运行时。
CRI中定义了容器和镜像的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，因此需要定义两个服务：