k8s容器互聯flannel?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   <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鏡像啟動了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   <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節點上的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<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內部去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地址的下一跳地址了。

host-gw的優缺點

相比于vxlan模式，因為少了封包解包的操作，會提升數據傳輸的性能。但由于這是一個純3層轉發的方案，要想主機作為的網關的前提，必須是集群中的兩臺主機是一個二層連通的環境中。

以上就是關于“k8s容器互聯flannel host-gw的原理是什么”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。