flannel的三种常见模式分析

news2024/11/23 21:17:09

概述

大家接触flannel这种网络模式大多数可能都是从k8s中知道的，初始使用很少去深入了解它，毕竟使用它其实是很简单的。但是有时候会出现奇奇怪怪的网络问题，这个时候就需要我们更深入了解一下flannel这种网络模式。
Flannel是CoreOS开源的，Overlay模式的CNI网络插件，Flannel在每个集群节点上运行一个flanneld的代理守护服务，为每个集群节点（host）分配一个子网（subnet），同时为节点上的容器组（pod）分配IP，在整个集群节点间构建一个虚拟的网络，实现集群内部跨节点通信。Flannel的数据包在集群节点间转发是由backend实现的，目前，常见的模式有UDP、VXLAN、HOST-GW三种，还有一些其他的可以自行了解。

常见三种模式对比

UDP模式：使用设备flannel.0进行封包解包，原生内核不支持，上下文切换较大，性能非常差
VXLAN模式：使用flannel.1进行封包解包，原生内核支持，性能较强，集群可以由不同网段的主机组成
HOST-GW模式：不需要flannel.1这样的中间设备，直接将宿主机的IP当作子网的下一跳地址，性能最强
大概来说，host-gw的性能损失大约在10%左右，而其他所有基于VXLAN“隧道”机制 的网络方案，性能损失在20%~30%左右

常见三种模式的测试

udp模式

flannel官文说明: Use UDP only for debugging if your network and kernel prevent you from using VXLAN or host-gw.
使用udp后端的节点会创建一个 flannel0的TUN设备(Tunnel设备)。在 Linux 中，TUN 设备是一种工作在三层（Network Layer）的虚拟网络设备。TUN 设备的功能非常简单，即：在操作系统内核和用户应用程序之间传递 IP 包。在这个过程中，由于使用了flannel0这个TUN设备，仅在发出IP包的过程中就要经过了三次用户态到内核态的数据拷贝（linux的上下文切换代价比较大），所以性能非常差。虽然vxlan模式用的也是udp协议，但因为是在内核态完成数据包的处理，所以性能要远高于udp模式。
在这里插入图片描述
UDP模式简单来说，就是数据报文在发送实际物理网络之前，通过flanneld进行一层UDP封装，将数据报文作为payload发送给对端，对端收到UDP报文之后，flanneld通过解包得到真正的数据报文后，再转发至最终的服务端，如上图所示。

UDP模式的核心点是虚拟网络设备tun/tap，该设备一端连接协议栈，另外一端连接用户程序，允许用户程序像读写文件一样进行收发数据包。tun/tap工作原理基本一致，tun模拟是三层网络设备，收发的是IP层数据包；tap模拟是二层网络设备，收发以太网数据帧。

udp模式部署

[root@k8s-m1 k8s-total]# wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
#主要修改type类型和securityContext.privileged为true，type后面可以指定端口Port，默认为8285。securityContext.privileged不修改的话会报open /dev/net/tun: no such file or directory这个错误
[root@k8s-m1 k8s-total]# cat kube-flannel.yml
       net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "udp"
      }
    }
        securityContext:
          privileged: true
          capabilities:
            add: ["NET_ADMIN", "NET_RAW"]

#udp模式下，会生成一个flannel0的网卡
[root@k8s-m1 k8s-total]#  ip a 
33: flannel0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1472 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet 10.244.2.0/32 scope global flannel0
       valid_lft forever preferred_lft forever

[root@k8s-m1 k8s-total]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.254   0.0.0.0         UG    0      0        0 ens32
10.244.0.0      0.0.0.0         255.255.0.0     U     0      0        0 flannel0
10.244.2.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 ens32
172.16.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     0      0        0 ens32
#可以看到去往10.244.0.0网段地址是走flannel0这个网卡

可以看到， 10.224.0.0 网段都会经过 cni0，同一主机网段的pod之间的访问都会从容器网络到 cni0 设备，然后再转发到目标容器中。而pod网段中非本机的网段 10.224.2.0/16 都会经过 flannel0 设备，然后通过flanneld进程封包后抓发到目标机器的udp端口。

udp模式抓包分析

