聊聊 Ulti-network Ns 在Underlay下的應(yīng)用-本手篇

作者：LanceZhang 2022-06-08 06:59:29

云計算

云原生 對容器而言，multiple namespace 這個技術(shù)的重要性怎么強調(diào)都不過分。因為 namespace 的出現(xiàn)，使得容器所用到的諸如 hostname、Network、Mount Points 等資源被隔離起來，由公用變成獨享。

10年積累的成都網(wǎng)站設(shè)計、網(wǎng)站制作經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先建設(shè)網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有東昌免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

大家好，我是二哥。

對容器而言，multiple namespace 這個技術(shù)的重要性怎么強調(diào)都不過分。因為 namespace 的出現(xiàn)，使得容器所用到的諸如 Hostname、Network、Mount Points 等資源被隔離起來，由公用變成獨享。

技術(shù)的進步是一把雙刃劍，基于 multi namespace 的容器在幾乎重塑了云計算市場的形態(tài)和云計算機基礎(chǔ)設(shè)施棧的同時，也給我們帶來了陡峭的學(xué)習曲線。

Network namespace 就是這樣一個例子。

今年全國新高考 Ⅰ 卷的作文題看了吧？“本手、妙手、俗手”是圍棋的三個術(shù)語。本手是指合乎棋理的正規(guī)下法；妙手是指出人意料的精妙下法；俗手是指貌似合理，而從全局看通常會受損的下法。對于初學(xué)者而言，應(yīng)該從本手開始，本手的功夫扎實了，棋力才會提高。一些初學(xué)者熱衷于追求妙手，而忽視更為常用的本手。本手是基礎(chǔ)，妙手是創(chuàng)造。一般來說，對本手理解深刻，才可能出現(xiàn)妙手；否則，難免下出俗手，水平也不易提升。

來吧，這篇讓我們從“本手”開始。下篇我們看“妙手”部分：將本文所聊內(nèi)容稍作變形看看 multi network namespace 在 Underlay 下面是如何玩的。

multi network namespace

我們先就著下圖來看看 multi network namespace 的典型使用方式。后文統(tǒng)一將 network namespace 寫成 network ns 。

圖 1：一個包含 multi network ns 的環(huán)境

這是一個包含 multi network ns 的環(huán)境。分為三大部分：最上層為 OS ，中間是一個網(wǎng)卡（物理的或者虛擬的），最下面是網(wǎng)卡所連接的外部（物理）網(wǎng)絡(luò)。

OS 部分包含了 root network ns 以及被 Pod 使用的其它 network ns 。

OS 部分還包含了 eth 和 bridge 這樣的網(wǎng)絡(luò)設(shè)備（struct net_device）。雖然圖中不同的 network ns 中的 eth 都叫 eth0 ，但 root network ns 中的 eth0 和其它網(wǎng)絡(luò)設(shè)備有著本質(zhì)的區(qū)別：

• root network ns 中的 eth0 是對網(wǎng)卡的軟件抽象，也就是說它對應(yīng)的是一個外部設(shè)備，如果這個網(wǎng)卡是物理的話，eth0 還包含控制該設(shè)備的一系列函數(shù)。
• 而圖中其它的 eth0 和 bridge 都是對根本不存在的虛擬網(wǎng)絡(luò)設(shè)備的抽象，說白了它們就只是一些不會與外部設(shè)備打交道的數(shù)據(jù)結(jié)構(gòu)，這些數(shù)據(jù)結(jié)構(gòu)存在的意義是為了可以最大程度上復(fù)用現(xiàn)有的代碼邏輯和功能。它們可以作為媒介用來在同一個 OS 內(nèi)進行進程間通信、用戶態(tài)和內(nèi)核態(tài)數(shù)據(jù)交換，但無法被用于外部通信。比如我們熟知的 loopback 設(shè)備，通過它可以使本機上兩個進程間的 socket 通信完整地走完 TCP/IP 協(xié)議棧。

network namespace

我們說 network ns 用來隔離包括網(wǎng)卡（Network Interface）、回環(huán)設(shè)備（Loopback Device）、網(wǎng)絡(luò)棧、IP 地址、端口等等在內(nèi)的網(wǎng)絡(luò)資源。它的特點是由可配置的數(shù)據(jù)組成。對于一個進程來說，這些要素，其實就構(gòu)成了它發(fā)起和響應(yīng)網(wǎng)絡(luò)請求的基本環(huán)境。這里所謂“網(wǎng)絡(luò)棧（Networking stack）”，包括了：路由表（Routing Table）， network filter，iptables 規(guī)則等。

無論是一個 Linux 容器還是宿主機的進程所能看見的“網(wǎng)絡(luò)?！?，實際上是被隔離在它們各自的 network ns 當中的，通信雙方的網(wǎng)卡（如典型的 veth pair ）也自然被隔離到相應(yīng)的 namespace 中。

另外還有一個棧也會被經(jīng)常提起：TCP/IP 協(xié)議棧。我們可以將 TCP/IP 協(xié)議?？闯墒浅绦虻拇a部分，而網(wǎng)絡(luò)?？闯墒浅绦虻臄?shù)據(jù)部分。很顯然 TCP/IP 棧應(yīng)該是被這個 OS 上所有人共享的，無論是進程還是容器，甚至是基于 qemu-kvm 的虛擬機都共享著宿主機的協(xié)議棧，但網(wǎng)絡(luò)棧卻是各個 network ns 獨享的。

