k8s容器互联-flannel host-gw原理篇

k8s容器互联flannel host-gw k8s容器互联 2023-05-14 17:05:14 715人浏览独家记忆

摘要

目录k8s容器互联-flannel host-gw原理篇简析host-gw集群基本信息分析集群内部网络流动方向host-gw的优缺点k8s容器互联-flannel host-gw原理

k8s容器互联-flannel host-gw原理篇

容器系列文章

容器系列视频

简析host-gw

前面分析了flannel vxlan模式进行容器跨主机通信的原理，但是vxlan模式需要对数据包进行额外的封包解包处理，带来的开销较大。

所以flannel提供了另外一种纯3层转发的通信模式，叫做host-gw，顾明思议，这种模式是将主机作为网关在用了。

先来看下网关在ip通信中的作用，例如，一个tcp包有源ip和目的ip，如果目的ip匹配不到路由信息，那么就会将包转发到网关，在一个发往目的ip的过程中，可能会经过多个网关。

网关的本质是作为ip通信的中转站，网络包在传输过程中，目的ip是不会变的，一直在变化的是Mac地址，每到达一台主机，那么目的mac地址就会发生变化，变成下一个网关的mac地址，数据包需要到达的下一台主机被称作”下一跳“（next hop）。

了解了网关的作用，再来看看flannel host-gw模式在k8s节点上做了哪些改动。

集群基本信息

这里我同样是启动了一个3节点的集群，cni插件就是用flannel，模式是host-gw模式。

net-conf.JSON: |
    {
      "Network": "10.10.0.0/16",
      "Backend": {
        "Type": "host-gw"
      }
    }

集群节点信息

parallels@master:~/k8s$ kubectl get nodes -o wide
NAME      STATUS   ROLES                  AGE   VERSioN   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE           KERNEL-VERSION      CONTaiNER-RUNTIME
master    Ready    control-plane,master   13D   v1.23.3   192.168.2.17   &lt;none&gt;        ubuntu 22.04 LTS   5.15.0-58-generic   Docker://20.10.12
worker1   Ready    &lt;none&gt;                 13d   v1.23.3   192.168.2.16   &lt;none&gt;        Ubuntu 22.04 LTS   5.15.0-60-generic   docker://20.10.12
worker2   Ready    &lt;none&gt;                 13d   v1.23.3   192.168.2.15   &lt;none&gt;        Ubuntu 22.04 LTS   5.15.0-60-generic   docker://20.10.12

然后用busybox镜像启动了4个pod

parallels@master:~/k8s$ kubectl  get pods -o wide
NAME                       READY   STATUS    RESTARTS   AGE   IP          NODE      NOMINATED NODE   READINESS GATES
busybox-8647b8666c-jpnb6   1/1     Running   0          21m   10.10.1.6   worker1   &lt;none&gt;           &lt;none&gt;
busybox-8647b8666c-pg7ps   1/1     Running   0          21m   10.10.2.4   worker2   &lt;none&gt;           &lt;none&gt;
busybox-8647b8666c-sgf8v   1/1     Running   0          21m   10.10.1.5   worker1   &lt;none&gt;           &lt;none&gt;
busybox-8647b8666c-zlxmm   1/1     Running   0          21m   10.10.2.3   worker2   &lt;none&gt;           &lt;none&gt;

我们的目的就是看看worker1节点上的ip为10.10.1.6 的pod 是如何ping通 worker2节点上的ip为 10.10.2.4 的pod的。

分析集群内部网络流动方向

为了接下来的分析更加形象化，这里我先贴上一张集群内部的网络拓扑图。后续的分析都可以随时回顾下这张图。

先从10.10.1.6的pod看起，进入10.10.1.6的pod查看路由信息。

worker1节点上的ip为10.10.1.6的pod路由信息

