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

容器系列文章

容器系列視頻

簡析host-gw

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

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

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

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

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

集群基本信息

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

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

集群節(jié)點(diǎn)信息

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   <none>        Ubuntu 22.04 LTS   5.15.0-58-generic   docker://20.10.12
worker1   Ready    <none>                 13d   v1.23.3   192.168.2.16   <none>        Ubuntu 22.04 LTS   5.15.0-60-generic   docker://20.10.12
worker2   Ready    <none>                 13d   v1.23.3   192.168.2.15   <none>        Ubuntu 22.04 LTS   5.15.0-60-generic   docker://20.10.12

然后用busybox鏡像啟動(dòng)了4個(gè)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   <none>           <none>
busybox-8647b8666c-pg7ps   1/1     Running   0          21m   10.10.2.4   worker2   <none>           <none>
busybox-8647b8666c-sgf8v   1/1     Running   0          21m   10.10.1.5   worker1   <none>           <none>
busybox-8647b8666c-zlxmm   1/1     Running   0          21m   10.10.2.3   worker2   <none>           <none>

我們的目的就是看看worker1節(jié)點(diǎn)上的ip為10.10.1.6 的pod 是如何ping通 worker2節(jié)點(diǎn)上的ip為 10.10.2.4 的pod的。

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

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

先從10.10.1.6的pod看起，進(jìn)入10.10.1.6的pod查看路由信息。

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

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

可以查到worker1節(jié)點(diǎn)上cni0的ip地址

parallels@worker1:~$ ifconfig
cni0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  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é)點(diǎn)的pod ip 10.10.2.4 會(huì)匹配上第二條路由信息，然后由eth0網(wǎng)卡出去，網(wǎng)關(guān)地址是10.10.1.1，所以網(wǎng)絡(luò)包就從pod內(nèi)部傳送到了worker1的cni0網(wǎng)橋上。

cni0網(wǎng)橋會(huì)將mac地址為其自身mac地址的數(shù)據(jù)包轉(zhuǎn)發(fā)到主機(jī)的3層網(wǎng)絡(luò)中，而具體要怎么路由，則是需要看worker1主機(jī)上的路由規(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é)點(diǎn)上路由的配置是由flannel 在每個(gè)節(jié)點(diǎn)上啟動(dòng)的flanneld進(jìn)程去進(jìn)行的配置的，配置信息來源是k8s集群內(nèi)部的etcd集群

我們發(fā)送的數(shù)據(jù)包目的ip是10.10.2.4 ，它會(huì)匹配上worker1主機(jī)的第二條路由信息，第二條路由信息是在說訪問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ù)包就到達(dá)到worker2節(jié)點(diǎn)了，到了worker2節(jié)點(diǎn)后，數(shù)據(jù)包的如何流動(dòng)是看worker2節(jié)點(diǎn)上的路由規(guī)則，所以我們再來看下節(jié)點(diǎn)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é)點(diǎn)上的cni0網(wǎng)橋上，cni0是如何找到要發(fā)送的目的ip的veth端口的呢？

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

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

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

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

host-gw的優(yōu)缺點(diǎn)

相比于vxlan模式，因?yàn)樯倭朔獍獍牟僮?，?huì)提升數(shù)據(jù)傳輸?shù)男阅?。但由于這是一個(gè)純3層轉(zhuǎn)發(fā)的方案，要想主機(jī)作為的網(wǎng)關(guān)的前提，必須是集群中的兩臺(tái)主機(jī)是一個(gè)二層連通的環(huán)境中。

以上就是k8s容器互聯(lián)-flannel host-gw原理篇的詳細(xì)內(nèi)容，更多關(guān)于k8s容器互聯(lián)flannel host-gw的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論