簡介：本文需要讀者熟悉 Ethernet（以太網）的基本原理和 Linux 系統的基本網絡命令，以及 TCP/IP 協議族并了解傳統的網絡模型和協議包的流轉原理。文中涉及到 Linux 內核的具體實現時，均以內核 v4.19.215 版本為準。

作者 | 淺奕
來源 | 阿里技術公眾號

本文需要讀者熟悉 Ethernet（以太網）的基本原理和 Linux 系統的基本網絡命令，以及 TCP/IP 協議族并了解傳統的網絡模型和協議包的流轉原理。文中涉及到 Linux 內核的具體實現時，均以內核 v4.19.215 版本為準。

一 內核網絡包接收流程

1 從網卡到內核協議棧

如圖[1]，網絡包到達 NC（Network Computer，本文指物理機）時，由 NIC（Network Interface Controller，網絡接口控制器，俗稱網卡）設備處理，NIC 以中斷的方式向內核傳遞消息。Linux 內核的中斷處理分為上半部（Top Half）和下半部（Bottom Half）。上半部需要盡快處理掉和硬件相關的工作并返回，下半部由上半部激活來處理后續比較耗時的工作。

具體到 NIC 的處理流程如下：當 NIC 收到數據時，會以 DMA 方式將數據拷貝到 Ring Buffer (接收隊列) 里描述符指向的映射內存區域，拷貝完成后會觸發中斷通知 CPU 進行處理。這里可以使用 ethtool -g {設備名，如eth0} 命令查看 RX/TX （接收/發送）隊列的大小。CPU 識別到中斷后跳轉到 NIC 的中斷處理函數開始執行。此時要區分 NIC 的工作模式，在早先的非 NAPI（New API）[2]模式下，中斷上半部更新相關的寄存器信息，查看接收隊列并分配 sk_buff 結構指向接收到的數據，最后調用 netif_rx() 把 sk_buff 遞交給內核處理。在 netif_rx() 的函數的流程中，這個分配的 sk_buff 結構被放入 input_pkt_queue隊列后，會把一個虛擬設備加入poll_list 輪詢隊列并觸發軟中斷 NET_RX_SOFTIRQ 激活中斷下半部。此時中斷上半部就結束了，詳細的處理流程可以參見 net/core/dev.c 的 netif_rx() -> netif_rx_internal() -> enqueue_to_backlog() 過程。下半部 NET_RX_SOFTIRQ 軟中斷對應的處理函數是 net_rx_action()，這個函數會調用設備注冊的 poll() 函數進行處理。非 NAPI 的情況下這個虛擬設備的 poll() 函數固定指向 process_backlog() 函數。這個函數將 sk_buff 從 input_pkt_queue 移動到 process_queue 中，調用 __netif_receive_skb() 函數將其投遞給協議棧，最后協議棧相關代碼會根據協議類型調用相應的接口進行后續的處理。特別地，這里的 enqueue_to_backlog() 以及 process_backlog() 函數也用于和啟用了 RPS 機制后的相關邏輯。

非 NAPI（New API）模式下每個網絡包的到達都會觸發一次中斷處理流程，這么做降低了整體的處理能力，已經過時了。現在大多數 NIC 都支持 NAPI 模式了。NAPI 模式下在首包觸發 NIC 中斷后，設備就會被加入輪詢隊列進行輪詢操作以提升效率，輪詢過程中不會產生新的中斷。為了支持 NAPI，每個 CPU 維護了一個叫 softnet_data 的結構，其中有一個 poll_list 字段放置所有的輪詢設備。此時中斷上半部很簡單，只需要更新 NIC 相關的寄存器信息，以及把設備加入poll_list 輪詢隊列并觸發軟中斷 NET_RX_SOFTIRQ就結束了。中斷下半部的處理依舊是 net_rx_action() 來調用設備驅動提供的 poll() 函數。只是 poll() 此時指向的就是設備驅動提供的輪詢處理函數了（而不是非 NAPI 模式下的內核函數 process_backlog()）。這個設備驅動提供的輪詢 poll() 函數最后也會調用 __netif_receive_skb() 函數把 sk_buff 提交給協議棧處理。

非 NAPI 模式和 NAPI 模式下的流程對比如下（其中灰色底色是設備驅動要實現的，其他都是內核自身的實現）：

關于 NAPI 模式網絡設備驅動的實現以及詳細的 NAPI 模式的處理流程，這里提供一篇文章和其譯文作為參考[3]（強烈推薦）。這篇文章很詳細的描述了 Intel Ethernet Controller I350 這個 NIC 設備的收包和處理細節（其姊妹篇發包處理過程和譯文[4]）。另外收包這里還涉及到多網卡的 Bonding 模式（可以在/proc/net/bonding/bond0 里查看模式）、網絡多隊列（sudo lspci -vvv 查看 Ethernet controller 的 Capabilities信息里有 MSI-X: Enable+ Count=10 字樣說明 NIC 支持，可以在 /proc/interrupts 里查看中斷綁定情況）等機制。這些本文都不再贅述，有興趣的話請參閱相關資料[5]。

2 內核協議棧網絡包處理流程

前文說到 NIC 收到網絡包構造出的 sk_buff 結構最終被 __netif_receive_skb() 提交給了內核協議棧解析處理。這個函數首先進行 RPS[5] 相關的處理，數據包會繼續在隊列里轉一圈（一般開啟了 RSS 的網卡不需要開啟 RPS）。如果需要分發包到其他 CPU 去處理，則會使用 enqueue_to_backlog() 投遞給其他 CPU 的隊列，并在 process_backlog()) 中觸發 IPI（Inter-Processor Interrupt，處理器間中斷，于 APIC 總線上傳輸，并不通過 IRQ）給其他 CPU 發送通知（net_rps_send_ipi()函數）。

最終，數據包會由 __netif_receive_skb_core() 進行下一階段的處理。這個處理函數主要的功能有：

• 處理ptype_all 上所有的 packet_type->func()，典型場景是 tcpdump 等工具的抓包回調（paket_type.type 為 ETH_P_ALL，libcap 使用 AF_PACKET Address Family）
• 處理 VLAN（Virtual Local Area Network，虛擬局域網）報文 vlan_do_receive() 以及處理網橋的相關邏輯（skb->dev->rx_handler() 指向了 br_handle_frame()）
• 處理 ptype_base上所有的 packet_type->func() , 將數據包傳遞給上層協議層處理，例如指向 IP 層的回調 ip_rcv() 函數

