k8s容器互联flannel vxlan通信原理

目录

• k8s容器互联-flannel vxlan 原理篇
• vxlan 模式通信原理
• flannel的xvlan模式是如何办到的呢？
• 集群网络模型
• 查看worker2网络设备类型
• 查看集群pod 信息
• worker1节点的接收过程
• 再看flannel xvlan模式

k8s容器互联-flannel vxlan 原理篇

容器系列文章

容器系列视频

vxlan 模式通信原理

flannel 在为不同主机的pod分配ip地址的时候，会在一个大的网段范围内分配ip地址，而同一台主机上的pod，则是在大的网段下延伸出一个较小的子网，同一台主机上的ip地址则是在较小的子网范围内去进行分配。

例如k8s启动flannel插件时，会通过flannel的配置文件指定大的网段的范围和flannel启动方式，我们选用的是vxlan模式

  net-conf.json: |
    {
      "Network": "10.10.0.0/16",
      "Backend": {
        "Type": "vxlan"
      }
    }

这样整个集群的ip地址就是在10.10.0.0/16 网段去进行分配。 而各个主机上的ip地址范围 则是在例如10.10.1.0/24 ，10.10.2.0/24这样的网段去进行分配。

跨主机通信的目的，就是让主机A上的网段10.10.1.0/24 内分配的ip能够ping通主机B上的 10.10.2.0/24 网段分配的ip。

flannel的xvlan模式是如何办到的呢？

为了更好的理解vxlan的模式，我搭建了一个真实的3节点集群环境，然后实际的去主机上分析vxlan工作模式

集群网络模型

集群有3个节点:

master 集群的控制节点，ip地址是 192.168.2.17;

worker1 工作节点 ip地址是 192.168.2.16;

worker2 工作节点 ip 地址是 192.168.2.15 ;

由于工作节点才承担具体的pod承载认为，所以我们只看工作节点即可。

这里先放一张集群网络模型的图，接下来的分析都将会根据这个图一步步分析网络包时如何从worker2 的pod到达到worker1的pod的。

查看worker2网络设备类型

查看网络接口有哪些

parallels@worker2:~/Desktop$ ifconfig
cni0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.10.2.1  netmask 255.255.255.0  broadcast 10.10.2.255
       ...
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:41:ce:a9:49  txqueuelen 0  (Ethernet)
        ...
enp0s5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.15  netma编程sk 255.255.255.0  broadcast 192.168.2.255
        ...
flannel.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 编程客栈10.10.2.0  netmask 255.255.255.255  broadcast 0.0.0.0
        inet6 fe80::647c:5aff:fe24:c42e  prefixlen 64  scopeid 0x20<link>
        ether 66:7c:5a:24:c4:2e  txqueuelen 0  (Ethernet)
        ...
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        ...
veth9c0a9a53: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet6 fe80::fc7d:fdff:fe6f:a32e  prefixlen 64  scopeid 0x20<link>
        ether fe:7d:fd:6f:a3:2e  txqueuelen 0  (Ethernet)
        ...
vethd6f08999: flags=4163<UP,BROADCAST,RUNNING,MUL开发者_Python培训TICAST>  mtu 1450
        inet6 fe80::68b2:41ff:fee2:9074  prefixlen 64  scopeid 0pythonx20<link>
        ether 6a:b2:41:e2:90:74  txqueuelen 0  (Ethernet)
        ...

k8s 在主上创建一个cni0和flannel.1的虚拟网络设备，cni0是网桥类型的设备，flannel.1是vxlan类型的设备 (准确的说是vtep设备，在vxlan模式下，我们将这个封包解包的设备叫做vtep设备VXLAN Tunnel Endpoints)。

记下这里worker2节点上cni0的ip地址10.10.2.1 ，flannel.1的ip地址 10.10.2.0

parallels@worker2:~/Desktop$ ethtool -i flannel.1
driver: vxlan
...
parallels@worker2:~/Desktop$ ethtool -i cni0
driver: bridge
...

先看下网桥的作用(vxlan设备作用稍后进行分析) 网桥拥有交换机的作用。

