Calico BGP通信分析

news2024/11/15 15:46:22

Calico BGP通信分析

在这里插入图片描述

BGP网络模型

  • BGP网络相比较IPIP网络,最大的不同之处就是没有隧道设备tunl0,pod之间的流量直接从·宿主机通过arp下一跳到目的地宿主机,减少了tunl0环节

BGP两种模式:

  • 全互联模式(node-to-node mesh)——全互联模式,每一个BGP Speaker都需要和其他BGP Speaker建立BGP连接,这样BGP连接总数就是N^2,如果数量过大会消耗大量连接。如果集群数量超过100台官方不建议使用此种模式
  • 路由反射模式Router Reflection(RR)——RR模式中会指定一个或多个BGP Speaker为RouterReflection,它与网络中其他Speaker建立连接,每个Speaker只要与Router Reflection建立BGP就可以获得全网的路由信息。在calico中可以通过Global Peer实现RR模式

BGP开启方式

# 开启IP In IP 模式方式:设置环境变量CALICO_IPV4POOL_IPIP来标识是否开启IPinIP Mode. 如果该变量的值为Always那么就是开启IPIP,如果关闭需要设置为Never
- name: CALICO_IPV4POOL_IPIP
  value: "Never"

测试容器YAML

主机IP
k8s-master-1192.168.0.11/24
K8s-node-1192.168.0.12/24
apiVersion: v1
kind: Service
metadata:
  name: busybox
  namespace: devops
spec:
  selector:
    app: busybox
  type: NodePort
  ports:
  - name: http
    port: 8888
    protocol: TCP
    targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: devops
spec:
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: busybox
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      name: busybox
      labels:
        app: busybox
    spec:
      affinity:	# 防止二个busybox 在同一个节点
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - topologyKey: kubernetes.io/hostname
            labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - busybox
      restartPolicy: Always
      containers:
      - command: ["/bin/sh","-c","mkdir -p /var/lib/www && httpd -f -v -p 80 -h /var/lib/www"]
        name: busybox
        image: docker.io/library/busybox:latest
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80

BGP跨主机分析

  1. 查看Pod信息
╰─ kubectl get pods -n devops -o custom-columns=NAME:.metadata.name,IP:.status.podIP,HOST:.spec.nodeName
NAME                       IP              HOST
busybox-77649b9c55-fv298   172.16.196.1    k8s-master-1
busybox-77649b9c55-s7zfv   172.16.109.65   k8s-node-1
jenkins-56b6774bb6-d8v8b   172.16.109.66   k8s-node-1
  1. 进入k8s-master-1的容器busybox-77649b9c55-fv298查看路由信息
/ # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
4: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 0e:1c:2c:f6:2a:f9 brd ff:ff:ff:ff:ff:ff
    inet 172.16.196.1/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c1c:2cff:fef6:2af9/64 scope link
       valid_lft forever preferred_lft forever

/ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         169.254.1.1     0.0.0.0         UG    0      0        0 eth0
169.254.1.1     0.0.0.0         255.255.255.255 UH    0      0        0 eth0

从上述中我们可以看出,k8s-master-1的容器busybox-77649b9c55-fv298默认有一个网关:169.254.1.1。但是整个网络中没有一张网卡是这个地址

  • 从路由表可以知道 169.254.1.1 是容器的默认网关,但却找不到任何一张网卡对应这个 IP 地址。当一个数据包的目的地址不是本机时,就会查询路由表,从路由表中查到网关后,它首先会通过 ARP广播获得网关的 MAC 地址,然后在发出的网络数据包中将目标 MAC 改为网关的 MAC,而网关的 IP 地址不会出现在任何网络包头中。也就是说,没有人在乎这个 IP 地址究竟是什么,只要能找到对应的 MAC 地址,能响应 ARP 就行了

  • 在Kubernetes Calico网络中,当一个数据包的目的地址不是本网络时,会先发起ARP广播,网关即169.254.1.1收到会将自己的mac地址返回给发送端
    后续的请求由这个veth对进行完成,使用代理arp做了arp欺骗。这样做抑制了arp广播攻击,并且通过代理arp也可以进行跨网络的访问

  • 查看MAC地址信息,这个 MAC 地址应该是 Calico 硬塞进去的,而且还能响应 ARP。正常情况下,内核会对外发送 ARP 请求,询问整个二层网络中谁拥有 169.254.1.1 这个 IP 地址,拥有这个 IP 地址的设备会将自己的 MAC地址返回给对方。但现在的情况比较尴尬,容器和主机都没有这个 IP 地址,甚至连主机上的网卡:calixxxxx,。MAC 地址也是一个无用的 ee:ee:ee:ee:ee:ee

  1. k8s-master-1宿主机节点网卡信息