#选取不在同一节点上的pod
[root@k8s-m1 k8s-total]# kubectl get po -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
liveness-exec-pod           1/1     Running   0          18m   10.244.2.2   k8s-m1   <none>           <none>
my-nginx-7ff446c4f4-6zk5c   1/1     Running   0          19m   10.244.0.2   k8s-m2   <none>           <none>
my-nginx-7ff446c4f4-bslht   1/1     Running   0          17m   10.244.2.3   k8s-m1   <none>           <none>
#查看对应的veth网卡
[root@k8s-m1 k8s-total]# kubectl exec -it liveness-exec-pod -- /bin/sh
/ #  cat /sys/class/net/eth0/iflink 
28
#ping不在同一节点的pod
/ # ping  10.244.0.2
PING 10.244.0.2 (10.244.0.2): 56 data bytes
64 bytes from 10.244.0.2: seq=0 ttl=60 time=0.704 ms
64 bytes from 10.244.0.2: seq=1 ttl=60 time=0.464 ms
64 bytes from 10.244.0.2: seq=2 ttl=60 time=0.477 ms
64 bytes from 10.244.0.2: seq=3 ttl=60 time=0.490 ms

#查看28这个veth网卡
[root@k8s-m1 k8s-total]# ip a
.....
28: vethfabdae20@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue master cni0 state UP group default 
    link/ether e2:c9:c1:f5:bf:59 brd ff:ff:ff:ff:ff:ff link-netnsid 5
.....

#抓28网卡上的包
[root@k8s-m1 k8s-total]#  tcpdump -i vethfabdae20  -p icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vethfabdae20, link-type EN10MB (Ethernet), capture size 262144 bytes
15:08:01.142468 IP 10.244.2.2 > 10.244.0.2: ICMP echo request, id 2091, seq 0, length 64
15:08:01.143012 IP 10.244.0.2 > 10.244.2.2: ICMP echo reply, id 2091, seq 0, length 64
15:08:02.142590 IP 10.244.2.2 > 10.244.0.2: ICMP echo request, id 2091, seq 1, length 64
15:08:02.142972 IP 10.244.0.2 > 10.244.2.2: ICMP echo reply, id 2091, seq 1, length 64
15:08:03.142709 IP 10.244.2.2 > 10.244.0.2: ICMP echo request, id 2091, seq 2, length 64
15:08:03.143117 IP 10.244.0.2 > 10.244.2.2: ICMP echo reply, id 2091, seq 2, length 64
15:08:04.142824 IP 10.244.2.2 > 10.244.0.2: ICMP echo request, id 2091, seq 3, length 64
15:08:04.143247 IP 10.244.0.2 > 10.244.2.2: ICMP echo reply, id 2091, seq 3, length 64
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel
#抓取flannel0上的包
[root@k8s-m1 k8s-total]#  tcpdump -i flannel0  -p icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on flannel0, link-type RAW (Raw IP), capture size 262144 bytes
15:08:14.144355 IP 10.244.2.2 > 10.244.0.2: ICMP echo request, id 2091, seq 13, length 64
15:08:14.144825 IP 10.244.0.2 > 10.244.2.2: ICMP echo reply, id 2091, seq 13, length 64
15:08:15.144557 IP 10.244.2.2 > 10.244.0.2: ICMP echo request, id 2091, seq 14, length 64
15:08:15.144951 IP 10.244.0.2 > 10.244.2.2: ICMP echo reply, id 2091, seq 14, length 64
15:08:15.621785 IP 10.244.0.0 > 10.244.2.0: ICMP host 10.244.0.12 unreachable, length 68
15:08:15.621889 IP 10.244.0.0 > 10.244.2.0: ICMP host 10.244.0.12 unreachable, length 68
15:08:15.621924 IP 10.244.0.0 > 10.244.2.0: ICMP host 10.244.0.12 unreachable, length 68
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel

#出口网卡ens32上的包
[root@k8s-m1 k8s-total]#  tcpdump -i ens32  -p icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes
15:08:20.878531 IP 192.168.2.141 > 192.168.2.140: ICMP 192.168.2.141 protocol 112 unreachable, length 48
15:08:20.941755 IP 192.168.2.140 > 103.39.231.155: ICMP echo request, id 1, seq 42132, length 64
15:08:20.978561 IP 103.39.231.155 > 192.168.2.140: ICMP echo reply, id 1, seq 42132, length 64
15:08:21.679384 IP 192.168.2.141 > 192.168.2.140: ICMP host 192.168.2.141 unreachable, length 68
15:08:21.679429 IP 192.168.2.141 > 192.168.2.140: ICMP host 192.168.2.141 unreachable, length 68
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel

