大家好，我是二哥。在文章《??特洛伊木馬-圖解VXLAN容器網絡通信方案??》里，二哥畫了下面這張鳥瞰大圖。它把基于Flannel VXLAN模式實現的K8s Overlay網絡模型所需要的各類網路設備放在了一起，主要突出的是這些設備之間的數據流向。但那篇文章有些許缺點(凡爾賽一下)：

• 配圖沒有很好地顯示這些網絡設備和協議棧之間的相對位置關系。
• 對于容器來說，network namespace是一個非常重要的隔離手段，這張圖沒有很好地展示出這個重要性。
• 文章沒有交代清楚一個重要的網絡包封裝節點：根據本機路由，cni0把從Pod a發過來的請求轉至flannel.1后，到底發生了什么?
• 配圖是為Flannel VXLAN模式準備的。我們知道為了效率，VXLAN模式下，所有的封裝和解封裝都是由VXLAN內核模塊完成的。因為在內核，看不見摸不著就比較抽象。本來K8s Overlay網絡模型就已經挺復雜了，加上這個更加不利于我們學習理解。

圖 1：基于flannel實現的Overlay網絡模型設備關系圖

新視角

二哥真是一個貼心的人，我特地畫了下面這張圖。換了一個視角，它突出了幾個重要的方面：

• 每個Pod都有自己的network namespace，因而有屬于它自己的routing table + iptables，這在圖中 1.1 ~ 1.3 以及 2.9 ~ 2.11 這兩條data path上能比較清晰地看得出來。你會看到在每個Node上都出現了若干個routing table + iptables，這很好解釋，因為這個Node上有多個network namespace。
• 為了強調容器本質上也是一個進程，我將每個Pod里面的container特意畫到最上面的用戶態的位置。
• 可以在Link Layer這一層看到有若干種網絡設備：veth、bridge、eth0、tun。它們都是組成Overlay網絡模型不可或缺的關鍵設備。但無論它們所司何職，都必須要統一位于Link Layer。嗯，找準自己的位置很重要。
• 這張圖是為Flannel UDP模式準備的。通過將圖1中的VXLAN內核模塊拆解成tun設備和flannel daemon，并將它們挪動到用戶態，我們可以非常清晰地看到進行數據封裝、解封的確切地點以及數據的流向。雖然因為效率問題，Flannel UDP模式已經不具備工程價值，但對我們學習來說，卻是極好的。

圖 2：設備和協議棧關系圖

圖2中Pod a的IP是10.244.0.2，Pod b的IP是10.244.1.3。左圖中bridge cni0配有IP地址10.244.0.1，右圖中bridge的IP是10.244.1.1。一切都和圖1保持一樣，只是換了個視角。我們的故事從左圖 Pod a中的容器發起請求開始，請求的對象是右圖 Pod b。也即src IP是10.244.0.2，dest IP是10.244.1.3。1.x 代表的是在Node 1上面，從容器內產生網絡包到它離開網卡的完整流程。而相應地，2.x表示在Node X上，從網卡收到請求到這個請求最終送至Pod b中容器的完整流程。這張圖沒有畫出響應流程，故圖中箭頭都是單向的。其實把所有的箭頭反過來就是響應流程了。此去路途山路十八彎，客官坐好，我要發車了。

發生在Pod里的故事

1.2 這個位置routing table + iptables用來控制Pod內容器的網絡路由。對于Pod a的容器而言，10.244.0.1扮演了網關的角色，而10.244.0.1正是圖中 cni0 這個bridge。下面是 1.2 處的路由表。

# on container of Pod a
$ route -n
Destination  Gateway     Genmask             Flags Metric Ref Use   Iface
default      10.244.0.1  0.0.0.0             UG    0      0    0    eth0
10.244.0.0   0.0.0.0     255.255.255.0       U     0      0    0    eth0

有一個概念再次強調一遍：雖然 1.2 和 1.6 處有兩個分屬不同network namespace的路由表，但TCP/IP協議棧卻只有一份。也即對于協議棧而言，它只是在處理相同數據結構的不同數據實例罷了。

完美轉場

當網絡包沿著 1.4 流進bridge cni0后，藉由bridge的一個特殊功能，實現了網絡包從一個network namespace完美跳轉到另一個network namespace的神奇效果。

bridge即為網橋，它的行為類似二層交換機。如果網絡包的目的 MAC 地址為網橋本身，并且網橋設置了 IP 地址的話，那么bridge就認為該網絡包應該是發往創建該網橋的那臺主機。因而這個網絡包將不會被bridge轉發到任何設備，而是直接交給上層(三層)協議棧去處理。處理的過程會涉及到基于本機路由表的路由查詢。1.6 處的路由表開始發揮它的作用。因為目的IP是10.244.1.3，所以網絡包需要被送往tun設備flannel.1。

# on host machine Node 1
$ route -n
Destination  Gateway       Genmask           Flags Metric Ref   Use   Iface
default      17.168.0.1    0.0.0.0           UG    0      0     0     eth0
10.244.0.0   0.0.0.0       255.255.255.0     U     0      0     0     cni0
10.244.1.0   10.244.1.0    255.255.255.0     UG    0      0     0     flannel.1
17.168.0.3   17.168.0.3    255.255.255.255   UG    0      0     0     eth0

其實在 1.4 ~ 1.5 這里涉及到更多的有趣問題。比如網絡包在veth pair之間是如何流轉的?網絡包在bridge內部是如何處理的?但這并非本文的重點，以后二哥再聊。不過我先把圖3 放上來。老鐵們在我的文章《看圖寫話：聊聊veth數據流》見過這張圖，我在那篇文章的配圖基礎上加上了bridge的處理細節，后面有機會二哥會細聊這個地方。

圖 3：veth + bridge網絡包接收流程中，Bridge處理細節

反著來一遍

當Node X收到從Node 1發來的數據后，沿著 2.1 一路兜兜轉轉，繞繞彎彎來到 2.11 ，Pod b也就收到了Pod a發出的請求。你也看到了，除了箭頭方向不同外，圖2的左、右兩部分幾乎完全一樣。是的，實際上畫圖的時候，我就是粘貼、拷貝加批量改箭頭方向這樣搞的。

右圖中 2.6 和 2.10 位置處的路由表和iptables的作用和左圖相同，就不再贅述了。雖然路途比較艱辛，但總歸是完整到達了，本篇也就到此結束了