截至目前，數據包仍舊在數據鏈路層的處理流程中。這里復習下 OSI 七層模型與 TCP/IP 五層模型：

在網絡分層模型里，后一層即為前一層的數據部分，稱之為載荷（Payload）。一個完整的 TCP/IP 應用層數據包的格式如下[6]：

__netif_receive_skb_core() 的處理邏輯中需要關注的是網橋和接下來 IP 層以及 TCP/UDP 層的處理。首先看 IP 層，__netif_receive_skb_core() 調用 deliver_skb()，后者調用具體協議的 .func() 接口。對于 IP 協議，這里指向的是 ip_rcv() 函數。這個函數做了一些統計和檢查之后，就把包轉給了 Netfilter [7]框架并指定了函數 ip_rcv_finish() 進行后續的處理（如果包沒被 Netfilter 丟棄）。經過路由子系統檢查處理后，如果包是屬于本機的，那么會調用 ip_local_deliver() 將數據包繼續往上層協議轉發。這個函數類似之前的邏輯，依舊是呈遞給 Netfilter 框架并指定函數 ip_local_deliver_finish() 進行后續的處理，這個函數最終會檢查和選擇對應的上層協議接口進行處理。

常見的上層協議比如 TCP 或者 UDP 協議的流程不在本文討論的范圍內，僅 TCP 的流程所需要的篇幅足以超過本文所有的內容。這里給出 TCP 協議（v4）的入口函數 tcp_v4_rcv() 以及 UDP 協議的入口函數 udp_rcv() 作為指引自行研究，也可以閱讀其他的資料進行進一步的了解[9]。

3 Netfilter/iptables 與 NAT（網絡地址轉換）

關于 Netfilter 框架需要稍微著重的強調一下，因為后文要提到的網絡策略和很多服務透出的實現都要使用 Netfilter 提供的機制。

Netfilter 是內核的包過濾框架（Packet Filtering Framework）的實現。簡單說就是在協議棧的各個層次的包處理函數中內置了很多的 Hook 點來支持在這些點注冊回調函數。

圖片來自 Wikimedia，可以點開參考文獻[8]查看大圖（svg 矢量圖，可以調大網頁顯示百分比繼續放大）。

Linux 上最常用的防火墻 iptables 即是基于 Netfilter 來實現的（nftables 是新一代的防火墻）。iptables 基于表和鏈（Tables and Chains）的概念來組織規則。注意這里不要被“防火墻”這個詞誤導了，iptables 所能做的不僅僅是對包的過濾（Filter Table），還支持對包進行網絡地址轉換（NAT Table）以及修改包的字段（Mangle Table）。在網絡虛擬化里，用的最多的便是 NAT 地址轉換功能。通常此類功能一般在網關網絡設備或是負載均衡設備中很常見。當 NC 需要在內部進行網絡相關的虛擬化時，也是一個類似網關以及負載均衡設備了。

在設置 iptables 的 NAT 規則前，還需要打開內核的包轉發功能 echo "1" > /proc/sys/net/ipv4/ip_forward 才可以。另外建議也打開 echo "1" /proc/sys/net/bridge/bridge-nf-call-iptables 開關（可能需要 modprobe br_netfilter）。bridge-nf-call-iptables 從上面的源碼分析就能理解，網橋的轉發處理是在 Netfilter 規則之前的。所以默認情況下二層網橋的轉發是不會受到三層 iptables 的限制的，但是很多虛擬化網絡的實現需要 Netfilter 規則生效，所以內核也支持了讓網橋的轉發邏輯也調用一下 Netfilter 的規則。這個特性默認情況不開啟，所以需要檢查開關。至于具體的 iptables 命令，可以參考這篇文章和其譯文[10]進行了解，本文不再討論。

這里強調下，Netfilter 的邏輯運行在內核軟中斷上下文里。如果 Netfilter 添加了很多規則，必然會造成一定的 CPU 開銷。下文在提到虛擬化網絡的性能降低時，很大一部分開銷便是源自這里。

二 虛擬網絡設備

在傳統的網絡認知里，網絡就是由帶有一個或多個 NIC 的一組 NC 使用硬件介質和 switch（交換機）、Router（路由器）所組成的一個通信集合（圖片來自 [11]，下同）:

網絡虛擬化作為 SDN（Software?Defined?Network，軟件定義網絡）的一種實現，無非就是虛擬出 vNIC（虛擬網卡）、vSwitch（虛擬交換機）、vRouter（虛擬路由器）等設備，配置相應的數據包流轉規則而已。其對外的接口必然也是符合其所在的物理網絡協議規范的，比如 Ethernet 和 TCP/IP 協議族。

隨著 Linux 網絡虛擬化技術的演進，有了若干種虛擬化網絡設備，在虛擬機和虛擬容器網絡中得到了廣泛的應用。典型的有 Tap/Tun/Veth、Bridge 等：

• Tap/Tun 是 Linux 內核實現的一對虛擬網絡設備，Tap/Tun 分別工作在二層/三層。Linux 內核通過 Tap/Tun 設備和綁定該設備的用戶空間之間交換數據。基于 Tap 驅動即可實現虛擬機 vNIC 的功能，Tun 設備做一些其他的轉發功能。
• Veth 設備總是成對創建（Veth Pair），一個設備收到內核發送的數據后，會發送到另一個設備上去，可以把 Veth Pair 可以想象成一對用網線連接起來的 vNIC 設備。
• Bridge 是工作在二層的虛擬網橋。這是虛擬設備，雖然叫網橋，但其實類似 vSwitch 的設計。當 Bridge 配合 Veth 設備使用時，可以將 Veth 設備的一端綁定到一個Bridge 上，相當于真實環境把一個 NIC 接入一個交換機里。

虛擬機和容器的網絡在傳輸流程上有些區別，前者比如 KVM 一般是使用 Tap 設備將虛擬機的 vNIC 和宿主機的網橋 Bridge 連接起來。而容器的 Bridge 網絡模式是將不同 Namespace 里的 Veth Pair 連接網橋 Bridge 來實現通信（其他方式下文討論）。

