k8s----解读kube三层网络方案

k8s----解读kube三层网络方案

纯三层的网络方案最经典的例子莫过于Flannel的host-gw模式和Calico项目
1.Flannel的host-gw模式

通信包数据流详解：
假设现在node1上的infra1要访问node2上的infra2.当设置Flannel使用host-gw模式之后。flanneld进程会在宿主机上创建一条通过node1的eth0设备到node2网段的路由，并且下一跳为node2ip地址。可以通过ip route查看到，
配置了下一跳的地址，哪么接下来ip包从网络层进入数据链路层封装成数据帧时，eth0设备就会使用下一跳对应的mac地址作为该数据帧的目的mac地址；
显然。这个目的mac地址应该是node2的mac地址，这个数据帧就从node1通过宿主机的二层网络顺利到达node2上；
Node2的内核网络栈从二层数据栈中获取到ip包后会看到这个ip包的目的ip地址是infra2容器的ip地址。燃弧根据node2上的路由规则进入infra2的网桥设备cni0.从而进入infra2容器内；

Flannel hostgw小结：
1.Hostgw模式的工作原理就是将每个Flannel子网的下一跳设置成该子网对应的宿主机的ip地址，然后这台宿主机就会充当容器通信路径里的网关。这正是hostgw的含义；

2.Flannel hostgw模式能够正常工作核心就是ip包封装成数据帧发送出去，使用路由表里的下一跳来设置目的mac地址。这样他就会通过二层网络到达目的宿主机，所以Flannel hostgw要求集群宿主机之间是二层连通的；

3.Flannel子网和主机的信息都是保存在etcd中的，Flanneld进程只需要watch这些数据的变化。然后实时更新路由表即可；

4.在kube v1.7之后，像Flannel和Calico这样的cni网络插件都可以直接连接到kube的apiserver来访问etcd。无需额外部署etcd供给他们使用；

下一跳，是指如果ip包从主机A发送到主机B。需要经过路由设备X的中转，哪么X设备就应该配置为主机A的下一跳地址；

从这里带出一个问题。宿主机之间也不一定二层都是互通的。比如宿主机分布在不同的子网vlan下，但是kube集群里，宿主机之间必须可以通过ip地址进行通信，也就是说至少三层是可达的。否则集群将不满足kube网络模型。宿主机之间ip互通的要求；
从这里引入一个更牛皮的项目：Calico
在容器生态中，Calico。项目提供的网络解决方案与Flannel的hostgw模式几乎完全一样。也就是说。Calico也会在每台宿主机上添加一条到达其他宿主机ip地址的路由规则；

Calico得以正常工作的核心也是为每个容器的ip地址找到对应的下一跳的网关，
不同点1：
Flannel hostgw通过宿主机的Flanneld进程通过apiserver的etcd获取Mac。ip地址来维护路由表信息。
Calico是使用一个重型武器来自动的在整个集群中分发路由信息，这个重型武器就是BGP。(border gateway protocol 边界网关协议)

BGP是一个linux内核原生支持的，专门用于在大规模数据中心维护不同自治系统之间的路由信息。无中心的路由协议。
使用BGP以后。可以认为在每个边界网关上都运行着一个小程序，他们会将各自的路由表信息通过tcp传输给其他边界网关，其他边界网关的小程序也会对这些数据进行分析。然后将需要的信息自动添加到自己的路由表里。
所以BGP。就是在大规模网络中实现节点路由信息共享的一种协议；这个能力正好可以取代Flanneld应用用户态中维护主机路由表的功能；而且BGP这种原生为大规模网络环境实现的协议，其可靠性和可扩展性远非Flanneld进程自己的方案可比；BGP也是一种最复杂的一种路由协议

Calico由三个部分组成：
cni插件， 这是Calico和kube对接的部分，
Felix 它是一个daemonSet。负责在宿主机上插入路由规则。写入linux内核的FIB转发信息库。以及维护Calico所需要的网络设备等工作；
BIRD， BGP客户端，专门负责在集群里分发路由规则信息；