/ # ip neigh
169.254.1.1 dev eth0 lladdr ee:ee:ee:ee:ee:ee used 0/0/0 probes 1 STALE

# k8s-master-1 自身网卡信息查看
[root@k8s-master-1 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:b1:02:f0 brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    inet 192.168.0.11/24 brd 192.168.0.255 scope global noprefixroute ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:feb1:2f0/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
4: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
    link/ether c2:25:66:ef:00:10 brd ff:ff:ff:ff:ff:ff
    inet 10.96.0.1/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.6.244/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.0.10/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.35.201/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
5: cali1dadcdd5b31@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default			# 容器busybox的对端设备
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-989b68fd-d10b-b11b-781e-18feb8b85b12
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
8: cali42cd276b2be@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default			# 其他容器的(coredns)
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-1328bbde-1a3c-a60c-9c3d-f4e1c2fbb3cd
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
       
# 查看calied926cbf5c7@if4网卡的ARP代理参数
[root@k8s-master-1 ~]# cat /proc/sys/net/ipv4/conf/cali1dadcdd5b31/proxy_arp
1
  • 通过veth-pair会传递到对端calixxx上,因为calixxx网卡开启了arp proxy,所以它会代答所有的ARP请求,让容器的报文都发到calixxx上,也就是发送到主机网络栈,再使用主机网络栈的路由来送到下一站. 可以通过cat /proc/sys/net/ipv4/conf/calixxx/proxy_arp/来查看,输出都是1
  • Calico 通过一个巧妙的方法将 workload 的所有流量引导到一个特殊的网关 169.254.1.1,从而引流到主机的 calixxx 网络设备上,最终将二三层流量全部转换成三层流量来转发
  • 在主机上通过开启代理 ARP 功能来实现 ARP 应答,使得 ARP 广播被抑制在主机上,抑制了广播风暴,也不会有 ARP 表膨胀的问题

k8s-master-1的busybox-77649b9c55-fv298尝试ping k8s-node-1的busybox-77649b9c55-s7zfv

# 查看k8s-master-1的busybox容器mac信息(为空)
/ # ip neigh show

# k8s-master-1的busybox 尝试ping k8s-node-1的busybox 
/ # ping -c 1 172.16.109.65
PING 172.16.109.65 (172.16.109.65): 56 data bytes
64 bytes from 172.16.109.65: seq=0 ttl=62 time=1.603 ms

--- 172.16.109.65 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.603/1.603/1.603 ms

# 查看ARP信息
/ # arp -n
? (169.254.1.1) at ee:ee:ee:ee:ee:ee [ether]  on eth0

# 查看k8s-master-1 busybox 当前网卡IP
/ # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
4: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1480 qdisc noqueue
    link/ether 86:9c:03:9e:db:9f brd ff:ff:ff:ff:ff:ff
    inet 172.16.196.1/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::849c:3ff:fe9e:db9f/64 scope link
       valid_lft forever preferred_lft forever

# 查看k8s-master-1路由信息
[root@k8s-master-1 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.2     0.0.0.0         UG    100    0        0 ens160
172.16.109.64   192.168.0.12    255.255.255.192 UG    0      0        0 ens160	# 其他节点的pod网段路由规则
172.16.196.0    0.0.0.0         255.255.255.192 U     0      0        0 *			  # 路由屏蔽,这里是把网段路由那些借助路由黑洞给屏蔽了
172.16.196.1    0.0.0.0         255.255.255.255 UH    0      0        0 cali1dadcdd5b31		# 容器busybox的对端设备
172.16.196.2    0.0.0.0         255.255.255.255 UH    0      0        0 cali42cd276b2be		# 其他容器的(coredns),每一个本机pod一个路由规则
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 ens160

# 查看路由详细信息
[root@k8s-master-1 ~]# ip route show
default via 192.168.0.2 dev ens160 proto static metric 100
172.16.109.64/26 via 192.168.0.12 dev ens160 proto bird
blackhole 172.16.196.0/26 proto bird
172.16.196.1 dev cali1dadcdd5b31 scope link
172.16.196.2 dev cali42cd276b2be scope link
192.168.0.0/24 dev ens160 proto kernel scope link src 192.168.0.11 metric 100

k8s-master-1的busybox-77649b9c55-fv298尝试ping k8s-node-1的busybox-77649b9c55-s7zfv整体流程数据报文流程如下:

  1. 由于172.16.109.65与当前172.16.196.1属于不同的网段,由于跨网段目的MAC地址为网关169.254.1.1的MAC地址,在获取网关的MAC地址时,由于veth-pair特效,eth0(容器)->cali1dadcdd5b31(宿主机)宿主机的cali1dadcdd5b31的网卡开启了ARP代理(ARP欺骗)会将MAC地址:ee:ee:ee:ee:ee:ee返回给容器
  2. 当获取到MAC地址后,构建数据报文:src: 172.16.196.1,dst: 172.16.109.65 src_mac: 86:9c:03:9e:db:9f dst_mac: ee:ee:ee:ee:ee:ee,此时容器查询本机路由规则发现命中默认网关路由,将数据报文丢给eth0,然后基于veth-pair设备对特性,数据报文到达宿主机的cali1dadcdd5b31网卡
[root@k8s-master-1 ~]# tcpdump -i cali1dadcdd5b31 icmp -e -Nnnvl
dropped privs to tcpdump
tcpdump: listening on cali1dadcdd5b31, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:55:45.042609 0e:1c:2c:f6:2a:f9 > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 5428, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.196.1 > 172.16.109.65: ICMP echo request, id 17, seq 10, length 64
16:55:45.043076 ee:ee:ee:ee:ee:ee > 0e:1c:2c:f6:2a:f9, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 62, id 60905, offset 0, flags [none], proto ICMP (1), length 84)
    172.16.109.65 > 172.16.196.1: ICMP echo reply, id 17, seq 10, length 64
  1. 数据报文到达k8s-master-1的cali1dadcdd5b31后进行路由匹配,此时会匹配到172.16.109.64 192.168.0.12 255.255.255.192 UG 0 0 0 ens160网段路由规则(k8s-node-1上所有pod都会命中这个路由规则),在BGP模式下tunl0是不会使用的,所以此时会直接封装数据报文:src: 172.16.196.1(POD IP),dst: 172.16.109.65(POD IP) src_mac: 00:0c:29:b1:02:f0(ens160物理网卡),dst_mac: 00:0c:29:90:fa:e2(ens160物理网卡)。由于源目IP为POD IP,而源目MAC分别为k8s-master-1/k8s-node-1的ens160的MAC地址,这表明:k8s-master-1节点的路由接收到数据,重新构建数据包时,使用arp请求,将k8s-node-1节点的mac拿到,然后封装到数据链路层。这就要求k8s-master-1和k8s-node-1处于同一个二层网络。否则会导致k8s-master-1无法拿到k8s-node-1的MAC地址。从而导致数据报文无法构建。数据报文构建后k8s-master-1将报文从ens160网卡丢出去
[root@k8s-master-1 ~]# tcpdump -i ens160 icmp -Nnnvle
dropped privs to tcpdump
tcpdump: listening on ens160, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:11:07.511766 00:0c:29:b1:02:f0 > 00:0c:29:90:fa:e2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 51277, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.196.1 > 172.16.109.65: ICMP echo request, id 17, seq 932, length 64
17:11:07.512366 00:0c:29:90:fa:e2 > 00:0c:29:b1:02:f0, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 42499, offset 0, flags [none], proto ICMP (1), length 84)
    172.16.109.65 > 172.16.196.1: ICMP echo reply, id 17, seq 932, length 64