Linux Bridge 配合橋接或者 NAT 模式很容易可以實現同主機或跨主機的虛擬機/容器之間通信，而且 Bridge 本身也支持 VLAN 的配置，可以實現一些三層交換機的能力。但是很多廠商都在研發功能更豐富的虛擬交換機，流行的有 Cisco Nexus 1000V、 VMware Virtual Switch 以及廣泛使用的開源的 Open vSwitch[12] 等。利用 vSwitch，可以構建出支持更多封裝協議、更高級的虛擬網絡：

1 Linux Bridge + Veth Pair 轉發

VRF（Virtual Routing and Forwarding，虛擬路由轉發）在網絡領域中是個很常見的術語。上世紀九十年代開始，很多二層交換機上就能創建出 4K 的 VLAN 廣播域了。4K 是因為 VLAN 標簽的格式遵循 802.1q 標準，其中定義的 VLAN ID 是 12 位的緣故（802.1q in 802.1q 可以做到 4094*4094 個，0 和 4095 保留）。如今 VRF 概念被引入三層，單個物理設備上也可以有多個虛擬路由/轉發實例了。Linux 的 VRF 實現了對三層的網絡協議棧的虛擬，而 Network Namespace（以下簡稱 netns）虛擬了整個網絡棧。一個 netns 的網絡棧包括：網卡（Network Interface）、回環設備（Loopback Device）、路由表（Routing Table）和 iptables 規則。本文使用 netns 進行演示（畢竟在討論容器），下文使用 ip[14] 命令創建和管理 netns 以及 Veth Pair 設備。

創建、查看、刪除 Network Namespace

# 創建名為 qianyi-test-1 和 add qianyi-test-2 的命名 netns，可以在 /var/run/netns/ 下查看 ip netns add qianyi-test-1 ip netns add qianyi-test-2# 查看所有的 Network Namespace ip netns list# 刪除 Network Namespace ip netns del qianyi-test-1 ip netns del qianyi-test-2

執行結果如圖（刪除先不執行）：

有興趣的話可以使用 strace 命令跟蹤這個創建過程看看 ip 命令是怎么創建的（strace ip netns add qianyi-test-1）。

在 netns 中執行命令

# 在 qianyi-test-1 這個 netns 中執行 ip addr 命令（甚至可以直接執行 bash 命令得到一個 shell） # nsenter 這個命令也很好用，可以 man nsenter 了解 ip netns exec qianyi-test-1 ip addr

執行結果如下：

圖片

這個新創建的 netns 里一貧如洗，只有一個孤獨的 lo 網卡，還是 DOWN 狀態的。下面開啟它：

開啟 lo 網卡，這個很重要

ip netns exec qianyi-test-1 ip link set dev lo up
ip netns exec qianyi-test-2 ip link set dev lo up

狀態變成了 UNKOWN，這是正常的。這個狀態是驅動提供的，但是 lo 的驅動沒有做這個事情。

創建 Veth Pair 設備

# 分別創建 2 對名為 veth-1-a/veth-1-b 和 veth-2-a/veth-2-b 的 Veth Pair 設備 ip link add veth-1-a type veth peer name veth-1-b ip link add veth-2-a type veth peer name veth-2-b

使用 ip addr 命令可以查看：

8-9，10-11 便是上面創建出來的 2 對 Veth Pair 設備，此時它們都沒有分配 IP 地址且是 DOWN 狀態。

將 Veth Pair 設備加入 netns

# 將 veth-1-a 設備加入 qianyi-test-1 這個 netns ip link set veth-1-a netns qianyi-test-1# 將 veth-1-b 設備加入 qianyi-test-2 這個 netns ip link set veth-1-b netns qianyi-test-2# 為設備添加 IP 地址/子網掩碼并開啟 ip netns exec qianyi-test-1 ip addr add 10.0.0.101/24 dev veth-1-a ip netns exec qianyi-test-1 ip link set dev veth-1-a upip netns exec qianyi-test-2 ip addr add 10.0.0.102/24 dev veth-1-b ip netns exec qianyi-test-2 ip link set dev veth-1-b up

此時我們分別在兩個 netns 中執行 ip addr 命令，即可看到設備已經存在，且路由表（route 或 ip route 命令）也被默認創建了：

這里操作和查看設備都必須采用 ip netns exec {...} 的方式進行，如果命令很多，也可以把執行的命令換成 bash，這樣可以方便的在這個 shell 里對該 netns 進行操作。

現在通過 veth-1-a/veth-1-b 這對 Veth Pair 聯通了 qianyi-test-1 和 qianyi-test-2 這兩個 netns，這兩個 netns 之間就可以通過這兩個 IP 地址相互訪問了。

ping 的同時在 101 上抓包的結果如下：

可以很清楚的看到，eth-1-a（10.0.0.101）先通過 ARP （Address Resolution Protocol，地址解析協議）詢問 10.0.0.102 的 MAC 地址。得到回應后，就以 ICMP (Internet Control Message Protocol，Internet 報文控制協議) request 和 reply 了，這也正是 ping 使用的協議。

ARP 解析的緩存信息也可以通過 arp 命令查看：

此時的網絡連接模式是這樣的：

這種連接模式，就很像是現實中把兩個帶有 NIC 的設備用網線連接起來，然后配置了相同網段的 IP 后彼此就可以通信了。那如果超過一個設備需要建立互聯呢？現實中就需要交換機等網絡設備了。還記得前文中說的 Linux 自帶的 Bridge 么？接下來就使用 Bridge 機制建立網絡。

進行下面的試驗前需要把 veth-1-a/veth-1-b 這對 Veth Pair 從 qianyi-test-1 和 qianyi-test-2 移動回宿主機的 netns 里，恢復初始的環境。

# 宿主機的 netns id 是 1（有些系統可能不是，請查詢相關系統的文檔） ip netns exec qianyi-test-1 ip link set veth-1-a netns 1 ip netns exec qianyi-test-2 ip link set veth-1-b netns 1

創建 Linux Bridge 并配置網絡

