七点半的菜市场

large picture of the cover

Kubernetes使用Flannel

⭐️ Kubernetes可以通过CNI接口接入其他插件来实现网络通讯。比较流行的有Flannel，calico等

⭐️ CNI插件存放位置：/etc/cni/net.d/10-flannel.conflist

⭐️插件使用的解决方案有：

  1. 虚拟网桥，多个容器共用一个虚拟网卡进行通信
  2. 多路复用,MacVLAN,多个容器共用一个物理网卡进行通讯
  3. 硬件交换，SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好

⭐️容器和容器之间通讯通过lo通讯

pod之间通讯

同一节点用cni网桥来转发数据包、

查看pod ip

[root@master ~]# kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
nginx-7bb7cd8db5-jmxmf   1/1     Running   0          59s   10.244.2.3   node     <none>           <none>
nginx-7bb7cd8db5-sl2nl   1/1     Running   0          59s   10.244.0.4   master   <none>           <none>
nginx-7bb7cd8db5-xjhjs   1/1     Running   0          59s   10.244.2.2   node     <none>           <none>

在来查看cni的ip 可以看见是在同一网段

[root@master ~]# ip add | grep cni
7: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
    inet 10.244.0.1/24 brd 10.244.0.255 scope global cni0

不同节点的Pod之间的通讯就需要网络插件支持了

flannel 支持的后端

Vxlan
vxlan			//报文封装，默认
Directrouting		//直接路由，跨网段使用vxlan，同网段使用host-gw模式。
host-gw：		//主机网关，性能好，但只能在二层网络中，不支持跨网络中，如果有成千上万的Pod，容易产生广播风暴，不推荐
UDP：			//性能差，不推荐

1️⃣ vxlan模式

什么是Vxlan？

Vxlan（Virtual ExtensibleLAN）

虚拟可扩展局域网，是Linux本身支持的一网种网络虚拟化技术。VXLAN可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制，构建出覆盖网络（OverlayNetwork）

在现有的三层网络之上，“覆盖”一层虚拟的、由内核VXLAN模块负责维护的二层网络，使得连接在这 个VXLAN二层网络上的“主机”（虚拟机或容器都可以），可以像在同一个局域网（LAN）里那样自由通信。

为了能够在二nfcu网络上打通“隧道”，VXLAN会在宿主机上设置一个特殊的网络设备作为“隧道”的两端，叫VTEP：VXLAN Tunnel End Point（虚拟隧道端点）

VTEP设备之间通过二层数据桢进行通信。源VTEP设备收到原始IP包后，在上面加上一个目的MAC地址，封装成一个导去数据桢，发送给目的VTEP设备（获取 MAC地址需要通过三层IP地址查询，这是ARP表的功能）

image-20240922115150210image-20240922115156797

  • VTEP：VXLAN Tunnel End Point（虚拟隧道端点），在Flannel中VNI的默认值是1，这也是为什么宿主机的VTEP设备都叫flannel.1的原因
  • Cni0: 网桥设备，每创建一个pod都会创建一对 veth pair。其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡）
  • Flannel.1: TUN设备(虚拟网卡)，用来进行 vxlan报文的处理（封包和解包）。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端
  • Flanneld：flannel在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息。

查看节点的flannel网段

[root@master ~]# cat /run/flannel/subnet.env 
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true
[root@node ~]# cat /run/flannel/subnet.env 
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.2.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true

[root@master ~]# ip n
192.168.200.2 dev ens32 lladdr 00:50:56:eb:ef:82 STALE
10.244.2.0 dev flannel.1 lladdr 82:ac:87:7a:a4:ef PERMANENT
10.244.0.3 dev cni0 lladdr fa:06:35:f5:ca:e5 REACHABLE
192.168.200.1 dev ens32 lladdr 00:50:56:c0:00:08 DELAY
10.244.0.2 dev cni0 lladdr a2:a4:25:95:d1:42 REACHABLE
192.168.200.20 dev ens32 lladdr 00:0c:29:fd:84:2c REACHABLE

刚刚查看pod也可以看出网段差距

💻 Vxlan模式跨主机通讯的实验

masterpod 10.244.0.4 ——> nodepod 10.244.2.3

（1）当容器发送IP包，通过veth pair 发往cni网桥，再路由到本机的flannel.1设备进行处理。

（2）VTEP设备之间通过二层数据帧进行通信，源VTEP设备收到原始IP包后，在上面加上一个目的MAC地址，封装成一个内部数据帧，发送给目的VTEP设备。

  • master通过缓存或者node的 flanne.1的mac地址
[root@master ~]# ip n
10.244.2.0 dev flannel.1 lladdr 82:ac:87:7a:a4:ef PERMANENT
  • 查看node flannel.1
[root@node ~]# ip addr
7: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default 
    link/ether 82:ac:87:7a:a4:ef brd ff:ff:ff:ff:ff:ff
    inet 10.244.2.0/32 brd 10.244.2.0 scope global flannel.1
       valid_lft forever preferred_lft forever

（3）内部数据桢并不能在宿主机的二层网络传输，Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧，承载着内部数据帧通过宿主机的eth0进行传输