17:11:08.512052 00:0c:29:b1:02:f0 > 00:0c:29:90:fa:e2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 51369, offset 0, flags [DF], proto ICMP (1), length 84)
  1. k8s-master-1将报文从ens160网卡丢出去后,数据报文到达二层交换机设备(虚拟机环境下,为虚拟交换机),由于数据报文的MAC地址中目的MAC地址为k8s-node-1的MAC地址,交换机会把数据报文丢给k8s-node-1节点

  2. k8s-node-1 ens160物理抓包查看报文,可以发现和k8s-master-1 ens160发出来的数据报文一致

[root@k8s-node-1 ~]# tcpdump -i ens160 icmp -Nnnvle
dropped privs to tcpdump
tcpdump: listening on ens160, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:40:05.566173 00:0c:29:b1:02:f0 > 00:0c:29:90:fa:e2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 3808, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.196.1 > 172.16.109.65: ICMP echo request, id 19, seq 1314, length 64
17:40:05.566306 00:0c:29:90:fa:e2 > 00:0c:29:b1:02:f0, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 62570, offset 0, flags [none], proto ICMP (1), length 84)
    172.16.109.65 > 172.16.196.1: ICMP echo reply, id 19, seq 1314, length 64
  1. k8s-node-1接收到报文后,匹配路由规则:172.16.109.65 0.0.0.0 255.255.255.255 UH 0 0 0 cali4e329df4a89,构建报文:src: 172.16.196.1(POD_IP),dst: 172.16.109.65(POD_IP),src_mac: ee:ee:ee:ee:ee:ee(k8s-node-1的busybox eth0对端的cali4e329df4a89网卡mac地址),dst_mac: 72:19:6b:9b:bf:e2(k8s-node-1的busybox eth0网卡mac地址)
