大家好，我是二哥。接著上篇《??multi-network ns在Underlay下的應用-本手篇??》，我們來聊聊基于 multiple network ns 的妙手級應用：Underlay 。上一篇包含 multi network ns 的基礎概念，建議沒有讀過的小伙伴先看一遍。畢竟高考作文題說了：對于初學者而言，應該從本手開始，本手的功夫扎實了，棋力才會提高。一些初學者熱衷于追求妙手，而忽視更為常用的本手。本手是基礎，妙手是創造。

1、從 multi-VM 到 multi-network ns

為了能顯示出 multi network ns 的重大作用，二哥想借另外一張圖來做個對比，讓小伙伴們看看從原先的 multi-VM 進化到 multi-network ns 是多么的必要。在圖 1 里，物理機器上創建了若干個 VM 。由 VMM 向 VM 虛擬出 CPU / Memory / Disk / 網卡等設備。每個 VM 的 OS 部分會創建一個 net_device ，它是一個數據結構，用來對這個VM所擁有的網卡進行軟件層次的抽象，盡管這個網卡本身也是虛擬的，但只要 VM 覺得它是一張實實在在的網卡，那就夠了。實際上這些網卡只是 tap 設備，它連接到物理機的 Open vSwitch 上，我們大致可以將 vSwitch 粗略地理解為一個 bridge 。

圖 1：multi-VM

熟悉 ECS 或者在阿里云/騰訊云上購買過云服務器的同學一定知道通常一臺 VM 上只會跑一個或極少量的應用（Workload），大部分情況下這個 VM 上的 CPU / Mem / Disk 等資源都是處于閑置狀態，更別提會使用多個 network ns 這種技術來隔離多個應用了。 無論是個人還是公司，大家的錢都不是天上掉下來的，降本增效是永恒的目標。一旦有更節省資源的方式出現，大家一定會趨之若鶩?；?multi namespace 的 Docker 的出現給云計算機市場所帶來的幾乎是顛覆性改變就很好地證明了這一點。圖 2：一個包含 multi network namespace 的環境

看過《蟻人2：黃蜂女現身》嗎？皮姆博士瞬間把整棟大樓縮小成了一個拉杠箱，是不是帥呆了？如果將 圖 1 中的 vSwitch 縮小到圖 2 中 bridge 大小，或者將其放置到 bridge 的位置，那么連接在 vSwitch 上的這些 VM 其實也就一下子縮小到了連接在 bridge 上的屬于多個 network ns 的 Pod 。也很帥，有沒有？以圖 2 為基礎：

• 加上 VTEP 就搭建了 Overlay 的基本盤
• 加上 flanneld 這樣的設施，搭配下面這樣的路由設置就改造成 host-gw 了一個 Work Node 上面運行有一個 bridge ，每個 bridge 組成一個子網。在所有 Work Node 的路由表上均添加一條記錄：通往一個子網（比如：10.244.1.0/24）的 “下一跳”為運行有該 bridge 的 Work Node 的 IP 地址。也就是說這臺 “主機”（Host）會充當通往這條容器通信路徑里的“網關”（Gateway）。Host-gateway 得名于此。

看起來好像挺不錯，將 Workload 所用資源從 VM 粒度縮小到 Pod 粒度所節省的資源確實非常的感人。按照二哥的經驗，對于一個像 Web server 這樣的 I/O 型的 Workload ，原先的 VM  粒度是 2 core + 4 GB Memory 的話，可以縮小到 0.5 core + 200 MB 這樣的 Pod 粒度（假設 Pod 里只有一個 container）。不過好像有哪里不太對勁：圖 2 中 bridge 是組成了一個子網，但看起來子網內每個 Pod 想要訪問子網外的資源，網絡流量就得從 root ns 走一圈。能不能既保留圖 2 這樣的細粒度資源虛擬化和分配方式，網絡流量又能像圖 1 的 VM 那樣大路朝天，各走各邊？

2、Underlay

群眾的呼聲就是容器云產商前進的動力。這不，以 AWS  ENI 為代表的，利用彈性網卡來實現的 Underlay 完美地解決了圖 2 的弊端。既然圖 2 所示弊端的根源在于所有的 Pod 共享了 VM 所擁有的這一張網卡，那能不能給圖 2 中每個 Pod 配備一張單獨的網卡呢？比如像圖 3 這樣，去掉 bridge ，人手一個網卡。豪橫的感覺出來了，有沒有？圖 3：拋掉 bridge ，給每個 Pod 裝上一個網卡示意圖

（1）新加網卡

這個想法看起來非常不錯，但前提是這臺 VM 上得有多余的網卡，另外還能把網卡插入到 Pod 中去。其實給一個 VM 添加一張新網卡這事，像 VMWare 公司的 vSphere 這樣的工具就可以方便地做到。比如在圖 4 里，二哥用鼠標點了幾下就手動給一臺 VM 添加了一個新的網卡。

圖 4：給 VM 手動添加一張新網卡