二哥知道，上面的描述還是太抽象。所以我畫了下面一張圖。圖 2 把內(nèi)核中負責描述進程的數(shù)據(jù)結(jié)構(gòu) task_struct 和 network ns 之間的結(jié)構(gòu)關(guān)系畫出來了。進程 1 和進程 2 共享宿主機 root network ns，它包含網(wǎng)卡 eth0 。Pod 內(nèi)的容器自然位于 Pod 自己的 network ns 中。但容器本質(zhì)上也是進程而已，雖然在圖中看起來 Pod 隔離了一個完全屬于自己的 eth1，但在內(nèi)核看來，一樣也是用相同的數(shù)據(jù)結(jié)構(gòu)來描述它和 network ns 之間的關(guān)系。

看完這個數(shù)據(jù)結(jié)構(gòu)示意圖，對于 TCP/IP 協(xié)議棧而言，希望下面兩點描述沒有讓你感到困惑：

• 網(wǎng)絡(luò)包無論是從容器內(nèi)的網(wǎng)卡流出，還是離開容器后再與其它網(wǎng)絡(luò)設(shè)備打交道，必然都會經(jīng)過內(nèi)核 TCP/IP 協(xié)議棧。
• 無論網(wǎng)絡(luò)包是屬于容器的還是屬于宿主機 native process 的，對于內(nèi)核 TCP/IP 協(xié)議棧而言，這些網(wǎng)絡(luò)包只是屬于不同的 network ns 而已。

圖 2：network ns與task_struct結(jié)構(gòu)關(guān)系圖

網(wǎng)絡(luò)設(shè)備

你一定看到了圖 1 的 OS 部分包含網(wǎng)絡(luò)設(shè)備 eth0 和 bridge。

其中 eth0 用來描述物理網(wǎng)卡，它在內(nèi)核中用數(shù)據(jù)結(jié)構(gòu) net_device 來表示。一個 net_device 里面都包含些什么呢？我將其中一些重要的部分畫在了圖 3 里面。簡單來說就是包含了用來操作這個物理網(wǎng)卡的 netdev_ops （如 set _mac / ioctl 之類），與 BSP 相關(guān)的諸如總線地址、IRQ等設(shè)置，與具體網(wǎng)卡型號相關(guān)的收/發(fā)環(huán)形隊列，還有 IP 地址設(shè)置等等。

因為 eth0 是屬于一個 network ns 的，這就意味著如果有多個 network ns ，就可能會出現(xiàn)多個 eth0（如果都重命名為 eth0 的話）。

圖 3：net_device 所含部分內(nèi)容示意圖

bridge 又名網(wǎng)橋，是一個虛擬的二層交互機。用它來搭配虛擬網(wǎng)絡(luò)設(shè)備 veth / tap 可以模擬物理交換機以及插入其上的 RJ-45 網(wǎng)絡(luò)插頭。

在圖 4 所示的這個環(huán)境里，一個網(wǎng)橋可以組成一個簡單子局域網(wǎng)，插在網(wǎng)橋上的設(shè)備之間可以如物理局域網(wǎng)絡(luò)那樣相互通過二層交流。這樣的交流不需要離開 bridge ，這通常發(fā)生在位于同一個 Work Node 上面的不同 Pod 之間相互通信的場景。

圖 4：veth + bridge 所組成的子局域網(wǎng)

而如果網(wǎng)絡(luò)包的目的 MAC 地址為網(wǎng)橋本身，并且網(wǎng)橋設(shè)置了 IP 地址的話，那么 bridge 就認為該網(wǎng)絡(luò)包應(yīng)該是發(fā)往創(chuàng)建該網(wǎng)橋的那臺主機，于是這個數(shù)據(jù)包將不會轉(zhuǎn)發(fā)到任何設(shè)備，而是直接交給上層（三層）協(xié)議棧去處理。處理的過程會涉及到基于本機路由表的路由查詢。

上述過程可以結(jié)合圖 5 來理解。例如當 Pod 想要訪問百度的時候，請求就會沿著圖中紅色的線流動。如果我們將紅線看成一個管道的話，那么 Pod 的請求從管道一端流入。而管道的流出端接進了宿主機協(xié)議棧的 IP 層。在這里經(jīng)過 iptables 和路由表的處理后，最終通過宿主機的 eth0 離開這臺機器。

這種情況下，如果我說宿主機的 eth0 可以看成 bridge 的 gateway，你同意嗎？

如果你對這個細節(jié)感興趣的話，可以閱讀《當從Pod訪問百度時會用到VTEP嗎》。

圖 5：bridge 將 traffic 交由宿主機三層處理

讓我們把圖 5 再放大一些。把圖 5 中 network ns 里的路由表、 iptables 、eth0 、bridge 拎出來看看?？纯串?bridge 處理 Pod 訪問百度的請求時，是如何把流量先送進 root network ns 又是如何以宿主機為 gateway 將流量送至外部網(wǎng)絡(luò)的。

圖 6：bridge 處理數(shù)據(jù)流放大示意圖

新聞名稱：聊聊 Ulti-Network Ns 在Underlay下的應(yīng)用-本手篇
本文路徑：http://www.dlmjj.cn/article/dpejpds.html