parallels@master:~/k8s$ kubectl exec -it busybox-8647b8666c-jpnb6 /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ #
/ # ip route
default via 10.10.1.1 dev eth0
10.10.0.0/16 via 10.10.1.1 dev eth0
10.10.1.0/24 dev eth0 scope link  src 10.10.1.6

默认网关是10.10.1.1 ，这个ip地址其实就是worker1节点上cni0网桥的ip地址

可以查到worker1节点上cni0的ip地址

parallels@worker1:~$ ifconfig
cni0: flags=4163&lt;UP,BROADCAST,RUNNING,MULTICAST&gt;  mtu 1500
        inet 10.10.1.1  netmask 255.255.255.0  broadcast 10.10.1.255

所以在ip为10.10.1.6的pod内部去ping上worker2节点的pod ip 10.10.2.4 会匹配上第二条路由信息，然后由eth0网卡出去，网关地址是10.10.1.1，所以网络包就从pod内部传送到了worker1的cni0网桥上。

cni0网桥会将mac地址为其自身mac地址的数据包转发到主机的3层网络中，而具体要怎么路由，则是需要看worker1主机上的路由规则。

parallels@worker1:~$ ip route
default via 192.168.2.1 dev enp0s5 proto dhcp src 192.168.2.16 metric 100
10.10.0.0/24 via 192.168.2.17 dev enp0s5
10.10.1.0/24 dev cni0 proto kernel scope link src 10.10.1.1
10.10.2.0/24 via 192.168.2.15 dev enp0s5
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.2.0/24 dev enp0s5 proto kernel scope link src 192.168.2.16 metric 100
192.168.2.1 dev enp0s5 proto dhcp scope link src 192.168.2.16 metric 100

这些节点上路由的配置是由flannel 在每个节点上启动的flanneld进程去进行的配置的，配置信息来源是k8s集群内部的etcd集群

我们发送的数据包目的ip是10.10.2.4 ，它会匹配上worker1主机的第二条路由信息，第二条路由信息是在说访问10.10.0.0/24 网段的数据包都将由enp0s5网卡发出，并且网关地址也就是下一跳的ip地址是192.168.2.17，而192.168.2.17 就是worker2的ip地址。

为了看的更加清晰，我们再来回顾下开局的图。

这样数据包就到达到worker2节点了，到了worker2节点后，数据包的如何流动是看worker2节点上的路由规则，所以我们再来看下节点2上面的路由规则。记住数据包的目的ip是10.10.2.4。

parallels@worker2:~$ ip route
default via 192.168.2.1 dev enp0s5 proto dhcp src 192.168.2.15 metric 100
10.10.0.0/24 via 192.168.2.17 dev enp0s5
10.10.1.0/24 via 192.168.2.16 dev enp0s5
10.10.2.0/24 dev cni0 proto kernel scope link src 10.10.2.1
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.2.0/24 dev enp0s5 proto kernel scope link src 192.168.2.15 metric 100
192.168.2.1 dev enp0s5 proto dhcp scope link src 192.168.2.15 metric 100

匹配上了第4条路由规则，发往 10.10.2.0/24 的网段的数据包是要被cni0网桥处理的，所以数据包来到了worker2节点上的cni0网桥上，cni0是如何找到要发送的目的ip的veth端口的呢？

pod内部的eth0 网卡其实就是个veth设备，veth设备一端连接在pod的网路命名空间中，一端连接在网桥上，从veth的一端发出去的网络包一定能够被另一端接收。

网桥收到主机发来的数据包后，首先看自身有没有数据包的目的ip的端口记录，如果有，那么就从该端口发送数据包，因为连接的veth设备，所以从端口发送出去后，一定能到达pod的内部，veth设备就像是网线一样。

如果没有记录，那么网桥会向通过arp协议广播帧，得到回应后便能知道端口与ip的映射关系。从而将数据包发往正确的端口。

这样一个数据包就完全的从一台主机通过路由规则到达到了另外一台主机，而主机ip实际上是被当成网关，作为原ip地址的下一跳地址了。