总结，在flannel的udp模式下，ping不在同一节点的pod，流量路径为pod（容器）->cni0->flannel0-> flanneld 进程将数据封装在UDP包-> 本端host 网卡->对端host 网卡 ->flanneld 进程解析出原始数据->flannel0-> cni0 ->对应的pod（容器），对端宿主机的流量可以用类似方法抓取。

和两台主机直接通信相比，Flannel UDP模式多了一个 flanneld 进程的处理，该处理会导致数据多次在用户态和内核态传递。如下图所示：
第一次，用户态的容器进程发出的 IP 包经过 cni0 网桥进入内核态；
第二次，IP 包根据路由表进入 TUN（flannel0）设备，从而回到用户态的 flanneld 进程；
第三次，flanneld 进行 UDP 封包之后重新进入内核态，将 UDP 包通过宿主机的 eth0 发出去。
在这里插入图片描述
在 Linux 操作系统中，上述这些上下文切换和用户态操作的代价其实是比较高的，这也正是造成 Flannel UDP 模式性能不好的主要原因。
Flannel 的VXLAN后端使用Linux 内核本身支持的VXLAN网络虚拟化技术，可以完全在内核态实现上述封装和解封装的工作，能明显提高网络性能，这也是Flannel支持的VXLAN网络成为主流容器网络方案的原因。

vxlan模式

VXLAN协议是一种隧道协议，旨在解决IEEE 802.1q中限制VLAN ID（4096）的问题。 使用 VXLAN，标识符的大小扩展到 24 位 (16777216)。
VXLAN的特点是将L2的以太帧封装到UDP报文（即L2 over L4）中，并在L3网络中传输。 在三层网络上构建一个逻辑的二层网络。
VXLAN本质上是一种隧道技术，在源网络设备与目的网络设备之间的IP网络上，建立一条逻辑隧道，将用户侧报文经过特定的封装后通过这条隧道转发。

vxlan模式部署

官方给的flannel部署yaml文件默认就是vxlan模式

#先清理环境，后面更换模式一样可以先清理
[root@k8s-m1 k8s-total]# kubectl delete -f kube-flannel.yml
[root@k8s-m1 k8s-total]# rm -rf /var/lib/cni/;rm -rf /etc/cni/;ifconfig cni0 down;ifconfig flannel.1 down;ip link delete cni0;ip link delete flannel.1    #这一步所有节点都需要执行

#修改配置
[root@k8s-m1 k8s-total]# cat kube-flannel.yml
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan"
      }
    }

[root@k8s-m1 k8s-total]# ip a
......
16: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default 
    link/ether ce:ce:74:1d:a6:f2 brd ff:ff:ff:ff:ff:ff
    inet 10.244.2.0/32 scope global flannel.1
       valid_lft forever preferred_lft forever
23: veth60f8f73d@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cni0 state UP group default 
    link/ether 26:13:a3:00:b5:75 brd ff:ff:ff:ff:ff:ff link-netnsid 5

[root@k8s-m1 k8s-total]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.254   0.0.0.0         UG    0      0        0 ens32
10.244.0.0      10.244.0.0      255.255.255.0   UG    0      0        0 flannel.1
10.244.1.0      10.244.1.0      255.255.255.0   UG    0      0        0 flannel.1
10.244.2.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 ens32
172.16.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     0      0        0 ens32

可以看到到，到其他节点的网段，此处是10.244.0.0，10.244.0.0，网关地址为对应的flannel.1网卡。

vxlan抓包分析

#注意改变了网络模式，pod要重新部署，后面的host-gw模式测试一样需要重新部署pod
[root@k8s-m1 k8s-total]# kubectl get po -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
liveness-exec-pod           1/1     Running   0          17h   10.244.2.10   k8s-m1   <none>           <none>
my-nginx-5b8555d6b8-9jns5   1/1     Running   0          17h   10.244.0.15   k8s-m2   <none>           <none>
my-nginx-5b8555d6b8-h5bws   1/1     Running   0          17h   10.244.1.6    k8s-m3   <none>           <none>

