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

• 配圖沒有很好地顯示這些網(wǎng)絡設備和協(xié)議棧之間的相對位置關系。

• 對于容器來說，network namespace是一個非常重要的隔離手段，這張圖沒有很好地展示出這個重要性。

• 文章沒有交代清楚一個重要的網(wǎng)絡包封裝節(jié)點：根據(jù)本機路由，cni0把從Pod a發(fā)過來的請求轉(zhuǎn)至flannel.1后，到底發(fā)生了什么?

• 配圖是為Flannel VXLAN模式準備的。我們知道為了效率，VXLAN模式下，所有的封裝和解封裝都是由VXLAN內(nèi)核模塊完成的。因為在內(nèi)核，看不見摸不著就比較抽象。本來K8s Overlay網(wǎng)絡模型就已經(jīng)挺復雜了，加上這個更加不利于我們學習理解。

編輯搜圖

圖 1：基于flannel實現(xiàn)的Overlay網(wǎng)絡模型設備關系圖

新視角

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

• 每個Pod都有自己的network namespace，因而有屬于它自己的routing table + iptables，這在圖中 1.1 ~ 1.3 以及 2.9 ~ 2.11 這兩條data path上能比較清晰地看得出來。你會看到在每個Node上都出現(xiàn)了若干個routing table + iptables，這很好解釋，因為這個Node上有多個network namespace。

• 為了強調(diào)容器本質(zhì)上也是一個進程，我將每個Pod里面的container特意畫到最上面的用戶態(tài)的位置。

• 可以在Link Layer這一層看到有若干種網(wǎng)絡設備：veth、bridge、eth0、tun。它們都是組成Overlay網(wǎng)絡模型不可或缺的關鍵設備。但無論它們所司何職，都必須要統(tǒng)一位于Link Layer。嗯，找準自己的位置很重要。

• 這張圖是為Flannel UDP模式準備的。通過將圖1中的VXLAN內(nèi)核模塊拆解成tun設備和flannel daemon，并將它們挪動到用戶態(tài)，我們可以非常清晰地看到進行數(shù)據(jù)封裝、解封的確切地點以及數(shù)據(jù)的流向。雖然因為效率問題，F(xiàn)lannel UDP模式已經(jīng)不具備工程價值，但對我們學習來說，卻是極好的。

編輯搜圖

圖 2：設備和協(xié)議棧關系圖

圖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中的容器發(fā)起請求開始，請求的對象是右圖 Pod b。也即src IP是10.244.0.2，dest IP是10.244.1.3。1.x 代表的是在Node 1上面，從容器內(nèi)產(chǎn)生網(wǎng)絡包到它離開網(wǎng)卡的完整流程。而相應地，2.x表示在Node X上，從網(wǎng)卡收到請求到這個請求最終送至Pod b中容器的完整流程。這張圖沒有畫出響應流程，故圖中箭頭都是單向的。其實把所有的箭頭反過來就是響應流程了。此去路途山路十八彎，客官坐好，我要發(fā)車了。

發(fā)生在Pod里的故事

1.2 這個位置routing table + iptables用來控制Pod內(nèi)容器的網(wǎng)絡路由。對于Pod a的容器而言，10.244.0.1扮演了網(wǎng)關的角色，而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    eth01.2.3.4.5.

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

完美轉(zhuǎn)場

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

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

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

編輯搜圖

圖 3：veth + bridge網(wǎng)絡包接收流程中，Bridge處理細節(jié)

反著來一遍

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

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