k8s容器互聯(lián)-flannel?host-gw原理篇

更新時間：2023年04月06日 14:03:01 作者：藍胖子的編程夢

這篇文章主要為大家介紹了k8s容器互聯(lián)-flannel?host-gw原理篇，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

k8s容器互聯(lián)-flannel host-gw原理篇

容器系列文章

容器系列視頻

簡析host-gw

前面分析了flannel vxlan模式進行容器跨主機通信的原理，但是vxlan模式需要對數(shù)據(jù)包進行額外的封包解包處理，帶來的開銷較大。

所以flannel提供了另外一種純3層轉(zhuǎn)發(fā)的通信模式，叫做host-gw，顧明思議，這種模式是將主機作為網(wǎng)關(guān)在用了。

先來看下網(wǎng)關(guān)在ip通信中的作用，例如，一個tcp包有源ip和目的ip，如果目的ip匹配不到路由信息，那么就會將包轉(zhuǎn)發(fā)到網(wǎng)關(guān)，在一個發(fā)往目的ip的過程中，可能會經(jīng)過多個網(wǎng)關(guān)。

網(wǎng)關(guān)的本質(zhì)是作為ip通信的中轉(zhuǎn)站，網(wǎng)絡(luò)包在傳輸過程中，目的ip是不會變的，一直在變化的是mac地址，每到達一臺主機，那么目的mac地址就會發(fā)生變化，變成下一個網(wǎng)關(guān)的mac地址，數(shù)據(jù)包需要到達的下一臺主機被稱作”下一跳“（next hop）。

了解了網(wǎng)關(guān)的作用，再來看看flannel host-gw模式在k8s節(jié)點上做了哪些改動。

集群基本信息

這里我同樣是啟動了一個3節(jié)點的集群，cni插件就是用flannel，模式是host-gw模式。

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

集群節(jié)點信息

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節(jié)點上的ip為10.10.1.6 的pod 是如何ping通 worker2節(jié)點上的ip為 10.10.2.4 的pod的。

分析集群內(nèi)部網(wǎng)絡(luò)流動方向

為了接下來的分析更加形象化，這里我先貼上一張集群內(nèi)部的網(wǎng)絡(luò)拓撲圖。后續(xù)的分析都可以隨時回顧下這張圖。

先從10.10.1.6的pod看起，進入10.10.1.6的pod查看路由信息。

worker1節(jié)點上的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

默認網(wǎng)關(guān)是10.10.1.1 ，這個ip地址其實就是worker1節(jié)點上cni0網(wǎng)橋的ip地址

可以查到worker1節(jié)點上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內(nèi)部去ping上worker2節(jié)點的pod ip 10.10.2.4 會匹配上第二條路由信息，然后由eth0網(wǎng)卡出去，網(wǎng)關(guān)地址是10.10.1.1，所以網(wǎng)絡(luò)包就從pod內(nèi)部傳送到了worker1的cni0網(wǎng)橋上。

cni0網(wǎng)橋會將mac地址為其自身mac地址的數(shù)據(jù)包轉(zhuǎn)發(fā)到主機的3層網(wǎng)絡(luò)中，而具體要怎么路由，則是需要看worker1主機上的路由規(guī)則。

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

這些節(jié)點上路由的配置是由flannel 在每個節(jié)點上啟動的flanneld進程去進行的配置的，配置信息來源是k8s集群內(nèi)部的etcd集群

我們發(fā)送的數(shù)據(jù)包目的ip是10.10.2.4 ，它會匹配上worker1主機的第二條路由信息，第二條路由信息是在說訪問10.10.0.0/24 網(wǎng)段的數(shù)據(jù)包都將由enp0s5網(wǎng)卡發(fā)出，并且網(wǎng)關(guān)地址也就是下一跳的ip地址是192.168.2.17，而192.168.2.17 就是worker2的ip地址。

為了看的更加清晰，我們再來回顧下開局的圖。

這樣數(shù)據(jù)包就到達到worker2節(jié)點了，到了worker2節(jié)點后，數(shù)據(jù)包的如何流動是看worker2節(jié)點上的路由規(guī)則，所以我們再來看下節(jié)點2上面的路由規(guī)則。記住數(shù)據(jù)包的目的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條路由規(guī)則，發(fā)往 10.10.2.0/24 的網(wǎng)段的數(shù)據(jù)包是要被cni0網(wǎng)橋處理的，所以數(shù)據(jù)包來到了worker2節(jié)點上的cni0網(wǎng)橋上，cni0是如何找到要發(fā)送的目的ip的veth端口的呢？

pod內(nèi)部的eth0 網(wǎng)卡其實就是個veth設(shè)備，veth設(shè)備一端連接在pod的網(wǎng)路命名空間中，一端連接在網(wǎng)橋上，從veth的一端發(fā)出去的網(wǎng)絡(luò)包一定能夠被另一端接收。

網(wǎng)橋收到主機發(fā)來的數(shù)據(jù)包后，首先看自身有沒有數(shù)據(jù)包的目的ip的端口記錄，如果有，那么就從該端口發(fā)送數(shù)據(jù)包，因為連接的veth設(shè)備，所以從端口發(fā)送出去后，一定能到達pod的內(nèi)部，veth設(shè)備就像是網(wǎng)線一樣。

如果沒有記錄，那么網(wǎng)橋會向通過arp協(xié)議廣播幀，得到回應(yīng)后便能知道端口與ip的映射關(guān)系。從而將數(shù)據(jù)包發(fā)往正確的端口。

這樣一個數(shù)據(jù)包就完全的從一臺主機通過路由規(guī)則到達到了另外一臺主機，而主機ip實際上是被當成網(wǎng)關(guān)，作為原ip地址的下一跳地址了。