不同点2：
Calico项目不会在宿主机上创建任何网桥设备，但是Calico的cni插件会为每个容器设置一个veth Pir设备然后把其中的一段设置在宿主机。名字以cali前缀。Calico的cni没有使用cni的网桥模式。因此Calico的cni还需要再宿主机上为每个容器的vethPair配置一条路由规则，用于接收传入容器的ip包。
有必要写一下route规则：
10.233.2.3 dev cali5863f3 scope link
意思是发往10.233.2.3的ip包应该进入cali5863f3设备；
基于以上原因，Calico项目在宿主机上设置的路由规则比Flannel项目多得多，
但是Flannel hostgw模式使用cni网桥。主要为了跟vxlan模式保持一致，否则。Flannel项目就需要维护2套cni插件了；
有了veth Pair设备之后，容器发出的ip包就会经过veth设备到达宿主机，然后宿主机网络栈就会根据路由规则的下一跳ip地址。把他们转到正确的网关。
Calico项目实际上是将集群中的所有节点当作边界路由器来处理。他们共同组成了一个全连通的网络。相互之间通过BGP协议交换路由规则，这些节点叫做BGP Peer
需要注意的是，Calico维护的网络的默认配置下是一种叫做node-to-node Mesh的模式，每台宿主机的BGPclient也就是BIRD，都选哦和其他节点的BIRD进行通信，以便交换路由信息，随着节点数量的增加，这些连接的数量会以N平方的规模快速增增长，从而给集群的网络带来巨大压力；
随意一般推荐将nodetonode mesh的模式用在少于100个节点的集群里，而在更大规模的集群里，需要route reflector模式；
在route reflector模式下，Calico会指定一个或者几个专门的节点来负责跟所有节点建立BGP连接，从而学习全局的路由规则；而其他节点只需要跟这几个专门的节点交换路由信息，即可获得整个集群的路由规则信息；这些专门的节点就是所谓的route reflecttor节点。他们实际上扮演了中间代理的角色，从而把BGP连接的规模控制在N的数量级上。
此外，Flannel hostgw模式最重要的限制就是要求集群宿主机之间的二层是连通的。整个要求对于Calico来说。整个限制同样存在；
例如：node1 ip：1.2.
node2 2.2
calico会在node1上添加一个到2.2的路由规则，
10.233.2.0/16 via 192.168.2.2 eth0
但2.2和node1根本不在一个二层子网中。无法通过二层网络将ip包发送到吓一跳node2的地址，这种情况下就需要为calico打开IPIP模式，在此模式下，Felix进程在node1上添加的路由规则会稍微不同，
10.233.2.0/24 via 192.168.2.2 tun10

这条路由的吓一跳仍然是node2的ip地址，但是这一次负责将ip包发出去的设备变成了tun10，注意：是tun10.不是Flannel的tun0，这两种设备的功能完全不同，Calico使用的这个设备使用的tun10设备是一个ip隧道设备。ip tunnel设备；
ip包进入ip隧道之后，会被linux的ipip驱动接管，ipip驱动会将这个ip包直接封装在要给宿主机网络的ip包中。封装成的新的ip包的目的地址是原ip包的下一跳的地址，原ip包则会被直接封装成新ip的payload。这原来从容器到node2的ip包就被封装成了从node1到node2的ip包。由于宿主机之间使用了路由器配置了三层转发，即设置了宿主机之间的吓一跳。因此这个ip包离开node1后就可以经过路由器跳到node2上；这样node2的网络栈会使用ipip驱动解包，拿到原始的ip包。然后同构路由规则到和vethPair设备到达目的容器内部；
但是当Calico使用ipip模式的时候。集群网络性能会因为额外的封包。解包工作而下降，实际测试中Calico ipip模式和Flannel Vxlan模式性能大致相当，所以在实际使用中，如非硬性需求，建议将所有宿主机节点放在要给子网内，避免使用iPIP模式；

通过上面对Calico工作原理的讲述，发现一个事实，如果Calico项目能够让宿主机之间的路由设备也通过BGP协议学习到的Calico网络里的路由规则，那么从容器发出的ip包不久可以将这些设备路由到目的宿主机了；
比如图中node1中会添加一条规则：
10.233.2.0/24 via 192.168.1.1 eth0
在route1中会添加规则：
10.233.2.0/24 via 192.168.2.1 eth0
那么容器1发出的IP包可以通过两次吓一跳道道route2.以此类推，在route2上在添加吓一跳路由。最终ip包转发到node2上；但是六层虽然简单明了，但是kube被广泛应用的公有云场景完全不可行，原因在于公有云环境中，宿主机之间的网关肯定不允许用户进行干预和设置；

在私有部署的环境中，宿主机属于不同vlan反而是更常见的部署状态，此时，设法将宿主机网关也加入到BGP mesh里从而避免使用IPIP。就成了迫切需求；
在Calico项目中已经提供了2中将宿主机网关建立BGP Peer关系；
第一：所有宿主机都跟宿主机网关建立BGP Peer关系
这种方案，node1和node2需要主动和宿主机网关route1和route2建立BGP连接，从而将所有路由同步到网关；这种方式Calico要求宿主机网关必须支持一种Dynamic Neighbors的BGP配置方式。Dynamic Neighbor允许给路由器配置一个网段，然后路由器会自动跟网络里的主机建立BGPPeer关系；
第二：使用一个或者多个独立组件负责收集整个集群里的所有路由信息，通过BGP的协议同步给网关 。Calico使用Route Refector节点方式进行组网。这里负责跟宿主机网关机型组网通信的独立组件直接由Route Reflector兼任即可；
更重要的是。这种情况下网关的BGPPeer个数有限且固定。所以我们可以直接将这些独立的组件配置成路由器的BGP Peer。而无需Dynamic Neighbors的支持；当然这些独立组件的工作原理也很简单。他们直选哦watch etcd中的宿主机和对应网段的变化，然后将这些信息同构BGP协议分发给网关即可；

小结：
在大规模集群中。三层网络方案在宿主机的路由规则可能会非常多，因此错误排查比那的很困难；因此在胸痛发生故障时，路由规则发生重叠冲突的该路会升高；
基于以上事实原因，在公有云上。由于宿主机网络本身比较直白，一般推荐更简单的Flannel host-gw模式；
但是不难看出，在私有部署环境中，Calico项目能够覆盖更多场景。并能提供更可靠的组网方案和架构思路；