前言
2台物理设备想要进行网络通信：
沿途需要经过TCP/IP的应用层、传输层、网络层、数据链路层、网络层，层层封包和解包， 以确保沿途不同的网络设备知道下一跳，应该把数据传递到哪里？最终达到目标主机；
2个运行在不同物理节点的虚拟机/容器想要进行网络通信，应该如何实现呢？
K8s网络插件的本质是在Underlay网络之上构建1个逻辑上的大2层网络，确保Pod可以漂移到任何Node节点，而不用配置3层路由条目；
关于容器和容器之间如何通信的原理，需要分3种情况进行剖析：
- 在同1个Pod中的容器，如何通信？ 本地回环地址
- 在同1宿主机内的Pod，如何通信？ 网桥和veth-pair
- 在不同宿主机的Pod，如何跨节点进行通信？
在不通宿主机的Pod间通信主要使用2种方式
- 报文封装：在3层网络报文之上再封装1层虚拟报文，使用隧道进行报文传输，例如VXLAN、GRE等
- 动态路由技术：动态更新路由表信息，动态控制下一跳IP地址实现，例如BGP
在K8s集群中使用SDN技术实现以上2种方式各有优劣：
- 报文封装：对原报文进行2次封装，2次封装和解封装效率低下、报文体积增大；
- 动态路由：CNI插件无权配置、修改物理路由器设备上的路由条目，导致容器间通信(Overlay网络)受限于同1网段的Underlay网络；
一、虚拟网络设备
虚拟化技术没出现之前，计算机网络系统都只包含物理的网卡设备，通过网卡适配器、线缆介质，连接外部网络，构成庞大的Internet。
虚拟化技术的出现之后，网络也随之被虚拟化，相较于单一的物理网络，虚拟网络变得非常复杂；
SDN需要实现诸如交换、路由、隧道、隔离、聚合等多种网络功能，而实现这些功能的基本元素就是虚拟的网络设备；
比如tap/tun、veth-pair、虚拟网桥/交换等网络设备；
TUN和TAP设备
TUN（网络层隧道）TAP（以太网隧道）设备是Linux系统中，2种不同虚拟网络设备；
TUN代表网络层隧道：工作在网络层，应用于VPN；
TAP代表以太网隧道：工作在数据链路层，应用于模拟虚拟交换机的以太网接口；
TUN设备
下图所示可以看出物理网卡和TUN设备模拟的虚拟网卡的区别；
- 物理网卡设备1端连接着网络协议栈，另1端连接着外部物理网络；
- TUN设备1端连接着网络协议栈，另1端连接着用户空间的ApplicationB；
上图中我们配置了1个物理网卡IP为18.12.0.92，tun0为1个 TUN/TAP设备IP配置为10.0.0.12。
数据包的流向为：
- ApplicationA 通过SocketA发送了1个数据包，假设这个数据包的目的IP地址是10.0.0.12;
- SocketA 将这个数据包丢给TCP/IP网络协议栈；
- TCP/IP网络栈协议栈根据本地路由规则和数据包的目的 IP，将数据包转发到tun0设备；
- tun0设备收到数据包之后，将数据包转发给了用户空间的ApplicationB
- ApplicationB收到数据包之后将原来的数据包嵌入在新的数据包(IPIP 包)中，最后通过SocketB将数据包转发出去；
Note: 新数据包的源地址变成了 tun0 的地址，而目的 IP 地址则变成了另外一个地址18.13.0.91.
- SocketB将数据包发给网络协议栈
- 网络协议栈根据本地路由规则和数据包的目的 IP，决定将这个数据包要通过设备eth0发送出去，于是将数据包转发给设备eth0
- eth0设备通过物理网络将数据包发送出去
我们看到发送给10.0.0.22的网络数据包通过在用户空间的应用程序 B，利用18.12.0.92发到远端网络的18.13.0.91，网络包到达18.13.0.91后，读取里面的原始数据包，再转发给本地的10.0.0.22。
这就是open-VPN/Flannel-udp/Calico-IPIP的基本实现原理。
TAP设备
TAP设备本质上是1个虚拟化的以太网接口，它允许用户程序与虚拟网络通信，将以太网帧数据包从内核传递给用户空间应用程序；
TAP设备是1个二层链路层设备，通常用作实现虚拟网卡。
以qemu-kvm为例，它利用tap设备和Bridge配合使用拥有极大的灵活性，可以实现各种各样的网络拓扑。
在qume-kvm开启 tap 模式之后，在启动的时候会向内核注册了1个tap类型虚拟网卡tapx，x 代表依次递增的数字；
这个虚拟网卡tapx是绑定在Bridge上面的，是它上面的1个接口，最终数据会通过 Bridge 来进行转发；
qume-kvm会通过其网卡eth0 向外发送数据，从 Host 角度看就是用户层程序 qume-kvm 进程将字符设备写入数据；
然后 tapx 设备会收到数据后由 Bridge 决定数据包如何转发。
如果 qume-kvm 要和外界通信，那么数据包会被发送到物理网卡，最终实现与外部通信。
从上面的图也可以看出 qume-kvm 发出的数据包通过 tap 设备先到达 Bridge ，然后到物理网络中，数据包不需要经过主机的的协议栈，这样效率也比较高。
桥接设备（Bridge Device）
网桥具备基本的交换功能，可以根据 MAC 地址学习、构建转发表，从而将数据帧发送到正确的端口。
这使得网桥更适合用于虚拟交换机的角色，在多台虚拟机或容器之间进行流量转发。
用于连接2个或多个网络接口，使其工作在同一个网络段内。桥接设备充当一个交换机，将连接到不同物理接口上的数据包进行转发。
veth-pair
以上基于Linux内核提供的强大功能
- KVM/LXC模拟出了虚拟主机/容器
- TAP设备模拟出容器/虚拟机的网卡接口
- Linux Bridge模拟出了虚拟交换机/网桥
那么如何将容器/虚拟主机的网卡接口通过1跟网线连接到交换机接口呢？
veth全程虚拟以太网（Virtual Ethernet Device），veth-pair是成对出现的，veth pair（Virtual Ethernet Pair）是1种 Linux内核技术;
可用于将2个虚拟网络接口连接在一起，从而可以在2个不同的命名空间之间进行通信;
veth-pair包括2个虚拟网络接口，这两个网络接口是成对出现的；
1个在一个命名空间中，另一个在另一个命名空间中。
其中1个接口的主机和路由信息将用于在这个命名空间和其它网络之间进行通信，另一个接口则被限制在本地网络命名空间中。
它们使用虚拟以太网技术模拟物理以太网适配器，并提供虚拟机或容器与物理网络之间的通信。
例如，eth0、eth1等都是虚拟以太网设备的命名。
二、虚拟大二层网络构建
以上通过Linux内核创建出了容器/虚拟主机，也虚拟出了接入网络所需的网络设备，仅实现了同1个物理节点内不同容器/Pod/虚拟机的通信；
如果想要实现不同物理节点上的Pod/虚拟主机间的通信，就需要基于节点的物理网络实现1个逻辑上的大二层网络，实现以下功能；
- 保证Pod在不同节点漂移
- 保证Pod可以跨节点通信
- 保证集群网络的灵活性
概念
从Pod的角度出发，突破Node节点的物理网络是2/3层网络的限制；
在1个K8s集群中所有Node节点上的所有Pod都处于1个2层网络，1个Pod和另外1个Pod可以直接通信；
Pod所在的大二层网络，需要继续隔离，保证各个租户使用的资源不冲突；
K8s采用名称空间(Namespac)的机制实现租户隔离，而不是继续划分vlan；
依赖物理的二层来构建虚拟大二层网络（vlan）
虽然K8s没有采用vlan模式，但是Openstack云平台会使用vlan对大二层网络继续划分vlan，把不同的租户的VM隔离在不同局域网；
vlan模式
虽然K8s没有采用vlan模式，但是Openstack云平台会使用vlan对大二层网络继续划分vlan，把不同的租户的VM隔离在不同局域网；
vlan模式的缺陷
vlan模式通过vlan id来标识1个vlan而vlan id只能分配4096个，限制了大二层网络的规模；
物理网络必须是二层的，限制底层网络的规模，无法异地构建；
vlan模式的缺陷
- vlan模式通过vlan id来标识1个vlan而vlan id只能分配4096个，限制了大二层网络的规模；
- 物理网络必须是二层的，限制底层网络的规模，无法异地构建；
依赖物理的二或三层来构建虚拟的大二层网络
物理的三层是指：物理网络是三层网络，Node物理节点可基于IP+路由的方式进行通信；
虚拟的二层是指：neutron实现的虚拟网络仍然是二层的，仍然需要基于以太网协议的广播方式进行通信，但毫无疑问的是该虚拟网络依赖物理的三层网络，需要将私网的包封装起来，打上隧道的IP地址传输；
gre和vxlan解决了vlan的缺陷，可以基于三层网络来构建虚拟的大二层网络；
协议封装：
- 外层封装着正常包：让沿途网络设备正常传递包；
- 内层藏着猫腻：需要专门的虚拟网络设备才能解析；
GRE协议（不常用）
GRE可以在一定程度上用于构建虚拟大二层网络，但有一定的局限性，现在基本不使用GRE构建虚拟的大二层网络；
GRE本身是3层隧道协议，主要用于封装IP数据包。
不过，通过一些特殊的配置和技术手段，如GRE over IPsec等，可以在不同站点之间建立连接，模拟出一个类似大二层的网络环境。
1.在云计算环境下连接不同的数据中心或站点时可以使用GRE。
例如，当企业有多个数据中心，并且这些数据中心内部采用了虚拟网络，GRE可以用来构建虚拟专用网络（VPN），通过在公共网络上建立GRE隧道，实现不同数据中心的虚拟网络之间的安全通信，传输虚拟机迁移相关的数据、存储数据同步等信息。
2.GRE可以为云计算中的租户网络提供一种简单的网络扩展方式
如果租户需要将自己的虚拟网络延伸到其他物理位置或者和外部的合作伙伴网络相连，GRE隧道可以用于封装租户网络的流量，使得租户网络能够跨越物理网络边界，同时保证网络连接的相对独立性和安全性。
封包解包设备：br-tun设备
GRE报文格式：
- Delivery头:IP协议，GRE是通过IP协议传输的；
- GRE头:GRE id等同于vlan id，用于区分不同租户的局域网
- Playload:内层包，即真实要发送的包
GRE缺陷
- 每个节点都需要维护与其他其他物理节点的隧道关系；
总结
与专门的大二层虚拟网络技术（如VXLAN）相比，GRE用于构建大二层网络时，在多租户环境下的MAC地址管理、广播风暴抑制等方面相对复杂，并且效率可能较低，基本不使用；
vxlan协议（较常用）
VXLAN的英文全称是Virtual Extensible Local Area Network即虚拟可扩展局域网：
VXLAN是1种网络虚拟化技术，专门用于构建大规模的数据中心网络。
VXLAN在UDP（用户数据报协议）上封装MAC（媒体访问控制）帧来实现虚拟网络，使得虚拟机或容器等端点可以在逻辑上处于同一网段，而不受物理位置和底层网络限制，能有效解决数据中心的租户隔离、多租户网络扩展等问题。
VXLAN内置了24位的VNID（VXLAN 网络标识符），支持多租户隔离。
封包解包设备：
VETP设备，k8s会在每个Node节点中创建flannel1.1
vxlan报文格式：
- Delivery头:UDP协议，vxlan是通过UDP协议传输的；
- Vxlan头:vni id等同于vlan id，用于区分不同租户的局域网；
- Playload:内层包，即真实要发送的包
k8s中flannel插件对vxlan模式下使用注意点
- vni id固定为1
- 由于pod的mac地址是静态的存储在etcd数据库，由flanneld进程配置维护，所以进行二层通信不需要发arp广播；
优势
相校于GRE协议vxlan协议支持组播，新节点加入组里，发包时组内的机器都会收到广播包，所以不需要维护与其他Node节点的隧道信息
基于UDP协议搬运包是无状态的
三、虚拟大二层网络划分子网（CIDR）
以上我们基于虚拟网络设备+协议封装构建出了1个逻辑上的大二层；
在K8s中如何基于这个大二层网络，继续划分子网，需要考虑以下问题
- 每个Pod都需要有1个独一无二的IP地址，因为大二层网络，IP地址肯定不能冲突；
- 能够标识Pod来源于哪个物理Node节点？哪个子网？
在学习CIDR之前，先回顾下IP地址相关知识；
1.IP地址
1个IP地址由32位组成（对于IPv4），这32位划分为以下2大部分
- 网络号：网络号用于标识IP地址所属的网络
- 主机号：主机号用于标识某1个网络内的第X个主机
2.子网掩码
子网掩码是IP地址辅助解释信息，用来区分1个IP地址中
- 哪些位表示网络号？
- 哪些位表示主机号？
在子网掩码的格式：网络号部分为1，主机号部分为0。
3.CIDR概念
无类别域间路由Classless Inter-Domain Routing，打破传统通过A/B/C类地址划分子网的概念；
CIDR标记法：IP地址/网络前缀的比特位数
145.13.3.10/20
4.CIDR作用
因为
- 网络前缀的比特位数越大，可以划分的子网越多，每1个子网可以分配的IP地址越少；
- 网络前缀的比特位数越小，可以划分的子网越少，每1个子网可以分配的IP地址越多；
所以CIDR有以下作用
- 子网划分：1个大的网络中划分出来N个更小的网络，减少IP地址浪费
- 超网聚合：N个子网聚合成1个超网，减少路由条目
5.CIDR在K8S中的应用
1.初始部署时为为poa的网络指定1个大段，k8s会在该大段的基础上进行子网划分每个节点被分配走1个子网段，在该节点上启动的Pod都属于自己分配到的网段
这么做的好处:
(1)每个Node物理节点都有自己的1个网段，具有标识性
(2)在访问某1个pod的IP地址时，可以直接确定该pod属于哪合物理机，发包效率更高，连组播都不需要了；
2.部署时会指定pod网络的大网段，例如podsubnet:10.244.0.0/16
k8s会在该网段的基础上进行子网划分，每个子网里ip地址要确保够用，每个节点领走一个网段，每个节点上最多能启110个pod，所默认用的子网掩码是24位
这会限制网络规模24-16=8
2**8=256 个子网-----》256台机器
3.虽然不同物理节点上的pod拥有各自的网段，看起来像是在不同的网里;
但是所有的市od都是可以直接二层通信的，ip地址是虚拟的，它只是一种标识其独一无二性的一直标识方式（管它在不在同1个网段，只要包发过去就行）；
四、K8s的CNI接口
CNI全程Container Network Interface，是实现容器网络的API接口规范；
CNI插件：Calico、Flannel实现了CNI API接口的网络插件；
K8s、DockerSwarm、Marathon等容器管理平台通过CNI提供的标准API来调用不同的网络插件，实现对容器网络的创建和配置方式；
1.CNI插件主要功能
IP地址管理（创建IP地址池）
创建veth网络接口（Pod拥有虚拟网卡了）
将IP地址分配给集群中Pod（Pod网卡连上网线）
连接Pod之间的网络（通过Overlay/Route/Underlay等方式,不使用NAT，实现Pod连上网网络）
提供网络安全策略（Pod网络安全）
2.CNI实现方式
CNI插件通常使用以下3种方式实现；
Flannel的UDP、VXLAN模式，Calico的IP-IP模式属于路由实现方式；
Flannel的host-gw模式、Calico的BGP模式属于Overlay实现方式；
3.K8s如何调用CNI插件
kubelet----》CRI----》CN----》读取CNI插件配置----》执行CNI插件
配置CNI配置文件(/etc/cni/net.d/xxnet.conf)
安装CNI二进制插件(/opt/cni/bin/xxnet)
在这个节点上创建Pod
Kubelet会根据CNI配置文件执行CNI插件
Pod的网络就配置完成了
五、Flannel
Flannel 由CoreOS开发，用于解决Docker集群跨主机通讯的覆盖网络(overlay network)；
它的主要思路是：预先留出1个网段，每个主机使用其中1部分，然后每个容器被分配不同的IP；
所有的容器认为大家在同1个直连的网络，底层通过UDP/VxLAN/Host-GW等进行报文的封装和转发。
跨主机通信的一个解决方案是Flannel，由CoreOS推出，支持3种实现：UDP、VXLAN、host-gw
1.UDP模式（性能差）
使用设备Flannel.0进行封包解包，不是内核原生支持，上下文切换较大，性能非常差
2.VXLAN模式
使用Flannel.1进行封包解包，内核原生支持，性能较强；
Flannel为每个Node节点分配1个独立的子网，所有Pod从本地子网中分配IP地址；
Pod在本节点通过Bridge网桥进行L2通信
默认情况下，跨节点通过vxlan通信，通过fannel.1这个udp隧道进行流量的转发；
除了vxlan,flannel也支持IPIP, Host-GW模式。
3.host-gw模式(无法跨子网)
host-gw模式无需Flannel.1这样的中间设备，使用路由技术，将宿主机当作子网的下一跳地址，性能相对VXLAN模式会更强；
3.1.Calico-BGP和Flannel-host-gw模式对比
Flannel-host-gw模式下，Flannel通过Etcd和宿主机上的Flanneld进程来维护路由信息
Calico-BGO模式下，Calico使用BGP来自动地在整个集群中分发路由信息。
Calico使用BGP协议取代了Flannel使用Flanneld进程维护主机上路由表的功能；
Calico的BGP模式，更加适用于大规模网络环境，其可靠性和可扩展性，远非Flannel-host-gw方案可比。
六、Calico
Calico是1个基于BGP协议的网络互联解决方案；
Calico是1个纯3层的SDN解决方案即CNI插件，使用路由来实现报文寻址和传输。
相比Flannel, ovs等SDN解决方案，Calico 避免了层叠网络带来的性能损耗。
- 将Node节点当做Router
- 将位于Node节点上的Container当做Router的直连设备
- 利用Kernel 来实现高效的路由转发。
Node节点间的路由信息通过BGP协议在整个Calico网络中传播。
Calico具有以下特点：
- 在Calico 中的数据包不需要进行封包和解封。
- 基于三层网络通信，troubleshoot 会更方便。
- 网络安全策略使用 ACL 定义，基于 iptables 实现，比起 overlay 方案中的复杂机制更只管和容易操作。
BGP协议
BGP全称Border Gateway Protocol边界网关协议，是1种运行在TCP上的自治系统的路由协议。
和OSPF/ISIS/RIP一样，BGP也属于动态路由协议，但BGP不生产路由信息，只是路由信息的搬运工；
BGP运行在不同的AS自治系统之间，用于在AS之间动态地交换路由信息；
Node中的Pod频繁更替，生命周期短暂，如果把Node看作1个连接Pod和其他Node的路由器，Node应该如何频繁且动态的更新路由信息呢？
总不能靠运维手动维护路由信息，所以CNI插件开发者想到了利用BGP在Node之间实时、动态交换路由信息；
AS
在互联网内，有大量的自治系统，例如大学/城市/国家称为AS，也可以是K8s中的1个Node；
每个AS内部网络中的路由器运行了不同的内部路由协议(如静态路由、RIP、OSPF、ISIS)
IBGP/EBGP
BGP可用于在AS内外，传输路由信息；
- 同AS内的2个或多个对等实体之间运行的BGP称为IBGP；
- 不同AS间的2个或多个对等实体之间运行的BGP称为EBGP；
BGP Speaker
当2个AS需要交换路由信息时，每个AS都必须指定一个运行BGP的节点，来代表AS与其他的AS交换路由信息。
这个节点可以是一个主机。但通常是路由器来执行BGP。
运行BGP协议的路由器称为1个BGP发言者或BGP路由器
BGP Peer
2个建立BGP会话的路由器称为对等体(Peer)，Peer之间交换BGP路由表；
RR
RR全称Router Reflector，基本思想是选择一部分节点(1个或者多个)作为 Global BGP Peer；
RR和所有的其他节点互联来交换路由信息，其他的节点只需要和 Global BGP Peer 相连就行，不需要之间再两两连接。
最核心的思想是在规避BGP-Full-Meshh的前提下， 集群内所有Node能获取到整个集群的路由信息。
A:路由环路
路由器A---->路由器B---路由器C--->再次回到路由器A，一直循环往复；
B:水平分割限制
BGP协议为了防止路由环路，规定了iBGP路由器不会将从1个iBGP对等体学到的路由再传递给下1个iBGP对等体(只能传1代)。
从任何IBGP邻居学来的路由信息都不再向任何IBGP路由器转发）的限制；
C:Full-Meash
由于BGP水平分割现在，集群内每1个节点都需要和其他节点通告路由，就需要建立(n*(n-1))/2个连接，形成了BGP-Full-Mesh现象。
BGP Speaker越多，将会消耗越多的连接。所以它只能支持小规模集群，一般50-100为上限。
1.BGP模式
Linux内核原生支持BGP协议，因此1个Node可以轻易的配置成边界网关。
边界网关之间通过TCP传输路由信息给其他的边界网关。
而其他边界网关上会对收到的这些数据进行分析，然后将需要的路由信息添加到自己的路由表里。
所以说BGP实现了大规模网络中节点路由信息共享。
在BGP模式下：Colico将运行容器的节点做为虚拟路由器，通过BGP生成动态路由，来实现集群内，运行在不同宿主机上的容器 间的网络访问；
[root@master ~]# route -n #BGP模式 Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 ens33 10.244.104.0 192.168.0.112 255.255.255.192 UG 0 0 0 ens33 10.244.166.128 192.168.0.111 255.255.255.192 UG 0 0 0 ens33 ... [root@master home]# route -n #IPIP模式 Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 ens33 10.244.104.0 192.168.0.112 255.255.255.192 UG 0 0 0 tunl0 10.244.166.128 192.168.0.111 255.255.255.192 UG 0 0 0 tunl0
在BGP模式下，报文直接通过Node节点的网卡转发到目标机Node节点上，不会进行2次IP报文的封装；
Pod跨Node通信流程
假设Node1的read命名空间中Pod-A(172.17.8.2)访问Node2的blue命名空间中的Pod-B(172.17.9.2)
Pod-A的虚拟网卡eth0通过veth-pair连接到默认网关是cni网桥(169.254.1.1)
veth-red-br虚拟网桥(169.254.1.1)相当于1块虚拟网卡，和物理网卡一样共享Linux内核配置的路由信息
veth-red-br虚拟网桥通过路由信息172.17.9.0/24 via 192.168.64.6 dev enpOs1其中enpOs1为Node1的物理网卡，直接将数据包转发到Node2(192.168.64.6)
Node2宿主机通过路由信息172.17.9.2 dev veth-blue-br scope link将数据包转发到veth-blue-br网桥
veth-blue-br网桥使用veth-pair直连着blue命名空间中的Pod-B(172.17.9.2)将数据包之间转发到Pod-B(172.17.9.2)
小结
因此从性能上来看，BGP肯定是占优的，但是也正是没有对报文进行2次封包，BGP模式只能在同1个子网内的Node间使用，Node节点之间跨网段无法使用BGP。
1.1.为什么Calico的BGB模式下Node必需在同1网段？
在Calico的BGP模式下，Node节点扮演路由器的角色；
如果2个路由器之间的直连接口，配置不同网段IP地址，为什么不能直接通信？
要通信必须有路由信息，同时也要有MAC地址信息；
- 路由信息：确定该向哪个路由器的接口转发(端到端的三层问题）
- MAC信息：数据帧如何进行传递。(点到点的二层问题）
1.AR1与AR2配置不同网段IP地址后，进行ping测试，经抓包查看，无任何通信数据;(无路由)
2.AR1或AR2添加静态路由后，经抓包查看，有ARP请求包，但无响应;(有路由，ARP工作机制限制)
3.AR1或AR2手动配置静态Mac地址信息后，可以通信。(有路由、有MAC)
1.2.Full-Mesh模式
Calico维护的BGP网络在默认是（Node-to-Node Mesh）全互联模式；
Calico集群中的节点之间都会相互建立连接，用于路由交换。但是随着集群规模的扩大，mesh模式将形成一个巨大服务网格，连接数成倍增加，就会产生性能问题。
这时就需要使用 Route Reflector（路由器反射）模式解决这个问题。
1.3.RR模式
为解决（Node-to-Node Mesh）全互联模式的问题，使用BGP路由反射，提升K8S集群网络传输效率；
从集群当中找出2个节点，这2个节点是自己选择的，将这2个节点当作路由反射器，让其他的BGP-Client通过这2个节点获取路由表的信息；
这2个路由反射器扮演着代理角色，其Node都是从这获取路由表的学习，那么压力就集中在这2台；
RR做路由的集中下发，BGP-Client就是从这里面获取所有的路由表信息；
每个节点只要和路由反射器(RR)建立连接关系就行；
如果K8s集群中有2个路由反射器，每1个Node只需建立2个连接，即可实现集群内所有Node能获取到整个集群的动态路由信息；
2.IPIP模式
所谓IPIP也就是IP in IP，即在IP报文的基础上又封装了1个新的IP头部；
2.1.Flannel-vxlan和Calico-IPIP模式对比
K8s常用的2大网络插件Flannel的和Calico都使用到了隧道技术，但是Flannel和Calico使用的隧道技术是有区别的；
Flannel使用的是vxlan技术，这种封包技术是MAC in UDP的方式，把数据帧封装到UDP协议跨网络传输；
- 因此Vxlan报文比原始报文多出了50个字节（8个vxlan协议相关字节+8个UDP头部字节+20个IP头部+14个MAC头部字节），这降低了网络线路传输有效数据得的比例，特别是小包。
- 而Calico的IPinIP的封装方法只是在原始报文上添加了新的IP头(新增20个字节)；
因此同样是隧道模式但是Calico的IPIP比Flannel的vxlan的网络性能更好。
3.混合模式
Calico-ipip模式和Calico-bgp模式都有对应的局限性，最终Calico的Corss-subnet模式兼顾了以上2种模式的优点，完美胜出；
在同子网内进行网络访问时，使用BGP模式，在跨子网网络访问时，使用IPIP模式。
参考