當然，我們也可以通過 API 的方式自動完成這樣的網卡創建工作。像 AWS / 阿里云都支持通過 API 的方式給 ECS 動態創建彈性網卡（ENI）。但一臺 ECS 所能綁定的 ENI 數量是有限制的，比如 AWS 上根據 ECS 實例的配置，最高可以綁定 15 個彈性網卡，阿里云也有類似的限制。彈性網卡是獨立的虛擬網卡，可以在多個云服務器之間遷移，實現業務的靈活擴展和遷移?？梢噪S ECS 實例創建并綁定彈性網卡，也可以單獨創建輔助彈性網卡再綁定到 ECS 實例上。彈性網卡具備以下功能特點：

• 除了隨 ECS 實例一起創建的主網卡外，一臺 ECS 實例支持綁定多個輔助網卡。這些輔助網卡和 ECS 實例必須屬于同一專有網絡VPC和同一可用區，可以分屬于不同虛擬交換機和不同安全組。
• 每個彈性網卡根據隨綁定的實例規格不同，可以分配相應的多個輔助私網IP地址。
• 將一個輔助彈性網卡從一個實例解綁，再重新綁定到另一個實例時，網卡的屬性不會發生變化，網絡流量將直接切換到新的實例。
• 彈性網卡支持熱插拔，可以在ECS實例之間自由遷移，切換彈性網卡綁定的實例時無需重啟實例，不影響實例上運行的業務。

（2）將新網卡插入到容器中

Um... NICE. 看起來新建網卡有門路了，那又該如何將其插入到 Pod 里面去呢？二哥以 Docker 來做個示意吧，將新建的一個名為 eth10 網卡插入到容器里面。首先啟動一個容器，假如這個容器的 PID 是 2022。

～# docker run -itd --net none ubuntu:16.04

在宿主機環境執行下面的命令，將 eth10 放到容器中，并重命名為 eth0 ，上電啟動再開啟 DHCP 。

~# mkdir /var/run/netns
~# ln -sf /proc/2022/ns/net /var/run/netns/2022
~# ip link set dev eth10 netns 2022
~# ip netns exec 2022 ip link set eth10 name eth0
~# ip netns exec 2022 ip link set eth0 up
~# ip netns exec 2022 dhclient eth0

一通猛如虎的操作后，宿主機上就再也看不到這個 eth10 了。而如果在容器內執行這條命令，你會發現它多了一個網卡。

～# ifconfig -a

其實準確地說，上面的操作是將 eth10 插入到容器的 network ns 中去的。一個 Pod 本質上是共享相同 network ns 的多個容器的集合，所以你可以想象得出將這些操作應用到 Pod 中發生了什么。

我們將圖 2 和圖 3 重新整理一下。圖 5 就是我們心心所念的，結合了圖 1 和圖 2 優勢的新方案：既保留圖 2 這樣的細粒度的資源虛擬化方式，網絡流量又能像圖 1 的 VM 那樣大路朝天，各向天涯。圖 5：支持 multi NIC 的 Underlay

（3）Performance

二哥在之前的文章中提到過，如以 VM 為 benchmark 來做對比的話，在傳輸性能方面：

• Overlay 模式的傳輸性能會有 20-30% 左右的下降。因為隧道帶來了解/封裝損耗，另外進出 Pod 的 traffic 要穿越兩次網絡棧（如圖 6 所示，進兩次，出也是兩次）。解/封裝的代價顯而易見，而兩次網絡棧的穿越所付出的代價卻很容易讓人忽略。圖 6 中用紅色標示出了 "iptables overhead"，意思是這部分是額外的工作量，言下之意是其實這部分工作量可以去掉。
• host-gw 模式大概有 10% 左右的性能損耗。原因是和 Overlay 模式一樣，主機間路由同樣會出現兩次穿越網絡棧的問題。

圖 6：進出 Pod 的 traffic 多次穿越網絡棧

那 Underlay 的性能損耗如何？它和 benchmark 相比，幾乎沒有任何性能損耗。原因也很容易找到：既沒有解/封裝，也不需要兩次網絡棧的穿越。我們再給大家附上一個性能測試對比報告，報告是阿里云團隊公布在他們的網站上的。報告鏈接 我放在這里，感興趣的同學可以自己去研究。

圖 7：performance 對比

3、總結

其實 K8s 的 Overlay / host-gw / Underlay 網絡模式的實現都離不開 multi network ns 。但 Underlay 對其利用得更干凈、更直觀、更高效，不過也更貴。周志明老師在《鳳凰架構》一書中說：對于真正的大型數據中心、大型系統，Underlay 模式才是最有發展潛力的網絡模式。這種方案能夠最大限度地利用硬件的能力，往往有著最優秀的性能表現。但也是由于它直接依賴于硬件與底層網絡環境，必須根據軟、硬件情況來進行部署，難以做到 Overlay 網絡那樣開箱即用的靈活性。大家看完這兩篇文章，不知道是否對周老師這番話有了更深刻的理解呢？對于《?multi-network ns在Underlay下的應用-本手篇?》文首所提的 3 個問題，你是不是有了答案呢？