我们知道，在同一台主机上，不同pod的网络命名空间是不同的，在linux上有一种veth的虚拟网络设备，它是成对出现的，所以也被叫做veth pair，可以连接不同命名空间。

从veth一端发出去的包能够被另外一端接收到，通过veth pair能够连通两个命名空间。

但是如果一台主机上，有许多pod，要想让那么多pod都连通的话，就得两两建立veth pair设备，这样的排列组合数量随着pod的增加会变得相当大。

而网桥的出现能够让这个网络模型变成 veth pair的一端连通着pod的网络命名空间，一端是连接在网桥上，让网桥充当交换机的作用，同一台主机的不同pod的数据包都经过网桥去进行转发。

交换机是工作在网络的第二层，所以只会将数据包解析到数据帧的格式，只认MAC地址，如果是广播帧，转发给所有接入网桥的设备，如果是单播帧，那么就会发往特定的端口。

但是网桥作为交换机与之不同的一点是，网桥具有将转发数据包到主机的三层网络协议栈的功能，如果发往网桥的数据包的mac地址就是网桥自身mac地址的话，那么网桥就会认为数据包是要发往数据的数据包，然后去对其进行转发。

查看集群pod 信息

再结合 pod 看看pod内部的网络数据包是如何输出到网桥上的。我在集群内部启动了一个3副本的busybox镜像的 pod。

来看看pod分布的工作节点以及其ip地址

(base) ➜  ~ kubectl get pods -o wide
NAME                       READY   STATUS    RESTARTS        AGE     IP          NODE      NOMINATED NODE   READINESS GATES
busybox-8647b8666c-74nmg   1/1     Running   0               3h19m   10.10.1.3   worker1   <none>           <none>
busybox-8647b8666c-bwgh9   1/1     Running   1 (4h29m ago)   12d     10.10.2.4   worker2   <none>           <none>
busybox-8647b8666c-qwzrh   1/1     Running   1 (4h29m ago)   4h57m   10.10.2.5   worker2   <none>           <none>

我们的目的就是让worker2节点上ip为10.10.2.4 的pod能ping通 worker1节点上ip为10.10.1.3的pod

进入worker2节点上 ip为10.10.2.4 的pod内部看看路由信息。

/ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.2.1       0.0.0.0         UG    0      0        0 eth0
10.10.0.0       10.10.2.1       255.255.0.0     UG    0      0        0 eth0
10.10.2.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0

还记得刚刚说的worker2节点上的cni0网桥的ip是10.10.2.1 吗？

通过路由信息，可以看到10.10.2.1正是pod的网关，所以如果在pod内部 ping worker1上的pod ip 10.10.1.3 ，就会匹配上第二条路由信息。

那么worker2 的pod发出去的数据包就指定到达10.10.2.1这个ip上，所以mac地址就是10.10.2.1对应的mac地址，即cni0的mac地址。

正是由于这个原因，触发了cni0网桥的转发到主机上的三层网络协议栈的这个机制，而到达worker2主机后，通过ip要看具体转发到哪张网卡是看主机的路由信息的，所以，先看下worker2的路由信息。

parallels@worker2:~/Desktop$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0python.0.0.0         192.168.2.1     0.0.0.0         UG    100    0        0 enp0s5
10.10.0.0       10.10.0.0       255.255.255.0   UG    0      0        0 flannel.1
10.10.1.0       10.10.1.0       255.255.255.0   UG    0      0        0 flannel.1
10.10.2.0       0.0.0.0         255.255.255.0   U     0      0        0 cni0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.2.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s5
192.168.2.1     0.0.0.0         255.255.255.255 UH    100    0        0 enp0s5

我们数据包目的地是worker1上的pod ，ip是10.10.1.3 ，通过路由信息，看到属于10.10.1.0/24这个网段的数据包都会经过 flannel.1发出，网关是10.10.1.0 ，这个ip也就是对端vtep设备的ip地址。

数据包就这样从worker2的pod来到了worker2节点上的flannel.1 这个网卡上。