# 創建一個名為 br0 的 bridge 并啟動（也可以使用 brctl 命令） ip link add br0 type bridge ip link set br0 up# 將 veth-1-a/veth-1-b 和 veth-2-a/veth-2-b 這兩對 Veth Pair 的 a 端放入 qianyi-test-1 和 qianyi-test-2 ip link set veth-1-a netns qianyi-test-1 ip link set veth-2-a netns qianyi-test-2# 為 veth-1-a 和 veth-2-a 配置 IP 并開啟 ip netns exec qianyi-test-1 ip addr add 10.0.0.101/24 dev veth-1-a ip netns exec qianyi-test-1 ip link set dev veth-1-a upip netns exec qianyi-test-2 ip addr add 10.0.0.102/24 dev veth-2-a ip netns exec qianyi-test-2 ip link set dev veth-2-a up# 將 veth-1-a/veth-1-b 和 veth-2-a/veth-2-b 這兩對 Veth Pair 的 b 端接入 br0 網橋并開啟接口 ip link set veth-1-b master br0 ip link set dev veth-1-b up ip link set veth-2-b master br0 ip link set dev veth-2-b up

執行完可以查看創建好的網橋和配置好的 IP，實際上 brctl show 命令顯示的結果更易懂，可以很清楚的看到 veth-1-b 和 veth-2-b 連接在了網橋的接口上。當 Veth Pair 的一端連接在網橋上時，就會從“網卡”退化成一個“水晶頭”。

當下模式抓包的結果并沒有什么區別，但網絡連接模式不同：

按照這個模式，如果有更多的 Network Namespace 和 Veth Pair 的話，使用相同的方式添加就可以水平擴展了。

但是嘗試從 qianyi-test-1 中 ping 宿主機自然是不通的，因為沒有任何網絡規則可以訪問到宿主機的網絡：

上面的截圖中有個 docker0 的網橋。當機器上安裝了 Docker 之后會被自動設置好這個網橋供 Docker 使用。可能你注意到了，這個名為 docker0 的網橋居然是有 IP 地址的。現實中的網橋自然是沒有 IP 的，但是 Linux Bridge 這個虛擬設備是可以設置的。當 Bridge 設置 IP 之后，就可以將其設置成這個內部網絡的網關（Gateway），再配合路由規則就可以實現最簡單的虛擬網絡跨機通信了（類似現實中的三層交換機）。

下面繼續給 br0 網橋創建地址并在 veth-1-a 和 veth-2-a 上設置其為默認的網關地址：

# 確認路由轉發開啟 echo "1" > /proc/sys/net/ipv4/ip_forward# 為 br0 設置 IP 地址 ip addr add local 10.0.0.1/24 dev br0# 為 veth-1-a 和 veth-2-a 設置默認網關 ip netns exec qianyi-test-1 ip route add default via 10.0.0.1 ip netns exec qianyi-test-2 ip route add default via 10.0.0.1

此時就能成功的訪問宿主機地址了（宿主機上的路由表在 ip link set br0 up 這一步自動創建了）：

網絡模型進一步變成了這樣：

如果此時，另一臺宿主機上也存在另一個網段的網橋和若干個 netns 的話，怎么讓他們互通呢？分別在兩邊宿主機上配置一條到目的宿主機的路由規則就好了。假設另一臺宿主機的 IP 地址是 10.97.212.160，子網是 10.0.1.0/24 的話，那么需要在當前機器上加一條 10.0.1.0/24 via 10.97.212.160 的規則，10.97.212.160 上加一條 10.0.0.0/24 via 10.97.212.159 的規則就可以了（或者 iptables 配置 SNAT/DNAT 規則）。那如果有 N 臺呢？那就會是個 N * N 條的規則，會很復雜。這就一個簡單的 Underlay 模式的容器通信方案了。缺點也很明顯，要求對宿主機底層網絡有修改權，且比較難和底層網絡解耦。那如果能在物理網絡上構建出一個橫跨所有宿主機的虛擬網橋，把所有相關的 netns 里面的設備都連接上去，不就可以解耦了么。這就是 Overlay Network（覆蓋網絡）方案，下文會進行闡述。至于本節其他虛擬網絡設備的安裝和配置（比如 Open vSwitch）也是比較類似的，這里不再贅述，有興趣的話可以自行查看文檔并測試。

2 Overlay 網絡方案之 VXLAN

VXLAN（Virtual eXtensible Local Area Network，虛擬可擴展局域網，RFC7348）[16]，VLAN 的擴展協議，是由 IETF 定義的 NVO3（Network Virtualization over Layer 3）標準技術之一（其他有代表性的還有 NVGRE、STT）。但是 VXLAN 和 VLAN 想要解決的問題是不一樣的。VXLAN 本質上是一種隧道封裝技術，它將數據鏈路層（L2）的以太網幀（Ethernet frames）封裝成傳輸層（L4）的 UDP 數據報（Datagrams），然后在網絡層（L3）中傳輸。效果就像數據鏈路層（L2）的以太網幀在一個廣播域中傳輸一樣，即跨越了三層網絡卻感知不到三層的存在。因為是基于 UDP 封裝，只要是 IP 網絡路由可達就可以構建出龐大的虛擬二層網絡。也因為是基于高層協議再次封裝，性能會比傳統的網絡低 20%~30% 左右（性能數據隨著技術發展會有變化，僅代表當前水平）。

這里簡要介紹下 VXLAN 的 2 個重要概念：

• VTEP（VXLAN Tunnel Endpoints，VXLAN 隧道端點），負責 VXLAN 報文的封裝和解封，對上層隱藏了鏈路層幀的轉發細節
• VNI（VXLAN Network Identifier，VXLAN 網絡標識符），代表不同的租戶，屬于不同 VNI 的虛擬網絡之間不能直接進行二層通信。

VXLAN 的報文格式如圖[17]：

Linux kernel v3.7.0 版本開始支持 VXLAN 網絡。但為了穩定性和其他功能，請盡量選擇 kernel v3.10.0 及之后的版本。下面我們使用 10.97.212.159 和 11.238.151.74 這兩臺機器創建一個測試的 VXLAN 網絡。

