1、什么是CNI？首先介绍一下什么是CNI。它的全称是ContainerNetworkInterface，即容器网络的API接口。它是K8s中调用网络实现的标准接口。Kubelet使用这个标准的API来调用不同的网络插件来实现不同的网络配置方式。实现这个接口的就是CNI插件，它实现了一系列的CNIAPI接口。常见的CNI插件包括Calico、flannel、Terway、WeaveNet和Contiv。2.如何在Kubernetes中使用CNIK8s使用CNI配置文件来确定使用哪个CNI。基本使用方法如下：首先在各个节点上配置CNI配置文件（/etc/cni/net.d/xxnet.conf），其中xxnet.conf为某个网络配置文件名；安装CNI配置文件对应的二进制插件；在该节点创建Pod后，Kubelet会根据CNI配置文件执行前两步安装的CNI插件；执行完上一步后，Pod网络的配置就完成了。具体流程如下图所示：3.哪种CNI插件适合自己一般来说，CNI插件可以分为三种：OverlayroutingUnderlayOverlay模式的典型特征是容器是独立于宿主机的IP段，跨宿主机使用该IP段进行网络通信时，在宿主机之间创建隧道，将整个容器网段的报文封装到底层物理网络中宿主机之间的报文中。这种方式的优点是不依赖于底层网络；在路由模式下，宿主机和容器也属于不同的网段。它和Overlay模式的主要区别是它的跨主机通信是通过路由打通的，不同主机之间不需要通信。做一个隧道数据包。但是，路由需要部分依赖于底层网络。例如要求底层网络具备二层可达性；Underlay模式下，容器和宿主机位于网络的同一层，具有相同的地位。容器之间的网络连接主要依赖于底层网络。因此，这种模式强烈依赖于底层能力。1.环境限制不同环境支持的底层能力是不一样的。虚拟化环境（如OpenStack）中有很多网络限制。例如，不允许通过第2层协议在机器之间进行直接访问。只有有IP地址的三层才能转发，只能使用某台机器。某些IP等，在这种限制比较强的底层网络，只能选择Overlay插件，常见的有Flannel-vxlan、Calico-ipip、Weave等；物理机环境下的底层网络限制较少。比如我们直接在同一个交换机下做一个二层通信。对于这种集群环境，我们可以选择Underlay或者路由模式的插件。Underlay是指我们可以直接在一台物理机上插入多个网卡或者对某些网卡做硬件虚拟化；路由方式是依靠Linux的路由协议来打通。这样就避免了像vxlan这样的packet方式带来的性能下降。在这个环境下，我们可选的插件包括clico-bgp、flannel-hostgw、sriov等；公有云环境也是虚拟化的，所以会有更多的底层限制。但是每个公有云都会考虑适配容器来提升容器性能，所以每个公有云可能会提供一些API来配置一些额外的网卡或者路由能力。在公有云上，我们应该尽量选择公有云厂商提供的CNI插件，以达到最好的兼容性和性能。比如阿里云提供了高性能的Terway插件。考虑到环境的限制后，我们应该有一些选择，知道哪些可以使用，哪些不可以。在此基础上，再考虑功能需求。2.功能需求首先是安全需求；K8s支持NetworkPolicy，也就是说我们可以使用NetworkPolicy的一些规则来支持诸如“Pod是否可以访问”等策略。但并非每个CNI插件都支持NetworkPolicy声明。如果你有这个需求，可以选择一些支持NetworkPolicy的插件，比如Calico、Weave等。二是集群外的资源是否需要和集群内的资源打通；每个人的应用程序最初都在虚拟机或物理机上。容器化后，应用无法一次性迁移，所以传统的虚拟机或者物理机可以通过容器的IP地址进行通信。为了实现这种互通，两者之间或者直接在同一层之间需要有某种方式打通。这时候可以选择Underlay网络，比如sriov，也就是说Pod和之前的虚拟机或者物理机在同一层。我们也可以使用calico-bgp。虽然此时它们不在同一个网段，但是我们可以利用它与原来的路由器发布一些BGP路由，这样虚拟机和容器也可以连接起来。最后要考虑的是K8s的服务发现和负载均衡能力。K8s的服务发现和负载均衡就是我们前面介绍的K8s的Service，但是并不是所有的CNI插件都能实现这两个能力。比如很多Underlay模式的插件，Pod中的网卡直接被Underlay硬件使用，或者通过硬件虚拟化插入到容器中。这个时候它的流量无法去到宿主机所在的命名空间，所以无法应用。由主机上的kube-proxy配置的规则。在这种情况下，插件无法访问K8s服务发现。因此，如果需要服务发现和负载均衡，在选择Underlay插件时需要注意是否支持这两个能力。过滤功能需求后，可以选择的插件就很少了。经过环境约束和功能需求筛选后，如果还剩下3、4个插件，可以再考虑性能需求。3.性能需求我们可以从Pod创建速度和Pod网络性能两个方面来衡量不同插件的性能。PodCreationSpeed当我们创建一组Pod时，比如业务高峰来临时，我们需要紧急扩容。这时候比如我们扩容1000个Pod，就需要CNI插件创建配置1000个网络资源。本例中Overlay和routing模式的创建速度非常快，因为是在机器中虚拟化的，所以这些操作只需要调用内核接口就可以完成。但是对于Underlay模式，由于需要创建一些底层网络资源，所以整个Pod的创建速度会相对慢一些。因此，对于经常需要紧急扩容或者创建大量Pod的场景，我们应该尽量选择Overlay或者路由方式的网络插件。一个Pod的网络性能主要体现在两个Pod之间的网络转发、网络带宽、PPS时延等性能指标上。Overlay模式性能较差，因为它在节点上有一层虚拟化，需要打包，打包会带来一些headerloss，CPU消耗等，如果你对网络性能有更高的要求，比如机器学习、大数据等场景就不适合使用Overlay模式。这种情况下，我们通常选择Underlay或者路由方式的CNI插件。