#对应上面看到的23网卡
[root@k8s-m1 k8s-total]# kubectl exec -it liveness-exec-pod -- /bin/sh
/ # cat /sys/class/net/eth0/iflink 
23
#ping不在同一节点的pod
/ # ping  10.244.0.15
PING 10.244.0.15 (10.244.0.15): 56 data bytes
64 bytes from 10.244.0.15: seq=0 ttl=62 time=0.477 ms
64 bytes from 10.244.0.15: seq=1 ttl=62 time=0.373 ms
64 bytes from 10.244.0.15: seq=2 ttl=62 time=0.351 ms
^C
--- 10.244.0.15 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.351/0.400/0.477 ms

#抓对应网卡上的包
[root@k8s-m1 k8s-total]#  tcpdump -i veth60f8f73d  -p icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth60f8f73d, link-type EN10MB (Ethernet), capture size 262144 bytes
09:48:02.442543 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 8039, seq 477, length 64
09:48:02.442773 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 8039, seq 477, length 64
09:48:03.442674 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 8039, seq 478, length 64
09:48:03.442915 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 8039, seq 478, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

[root@k8s-m1 k8s-total]#  tcpdump -i cni0  -p icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cni0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:48:14.444007 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 8039, seq 489, length 64
09:48:14.444264 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 8039, seq 489, length 64
09:48:15.444132 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 8039, seq 490, length 64
09:48:15.444364 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 8039, seq 490, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

[root@k8s-m1 k8s-total]#  tcpdump -i flnanel.1  -p icmp -nn
tcpdump: flnanel.1: No such device exists
(SIOCGIFHWADDR: No such device)
[root@k8s-m1 k8s-total]#  tcpdump -i flannel.1  -p icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on flannel.1, link-type EN10MB (Ethernet), capture size 262144 bytes
09:48:33.447459 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 8039, seq 508, length 64
09:48:33.447695 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 8039, seq 508, length 64
09:48:34.447606 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 8039, seq 509, length 64
09:48:34.447857 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 8039, seq 509, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

[root@k8s-m1 k8s-total]#  tcpdump -i ens32  -p icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes
09:48:39.944790 IP 192.168.2.140 > 103.39.231.155: ICMP echo request, id 1, seq 22955, length 64
09:48:39.981623 IP 103.39.231.155 > 192.168.2.140: ICMP echo reply, id 1, seq 22955, length 64
09:48:40.944945 IP 192.168.2.140 > 103.39.231.155: ICMP echo request, id 1, seq 22956, length 64
09:48:40.981931 IP 103.39.231.155 > 192.168.2.140: ICMP echo reply, id 1, seq 22956, length 64
09:48:41.059271 IP 192.168.2.141 > 192.168.2.140: ICMP 192.168.2.141 protocol 112 unreachable, length 48

总结，在flannel的vxlan模式下，ping不在同一节点的pod，流量路径为pod（容器）->cni0->flannel.1-> 本host IP -对端host IP ->flannel.1-> cni0 ->对应的pod（容器），对端宿主机的流量可以用类似方法抓取。

如下图，使用vxlan 后数据包传输过程：
假设 k8s-m2节点上的pod1（container1） 需要访问 k8s-m3节点上的pod2（container2）

  • 容器路由：根据容器路由表，数据从容器的 eth0 发出
  • 主机路由：数据包接入到主机网络设备 cni0后， 根据主机路由到 flannel.1 设备，即隧道入口。
  • vxlan 封装：加上 vxlan 相关的header，封装成一个普通的数据帧
  • 封装为udp包转发到目的机器：从FDB获取目标设备对应的 ip 和 mac，形成一个UDP包并转发出去。
  • 数据到达目标机器：数据包到达k8s-m3节点，在内核解封装发现是VXLAN数据包，把它交给flannel.1设备。flannel.1设备则会进一步拆包，取出原始IP包（源容器IP和目标容器IP），通过cni0网桥转发给容器。

在这里插入图片描述

host-gw模式

可查看flannel官方文档：Use host-gw to create IP routes to subnets via remote machine IPs. Requires direct layer2 connectivity between hosts running flannel.

