k8s插件--CRI,CNI,CSI

k8s插件–CRI,CNI,CSI

CNI插件----网络插件

K8S提供了一个插件规范，称为容器网络接口(CNI)。只要满足K8S的基本需求，第三方厂商可以随意使用自己的网络栈，通过使用overlay网络来支持多子网或者一些个性化使用场景，所以出现很多优秀的CNI插件被添加到Kubernetes集群中。

k8s将网络docker0网桥更换成了cni插件。

主要的原因是：docker0网桥无法完成不同节点间的通信。并且，K8S在Pod范围内的所有容器共享同一个网络命名空间——包括它们的IP地址。这意味着同一个Pod内部的容器可以通过localhost直接通信，这一点通过docker0网桥是无法直接简单实现的。

1. Calico是许多集群管理员使用的一个流行插件，它使用标准的三层网络方案提供可伸缩的网络功能。它不仅支持AWS等公有云环境中的网络划分，而且能够跟私有云网络无缝集成。
2. Flannel是另一个利用三层网络结构的CNI插件。它直接使用K8S API并直接设置默认的VXLAN体系结构。与其他工具一起使用时，Flannel为用户提供了可扩展的支持，比如我们可以选择使用hostgw。

CRI插件----容器进行时插件

初期，K8S并没有实现CRI功能，docker运行时代码跟kubelet代码耦合在一起，再加上后期其它容器运行时的加入给kubelet的维护人员带来了巨大负担。解决方式也很简单，把kubelet对容器的调用之间再抽象出一层接口即可，这就是CRI。CRI接口设计的一个重要原则是只关注接口本身，而不关心具体实现，kubelet就只需要跟这个接口打交道。而作为具体的容器项目，比如Docker、rkt、containerd、kata container它们就只需要自己提供一个该接口的实现，然后对kubelet暴露出gRPC服务即可。简单来说，CRI主要作用就是实现了kubelet和容器运行时之间的解耦。

CRI插件提供了三个主要功能：第一个是前面提到的对更换容器运行时的支持。这意味着您可以在任何阶段和任何原因更改Kubernetes环境使用的运行时。如果您发现一个运行时比另一个运行时更有效率，通过CRI，更换就变得容易，很多组织就把Docker运行时换成了相对更高效的containerd。

CRI主要作用就是实现了kubelet和容器运行时(如，docker，ccontainerd)之间的解耦。

CSI----存储接口

CSI允许第三方存储提供商提供持久的和动态的存储块，而K8S集群本身并不需要去实现它们。CSI插件和核心K8S卷插件之间的主要区别是CSI插件不需要编译和附带核心Kubernetes二进制文件。

CSI插件的其他特性也同样有趣。原始块卷允许您为块卷创建CSI驱动程序，并允许将这些块分配给K8S运行时。支持在任意时间点创建和恢复存储块快照。像MapR Data Fabric这样的插件甚至支持livenessprobe这样的命令，它允许容器探测存储驱动程序。