Linux会在内部数据帧前面，加上一个VXLAN头，VXLAN头里有一个重要的标志叫VNI，它是VTEP识别某个数据桢是不是应该归自己处理的重要标识。

flannel.1设备只知道另一端flannel.1设备的MAC地址，却不知道对应的宿主机地址是什么。在linux内核里面，网络设备进行转发的依据，来自FDB的转发数据库，这个flannel.1网桥对应的FDB信息，是由flanneld进程维护

FDB -- Forwarding Data Base

交换机从它的所有端口接收Media Access Control (MAC)地址信息，形成MAC地址表并维护它。当交换机收到一帧数据时，它将根据自己的MAC地址表来决定是将这帧数据进行过滤还是转发。此时，维护的这张MAC表就是FDB地址表。

是用FDB来获取目的的flannel.1的mac地址对应的ip地址

[root@master ~]# bridge fdb
82:ac:87:7a:a4:ef dev flannel.1 dst 192.168.200.20 self permanent

linux内核在IP包前面再加上二层数据帧头，把目标节点的MAC地址填进去，MAC地址从宿主机的ARP表获取

  • 通过arp获取node的网卡ip地址的mac地址
[root@master ~]# arp -n
192.168.200.20           ether   00:0c:29:fd:84:2c   C                     ens32
  • 查看node的ip和mac
[root@node ~]# ip a
 ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:fd:84:2c brd ff:ff:ff:ff:ff:ff
    inet 192.168.200.20/24 brd 192.168.200.255 scope global noprefixroute ens32

（4）此时flannel.1设备就可以把这个数据帧从eth0发出去，再经过宿主机网络来到目标节点的eth0设备。目标主机内核网络栈会发现这个数据帧有VXLAN Header，并且VNI为1，Linux内核会对它进行拆包，拿到内部数据帧，根据VNI的值，交给本机flannel.1设备处理,flannel.1拆包，根据路由表发往cni网桥，最后到达目标容器

  • 查看node的flanne.l 和cni ip
[root@node ~]# ip a
7: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default 
    link/ether 82:ac:87:7a:a4:ef brd ff:ff:ff:ff:ff:ff
    inet 10.244.2.0/32 brd 10.244.2.0 scope global flannel.1
       valid_lft forever preferred_lft forever
8: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether e2:53:5a:de:b3:c6 brd ff:ff:ff:ff:ff:ff
    inet 10.244.2.1/24 brd 10.244.2.255 scope global cni0
       valid_lft forever preferred_lft forever

在创建几个centos的pod

[root@master ~]# kubectl run  centos --image=centos:centos7.5.1804 --replicas=3
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/centos created

报错

[root@master ~]# kubectl get pod -o wide
NAME                       READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
centos-dy-d5b7cb6b-6pf7w   1/1     Running   0          10s   10.244.0.7    master   <none>           <none>
centos-dy-d5b7cb6b-f78qt   1/1     Running   0          11s   10.244.2.22   node     <none>           <none>
centos-dy-d5b7cb6b-w9j8c   1/1     Running   0          11s   10.244.2.23   node     <none>           <none>

进入master节点的pod ping node节点的pod

[root@master ~]# kubectl exec -it centos-dy-d5b7cb6b-6pf7w
[root@centos-dy-d5b7cb6b-6pf7w /]# ping 10.244.2.22
PING 10.244.2.22 (10.244.2.22) 56(84) bytes of data.
64 bytes from 10.244.2.22: icmp_seq=1 ttl=62 time=0.781 ms
64 bytes from 10.244.2.22: icmp_seq=2 ttl=62 time=0.552 ms
64 bytes from 10.244.2.22: icmp_seq=3 ttl=62 time=0.705 ms
64 bytes from 10.244.2.22: icmp_seq=4 ttl=62 time=0.635 ms

抓包查看

[root@node ~]# tcpdump -i ens32 -nn host 192.168.200.10
IP 10.244.0.7 > 10.244.2.22: ICMP echo request, id 19, seq 79, length 64
IP 10.244.2.22 > 10.244.0.7: ICMP echo reply, id 19, seq 79, length 64
IP 10.244.0.7 > 10.244.2.22: ICMP echo request, id 19, seq 80, length 64
IP 10.244.2.22 > 10.244.0.7: ICMP echo reply, id 19, seq 80, length 64

2️⃣ host-gw

howt-gw模式的工作原理，就是将每个Flannel子网的下一跳，设置成了该子网对应的宿主机的IP地址，也就是说，宿主机（host）充当了这条容器通信路径的“网关”（Gateway），这正是host-gw的含义所有的子网和主机的信息，都保存在Etcd中，flanneld只需要watch这些数据的变化 ，实时更新路由表就行了。

核心是IP包在封装成桢的时候，使用路由表的“下一跳”设置上的MAC地址，这样可以经过二层网络到达目的宿主机

image-20240922115538941

  • 配置flannel
  [root@master ~]# kubectl -n kube-system edit cm kube-flannel-cfg
      {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "host-gw"
      }
    }
  • 修改后需要更新flannel的pod
