7 張圖帶你搞懂 Kubernetes Flannel 高效能網路外掛的兩種常用工作模式

VXLAN使用VTEP（VXLAN Tunnel Endpoint）來進行封包和解包，它是VXLAN隧道的起點或終點：

• 在傳送端，源VTEP將原始報文封裝成VXLAN報文，通過UDP傳送到對端VTEP。

• 在接收端，VTEP將解開VXLAN報文，將原始的2層資料幀轉發給目的的接收方。

VTEP可以是獨立的網路裝置，例如交換機，也可以是部署在伺服器上的虛擬裝置。例如使用置頂交換機（TOR）作為VTEP時，VXLAN的網路模型如下圖：

大致概括一下整個過程：

• 傳送端：在PodA中發起 ping 10.244.1.21 ，ICMP 報文經過 cni0 網橋後交由 flannel.1 裝置處理。flannel.1 裝置是一個VXLAN型別的裝置，負責VXLAN封包解包。因此，在傳送端，flannel.1 將原始L2報文封裝成VXLAN UDP報文，然後從 eth0 傳送。

• 接收端：Node2收到UDP報文，發現是一個VXLAN型別報文，交由 flannel.1 進行解包。根據解包後得到的原始報文中的目的IP，將原始報文經由 cni0 網橋傳送給PodB。

哪些IP要交由 flannel.1 處理

flanneld 從 etcd 中可以獲取所有節點的子網情況，以此為依據為各節點配置路由，將屬於非本節點的子網IP都路由到 flannel.1 處理，本節點的子網路由到 cni0 網橋處理。

[[email protected] ~]# ip r
...
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1 # Node1子網為10.224.0.0/24， 本機PodIP都交由cni0處理
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink # Node2子網為10.224.1.0/24，Node2的PodID都交由flannel.1處理
...

如果節點資訊有變化， flanneld 也會同步的對路由資訊做修改。

flannel.1 的封包過程

VXLAN的封包是將 二層乙太網幀 封裝到 四層UDP報文 中的過程。

原始L2幀

要生成原始的L2幀， flannel.1 需要得知：

• 內層源/目的IP地址

• 內層源/目的MAC地址

內層的源/目的IP地址是已知的，即為PodA/PodB的PodIP，在圖例中，分別為 10.224.0.20 和 10.224.1.20 。內層源/目的MAC地址要結合路由表和ARP表來獲取。根據路由表①得知：

• 下一跳地址是10.224.1.0，關聯ARP表②，得到下一跳的MAC地址，也就是目的MAC地址：Node2_flannel.1_MAC；

• 報文要從 flannel.1 虛擬網絡卡發出，因此源MAC地址為 flannel.1 的MAC地址。

要注意的是，這裡ARP表的表項②並不是通過ARP學習得到的，而是 flanneld 預先為每個節點設定好的，由 flanneld負責維護，沒有過期時間。

# 檢視ARP表
[[email protected] ~]# ip n | grep flannel.1
10.244.1.0 dev flannel.1 lladdr ba:74:f9:db:69:c1 PERMANENT # PERMANENT 表示永不過期

有了上面的資訊， flannel.1 就可以構造出內層的2層乙太網幀：

外層VXLAN UDP報文

要將原始L2幀封裝成VXLAN UDP報文， flannel.1 還需要填充源/目的IP地址。前面提到，VTEP是VXLAN隧道的起點或終點。因此，目的IP地址即為對端VTEP的IP地址，通過FDB表獲取。在FDB表③中，dst欄位表示的即為VXLAN隧道目的端點（對端VTEP）的IP地址，也就是VXLAN DUP報文的目的IP地址。FDB表也是由 flanneld 在每個節點上預設並負責維護的。

可以使用 bridge fdb show 檢視FDB表：

[root[email protected] ~]# bridge fdb show | grep flannel.1
ba:74:f9:db:69:c1 dev flannel.1 dst 192.168.50.3 self permanent

源IP地址資訊來自於 flannel.1 網絡卡設定本身，根據 local 192.168.50.2 可以得知源IP地址為192.168.50.2。

[[email protected] ~]# ip -d a show flannel.1
6: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default
    link/ether 32:02:78:2f:02:cb brd ff:ff:ff:ff:ff:ff promiscuity 0
    vxlan id 1 local 192.168.50.2 dev eth0 srcport 0 0 dstport 8472 nolearning ageing 300 noudpcsum noudp6zerocsumtx noudp6zerocsumrx numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
    inet 10.244.0.0/32 brd 10.244.0.0 scope global flannel.1
       valid_lft forever preferred_lft forever
    inet6 fe80::3002:78ff:fe2f:2cb/64 scope link
       valid_lft forever preferred_lft forever

至此， flannel.1 已經得到了所有完成VXLAN封包所需的資訊，最終通過 eth0 傳送一個VXLAN UDP報文：

在上述的VXLAN的示例中，Node1和Node2其實是同一宿主機中的兩臺使用橋接模式的虛機，也就是說它們在一個二層網路中。在二層網路互通的情況下，直接配置節點的三層路由即可互通，不需要使用VXLAN隧道。要使用host-gw模式，需要修改 ConfigMap kube-flannel-cfg ，將 Backend.Type 從vxlan改為host-gw，然後重啟所有kube-flannel Pod即可：

...
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "host-gw" // <- 改成host-gw
      }
    }
 ...

host-gw模式下的通訊過程如下圖所示：

在host-gw模式下，由於不涉及VXLAN的封包解包，不再需要flannel.1虛機網絡卡。flanneld 負責為各節點設定路由 ，將對應節點Pod子網的下一跳地址指向對應的節點的IP，如圖中路由表①所示。

[[email protected] ~]# ip r
...
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1
10.244.1.0/24 via 192.168.50.3 dev eth0 # Node2子網的下一跳地址指向Node2的public ip。
...

由於沒有封包解包帶來的消耗，host-gw是效能最好的。不過一般在雲環境下，都不支援使用host-gw的模式，在私有化部署的場景下，可以考慮。

    參考：

• What is VXLAN

• 深入理解CNI

• bridge man page

• ip-route man page

• ip-neighbour man page

• flannel原理之vxlan模式