# 10.97.212.159 上操作# 創建名為 qianyi-test-1 和 add qianyi-test-2 的命名 netns，可以在 /var/run/netns/ 下查看 ip netns add qianyi-test-1 ip netns add qianyi-test-2# 開啟 lo 網卡，這個很重要 ip netns exec qianyi-test-1 ip link set dev lo up ip netns exec qianyi-test-2 ip link set dev lo up# 創建一個名為 br0 的 bridge 并啟動（也可以使用 brctl 命令） ip link add br0 type bridge ip link set br0 up# 分別創建 2 對名為 veth-1-a/veth-1-b 和 veth-2-a/veth-2-b 的 Veth Pair 設備 ip link add veth-1-a type veth peer name veth-1-b ip link add veth-2-a type veth peer name veth-2-b# 將 veth-1-a/veth-1-b 和 veth-2-a/veth-2-b 這兩對 Veth Pair 的 a 端放入 qianyi-test-1 和 qianyi-test-2 ip link set veth-1-a netns qianyi-test-1 ip link set veth-2-a netns qianyi-test-2# 為 veth-1-a 和 veth-2-a 配置 IP 并開啟 ip netns exec qianyi-test-1 ip addr add 10.0.0.101/24 dev veth-1-a ip netns exec qianyi-test-1 ip link set dev veth-1-a upip netns exec qianyi-test-2 ip addr add 10.0.0.102/24 dev veth-2-a ip netns exec qianyi-test-2 ip link set dev veth-2-a up# 將 veth-1-a/veth-1-b 和 veth-2-a/veth-2-b 這兩對 Veth Pair 的 b 端接入 br0 網橋并開啟接口 ip link set veth-1-b master br0 ip link set dev veth-1-b up ip link set veth-2-b master br0 ip link set dev veth-2-b up# 11.238.151.74 上操作# 創建名為 qianyi-test-3 和 add qianyi-test-4 的命名 netns，可以在 /var/run/netns/ 下查看 ip netns add qianyi-test-3 ip netns add qianyi-test-4# 開啟 lo 網卡，這個很重要 ip netns exec qianyi-test-3 ip link set dev lo up ip netns exec qianyi-test-4 ip link set dev lo up# 創建一個名為 br0 的 bridge 并啟動（也可以使用 brctl 命令） ip link add br0 type bridge ip link set br0 up# 分別創建 2 對名為 veth-3-a/veth-3-b 和 veth-4-a/veth-4-b 的 Veth Pair 設備 ip link add veth-3-a type veth peer name veth-3-b ip link add veth-4-a type veth peer name veth-4-b# 將 veth-3-a/veth-3-b 和 veth-4-a/veth-4-b 這兩對 Veth Pair 的 a 端放入 qianyi-test-3 和 qianyi-test-4 ip link set veth-3-a netns qianyi-test-3 ip link set veth-4-a netns qianyi-test-4# 為 veth-3-a 和 veth-4-a 配置 IP 并開啟 ip netns exec qianyi-test-3 ip addr add 10.0.0.103/24 dev veth-3-a ip netns exec qianyi-test-3 ip link set dev veth-3-a upip netns exec qianyi-test-4 ip addr add 10.0.0.104/24 dev veth-4-a ip netns exec qianyi-test-4 ip link set dev veth-4-a up# 將 veth-3-a/veth-3-b 和 veth-4-a/veth-4-b 這兩對 Veth Pair 的 b 端接入 br0 網橋并開啟接口 ip link set veth-3-b master br0 ip link set dev veth-3-b up ip link set veth-4-b master br0 ip link set dev veth-4-b up

這一長串的命令和之前的步驟完全一致，構建了一個如下圖所示的網絡環境：

這個環境里，10.0.0.101 和 10.0.0.102 是通的，10.0.0.103 和 10.0.0.104 也是通的，但是顯然 10.0.0.101/10.0.0.102 和 10.0.0.103/10.0.0.104 是無法通信的。

接下來配置 VXLAN 環境打通這四個 netns 環境：

# 10.97.212.159 上操作（本機有多個地址時可以用 local 10.97.212.159 指定） ip link add vxlan1 type vxlan id 1 remote 11.238.151.74 dstport 9527 dev bond0 ip link set vxlan1 master br0 ip link set vxlan1 up# 11.238.151.74 上操作（本機有多個地址時可以用 local 11.238.151.74 指定） ip link add vxlan2 type vxlan id 1 remote 10.97.212.159 dstport 9527 dev bond0 ip link set vxlan2 master br0 ip link set vxlan2 up

使用 brctl show br0 命令可以看到兩個 VXLAN 設備都連接上去了：

然后從 10.0.0.101 上就可以 ping 通 10.0.0.103 了：

在 10.0.0.101 上抓的包來看，就像是二層互通一樣：

直接查看 arp 緩存，也是和二層互通一模一樣：

使用 arp -d 10.0.0.103 刪掉這個緩存項目，在宿主機上重新抓包并保存文件，然后用 WireShark 打開看看（因為上面設置的不是 VXLAN 默認端口 4789，還需要設置 WireShark 把抓到的 UDP 解析為 VXLAN 協議）：

我們得到了預期的結果。此時的網絡架構如圖所示：

那么問題來了，這里使用 UDP 協議能實現可靠通信嗎？當然可以，可靠性不是這一層考慮的事情，而是里層被包裹的協議需要考慮的。完整的通信原理其實也并不復雜，兩臺機器上各自有 VTEP（VXLAN Tunnel Endpoints，VXLAN 隧道端點）設備，監聽著 9527 端口上發送的 UDP 數據包。在收到數據包后拆解通過 Bridge 傳遞給指定的設備。那 VETP 這個虛擬設備怎么知道類似 10.0.0.3 這樣的地址要發送給哪臺機器上的 VETP 設備呢？這可是虛擬的二層網絡，底層網絡上可不認識這個地址。事實上在 Linux Bridge 上維護著一個名為 FDB（Forwarding Database entry）的二層轉發表，用于保存遠端虛擬機/容器的 MAC 地址、遠端 VTEP 的 IP，以及 VNI 的映射關系，可以通過 bridge fdb 命令來對 FDB 表進行操作：

# 新增條目 bridge fdb add <remote_host_mac_addr> dev <vxlan_interface> dst <remote_host_ip_addr># 刪除條目 bridge fdb del <remote_host_mac_addr> dev <vxlan_interface># 替換條目 bridge fdb replace <remote_host_mac_addr> dev <vxlan_interface> dst <remote_host_ip_addr># 顯示條目 bridge fdb show