howt-gw模式的工作原理，就是将每个Flannel子网的下一跳，设置成了该子网对应的宿主机的IP地址，也就是说，宿主机（host）充当了这条容器通信路径的“网关”（Gateway），这正是host-gw的含义。所有的子网和主机的信息，都保存在Etcd中，flanneld只需要watch这些数据的变化 ，实时更新路由表就行了。它核心是IP包在封装成桢的时候，使用路由表的“下一跳”设置上的MAC地址，这样可以经过二层网络到达目的宿主机。要求集群的主机位于同一个子网段。
vxlan模式修改为host-gw模式，直接修改type即可。

host-gw部署

[root@k8s-m1 k8s-total]# cat kube-flannel.yml 
......
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "host-gw"
      }
    }

#然后部署
[root@k8s-m1 k8s-total]# kubectl apply -f kube-flannel.yml 
[root@k8s-m1 k8s-total]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.254   0.0.0.0         UG    0      0        0 ens32
10.244.0.0      192.168.2.141   255.255.255.0   UG    0      0        0 ens32
10.244.1.0      192.168.2.142   255.255.255.0   UG    0      0        0 ens32
10.244.2.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 ens32
172.16.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     0      0        0 ens32

和vxlan打的路由对比，发现在host-gw模式下到10.244 的其他网段的Gateway已经是对应宿主机ens32 的IP地址，而上面的vxlan的下一跳是每个宿主机上flannel.1这个网卡的IP地址

host-gw抓包分析

创建测试的pod，带ping命令，位于不同节点就可以。

[root@k8s-m1 k8s-total]# kubectl get po -o wide
NAME                        READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
liveness-exec-pod           1/1     Running   0          4h29m   10.244.2.10   k8s-m1   <none>           <none>
my-nginx-5b8555d6b8-9jns5   1/1     Running   0          4h32m   10.244.0.15   k8s-m2   <none>           <none>
my-nginx-5b8555d6b8-h5bws   1/1     Running   0          4h33m   10.244.1.6    k8s-m3   <none>           <none>
[root@k8s-m1 k8s-total]# kubectl exec -it liveness-exec-pod -- /bin/sh
/ # cat /sys/class/net/eth0/iflink 
23
/ # ^C
/ # ping 10.244.0.15 
PING 10.244.0.15 (10.244.0.15): 56 data bytes
64 bytes from 10.244.0.15: seq=0 ttl=62 time=0.452 ms
64 bytes from 10.244.0.15: seq=1 ttl=62 time=0.336 ms
64 bytes from 10.244.0.15: seq=2 ttl=62 time=0.387 ms
^C
--- 10.244.0.15 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.336/0.391/0.452 ms

在对应节点进行抓包，如上在k8s-m1节点先抓包。

#查看对应veth的网卡名称
[root@k8s-m1 k8s-total]#  ip a
......
22: veth6250cd19@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP group default 
    link/ether 46:95:62:b1:34:cb brd ff:ff:ff:ff:ff:ff link-netnsid 7
23: veth60f8f73d@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cni0 state UP group default 
    link/ether 26:13:a3:00:b5:75 brd ff:ff:ff:ff:ff:ff link-netnsid 5

[root@k8s-m1 k8s-total]#  tcpdump -i veth60f8f73d  -p icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth60f8f73d, link-type EN10MB (Ethernet), capture size 262144 bytes
20:49:40.746935 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 27224, seq 0, length 64
20:49:40.747213 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 27224, seq 0, length 64
20:49:41.747140 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 27224, seq 1, length 64
20:49:41.747424 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 27224, seq 1, length 64
20:49:42.747341 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 27224, seq 2, length 64
20:49:42.747545 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 27224, seq 2, length 64
20:49:43.747487 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 27224, seq 3, length 64
20:49:43.747703 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 27224, seq 3, length 64
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

[root@k8s-m1 k8s-total]#  tcpdump -i cni0  -p icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cni0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:49:55.749255 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 27224, seq 15, length 64
20:49:55.749460 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 27224, seq 15, length 64
20:49:56.749400 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 27224, seq 16, length 64
20:49:56.750816 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 27224, seq 16, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

