上图即一个典型overlay网络的拓扑图。和bridge网路类似，Pod同样接在Linux网桥上，目的地址是本机Pod的网络包同样发给Linux网桥cni0。不一样的是，目的Pod在其他节点上的路由表规则，例如：
10.1.0.0/16 dev tun0
这次是直接发给本机的TAP设备tun0，而tun0就是overlay隧道网络的入口。我们注意到，集群内所有机器都只需要这么一条路由表，而不需要像bridge网络那样，写N-1条路由表项。那如何才能将网络包正确地传递到目标主机的隧道口另一端呢？一般情况下，例如flannel的实现，会借助一个分布式的数据库，用于记录目的容器IP与所在主机的IP的映射关系，而且每个节点上都会运行一个agent，例如flanneld，会监听在tun0上，进行封包和解包操作。例如：Node1上的容器发包给Node2上的容器，flanneld会在tun0处将一个目的地址是192.168.1.101:8472的UDP包头（校验和置成0）封装到这个包的外层，然后接着主机网络的东风顺利到达Node2。监听在Node2的tun0上的flanneld捕获这个特殊的UDP包（检验和为0），知道这是一个overlay的封包，于是解开UDP包头，将它发给本机的Linux网桥cni0，进而广播给目的容器。
接下来我们来了解下什么是CNI？CNI是Container Network Interface的缩写，是容器网络的标准化，试图通过JSON来描述一个容器网络配置。
图4
从上图可以看出，CNI是K8S与底层网络插件之间的一个抽象层，为K8S屏蔽了底层网络实现的复杂度，同时也解耦了K8S的具体网络插件实现。
CNI主要有两类接口，分别是在创建容器时调用的配置网络接口：
图5
和删除容器时调用的清理网络接口：
图6
不论是配置网络接口还是删除网络接口，都有两个入参，分别是网络配置和runtime配置。网络配置很好理解，rumtime配置则主要是容器运行时传入的网络namespace信息。符合CNI标准的默认/第三方网络插件有：
图7
其中CNI-Genie是一个开源的多网络的容器解决方案，感兴趣的读者可以自行去Github上搜索。