上面這個簡單的實驗就 2 臺機器，使用了命令的方式直接指定了彼此的 VTEP 地址，當 fdb 表查不到信息時發給對方就行了，這是最簡單的互聯模式。大規模 VXLAN 網絡下，就需要考慮如何發現網絡中其他的 VETP 地址了。解決這個問題一般有 2 種方式：一是使用組播/多播（ IGMP, Internet Group Management Protocol），把節點組成一個虛擬的整體，包不清楚發給誰的話就廣播給整個組了（上述實驗中的創建 VETH 設備的命令修改為組播/多播地址比如 224.1.1.1 就行，remote 關鍵字也要改成 group，具體請參閱其他資料）；二是通過外部的分布式控制中心來收集 FDB 信息并分發給同一個 VXLAN 網絡的所有節點。組播/多播受限于底層網絡的支持情況和大規模下的的性能問題，比如很多云網絡上不一定允許這么做。所以下文在討論和研究 K8s 的網絡方案時會看到很多網絡插件的實現采用的都是類似后者的實現方式。

這節就介紹到這里了。當然 Overlay 網絡方案也不止 VXLAN 這一種方式，只是目前很多主流的方案都采用了這種方式。其他的 Overlay 模式看上去眼花繚亂，其實說白了，無非就是 L2 over L4，L2 over L3，L3 over L3 等等各種包裝方式罷了，懂了基本原理之后都沒什么大不了的。網絡虛擬化的設備和機制也有很多[18]，細說的話一天都說不完，但是基本的網絡原理掌握之后，無非是各種協議包的流轉罷了。

三 K8s 的網絡虛擬化實現

1 K8s 的網絡模型

每一個 Pod 都有它自己的 IP 地址，這就意味著你不需要顯式地在每個 Pod 之間創建鏈接， 你幾乎不需要處理容器端口到主機端口之間的映射。這將創建一個干凈的、向后兼容的模型，在這個模型里，從端口分配、命名、服務發現、 負載均衡、應用配置和遷移的角度來看，Pod 可以被視作虛擬機或者物理主機。

Kubernetes 對所有網絡設施的實施，都需要滿足以下的基本要求（除非有設置一些特定的網絡分段策略）：

• 節點上的 Pod 可以不通過 NAT 和其他任何節點上的 Pod 通信
• 節點上的代理（比如：系統守護進程、kubelet）可以和節點上的所有 Pod 通信

備注：僅針對那些支持 Pods 在主機網絡中運行的平臺（比如：Linux）：

• 那些運行在節點的主機網絡里的 Pod 可以不通過 NAT 和所有節點上的 Pod 通信

這個模型不僅不復雜，而且還和 Kubernetes 的實現廉價的從虛擬機向容器遷移的初衷相兼容， 如果你的工作開始是在虛擬機中運行的，你的虛擬機有一個 IP，這樣就可以和其他的虛擬機進行通信，這是基本相同的模型。

Kubernetes 的 IP 地址存在于 Pod 范圍內 - 容器共享它們的網絡命名空間 - 包括它們的 IP 地址和 MAC 地址。這就意味著 Pod 內的容器都可以通過 localhost 到達各個端口。這也意味著 Pod 內的容器都需要相互協調端口的使用，但是這和虛擬機中的進程似乎沒有什么不同， 這也被稱為“一個 Pod 一個 IP”模型。

這幾段話引用自 K8s 的官方文檔[19]，簡單概括下就是一個 Pod 一個獨立的 IP 地址，所有的 Pod 之間可以不通過 NAT 通信。這個模型把一個 Pod 的網絡環境近似等同于一個 VM 的網絡環境。

2 K8s 的主流網絡插件實現原理

K8s 中的網絡是通過插件方式實現的，其網絡插件有 2 種類型：

• CNI 插件：遵守 CNI（Container Network Interface，容器網絡接口）規范，其設計上偏重互操作性
• Kubenet 插件：使用 bridge 和 host-local CNI 插件實現了基本的 cbr0

圖片來自[20]，本文只關注 CNI 接口插件。主流的 K8s 網絡插件有這些[21]，本文選出 github star 數在千以上的幾個項目分析下：

• Flannel：https://github.com/flannel-io/flannel
• Calico：https://github.com/projectcalico/calico
• Cilium：GitHub - cilium/cilium: eBPF-based Networking, Security, and Observability

Flannel

CNI 是由 CoreOS 提出的規范，那就先看下 CoreOS 自己的 Flannel 項目的設計。Flannel 會在每臺機宿主機上部署一個名為 flanneld 的代理進程，網段相關的數據使用 Kubernetes API/Etcd 存儲。Flannel 項目本身是一個框架，真正為我們提供容器網絡功能的，是 Flannel 的后端實現。

目前的 Flannel 有下面幾種后端實現：VXLAN、host-gw、UDP 以及阿里云和其他大廠的支持后端（云廠商都是實驗性支持），還有諸如 IPIP、IPSec 等一些隧道通信的實驗性支持。按照官方文檔的建議是優先使用 VXLAN 模式，host-gw 推薦給經驗豐富且想要進一步提升性能的用戶（云環境通常不能用，原因后面說），UDP 是 Flannel 最早支持的一種性能比較差的方案，基本上已經棄用了。

下文分別對這三種模式進行分析。

1）VXLAN

使用 Linux 內核 VXLAN 封裝數據包的方式和原理上文已經介紹過了，Flannel 創建了一個名為 flannel.1 的 VETH 設備。因為 flanneld 進程的存在，所以注冊和更新新的 VETH 設備關系的任務就依靠這個進程了。所以好像也沒什么需要說的了，就是每個新的 K8s Node 都會創建 flanneld 這個 DeamonSet 模式的守護進程。然后注冊、更新新的 VETH 設備就變得非常自然了，全局的數據自然也是保存在 Etcd 里了。這種方式圖已經畫過了，無非是設備名字不一樣（VETH 叫 flannel.1，網橋叫 cni0）而已。

2）host-gw

顧名思義，host-gw 就是把宿主機 Host 當做 Gateway 網關來處理協議包的流動。這個方式上文其實也演示過了，至于節點的變化和路由表的增刪也是依靠 flanneld 在做的。這個方案優缺點都很明顯，最大的優點自然是性能，實打實的直接轉發（性能整體比宿主機層面的通信低 10%，VXLAN 可是20% 起步，甚至 30%）。缺點也很明顯，這種方式要求宿主機之間是二層連通的，還需要對基礎設施有掌控權（編輯路由表），這個在云服務環境一般較難實現，另外規模越來越大時候的路由表規模也會隨之增大。這種方式原理上比較簡單，圖不畫了。