#可以看到，由于我开始部署了vxlan模式，flannel.1的网卡没有清理，但是抓flannel上的包已经没有icmp数据
[root@k8s-m1 k8s-total]#  tcpdump -i flannel.1  -p icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on flannel.1, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

[root@k8s-m1 k8s-total]#  tcpdump -i ens32  -p icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes
20:50:12.770374 IP 103.39.231.155 > 192.168.2.140: ICMP echo reply, id 1, seq 41794, length 64
20:50:13.733641 IP 192.168.2.140 > 103.39.231.155: ICMP echo request, id 1, seq 41795, length 64
20:50:13.751660 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 27224, seq 33, length 64
20:50:13.751826 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 27224, seq 33, length 64
20:50:13.770154 IP 103.39.231.155 > 192.168.2.140: ICMP echo reply, id 1, seq 41795, length 64
^X20:50:14.733778 IP 192.168.2.140 > 103.39.231.155: ICMP echo request, id 1, seq 41796, length 64
20:50:14.751769 IP 10.244.2.10 > 10.244.0.15: ICMP echo request, id 27224, seq 34, length 64
20:50:14.751933 IP 10.244.0.15 > 10.244.2.10: ICMP echo reply, id 27224, seq 34, length 64
20:50:14.770229 IP 103.39.231.155 > 192.168.2.140: ICMP echo reply, id 1, seq 41796, length 64
20:50:15.430190 IP 192.168.2.141 > 192.168.2.140: ICMP 192.168.2.141 protocol 112 unreachable, length 48
^C
10 packets captured
18 packets received by filter
0 packets dropped by kernel

**总结：flannel的host-gw模式下的不同节点上pod访问流量路径如下：
pod（容器）->cni0-> 本host IP -对应host IP -> cni0 ->对应的pod（容器）**而不会经过flannel.1网卡。对端宿主机的流量可以用类似方法抓取。

host-gw 模式的工作原理，其实就是将每个 Flannel 子网（Flannel Subnet，比如：10.244.1.0/24）的“下一跳”，设置成了该子网对应的宿主机的 IP 地址；从而让这台主机充当容器网络的网关角色。

在这里插入图片描述

如何查看集群使用flannel的哪种网络模式

通过configmap查看

[root@k8s-m1 k8s-total]# kubectl get cm -n kube-system kube-flannel-cfg -o yaml|grep Type
        "Type": "udp"

直接通过网卡加路由进行查看

[root@k8s-m1 k8s-total]# ip a
.....
25: flannel0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1472 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet 10.244.1.0/32 scope global flannel0
       valid_lft forever preferred_lft forever

查看flannel的名字，如果是flannel0，则是udp模式，如果是flannel.1，还需通过路由进一步查看

[root@k8s-m1 k8s-total]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.254   0.0.0.0         UG    0      0        0 ens32
10.244.0.0      192.168.2.141   255.255.255.0   UG    0      0        0 ens32
10.244.1.0      192.168.2.142   255.255.255.0   UG    0      0        0 ens32
10.244.2.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 ens32
172.16.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     0      0        0 ens32

如果10.244. （根据实际环境设置的pod网段）的gateway地址是宿主机的IP地址，则是host-gw模式。而如果gateway也是10.244网段的，则是vxlan模式。

更多关于kubernetes的知识分享，请前往博客主页。编写过程中，难免出现差错，敬请指出

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/820394.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

【BASH】回顾与知识点梳理（四）

【BASH】回顾与知识点梳理（四）

【BASH】回顾与知识点梳理 四 四. Bash Shell 的操作环境4.1 路径与指令搜寻顺序4.2 bash 的进站与欢迎讯息&#xff1a; /etc/issue, /etc/motd4.3 bash 的环境配置文件login与non-login shell/etc/profile (login shell 才会读)~/.bash_profile (login shell 才会读)source &…
阅读更多...
Spark2x原理剖析（一）

Spark2x原理剖析（一）

一、简介 Spark是基于内存的分布式计算框架。在迭代计算的场景下&#xff0c;数据处理过程中的数据可以存储在内存中&#xff0c;提供了比MapReduce高10到100倍的计算能力。Spark可以使用HDFS作为底层存储&#xff0c;使用户能够快速地从MapReduce切换到Spark计算平台上去。Sp…
阅读更多...
【数据结构】二叉树、二叉搜索树、平衡二叉树、红黑树、B树、B+树