# 查看k8s-node-1物理网卡信息
[root@k8s-node-1 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:90:fa:e2 brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    inet 192.168.0.12/24 brd 192.168.0.255 scope global noprefixroute ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe90:fae2/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
4: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
    link/ether 42:2d:65:bc:7a:b1 brd ff:ff:ff:ff:ff:ff
    inet 10.96.0.1/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.6.244/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.0.10/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.35.201/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
5: cali4e329df4a89@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default		# busybox容器的网卡
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-d7eaf0a1-1638-338d-5309-dbd5ec632608
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
8: cali523840de229@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default	# 其他容器的网卡
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-bd969f87-9e94-599c-119a-f8b8f3efc9c6
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
       
# 查看路由信息
[root@k8s-node-1 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.2     0.0.0.0         UG    100    0        0 ens160
172.16.109.64   0.0.0.0         255.255.255.192 U     0      0        0 *					# 路由屏蔽,这里是把网段路由那些借助路由黑洞给屏蔽了
172.16.109.65   0.0.0.0         255.255.255.255 UH    0      0        0 cali4e329df4a89	# 容器busybox的对端设备
172.16.109.66   0.0.0.0         255.255.255.255 UH    0      0        0 cali523840de229	# 其他容器的,每一个本机pod一个路由规则
172.16.196.0    192.168.0.11    255.255.255.192 UG    0      0        0 ens160		# 其他节点的pod网段路由规则
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 ens160


# 查看MAC地址
[root@k8s-node-1 ~]# tcpdump -i cali4e329df4a89 -Nnnvle icmp
dropped privs to tcpdump
tcpdump: listening on cali4e329df4a89, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:47:31.196897 ee:ee:ee:ee:ee:ee > 72:19:6b:9b:bf:e2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 62, id 37592, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.196.1 > 172.16.109.65: ICMP echo request, id 29, seq 0, length 64
17:47:31.196950 72:19:6b:9b:bf:e2 > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 29435, offset 0, flags [none], proto ICMP (1), length 84)
    172.16.109.65 > 172.16.196.1: ICMP echo reply, id 29, seq 0, length 64
    
# 查看ARP表
[root@k8s-node-1 ~]# arp -an
? (192.168.0.1) at 5e:e9:1e:fb:06:64 [ether] on ens160
? (172.16.109.66) at aa:2d:89:c6:49:dd [ether] PERM on cali523840de229
? (192.168.0.11) at 00:0c:29:b1:02:f0 [ether] on ens160
? (172.16.109.65) at 72:19:6b:9b:bf:e2 [ether] PERM on cali4e329df4a89
? (192.168.0.2) at 00:50:56:e0:1b:11 [ether] on ens160

按照上述分析,网络通信流程如下:

  1. busybox(k8s-master-1)-> calixxx -> ens160(k8s-master-1) <----> ens160(k8s-node-1) -> calixxx -> busybox(k8s-node-1)
  2. 根据k8s-master-1宿主机中的路由规则中的下一跳,使用路由规则发送到k8s-node-1的宿主机
  3. BGP模式要求节点必须属于同一个2层网络,由于跨节点POD间的通信报文在节点的物理网卡格式为:src_ip: pod_ip1 dst_ip: pod src_mac: node1_ensxx_mac,dst_mac: node2_ensxx_mac,如果二个节点不属于同一个二层网络,会导致节点之间无法互相获取MAC地址,从而导致数据报文构建失败

BGP同主机分析

  1. 查看Pod信息与宿主机路由信息
# 查看pod分布情况
╰─ kubectl get pods -n devops -o custom-columns=NAME:.metadata.name,IP:.status.podIP,HOST:.spec.nodeName
NAME                       IP              HOST
busybox-77649b9c55-fv298   172.16.196.1    k8s-master-1
busybox-77649b9c55-s7zfv   172.16.109.65   k8s-node-1
jenkins-56b6774bb6-d8v8b   172.16.109.66   k8s-node-1

# k8s-node-1查看路由信息
[root@k8s-node-1 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.2     0.0.0.0         UG    100    0        0 ens160
172.16.109.64   0.0.0.0         255.255.255.192 U     0      0        0 *
172.16.109.65   0.0.0.0         255.255.255.255 UH    0      0        0 cali4e329df4a89	# busybox容器
172.16.109.66   0.0.0.0         255.255.255.255 UH    0      0        0 cali523840de229 # 其他容器
172.16.196.0    192.168.0.11    255.255.255.192 UG    0      0        0 ens160
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 ens160

# 查看mac信息
[root@k8s-node-1 ~]# arp -an
? (192.168.0.1) at 5e:e9:1e:fb:06:64 [ether] on ens160
? (172.16.109.66) at aa:2d:89:c6:49:dd [ether] PERM on cali523840de229	# 其他容器
? (192.168.0.11) at 00:0c:29:b1:02:f0 [ether] on ens160
? (172.16.109.65) at 72:19:6b:9b:bf:e2 [ether] PERM on cali4e329df4a89	# busybox容器
? (192.168.0.2) at 00:50:56:e0:1b:11 [ether] on ens160

# 查看网卡信息
[root@k8s-node-1 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:90:fa:e2 brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    inet 192.168.0.12/24 brd 192.168.0.255 scope global noprefixroute ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe90:fae2/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
4: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
    link/ether 42:2d:65:bc:7a:b1 brd ff:ff:ff:ff:ff:ff
    inet 10.96.0.1/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.6.244/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.0.10/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.35.201/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
5: cali4e329df4a89@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default		# busybox容器
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-d7eaf0a1-1638-338d-5309-dbd5ec632608	
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
8: cali523840de229@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default	  # 其他容器
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-bd969f87-9e94-599c-119a-f8b8f3efc9c6
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever

当k8s-node-1的busybox容器ping其他容器时,数据包转发流程大致如下:

  1. 172.16.109.65和172.16.109.66属于同一个网段,当是我们查看busybox的路由信息发现并没有172.16.109.64的网段路由信息,所以会去默认网关169.254.1.1获取MAC地址信息,由于busybox的对端网卡:cali4e329df4a89开启了ARP代理,所以会返回ee:ee:ee:ee:ee:ee。然后封装数据报文:src_addr: 172.16.109.65 dst_addr: 172.16.109.66 src_mac: 72:19:6b:9b:bf:e2 dst_mac: ee:ee:ee:ee:ee:ee , 该数据报文会被送到宿主机的cali4e329df4a89
# k8s-node-1的busybox ping 其他容器
/ # ping -c 1 172.16.109.66
PING 172.16.109.66 (172.16.109.66): 56 data bytes
64 bytes from 172.16.109.66: seq=0 ttl=63 time=0.206 ms

--- 172.16.109.66 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.206/0.206/0.206 ms

[root@k8s-node-1 ~]# tcpdump -i cali4e329df4a89 -Nnnvle
dropped privs to tcpdump
tcpdump: listening on cali4e329df4a89, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:17:06.642985 72:19:6b:9b:bf:e2 > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 17087, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.109.65 > 172.16.109.66: ICMP echo request, id 37, seq 0, length 64
18:17:06.643095 ee:ee:ee:ee:ee:ee > 72:19:6b:9b:bf:e2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 8840, offset 0, flags [none], proto ICMP (1), length 84)
    172.16.109.66 > 172.16.109.65: ICMP echo reply, id 37, seq 0, length 64
  1. 当数据到达宿主机的cali4e329df4a89网卡,此时会进行路由匹配,匹配到规则172.16.109.66 0.0.0.0 255.255.255.255 UH 0 0 0 cali523840de229规则,会将数据报文转发给本机的cali523840de229网卡(因veth-pair特性,这个数据报文会直接被丢给容器),此时会构建数据报文:src_addr: 172.16.109.65 dst_addr: 172.16.109.66 src_mac: ee:ee:ee:ee:ee:ee dst_mac: 2d:89:c6:49:dd
[root@k8s-node-1 ~]# tcpdump -i cali523840de229 -Nnnvle icmp
dropped privs to tcpdump
tcpdump: listening on cali523840de229, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:19:07.901457 ee:ee:ee:ee:ee:ee > aa:2d:89:c6:49:dd, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 24224, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.109.65 > 172.16.109.66: ICMP echo request, id 38, seq 0, length 64
18:19:07.901483 aa:2d:89:c6:49:dd > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 14344, offset 0, flags [none], proto ICMP (1), length 84)
    172.16.109.66 > 172.16.109.65: ICMP echo reply, id 38, seq 0, length 64
  1. 数据报文回来和出去一致,这里就不分析了

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

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

相关文章

批量采集的时间管理与优化

在进行大规模数据采集时&#xff0c;如何合理安排和管理爬取任务的时间成为了每个专业程序员需要面对的挑战。本文将分享一些关于批量采集中时间管理和优化方面的实用技巧&#xff0c;帮助你提升爬虫工作效率。 1. 制定明确目标并设置合适频率 首先要明确自己所需获取数据的范…

陇剑杯2023WriteUp学习笔记【初赛】

文章目录 数据分析1、hard_webhard_web_1hard_web_2hard_web_3 2、sevrer savesevrer save_1sevrer save_2sevrer save_3sevrer save_4sevrer save_5sevrer save_6sevrer save_7sevrer save_8 3、WiresharkWireshark1_1Wireshark1_2Wireshark1_3Wireshark1_4 4、Incidentrespon…

C++信息学奥赛1187:统计字符数

#include <bits/stdc.h> using namespace std; int main() {string arr;cin >> arr; // 输入一个字符串int n, a, max; // 定义变量n, a, maxchar ArrMax; // 定义字符变量ArrMaxn arr.length(); // 获取字符串长度max a 0; // 初始化max和a为0// 外层循环&…

GPT引领前沿与应用突破之GPT4科研实践技术与AI绘图教程

详情点击链接&#xff1a;GPT引领前沿与应用突破之GPT4科研实践技术与AI绘图教程 前沿 GPT对于每个科研人员已经成为不可或缺的辅助工具&#xff0c;不同的研究领域和项目具有不同的需求。如在科研编程、绘图领域&#xff1a;1、编程建议和示例代码: 无论你使用的编程语言是Py…

Java多线程篇(1)——深入分析synchronized

文章目录 synchronized原理概述锁升级 初始状态偏向锁偏向锁获取/重入偏向锁的撤销/重偏向和升级批量重偏向和批量偏向撤销偏向锁的释放 轻量级锁轻量级锁获取/重入轻量级锁膨胀轻量级锁释放 重量级锁重量级锁获取/重入重量级锁释放重量级锁的降级 其他锁粗化、锁消除调用hashc…

Elasticsearch 中的向量搜索:设计背后的基本原理

作者&#xff1a;ADRIEN GRAND 实现向量数据库有不同的方法&#xff0c;它们有不同的权衡。 在本博客中&#xff0c;你将详细了解如何将向量搜索集成到 Elastisearch 中以及我们所做的权衡。 你有兴趣了解 Elasticsearch 用于向量搜索的特性以及设计是什么样子吗&#xff1f; …

【ROS】例说mapserver静态地图参数(对照Rviz、Gazebo环境)

文章目录 例说mapserver静态地图参数1. Rviz中显示的地图2. mapserver保存地图详解3. 补充实验 例说mapserver静态地图参数 1. Rviz中显示的地图 在建图过程中&#xff0c;rviz会显示建图的实时情况&#xff0c;其输出来自于SLAM&#xff0c;浅蓝色区域为地图大小&#xff0c…

SAP GUI登陆界面图片更换

导语&#xff1a;SAP登陆界面的图片不太好看&#xff0c;换一个客户需要的图片上去。 一、上传至SMW0 将准备好的图片&#xff0c;通过事物码SMW0进行上传。 二、更改配置表 事物码SM30&#xff0c;更改配置表【SSM_CUST】&#xff0c;以调用上传的图片 三、效果展示 作者…

Redis6搭建高可用的多主多从集群

Redis6搭建高可用的多主多从集群 环境准备搭建redis6集群安装redis6修改配置文件修改cluster-enabled修改cluster-config-file修改cluster-node-timeout 启动集群 环境准备 首先我们需要6台redis&#xff0c;那么为啥是6太呢&#xff1f;是因为我们要部署多master和多slaver集…

SpringCloudAlibaba之Sentinel介绍

文章目录 1 Sentinel1.1 Sentinel简介1.2 核心概念1.2.1 资源1.2.2 规则 1.3 入门Demo1.3.1 引入依赖1.3.2 集成Spring1.3.3 Spring中资源规则 1.4 Sentinel控制台1.5 核心原理1.5.1 NodeSelectorSlot1.5.2 ClusterBuilderSlot1.5.3 LogSlot1.5.4 StatisticSlot1.5.5 Authority…

ESP-C3入门23. I2C读写外部存储器

ESP-C3入门23. I2C读写外部存储器 一、准备工作1. 开发环境2. ESP32-C3 I2C资源介绍 二、主要函数1. 配置驱动程序2. 源时钟配置3. 安装驱动程序4. 通信5. 指示写入或读取数据 二、实现步骤1. 配置 I2C 总线&#xff1a;2. 初始化 I2C 总线&#xff1a;3. 与外部存储设备通信&a…

华为OD机试 - 找出经过特定点的路径长度 - 深度优先搜索(Java 2022 Q4 100分)

目录 专栏导读一、题目描述二、输入描述三、输出描述四、解题思路五、Java算法源码六、效果展示1、输入2、输出3、说明 华为OD机试 2023B卷题库疯狂收录中&#xff0c;刷题点这里 专栏导读 本专栏收录于《华为OD机试&#xff08;JAVA&#xff09;真题&#xff08;A卷B卷&#…

特征值,特征向量,SVD分解,PCD分解

特征值&#xff0c;特征向量&#xff1a; 对于n阶方阵A&#xff0c;在A张成的空间里&#xff0c;存在非零向量v&#xff0c; 该向量转换到A张成的空间时&#xff0c;方向不变&#xff0c;大小变为λ倍。 ① Av λv 变换一下&#xff1a; ② (A - λI)v 0 对于A向量&#x…

安全编程:初始化那些你忽略掉的东西

对于黑客来说&#xff0c;特权提升漏洞是令他感到非常兴奋的事情&#xff0c;而有时候这种漏洞的来源仅仅是因为开发者忘记将内存缓冲区中的垃圾数据进行初始化。此话怎讲&#xff1f; 我想&#xff0c;现在每个人都应该熟悉 SecureZeroMemory 函数的使用&#xff0c;它用来擦…

ESD实时监控监测系统包括哪些功能

ESD实时监控监测系统是一种用于监测和控制静电放电的系统。静电放电&#xff08;Electrostatic Discharge&#xff0c;ESD&#xff09;是指由于电荷的不平衡而引起的突发放电现象&#xff0c;可能对电子元器件、设备和工作环境造成损害。 ESD实时监控监测系统通常包括以下功能…

elmentui表单重置及出现的问题

一、表单&#xff1a; 二、代码——拿官方的代码举例(做了一些小改动)&#xff1a; 改动&#xff1a;model绑定的字段&#xff0c;由form改为queryParams ref绑定的字段form改为queryFrom 注&#xff1a;model绑定的这个字段用来做数据双向绑定的 注&#xff1a;ref绑定的这…

【TypeScript】一直提示 :无法重新声明块范围变量

【TypeScript】一直提示 &#xff1a;无法重新声明块范围变量 问题描述&#xff1a;在VSCode中编写ts代码时&#xff0c;编写保存完之后&#xff0c;通过tsc 文件名.ts编译就会看到变量名下面出现了红色的波浪线&#xff0c;提示的内容是无法重新声明块范围变量。 解决方法&am…

书单制作方法详细步骤,需要的小伙伴快来看看~

随着网络的发展&#xff0c;视频已经成为了人们获取信息的主要途径之一。书单视频作为一种特殊类型的视频&#xff0c;既能为观众提供阅读建议&#xff0c;又能为制作者带来收益&#xff0c;因此备受欢迎。本文将分享书单视频制作的详细步骤&#xff0c;帮助有兴趣的朋友们快速…

k8s基本概念

一、什么是Kubernetes二&#xff1a;Kubernetes部署方式的演变三、为什么要用K8S四、K8S的特性五、Kubernetes 集群架构与组件5.1 Master 组件① Kube-apiserver② Kube-controller-manager③ Kube-scheduler④ AUTH 认证模块 5.2 配置存储中心5.3 Node 组件① Kubelet② Kube-…

【校招VIP】产品分析之活动策划宣传

考点介绍&#xff1a; 产品的上线运营是非常重要的。应该来说好的产品都是运营出来的&#xff0c;在一运营过程中难免会依靠策划活动来提高产品知名度、用户数。用户粘度等等指标一&#xff0c;如何策划一个成功的活动就显得非常重要。 产品分析之活动策划宣传-相关题目及解析…