3）UDP

每臺宿主機上的 flanneld 進程會創建一個默認名為 flannel0 的 Tun 設備。Tun 設備的功能非常簡單，用于在內核和用戶應用程序之間傳遞 IP 包。內核將一個 IP 包發送給 Tun 設備之后，這個包就會交給創建這個設備的應用程序。而進程向 Tun 設備發送了一個 IP 包，那么這個 IP 包就會出現在宿主機的網絡棧中，然后根據路由表進行下一跳的處理。在由 Flannel 管理的容器網絡里，一臺宿主機上的所有容器都屬于該宿主機被分配的一個“子網”。這個子網的范圍信息，所屬的宿主機 IP 地址都保存在 Etcd 里。flanneld 進程均監聽著宿主機上的 UDP 8285 端口，相互之間通過 UDP 協議包裝 IP 包給目的主機完成通信。之前說過這個模式性能差，差在哪里？這個方案就是一個在應用層模擬實現的 Overlay 網絡似得（像不像一個用戶態實現的 VETH 設備？），數據包相比內核原生支持的 VXLAN 協議在用戶態多了一次進出（flanneld 進程封包/拆包過程），所以性能上損失要大一些。

Calico

Calico 是個挺有意思的項目，基本思想是把宿主機完全當成路由器，不使用隧道或 NAT 來實現轉發，把所有二三層流量轉換成三層流量，并通過宿主機上的路由配置完成包的轉發。

Calico 和之前說的 Flannel 的 host-gw 模式區別是什么？首先 Calico 不使用網橋，而是通過路由規則在不同的 vNiC 間轉發數據。另外路由表也不是靠 Etcd 存儲和通知更新，而是像現實環境一樣直接用 BGP（Border Gateway Protocol, 邊界網關協議）進行路由表數據交換。BGP 挺復雜的，詳細的闡述這個協議有點費勁（而且我也不是很懂），在本文里只需要知道這個協議使得路由設備可以相互發送和學習對方的路由信息來充實自己就可以了，有興趣的話請查閱其他資料進一步了解。回到 Calico，宿主機上依舊有個名為 Felix 的守護進程和一個名為 BIRD的 BGP 客戶端。

上文說過，Flannel 的 host-gw 模式要求宿主機二層是互通的（在一個子網），在 Calico 這里依然有這個要求。但是 Calico 為不在一個子網的環境提供了 IPIP 模式的支持。開啟這個模式之后，宿主機上會創建一個 Tun 設備以 IP 隧道（IP tunnel）的方式通信。當然用了這個模式之后，包又是L3 over L3 的 Overlay 網絡模式了，性能也和 VXLAN 模式相當。

全路由表的通信方式也沒有額外組件，配置好 IP 路由轉發規則后全靠內核路由模塊的流轉來做。IPIP 的架構圖也是大同小異的，也不畫了。

Cilium

eBPF-based Networking, Security, and Observability

光從這個介紹上就看出來 Cilium 散發出的那種與眾不同的氣息。這個項目目前的 Github Star 數字快過萬了，直接力壓前面兩位。Cilium 部署后會在宿主機上創建一個名為 cilium-agent 的守護進程，這個進程的作用就是維護和部署 eBPF 腳本來實現所有的流量轉發、過濾、診斷的事情（都不依賴 Netfilter 機制，kenel > v4.19 版本）。從原理圖的角度畫出來的架構圖很簡單（配圖來自 github 主頁）：

Cilium 除了支持基本的網絡連通、隔離與服務透出之外，依托 eBPF 所以對宿主機網絡有更好的觀測性和故障排查能力。這個話題也很大，本文就此收住。這里給兩幾篇寫的很好的文章何其譯文可以進一步了解22。

3 K8s 容器內訪問隔離

上文介紹了網絡插件的機制和實現原理，最終可以構建出一個二層/三層連通的虛擬網絡。默認情況下 Pod 間的任何網絡訪問都是不受限的，但是內部網絡中經常還是需要設置一些訪問規則（防火墻）的。

針對這個需求，K8s 抽象了一個名為 NetworkPolicy 的機制來支持這個功能。網絡策略通過網絡插件來實現，要使用網絡策略就必須使用支持 NetworkPolicy 的網絡解決方案。為什么這么說？因為不是所有的網絡插件都支持 NetworkPolicy 機制，比如 Flannel 就不支持。至于 NetworkPolicy 的底層原理，自然是使用 iptables 配置 netfilter 規則來實現對包的過濾的。NetworkPolicy 配置的方法和 iptables/Netfilter 的原理細節不在本文范圍內，請參閱其他資料進行了解24。

4 K8s 容器內服務透出

在一個 K8s 集群內部，在網絡插件的幫助下，所有的容器/進程可以相互進行通信。但是作為服務提供方這是不夠的，因為很多時候，服務的使用方不會在同一個 K8s 集群內的。那么就需要一種機制將這個集群內的服務對外透出。K8s 使用 Service 這個對象來完成這個能力的抽象。Service 在 K8s 里是個很重要的對象，即使在 K8s 內部進行訪問，往往也是需要 Service 包裝的（一來 Pod 地址不是永遠固定的，二來總是會有負載均衡的需求）。

一句話概括 Service 的原理就是：Service = kube-proxy + iptables 規則。當一個 Service 創建時，K8s 會為其分配一個 Cluster IP 地址。這個地址其實是個 VIP，并沒有一個真實的網絡對象存在。這個 IP 只會存在于 iptables 規則里，對這個 VIP:VPort 的訪問使用 iptables 的隨機模式規則指向了一個或者多個真實存在的 Pod 地址（DNAT），這個是 Service 最基本的工作原理。那 kube-proxy 做什么？kube-proxy 監聽 Pod 的變化，負責在宿主機上生成這些 NAT 規則。這個模式下 kube-proxy 不轉發流量，kube-proxy 只是負責疏通管道。