【数据结构】二叉树、二叉搜索树、平衡二叉树、红黑树、B树、B+树

概述 二叉树&#xff08;Binary Tree&#xff09;&#xff1a;每个节点最多有两个子节点&#xff08;左子节点和右子节点&#xff09;&#xff0c;没有限制节点的顺序。特点是简单直观&#xff0c;易于实现&#xff0c;但查找效率较低。 二叉搜索树&#xff08;Binary Search…
阅读更多...
【严重】PowerJob＜=4.3.3 远程代码执行漏洞

【严重】PowerJob＜=4.3.3 远程代码执行漏洞

漏洞描述 PowerJob 是一款开源的分布式任务调度框架。 由于 PowerJob 未对网关进行鉴权&#xff0c;4.3.3 及之前版本中&#xff0c;未经授权的攻击者可向 /instance/detail 端点发送恶意构造的 instanceId 参数远程执行任意代码。 漏洞名称 PowerJob<4.3.3 远程代码执行漏…
阅读更多...
集团MySQL的酒店管理系统

集团MySQL的酒店管理系统

酒店管理系统 概述 基于Spring Spring MVC MyBatis的酒店管理系统&#xff0c;主要实现酒店客房的预定、入住以及结账等功能。使用Maven进行包管理。 用户端主要功能包括&#xff1a; 登录注册、客房预订、客房评论&#xff08;编写评论和查看评论&#xff09; 后台管理主要…
阅读更多...
如何理解PID？

如何理解PID？

1 理解PID 先说结论&#xff1a;调整开关量让反馈更接近目标。 这里拿水龙头打比方&#xff0c;我们想控制水龙头的出水量为一半&#xff0c;这里就涉及两个关键量&#xff0c;阀门和出水量&#xff1b;阀门&#xff0c;即上面说的开关量&#xff1b;出水量即反馈&#xff1b…
阅读更多...
postman和jmeter的区别何在？

postman和jmeter的区别何在？

小伙伴们大家好呀&#xff0c;前段时间笔者做了一个小调查&#xff0c;发现软件测试行业做功能测试和接口测试的人相对比较多。在测试工作中&#xff0c;有高手&#xff0c;自然也会有小白&#xff0c;但有一点我们无法否认&#xff0c;就是每一个高手都是从小白开始的&#xf…
阅读更多...
推荐50个超实用的 Chrome 扩展，建议收藏！

推荐50个超实用的 Chrome 扩展，建议收藏！

今天来分享 50 个超实用的 Chrome 浏览器扩展&#xff01; JSON Viewer Pro JSON Viewer Pro 用于可视化JSON文件。其核心功能包括&#xff1a; 支持将JSON数据进行格式化&#xff0c;并使用属性或者图表进行展示&#xff1b;使用面包屑深入遍历 JSON 属性&#xff1b;在输入…
阅读更多...
大势智慧与深信服签署战略合作协议，助推实景三维中国建设

大势智慧与深信服签署战略合作协议，助推实景三维中国建设

7月28日&#xff0c;武汉大势智慧科技有限公司&#xff08;以下简称“大势智慧”&#xff09;与深信服成功签署战略合作协议&#xff0c;双方将围绕“实景三维中国建设”和测绘行业数字化领域开展深度合作&#xff0c;共同为广大测绘行业用户打造一款灵活高效的测绘数据生产和存…
阅读更多...
【CDC】跨时钟域处理方法总结一

【CDC】跨时钟域处理方法总结一

文章目录 一、概述1.异步时序2.亚稳态与建立保持时间 二、跨时钟域处理1.控制信号的跨时钟域处理&#xff08;单bit数据&#xff09;a.慢时钟域到快时钟域b.快时钟域到慢时钟域握手“扩宽”快时钟域脉冲时钟停止法窄脉冲捕捉电路 2.数据信号的跨时钟域处理&#xff08;多bit数据…
阅读更多...
C++动态内存管理（new和delete）

C++动态内存管理（new和delete）

C动态内存管理 1. C中动态内存管理1.1 new/delete操作内置类型1.2 new和delete操作自定义类型 2. operator new与operator delete函数2.1 operator new与operator delete函数&#xff08;重点&#xff09;3. new和delete的实现原理3.1 内置类型3.2 自定义类型 4. 常见面试题4.1…
阅读更多...
快速转换PDF文件: Python和PyMuPDF教程

