![](https://i-blog.csdnimg.cn/direct/b7b4f9fef9e24a6e831b3d8cd632684c.jpeg)
前两篇文章中我们介绍了pod怎么和宿主机通信以及pod怎么访问外网,这两种通信是理解pod间通信的基础。
关于pod间的相互访问,这里还需要细化一下。回想一下pod在k8s节点中的分布,两个pod可能分布在同一台宿主机上,也可能分布在不同宿主机上。这两种不同的拓扑结构,其组网模型也不一样。
本文先介绍第一种,同宿主内pod间如何访问
同宿主内pod间如何访问
关于同主机下的pod如何访问,有多种技术可以实现,因为这个pod发送的数据包,无论如何流转,始终不会出宿主机。
正如前文所说,要分析网络,总是离不开网络设备和路由表。
veth pair
既然之前文章我们说过,veth pair可以实现跨network namespace通信,最简单的我们可以用veth pair来做这件事情。
回想第一篇文章,我们的veth pair一端在pod的network namespace,另外一端在宿主机上,也就是root network namespace。如果我们将另外一端放到要通信pod的network namespace中不就可以了吗?
没错,这种模型完全可以。并且也很简单,但是要维护它却很困难。
因为这种模型类似一个点对点的结构,它要求pod两两之间都需要有veth pair。
试想,如果同一个主机内存在N个Pod。那么每个pod ns中都会存在N-1个veth设备,以及N-1条路由规则,整个主机上存在N*N个veth pair。
那你可能会说了,node节点默认可运行的pod数目上限是110个,也不是天文数字,似乎也能接受
确实,但再试想一个场景,当一个pod的IP发生变化的时候,你需要做什么?这时候可能就需要修改其他所有pod的路由规则。
这样一想,似乎就不太好接受了,veth pair的数量和路由表的维护是一个麻烦事。
那如果有个角色,能够将这些veth pair 束口呢?
bridge
接着刚才那个问题,熟悉linux设备的同学可能马上会想到,Liunx网桥不就能干这件事情吗?
确实可以,Linux bridge可以让这些网络设备作为一个端口连接到网桥上来,如下图所示:
![](https://i-blog.csdnimg.cn/direct/4ee9020f3aeb41d7910ca68871a82d68.png)
在这里,Linux bridge充当了一个二层交换机的角色。负责将来自不同veth设备的流量进行交换和转发。
网桥的定义 :网桥是一个工作在数据链路层的网络设备,可以连接多个局域网段,它能够根据MAC地址来转发帧,使得多个网络段上的设备能够像在同一个网络中一样进行通信。
Linux网桥:在Linux系统中,网桥是通过软件模拟实现的。它允许系统管理员创建一个逻辑上的交换机,可以绑定多个物理或虚拟网络接口。
这个模型很简单,它解决了第一种模型下veth pair数量多和需要维护路由的问题。
还是以同一个主机下N个Pod为例,在这个模型下,每个Pod的network namespace下只需要存在一个veth设备,整个主机也只需要N个veth pair。同时pod间的路由规则不需要任何路由表来记录。
没了路由表,Linux bridge怎么知道发送给谁呢?
答案是广播和转发表
广播的含义是当Linux bridge一个端口收到报文,而转发表中没有目标地址的MAC时,就会广播所有连接到bridge上的网络接口。
转发表的含义是bridge会记录所有经过的报文的MAC地址,它是自学习的。
有了linux bridge,大大减少了管理的复杂度,下面通过一个小实验,感受一个pod间如何通信。
实验
本实验用到的命令在Kubernets(k8s) 网络原理一:Pod与宿主机通信文章中有简单介绍
如无特殊说明,我们实验都用network namespace代指pod
创建pod-1和pod-2
bash
# ip netns add pod-1
# ip netns add pod-2
创建eth0和veth1,并将eth0加入pod-1 ns
bash
# ip link add eth0 type veth peer name veth1
# ip link set eth0 netns pod-1
创建eth0和veth2,并将eth0加入pod-2 ns
bash
# ip link add eth0 type veth peer name veth2
# ip link set eth0 netns pod-2
分别给pod-1和pod-2中的eth0配置ip
bash
# ip netns exec pod-1 ip addr add 10.10.1.10/32 dev eth0
# ip netns exec pod-2 ip addr add 10.10.1.11/32 dev eth0
启动pod-1中veth pair,并添加路由,为什么添加路由请查看前一篇文章
bash
# ip netns exec pod-1 ip link set eth0 up
# ip link set veth1 up
# ip netns exec pod-1 ip ro add default dev eth0
启动pod-2中veth pair,并添加路由
bash
# ip netns exec pod-2 ip link set eth0 up
# ip link set veth2 up
# ip netns exec pod-2 ip ro add default dev eth0
创建网桥cbr0并启动,需要安装bridge-utils
bash
# brctl addbr cbr0
# ip link set cbr0 up
将vteh1和veth2 添加进网桥
bash
# brctl addif cbr0 veth1
# brctl addif cbr0 veth2
查看vteh1和veth2是否正确添加到网桥
bash
# brctl show
bridge name bridge id STP enabled interfaces
cbr0 8000.d6821b81f256 no veth1
veth2
准备工作就绪,此时网络拓扑如下
我们尝试在pod-1中ping pod-2来模拟通信
bash
# ip netns exec pod-1 ping -c 1 10.10.1.11
PING 10.10.1.11 (10.10.1.11) 56(84) bytes of data.
64 bytes from 10.10.1.11: icmp_seq=1 ttl=64 time=0.033 ms
--- 10.10.1.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.033/0.033/0.033/0.000 ms
一切顺利,可以ping通,我们抓包看看这个过程发生了什么
bash
# ip netns exec pod-1 tcpdump -pne -i eth0
12:20:24.329781 12:35:c3:bb:69:bc > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 10.10.1.11 tell 10.10.1.10, length 28
12:20:24.329812 7e:55:17:b0:dc:bb > 12:35:c3:bb:69:bc, ethertype ARP (0x0806), length 42: Reply 10.10.1.11 is-at 7e:55:17:b0:dc:bb, length 28
12:20:24.329814 12:35:c3:bb:69:bc > 7e:55:17:b0:dc:bb, ethertype IPv4 (0x0800), length 98: 10.10.1.10 > 10.10.1.11: ICMP echo request, id 48389, seq 1, length 64
12:20:24.329827 7e:55:17:b0:dc:bb > 12:35:c3:bb:69:bc, ethertype IPv4 (0x0800), length 98: 10.10.1.11 > 10.10.1.10: ICMP echo reply, id 48389, seq 1, length 64
12:20:29.340282 7e:55:17:b0:dc:bb > 12:35:c3:bb:69:bc, ethertype ARP (0x0806), length 42: Request who-has 10.10.1.10 tell 10.10.1.11, length 28
12:20:29.340285 12:35:c3:bb:69:bc > 7e:55:17:b0:dc:bb, ethertype ARP (0x0806), length 42: Reply 10.10.1.10 is-at 12:35:c3:bb:69:bc, length 28
查看MAC地址与端口的映射关系
bash
# brctl showmacs cbr0
port no mac addr is local? ageing timer
1 12:35:c3:bb:69:bc no 2.30
2 7e:55:17:b0:dc:bb no 2.30
1 d6:82:1b:81:f2:56 yes 0.00
2 fe:c5:af:3f:03:b6 yes 0.00
值得说明的是,is local为no表示不是这个MAC地址不在root network namespace,上面回显中d6:82:1b:81:f2:56和fe:c5:af:3f:03:b6是veth1和veth2的mac地址,他们的is local为yes是因为veth1和veth2在root namespace。同时还可以看到相同端口号对应的正好是一对veth pair。
因此我们可以根据这两个信息总结关键流程如下:
- pod-1发起ICMP请求,因为无pod-2的MAC地址,于是先发起ARP请求
- pod-1 eth0发起ARP请求,希望获取10.1.10.11的mac地址
- cbr0收到广播的ARP请求,在转发表中记录MAC地址和端口
- 此时crb0中不存在pod-2中eth0的MAC地址,于是向所有将广播转发到其所绑定的所有端口,除了源veth
- pod-2 发现ieth0的ip刚好匹配,于是响应ARP请求,告诉自己的MAC地址
- crb0收到pod-2的ARP响应,在转发表中记录MAC地址和端口
- pod-1 向pod-2发起ICMP请求
- pod-2 响应ICMP请求
实验过程非常简单,这个模型能工作的原理就是利用了Linux bridge在二层通信。
实验环境清理
执行以下命令清理上文配置的设备
bash
# ip netns del pod-1
# ip netns del pod-2
# ip link set cbr0 down
# brctl delbr cbr0
小结
整个模型非常简单,完全是利用Linux Bridge的特性,没有什么好总结的,既然不总结,那就提几个问题
- veth1和veth2为什么不需要配置IP?
- bridge模型下主机内pod通信需要主机的eth0参与吗?
- 如果主机内pod通信不需要eth0参与,那什么时候需要它参与呢?
- cbr0网桥什么时候需要配置IP?
这些问题可能没有一个唯一的答案,但是能够触发我们思考。
直接点就是想说,要分析一种网络模型,你必须要知道这个网络下的各种网络设备作用。以及当网络诉求变化时,相关网络设备应该如何变化。
route table
bridge可以充当束口的角色,但是如果不想引入Linux bridge这个网络设备,又该如何处理呢?
我们知道一个主机打开ip_forward转发的时候,他自己就可以转发报文。
转发报文也就意味着从一个网络接口,转给另外一个网络接口,这个好理解,也就是说只要将veth pair的另一端连接到root network namesapce,让主机就能看到这个网络设备就可以做到。
问题在于第二个,如何转发?
话都到这了,肯定会想到路由表嘛
没错,在这个模型下,就是让主机承担这个转发的任务,同时将这些veth pair收拢到root network namesapce里面来。
通信模型如下。
在这个模型下,省去了网桥概念,通信模型更为简单,但是需要维护root network namespace中的route规则。不过好在这不会太多。
还是以同一个主机下N个Pod为例,在这个模型下,每个Pod的network namespace下只需要存在一个veth设备,整个主机也只需要N个veth pair,此外root network namespace中还需要有N条路由规则。
同理,我们也进行一个小实验来模拟
实验
建议先查看Kubernets(k8s) 网络原理一:Pod与宿主机通信,理解network namespace怎么和主机通信
老规矩,我们创建pod-1和pod-2 network namespace代表两个pod
以路由的方式配置nework namespace在上一篇文章中已经介绍了每一条命令的作用,因此这里只罗列命令
配置pod-1
bash
# ip netns add pod-1
# ip link add eth0 type veth peer name veth1
# ip link set eth0 netns pod-1
# ip netns exec pod-1 ip addr add 10.10.1.10 dev eth0
# ip netns exec pod-1 ip link set dev eth0 up
# ip netns exec pod-1 ip route add 169.254.1.1 dev eth0
# ip netns exec pod-1 ip route add default via 169.254.1.1 dev eth0
# ip link set dev veth1 up
# echo 1 > /proc/sys/net/ipv4/conf/veth1/proxy_arp
# echo 1 > /proc/sys/net/ipv4/ip_forward
配置pod-2
bash
# ip netns add pod-2
# ip link add eth0 type veth peer name veth2
# ip link set eth0 netns pod-2
# ip netns exec pod-2 ip addr add 10.10.1.11 dev eth0
# ip netns exec pod-2 ip link set dev eth0 up
# ip netns exec pod-2 ip route add 169.254.1.1 dev eth0
# ip netns exec pod-2 ip route add default via 169.254.1.1 dev eth0
# ip link set dev veth2 up
# echo 1 > /proc/sys/net/ipv4/conf/veth2/proxy_arp
# echo 1 > /proc/sys/net/ipv4/ip_forward
然后在主机上配置路由表
bash
# ip route add 10.10.1.10 dev veth1 scope link
# ip route add 10.10.1.11 dev veth2 scope link
路由表的意思是说,所有发给10.10.1.10的报文都从veth1出去,同理,所有发给10.10.1.11的报文都从veth2 出去。
此时网络拓扑如下图所示:
此时我们尝试在pod-1中ping pod-2来模拟通信
bash
# ip netns exec pod-1 ping -c 1 10.10.1.11
PING 10.10.1.11 (10.10.1.11) 56(84) bytes of data.
64 bytes from 10.10.1.11: icmp_seq=1 ttl=63 time=0.035 ms
--- 10.10.1.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.035/0.035/0.035/0.000 ms
没有问题,但是整个过程发生了什么呢,我们来抓包看一下
在pod-1中抓包
bash
# ip netns exec pod-1 tcpdump -n -i eth0
09:53:29.297355 ARP, Request who-has 169.254.1.1 tell 10.10.1.10, length 28
09:53:29.382379 ARP, Reply 169.254.1.1 is-at be:7c:fa:0e:81:25, length 28
09:53:29.382386 IP 10.10.1.10 > 10.10.1.11: ICMP echo request, id 36618, seq 1, length 64
09:53:29.541810 IP 10.10.1.11 > 10.10.1.10: ICMP echo reply, id 36618, seq 1, length 64
这个过程其实我们已经在pod与宿主机通信文章中分析过了,这里简单梳理以下流程
- pod-1中执行ping命令,通过socket调用给到pod-1协议栈
- pod-1协议栈准备发起ICMP报文,查找路由表,获知从eth0出去,下一跳是169.254.1.1
- pod-1协议栈查找Arp表,没有169.254.1.1的MAC地址,于是先发起Arp请求
- veth1收到pod-1中eth0发来的Arp请求,因为配置了proxy_arp,于是响应自己的MAC地址
- pod-1协议栈收到响应,组装ICMP报文,发送给veth-1
- veth-1收到ICMP报文,交给自己的协议栈,即host协议栈
- host协议栈因开启了ip_forward,于是查找本地路由表,发现应该从veth2设备发送
- veth2和pod-2中eth0为veth pair关系,于是eth0收到pod-1发送的ICMP报文,交给pod-2协议栈
- pod-2协议栈处理报文,按照原路返回响应报文。
小结
路由规则关心的是IP,而不是MAC地址,换句话说当跨物理网络时,路由模式的好处就显示出来了。虽然我们一台主机内不会存在跨网段,但是在后面我们总会用到的。
此外还值得说的一点是使用bridge的方式,Linux bridge会根据目的地址进行广播,所有设备都能收到,而L3 路由的方式则会隔离广播,请求的目的地址是固定的,因此广播限定在指定的广播域中,其它设备不会收到广播。
总结
本文分析两种主机内的组网模型,他们都可以达到主机内Pod相互通信的目的。只是采用不同的技术去实现,这两种方式没有严格的好坏之分,只是适用的场景不一样。
例如fiannel和docker就是采用bridge这种方式,依赖于一个网桥cni0(docker0)
进行二层数据的转发。而calico就使用的L3路由的方式。
理解了主机内pod如何通信,在下一篇文章中,我们将分析整个容器组网最复杂的一部分,不同主机上的pod如何通信。