一文理解 K8s 容器網路虛擬化
簡介：本文需要讀者熟悉 Ethernet（乙太網）的基本原理和 Linux 系統的基本網路命令，以及 TCP/IP 協議族並瞭解傳統的網路模型和協議包的流轉原理。文中涉及到 Linux 核心的具體實現時，均以核心 v4.19.215 版本為準。
作者 | 淺奕
來源 | 阿里技術公眾號
本文需要讀者熟悉 Ethernet（乙太網）的基本原理和 Linux 系統的基本網路命令，以及 TCP/IP 協議族並瞭解傳統的網路模型和協議包的流轉原理。文中涉及到 Linux 核心的具體實現時，均以核心 v4.19.215 版本為準。
一 核心網路包接收流程
1 從網絡卡到核心協議棧
具體到 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 模式下的流程對比如下（其中灰色底色是裝置驅動要實現的，其他都是核心自身的實現）：
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 五層模型：
常見的上層協議比如 TCP 或者 UDP 協議的流程不在本文討論的範圍內，僅 TCP 的流程所需要的篇幅足以超過本文所有的內容。這裡給出 TCP 協議（v4）的入口函式 tcp_v4_rcv() 以及 UDP 協議的入口函式 udp_rcv() 作為指引自行研究，也可以閱讀其他的資料進行進一步的瞭解[9]。
3 Netfilter/iptables 與 NAT（網路地址轉換）
關於 Netfilter 框架需要稍微著重的強調一下，因為後文要提到的網路策略和很多服務透出的實現都要使用 Netfilter 提供的機制。
Netfilter 是核心的包過濾框架（Packet Filtering Framework）的實現。簡單說就是在協議棧的各個層次的包處理函式中內建了很多的 Hook 點來支援在這些點註冊回撥函式。
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]，下同）:
- 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，可以構建出支援更多封裝協議、更高階的虛擬網路：
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執行結果如圖（刪除先不執行）：
在 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
建立 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 命令可以檢視：
將 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 up
ip 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 命令）也被預設建立了：
現在通過 veth-1-a/veth-1-b 這對 Veth Pair 聯通了 qianyi-test-1 和 qianyi-test-2 這兩個 netns，這兩個 netns 之間就可以通過這兩個 IP 地址相互訪問了。
ARP 解析的快取資訊也可以通過 arp 命令檢視：
進行下面的試驗前需要把 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 up
ip 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 的一端連線在網橋上時，就會從“網絡卡”退化成一個“水晶頭”。
但是嘗試從 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 這一步自動建立了）：
網路模型進一步變成了這樣：
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]：
# 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 up
ip 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 up
ip 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這一長串的命令和之前的步驟完全一致，構建了一個如下圖所示的網路環境：
接下來配置 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 裝置都連線上去了：
# 新增條目
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
- Flannel：
- Calico：
- Cilium：
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 主頁）：
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]）：
四 總結
網路虛擬化是個很大的話題，很難在一篇文章中完全講清楚。儘管這篇文章儘量想把重要的知識節點編織清楚，但受限於作者本人的精力以及認知上的限制，可能存在疏忽甚至錯漏。如有此類問題，歡迎在評論區討論/指正。參考文獻裡給出了很多不錯的資料值得進一步去學習（部分地址受限於網路環境，可能需要特定的方式才能訪問）。
參考文獻
1、TCP Implementation in Linux: A Brief Tutorial, Helali Bhuiyan, Mark McGinley, Tao Li, Malathi Veeraraghavan, University of Virginia：
24、A Deep Dive into Iptables and Netfilter Architecture, Justin Ellingwood：
25、Iptables Tutorial 1.2.2, Oskar Andreasson：
26、Virtual IPs and service proxies, 英文地址：
27、Ingress, 英文地址：
28、NGINX Ingress Controller,
29、Ingress Controllers, 英文地址：
30、Cracking kubernetes node proxy (aka kube-proxy), [譯] 深入理解 Kubernetes 網路模型：自己實現 Kube-Proxy 的功能：
原文連結
本文為阿里雲原創內容，未經允許不得轉載。