[root@master ~]# kubectl get pod -n kube-system |grep kube-flannel| awk '{system("kubectl delete pod "$1" -n kube-system")}'
pod "kube-flannel-ds-5j9d9" deleted
pod "kube-flannel-ds-q864r" deleted
  • 被删除后可以直接调度回来
[root@master ~]# kubectl get pod -n kube-system 
NAME                             READY   STATUS    RESTARTS   AGE
coredns-bccdc95cf-5rgmw          1/1     Running   0          9h
coredns-bccdc95cf-r2mqh          1/1     Running   0          9h
etcd-master                      1/1     Running   0          9h
kube-apiserver-master            1/1     Running   0          9h
kube-controller-manager-master   1/1     Running   0          9h
kube-flannel-ds-4nvgm            1/1     Running   0          64s
kube-flannel-ds-6867k            1/1     Running   0          60s
kube-proxy-dswk8                 1/1     Running   0          9h
kube-proxy-sbcvs                 1/1     Running   0          104m
kube-scheduler-master            1/1     Running   0          9h
  • 查看网关
[root@master ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.200.2   0.0.0.0         UG    100    0        0 ens32
10.244.0.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0
10.244.2.0      192.168.200.20  255.255.255.0   UG    0      0        0 ens32
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.200.0   0.0.0.0         255.255.255.0   U     100    0        0 ens32

这里应为网段master也被设置为可调度节点了所以没有显示10.244.0.1 的

3️⃣ 直接路由

跨网段用vxlan 同网段使用host-gw模式

[root@master ~]# kubectl -n kube-system edit cm kube-flannel-cfg
    net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan"
        "Directrouting": "True"
      }
    }
  • 删除flanne旧容器调度新容器
[root@master ~]# kubectl get pod -n kube-system |grep kube-flannel| awk '{system("kubectl delete pod "$1" -n kube-system")}'
pod "kube-flannel-ds-9ttl2" deleted
pod "kube-flannel-ds-gg9n5" deleted
  • 我们进入master节点的容器pod
[root@master ~]# kubectl get pod -o wide
NAME                       READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
centos-dy-d5b7cb6b-6pf7w   1/1     Running   0          26m   10.244.0.7    master   <none>           <none>
centos-dy-d5b7cb6b-f78qt   1/1     Running   0          26m   10.244.2.22   node     <none>           <none>
centos-dy-d5b7cb6b-w9j8c   1/1     Running   0          26m   10.244.2.23   node     <none>           <none>
[root@master ~]# kubectl exec -it centos-dy-d5b7cb6b-6pf7w bash
[root@centos-dy-d5b7cb6b-6pf7w /]# ping 10.244.2.22 
PING 10.244.2.22 (10.244.2.22) 56(84) bytes of data.
64 bytes from 10.244.2.22: icmp_seq=1 ttl=62 time=0.475 ms
64 bytes from 10.244.2.22: icmp_seq=2 ttl=62 time=1.47 ms
64 bytes from 10.244.2.22: icmp_seq=3 ttl=62 time=0.721 ms
64 bytes from 10.244.2.22: icmp_seq=4 ttl=62 time=0.635 ms
64 bytes from 10.244.2.22: icmp_seq=5 ttl=62 time=0.445 ms
64 bytes from 10.244.2.22: icmp_seq=6 ttl=62 time=0.584 ms
64 bytes from 10.244.2.22: icmp_seq=7 ttl=62 time=0.828 ms
64 bytes from 10.244.2.22: icmp_seq=8 ttl=62 time=0.543 ms
64 bytes from 10.244.2.22: icmp_seq=9 ttl=62 time=0.649 ms
64 bytes from 10.244.2.22: icmp_seq=10 ttl=62 time=0.624 ms
64 bytes from 10.244.2.22: icmp_seq=11 ttl=62 time=0.598 ms

[root@node ~]# tcpdump -i ens32 -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes
22:36:08.425464 IP 10.244.0.7 > 10.244.2.22: ICMP echo request, id 35, seq 7, length 64
22:36:08.425650 IP 10.244.2.22 > 10.244.0.7: ICMP echo reply, id 35, seq 7, length 64
22:36:09.449760 IP 10.244.0.7 > 10.244.2.22: ICMP echo request, id 35, seq 8, length 64
22:36:09.449874 IP 10.244.2.22 > 10.244.0.7: ICMP echo reply, id 35, seq 8, length 64
22:36:10.473137 IP 10.244.0.7 > 10.244.2.22: ICMP echo request, id 35, seq 9, length 64
22:36:10.473230 IP 10.244.2.22 > 10.244.0.7: ICMP echo reply, id 35, seq 9, length 64
22:36:11.497702 IP 10.244.0.7 > 10.244.2.22: ICMP echo request, id 35, seq 10, length 64
22:36:11.497786 IP 10.244.2.22 > 10.244.0.7: ICMP echo reply, id 35, seq 10, length 64
22:36:12.522853 IP 10.244.0.7 > 10.244.2.22: ICMP echo request, id 35, seq 11, length 64
22:36:12.522946 IP 10.244.2.22 > 10.244.0.7: ICMP echo reply, id 35, seq 11, length 64

site logo

Hi,Friend

© 2024 七点半的菜市场