快速转换PDF文件: Python和PyMuPDF教程

解决问题 有时候将文档上传Claude2做分析&#xff0c;有大小限制&#xff0c;所以需要切割pdf文档为几个小点的文档&#xff0c;故才有了本文章。 如何用Python和PyMuPDF制作你想要大小的PDF&#xff1f; PDF是一种广泛使用的文件格式&#xff0c;可以在任何设备上查看和打印…
阅读更多...
C#核心知识回顾——19.插入排序

C#核心知识回顾——19.插入排序

1.插入排序的基本原理 871542639 两个区域 排序区 未排序区 用一个索引值做分水岭 未排序区元素 与排序区元素比较 插入到合适位置 直到未排序区清空 int[] arr { 8, 6, 7, 2, 9, 4 };//第一步//能取出未排序区…
阅读更多...
防御第六次作业-文案

防御第六次作业-文案

1.录制一个讲解密码学综合应用视频&#xff0c;参考讲义中的综合应用图 过程&#xff1a; 发送者为Alice 接受者为Bob 首先对原始信息进行hash运算得到信息摘要&#xff0c;然后使用私钥进行签名&#xff08;签名的作用是验证该信息是Alice的&#xff09;&#xff0c;然后将…
阅读更多...
设备类资产盘点报告系统怎么处理？

设备类资产盘点报告系统怎么处理？

对于一个企业或者公司来说&#xff0c;掌握公司资产的实际情况是最基本的。要知道公司的资产&#xff0c;主要工作内容之一就是固定资产盘点。对于资产盘点&#xff0c;有一些应用。Excel人力资源方式&#xff0c;有的则采用固定资产管理系统。 RFID固定资产管理系统是指通过射…
阅读更多...
Footprint Analytics 宣布 20+ 链 API 免费增速，助力熊市 buidler

Footprint Analytics 宣布 20+ 链 API 免费增速，助力熊市 buidler

7 月 31 日&#xff0c;web3 数据供应商 Footprint Analytics 宣布其 API 产品的重大更新。 此次升级不仅大幅提升了 API 产品调用速度限制&#xff0c;还开放了包括 Ethereum, BNB, Polygon, zkSync 等在内的 20 公链的免费数据调用。 此外&#xff0c;Footprint 还更新了新…
阅读更多...
【网络】传输层

【网络】传输层

目录 一、端口号 1、端口号范围划分 2、知名端口号(Well-Know Port Number) 3、netstat 4、pidof 二、UDP协议 1、UDP协议段格式 2、UDP的特点 3、面向数据报 4、UDP的缓冲区 5、UDP使用注意事项 6、基于UDP的应用层协议 三、TCP协议 1、TCP协议段格式 2、确认应…
阅读更多...
vim、awk、tail、grep的使用

vim、awk、tail、grep的使用

vim命令 $定位到光标所在行的行末^定位到光标所在行的行首gg定位到文件的首行G定位到文件的末行dd删除光标所在行ndd删除n行&#xff08;从光标所在行开始&#xff09;D删除光标所在行&#xff0c;使之变为空白行x删除光标所在位置字符nx删除n个字符&#xff0c;从光标开始向后…
阅读更多...
mac屏幕提词器Presentation Prompter for mac

mac屏幕提词器Presentation Prompter for mac

Presentation Prompter是一款专业的电脑提词器软件&#xff0c;主要用于辅助演讲者、主持人等在演讲或演示过程中更加流畅地展示内容。它可以将文字以滚动或分页的形式显示在屏幕上&#xff0c;帮助演讲者在不中断演讲的情况下更好地掌控演讲进度。 以下是Presentation Prompt…
阅读更多...
城市内涝积水监测预警系统的重要性

城市内涝积水监测预警系统的重要性

一、系统概述 随着我国城镇化快速发展&#xff0c;城市建设产生的大量地面硬底化&#xff0c;大部分的降雨将形成地表径流&#xff0c;仅有少量雨水渗入地下&#xff0c;导致城市内涝等一系列问题。当前&#xff0c;全国多地发生洪涝&#xff0c;我国南北方全面进入主汛期。需要…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023