kubelet配置cni插件_Kubelet 对CNI的实现

不管是 docker 还是 kubernetes，在网络方面目前都没有一个完美的、终极的、普适性的解决方案，不同的用户和企业因为各种原因会使用不同的网络方案。目前存在网络方案 flannel、calico、openvswitch、weave、ipvlan等，而且以后一定会有其他的网络方案，这些方案接口和使用方法都不相同，而不同的容器平台都需要网络功能，它们之间的适配如果没有统一的标准，会有很大的工作量和重复劳动。

CNI 就是这样一个标准，它旨在为容器平台提供网络的标准化。不同的容器平台(比如目前的 kubernetes、mesos 和 rkt)能够通过相同的接口调用不同的网络组件。

CNI(Conteinre Network Interface) 是 google 和 CoreOS 主导制定的容器网络标准，它 本身并不是实现或者代码，可以理解成一个协议。这个标准是在 rkt 网络提议 的基础上发展起来的，综合考虑了灵活性、扩展性、ip 分配、多网卡等因素。

这个协议连接了两个组件：容器管理系统和网络插件。它们之间通过 JSON 格式的文件进行通信，实现容器的网络功能。具体的事情都是插件来实现的，包括：创建容器网络空间(network namespace)、把网络接口(interface)放到对应的网络空间、给网络接口分配 IP 等等。

关于网络，docker 也提出了 CNM 标准，它要解决的问题和 CNI 是重合的，也就是说目前两者是竞争关系。目前 CNM 只能使用在 docker 中，而 CNI 可以使用在任何容器运行时。CNM 主要用来实现 docker 自身的网络问题，也就是 docker network 子命令提供的功能。

官方网络插件

所有的标准和协议都要有具体的实现，才能够被大家使用。CNI 也不例外，目前官方在 github 上维护了同名的 CNI 代码库，里面已经有很多可以直接拿来使用的 CNI 插件。

官方提供的插件目前分成三类：main、meta 和 ipam。main 是主要的实现了某种特定网络功能的插件；meta 本身并不会提供具体的网络功能，它会调用其他插件，或者单纯是为了测试；ipam 是分配 IP 地址的插件。

ipam 并不提供某种网络功能，只是为了灵活性把它单独抽象出来，这样不同的网络插件可以根据需求选择 ipam，或者实现自己的 ipam。

这些插件的功能说明如下：main