K8s 官方文檔比較好的介紹了 kube-proxy 支持的多種模式和基本的原理[26]。早先的 userspace 模式基本上棄用了，上面所述的 iptables 隨機規則的做法在大規模下也不推薦使用了（想想為什么）。現在最推薦的當屬 IPVS 模式了，相對于前兩種在大規模下的性能更好。如果說 IPVS 這個詞比較陌生的話，LVS 這個詞恐怕是我們耳熟能詳的。在這個模式下，kube-proxy 會在宿主機上創建一個名為 kube-ipvs0 的虛擬網卡，然后分配 Service VIP 作為其 IP 地址。最后 kube-proxy 使用內核的 IPVS 模塊為這個地址設置后端 POD 的地址（ipvsadm 命令可以查看）。其實 IPVS 在內核中的實現也是用了 Netfilter 的 NAT 機制。不同的是，IPVS 不會為每一個地址設置 NAT 規則，而是把這些規則的處理放到了內核態，保證了 iptables 規則的數量基本上恒定，比較好的解決了之前的問題。

上面說的只是解決了負載均衡的問題，還沒提到服務透出。K8s 服務透出的方式主要有 NodePort、LoadBalancer 類型的 Service（會調用 CloudProvider 在公有云上為你創建一個負載均衡服務）以及 ExternalName（kube-dns 里添加 CNAME）的方式。對于第二種類型，當 Service 繁多但是又流量很小的情況下，也可以使用 Ingress 這個 Service 的 Service 來收斂掉[27]。Ingress 目前只支持七層 HTTP(S) 轉發（Service 目前只支持四層轉發），從這個角度猜猜 Ingress 怎么實現的？來張圖看看吧[28]（當然還有很多其他的 Controller[29]）：

對于這部分，本文不再進行詳細闡述了，無非就是 NAT，NAT 多了就想辦法收斂 NAT 條目。按照慣例，這里給出一篇特別好的 kube-proxy 原理闡述的文章供進一步了解[30]。

四 總結

網絡虛擬化是個很大的話題，很難在一篇文章中完全講清楚。盡管這篇文章盡量想把重要的知識節點編織清楚，但受限于作者本人的精力以及認知上的限制，可能存在疏忽甚至錯漏。如有此類問題，歡迎在評論區討論/指正。參考文獻里給出了很多不錯的資料值得進一步去學習（部分地址受限于網絡環境，可能需要特定的方式才能訪問）。

參考文獻

1、TCP Implementation in Linux: A Brief Tutorial, Helali Bhuiyan, Mark McGinley, Tao Li, Malathi Veeraraghavan, University of Virginia：[PDF] TCP Implementation in Linux : A Brief Tutorial | Semantic Scholar
2、NAPI, linuxfoundation,?networking:napi [Wiki]
3、Monitoring and Tuning the Linux Networking Stack: Receiving Data, Joe Damato，譯文：Linux 網絡棧監控和調優：接收數據（2016）：[譯] Linux 網絡棧監控和調優：接收數據（2016）
4、Monitoring and Tuning the Linux Networking Stack: Sending Data, Joe Damato, 譯文：Linux 網絡棧監控和調優：發送數據（2017）：[譯] Linux 網絡棧監控和調優：發送數據（2017）
5、Scaling in the Linux Networking Stack,?https://github.com/torvalds/linux/blob/master/Documentation/networking/scaling.rst
6、Understanding TCP internals step by step for Software Engineers and System Designers, Kousik Nath
7、Netfilter,?https://www.netfilter.org/
8、Netfilter-packet-flow,?https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
9、Analysis TCP in Linux,?https://github.com/fzyz999/Analysis_TCP_in_Linux
10、NAT - Network Address Translation, 譯文：NAT - 網絡地址轉換（2016）：[譯] NAT - 網絡地址轉換（2016）
11、Virtual networking in Linux, By M. Jones, IBM Developer：Virtual networking in Linux – IBM Developer
12、Open vSwitch,?Open vSwitch
13、Linux Namespace,?namespaces(7) - Linux manual page
14、ip,?ip(8) - Linux manual page
15、Veth,?veth(4) - Linux manual page
16、VxLAN,?https://en.wikipedia.org/wiki/Virtual_Extensible_LAN
17、QinQ vs VLAN vs VXLAN, John,?https://community.fs.com/blog/qinq-vs-vlan-vs-vxlan.htm
18、Introduction to Linux interfaces for virtual networking, Hangbin Liu：Introduction to Linux interfaces for virtual networking | Red Hat Developer
19、Cluster Networking, 英文地址集群網絡系統 | Kubernetes
20、THE CONTAINER NETWORKING LANDSCAPE: CNI FROM COREOS AND CNM FROM DOCKER, Lee Calcote：The Container Networking Landscape: CNI from CoreOS and CNM from Docker – The New Stack
21、CNI - the Container Network Interface,?https://github.com/containernetworking/cni
22、Making the Kubernetes Service Abstraction Scale using eBPF, [譯] 利用 eBPF 支撐大規模 K8s Service (LPC, 2019)：Linux Plumbers Conference 2019 (9-11 September 2019): Making the Kubernetes Service Abstraction Scale using eBPF · Indico
23、基于 BPF/XDP 實現 K8s Service 負載均衡 (LPC, 2020)Linux Plumbers Conference 2020 (24-28 August 2020): Kubernetes service load-balancing at scale with BPF & XDP · Indico

24、A Deep Dive into Iptables and Netfilter Architecture, Justin Ellingwood：A Deep Dive into Iptables and Netfilter Architecture | DigitalOcean

25、Iptables Tutorial 1.2.2, Oskar Andreasson：Iptables Tutorial 1.2.2

26、Virtual IPs and service proxies, 英文地址：Service | Kubernetes

27、Ingress, 英文地址：Ingress | Kubernetes

28、NGINX Ingress Controller,?F5 NGINX Ingress Controller - Production-Grade Kubernetes

29、Ingress Controllers, 英文地址：Ingress Controllers | Kubernetes

30、Cracking kubernetes node proxy (aka kube-proxy), [譯] 深入理解 Kubernetes 網絡模型：自己實現 Kube-Proxy 的功能：深入理解 Kubernetes 網絡模型：自己實現 kube-proxy 的功能 | 云原生社區

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的一文理解 K8s 容器网络虚拟化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。