flannel.1会对数据包进行一些加工，加工时需要加上对端vtep的mac地址，由于flannel.1 通过路由信息已经知道对端vtep的ip地址，通过查询本地arp缓存表，得到目的vtep的mac地址。

parallels@worker2:~/Desktop$ ip neigh show dev flannel.1
10.10.1.0 lladdr 72:5a:79:44:22:7b PERMANENT
10.10.0.0 lladdr 62:03:91:cb:cc:36 PERMANENT

k8s是通过flanneld（在flannel插件工作模式下，每个节点上都有一个flanneld的后台进程，对节点上的一些网络信息进行配置）在worker2的arp缓存中写入了mac地址，且永不过期。

同时还会加上vxlan头部信息，在头部信息中表明了这是一个vxlan帧，这样worker1节点收到数据包时，知道这是一个vxlan帧后，会将这个包去进行解包操作，同时头部信息中也包含一个vni的信息，只有vni相同的网络设备才有解包的资格。

这样封装以后，还需要将这个包发往对端vtep所在的主机节点，怎么发送呢？

worker2的flannel.1用udp格式的数据包再包裹一下vxlan帧，封装成udp时，需要知道对端的ip地址。

这里封装成udp包的时候，是如何知道目的节点主机的ip的呢。 flannel.1 通过查询本机的一个叫做fdb的转发数据库获取目的节点主机的ip。

parallels@worker2:~/Desktop$ bridge fdb show flannel.1 | grep 72:5a:79:44:22:7b
72:5a:79:44:22:7b dev flannel.1 dst 192.168.2.16 self permanent

注意这些配置信息是在woker1节点启动后，就会在workejsr2节点自动加上的，而完成配置信息的动作是由各个主机上的flanneld进程完成的

知道了udp的目的ip后，就是一个正常数据包在宿主机上的封包，发送流程了。

这样，数据包就到达了worker1。

worker1节点的接收过程

worker1 的内核协议栈收到数据包以后，发现有vxlan header以及vni标记是1，就将这个vxlan包发给本机的vni标记也为1的flannel.1设备。

然后flannel.1进行解包，取出数据包的目的ip是10.10.1.3，然后查看worer1本机路由信息。

arallels@worker1:~/Desktop$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    100    0        0 enp0s5
10.10.0.0       10.10.0.0       255.255.255.0   UG    0      0        0 flannel.1
10.10.1.0       0.0.0.0         255.255.255.0   U     0      0        0 cni0
10.10.2.0       10.10.2.0       255.255.255.0   UG    0      0        0 flannel.1
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.2.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s5
192.168.2.1     0.0.0.0         255.255.255.255 UH    100    0        0 enp0s5
parallels@worker1:~/Desktop$ 

发现发往10.10.1.0/24这个网段的包要经过cni0网桥，所以flannel.1将解包后的数据包转发给了cni0网桥。

接下来就是cni0网桥在一个10.10.1.0/24 子网内发送目的ip为 10.10.1.3 的流程了。

cni0网桥先通过10.10.1.3查找本地mac地址，如果有则发往mac地址对应的端口，端口连通的另一端是veth设备也是worker1上的pod的网卡。

如果没有10.10.1.3的mac地址，则先通过arp协议，在一个局域网内获得arp响应包后，再发送数据包到对应端口连通的pod veth网卡上。

至此，worker1成功收到了worker2发送的数据包了。

再看flannel xvlan模式

本质上是通过flannel.1这个vxlan设备对主机发出去的数据包进行udp封装，然后发往经过物理网卡发往对端。

再进一步思考下，udp是可以丢包的，那么经过udp去封装数据包 的网络传输是可靠的吗？

答案是不需要可靠，整个flannel的转发模型，可以看出flannel完成的是网络模型的第三层次ip层的互通， 这里udp封装的ip包实际上是充当了第二层链路层的工作了，传输的可靠性是靠传输层实现的，传输层的靠是在对应pod所在命名空间中的tcp 的重传保证的。

以上就是k8s容器互联flannel vxlan通信原理的详细内容，更多关于k8s容器互联flannel vxlan的资料请关注我们其它相关文章！