一文徹悟容器網絡通信

來源：阿里巴巴中間件時間：2022-05-14 05:41:54

作者 | 陳赟豪(環河)

一、背景1.容器網絡為何出現

在一個汽車發動機的生產車間中，汽車發動機的各個組件會存在一定的順序進行組裝，這就要求有直接關系的組件必須知道下一個組件的具體位置。當一個汽車發動機組裝完成后，距離最后成品汽車，還差了很多部件，比如底盤，車身等。此時，需要將發動機發往一個裝配中心進行組合安裝，這樣我們就必須知道裝配中心的地理位置。

這些位置在容器中可以理解為 IP 地址，容器網絡便是如此。在上面這個例子里，即描述了容器網絡本節點內部互通場景，又描述了跨節點的通信場景。

隨著云計算的發展，應用間通信從物理機網絡，虛擬機網絡，發展到目前的容器網絡。由于容器不同于物理機、虛擬機，容器可以被理解為一個標準的，輕量級的，便攜的，獨立的集裝箱，集裝箱之間相互隔離，都使用自己的環境和資源。但隨著越來越復雜環境變化，容器在運行中會需要容器間或者容器與集群外部之間的信息傳輸，這時候容器就要在網絡層面擁有一個名字(即 IP 地址)，由此容器網絡就應運而生。

再從技術的角度來談容器網絡的由來，首先要從容器本質說起，它是由以下幾點來實現的：

cgroup：實現資源的可配額。overlay fs：實現文件系統的安全性和便攜性。namespace：實現資源的隔離性。

IPC ：System V IPC 和 POSIX 消息隊列；

Network：網絡設備、網絡協議棧、網絡端口等；

PID：進程；

Mount：掛載點；

UTS：主機名和域名；

USR：用戶和用戶組；

由于主機與容器、容器與容器間的網絡棧并不相通，也沒有統一的控制面，導致容器間無法直接的感知。為了解決這個問題，本文中我們要討論的容器網絡出現了，再配合不同的網絡虛擬化技術帶來了多樣化的容器網絡方案。

2.容器網絡的基本要求

IP-per-Pod，每個 Pod 都擁有一個獨立 IP 地址，Pod 內所有容器共享一個網絡命名空間。

集群內所有 Pod 都在一個直接連通的扁平網絡中，可通過 IP 直接訪問。

所有容器之間無需 NAT 就可以直接互相訪問。

所有 Node 和所有容器之間無需 NAT 就可以直接互相訪問。

容器自己看到的 IP 跟其他容器看到的一樣。

Service cluster IP 盡可在集群內部訪問，外部請求需要通過 NodePort、LoadBalance 或者 Ingress 來訪問。

二、網絡插件介紹1.網絡插件概述

容器和該容器所在的宿主機是分隔的兩地，如果需要連通就得建立一座橋梁，但由于容器側還沒有名字，就無法建立橋梁，這時候就先需要給容器側命名，這樣才能成功建立起橋梁。網絡插件就是起到給容器側命名和建立橋梁的功能。

即網絡插件將網絡接口插入容器網絡命名空間(例如，veth 對的一端)，并在主機上進行任何必要的改變(例如將 veth 的另一端連接到網橋)。然后通過調用適當的 IPAM 插件(IP 地址管理插件)分配給接口一個空閑的 IP 地址，并設置與此 IP 地址相對應的路由規則。

對于 K8s 來講，網絡屬于最重要的功能之一，因為沒有一個良好的網絡，集群不同節點之間甚至同一個節點之間的 pod 就無法良好的運行起來。

但是 K8s 在設計網絡的時候，采用的準則就一點：“靈活”!那怎么才能靈活呢?那就是 K8s 自身沒有實現太多跟網絡相關的操作，而是制定了一個規范：

有配置文件，能夠提供要使用的網絡插件名，以及該插件所需信息。讓 CRI 調用這個插件，并把容器的運行時信息，包括容器的命名空間，容器 ID 等信息傳給插件。不關心網絡插件內部實現，只需要最后能夠輸出網絡插件提供的 pod IP 即可。

沒錯一共就這三點，如此簡單靈活的規范就是大名鼎鼎的 CNI 規范。

不過恰恰因為 K8s 自己“啥也不干”，所以大家可以自由發揮，自由實現不同的 CNI 插件，即網絡插件。除了社區大名鼎鼎的 Calico、Bifrost 網絡插件，阿里也開發了一款功能和性能極優的網絡插件 Hybridnet。

Hybridnet

Hybridnet 是專為混合云設計的開源容器網絡解決方案，與 Kubernetes 集成，并被以下 PaaS 平臺使用:

阿里云 ACK 發行版阿里云 AECP螞蟻金服 SOFAStack

Hybridnet 專注于高效的大規模集群、異構基礎設施和用戶友好性。

Calico

Calico 是一種廣泛采用、久經考驗的開源網絡和網絡安全解決方案，適用于 Kubernetes、虛擬機和裸機工作負載。Calico 為 Cloud Native 應用程序提供兩大服務：

工作負載之間的網絡連接

工作負載之間的網絡安全策略

Bifrost

Bifrost 是一個可為 Kubernetes 啟用 L2 網絡的開源解決方案，支持以下特性。

Bifrost 中的網絡流量可以通過傳統設備進行管理和監控。

支持 macvlan 對于 service 流量的訪問。

2.通信路徑介紹

Overlay 方案：意味著將不同主機上的容器用同一個虛擬網絡連接起來的跨主機網絡。

VXLAN

VXLAN(Virtual eXtensible Local Area Network，虛擬擴展局域網)，是由 IETF 定義的 NVO3(Network Virtualization over Layer 3)標準技術之一，采用 L2 over L4(MAC-in-UDP)的報文封裝模式，將二層報文用三層協議進行封裝，可實現二層網絡在三層范圍內進行擴展，同時滿足數據中心大二層虛擬遷移和多租戶的需求。

IPIP

基于 TUN 設備實現 IPIP 隧道，TUN 網絡設備能將三層(IP 網絡數據包)數據包封裝在另外一個三層數據包之中，Linux 原生支持好幾種不同的 IPIP 隧道類型，但都依賴于 TUN 網絡設備。

ipip: 普通的 IPIP 隧道，就是在報文的基礎上再封裝成一個 IPv4 報文。

gre: 通用路由封裝(Generic Routing Encapsulation)，定義了在任意網絡層協議上封裝其他網絡層協議的機制，所以對于 IPv4 和 IPv6 都適用。

sit: sit 模式主要用于 IPv4 報文封裝 IPv6 報文，即 IPv6 over IPv4。

isatap: 站內自動隧道尋址協議(Intra-Site Automatic Tunnel Addressing Protocol)，類似于 sit 也是用于 IPv6 的隧道封裝。

vti: 即虛擬隧道接口(Virtual Tunnel Interface)，是一種 IPsec 隧道技術。

本文中我們使用的是 ipip 這種普通的 IPIP 隧道。

Underlay 方案：由交換機和路由器等設備組成，借助以太網協議、路由協議和 VLAN 協議等驅動的網絡。

BGP

邊界網關協議BGP(Border Gateway Protocol)是一種實現自治系統AS(Autonomous System)之間的路由可達，并選擇最佳路由的距離矢量路由協議。

Vlan

VLAN(Virtual Local Area Network)即虛擬局域網，是將一個物理的LAN在邏輯上劃分成多個廣播域的通信技術。VLAN內的主機間可以直接通信，而VLAN間不能直接通信，從而將廣播報文限制在一個VLAN內。

3.網絡插件的原理calico 利用 IPIP 等隧道技術或者宿主機間建立 BGP 連接完成容器路由的互相學習解決了跨節點通信的問題。hybridnet 利用 vxlan 隧道技術、宿主機間建立 BGP 連接完成容器路由的互相學習或者 ARP 代理來解決跨節點通信的問題。bifrost 通過內核 macvlan 模塊利用交換機 vlan 的能力來解決容器通信問題。4.網絡插件分類及對比網絡插件分類

	overlay 方案	underlay 方案
主流方案	路由或 SDN 方案:Calico IPIP/Calico VXLAN	Calico BGP/MACVLAN/IPVLAN
優點	對物理網絡無侵入維護和管理簡單	高性能網絡流量可管理、可監控
缺點	容器網絡難以監控容器訪問集群外部通過 Node SNAT，無法精確管理流量	對現有組網有侵入維護和管理工作量大占用現網 IP 地址，前期需要詳細規劃

網絡插件對比

	hybridnet	calico ipip	calico bgp	bifrost
支持場景	overlay/underlay	overlay	underlay	underlay
網絡棧	IPv4/IPv6	IPv4	IPv4/IPv6	IPv4
通信技術	vxlan/vlan/bgp	ipip	bgp	macvlan
通信機制	隧道通信/二層+三層通信/三層通信	隧道通信	三層通信	二層通信
容器通信	veth pair	veth pair	veth pair	macvlan子接口
是否支持固定IP/固定IP池	是	是	是	是
IPPool模式	block + detail	block(如1.1.1.0/24)	block(如1.1.1.0/24)	detail(如1.1.1.1~1.1.1.9)
南北向流量出口	SNAT/podIP	SNAT	SNAT/podIP	podIP
是否支持網絡策略	是	是	是	商用版支持

SNAT: 對數據包的源 IP 地址進行轉化。podIP：由 podIP 直接通信。veth pair：在 Linux 下，可以創建一對 veth pair 的網卡，從一邊發送包，另一邊就能收到，對于容器流量來說會通過主機側的 veth 。pair 網卡進入主機網絡棧，即會過主機的 iptables 規則后再由物理網卡發出。macvlan子接口：macvlan 子接口和原來的宿主機主接口是完全獨立的，可以單獨配置 MAC 地址和 IP 地址，對外通信時，容器流量不會進入主機網絡棧，既不會過主機的iptables規則，只會經過二層由物理網卡發出。5.網絡插件應用場景

針對數據中心復雜的網絡情況，我們要按需求出發去選擇相對應的容器網絡方案。

希望對數據中心物理網絡較少侵入性，可選擇使用隧道方案。需支持雙棧，則可選 hybridnet vxlan 方案。只支持單棧 IPv4，則可選 calico IPIP，calico vxlan 方案。希望數據中心支持并使用 BGP宿主機處于同網段內，則可選 calico BGP 方案(支持雙棧)。宿主機處于不同網段內，則可選 hybridnet bgp 方案(支持雙棧)。對于業務的高性能和低延遲的追求，出現了 macvlan，ipvlan l2 等方案。公有云場景下，可選用 terway 方案，或者其他 ipvlan l3 方案，或者隧道方案。也有為了滿足全場景而開發的方案，如 hybridnet、multus 等，Multus 一款為支持其他 CNI 能力的開源容器網絡插件。

本文我們將對 hybridnet vxlan、hybridnet vlan、hybridnet bgp、calico IPIP、calico BGP 和基于 macvlan 改造的 bifrost 進行 pod 數據鏈路上的詳細分析。

三、網絡插件架構及通信路徑1.Hybridnet整體架構Hybridnet-daemon：控制每個節點上的數據平面配置，例如 Iptables 規則，策略路由等。通信路徑

（1）VXLAN 模式

同節點通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 veth-pair 網卡，即從 pod1 的 eth0->主機側的 hybrXXX，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到 39999 路由表，并在 39999 路由表中匹配到 Pod2 的路由規則。

流量從 hybrYYY 網卡進入 Pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 veth-pair 網卡，即從pod2的eth0->主機側的hybrYYY，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到39999路由表，并在39999路由表中匹配到 Pod1 的路由規則。

流量從 hybrXXX 網卡進入 Pod1 容器網絡棧，完成回包動作。

跨節點通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 veth-pair 網卡，即從 pod1 的 eth0->主機側的 hybrXXX，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到 40000 路由表，并在 40000 路由表中匹配到 Pod2 所在網段需要發往 eth0.vxlan20 網卡的路由規則。

eth0.vxlan20 設備的轉發表中記錄了對端 vtep 的 mac 地址和 remoteip 的對應關系。

流量經過 eth0.vxlan20 網卡，封裝一個 UDP 的頭部。

經過查詢路由，與本機處于同網段，通過 mac 地址查詢獲取到對端物理網卡的 mac 地址，經由 Node1 eth0 物理網卡發送。

流量從 Node2 eth0 物理網卡進入，并經過 eth0.vxlan20 網卡解封一個 UDP 的頭部。

根據 39999 路由表，流量從hybrYYY網卡進入 Pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 veth-pair 網卡，即從 pod2 的 eth0->主機側的 hybrYYY，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到 40000 路由表，并在 40000 路由表中匹配到 Pod1 所在網段需要發往 eth0.vxlan20 網卡的路由規則。

eth0.vxlan20 設備的轉發表中記錄了對端 vtep 的 mac 地址和 remoteip 的對應關系。

流量經過 eth0.vxlan20 網卡，封裝一個 UDP 的頭部。

經過查詢路由，與本機處于同網段，通過 mac 地址查詢獲取到對端物理網卡的 mac 地址，經由 Node2 eth0 物理網卡發送。

流量從 Node1 eth0 物理網卡進入，并經過 eth0.vxlan20 網卡解封一個 UDP 的頭部。

根據 39999 路由表，流量從 hybrXXX 網卡進入 Pod1 容器網絡棧，完成回包動作。

（2）VLAN 模式

同節點通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 veth-pair 網卡，即從 pod1 的 eth0->主機側的 hybrXXX，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到 39999 路由表，并在 39999 路由表中匹配到 Pod2 的路由規則。

流量從 hybrYYY 網卡進入 Pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 veth-pair 網卡，即從 pod2 的 eth0->主機側的 hybrYYY，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到 39999 路由表，并在 39999 路由表中匹配到 Pod1 的路由規則。

流量從 hybrXXX 網卡進入 Pod1 容器網絡棧，完成回包動作。

跨節點通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 veth-pair 網卡，即從 pod1 的 eth0->主機側的 hybrXXX，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到 10001 路由表，并在 10001 路由表中匹配到 Pod2 相對應的路由規則。

根據路由規則，流量從 eth0.20 網卡所對應的 eth0 物理網卡發出，并發往交換機。

在交換機上匹配到 pod2 的 MAC 地址，所以將流量發往 Node2 所對應的 eth0 物理網卡。

流量被 eth0.20 vlan 網卡接收到，并根據 39999 路由表匹配到的路由，將流量從 hybrYYY 網卡打入 pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 veth-pair 網卡，即從 pod2 的 eth0->主機側的 hybrYYY，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到 10001 路由表，并在 10001 路由表中匹配到 Pod1 相對應的路由規則。

根據路由規則，流量從 eth0.20 網卡所對應的 eth0 物理網卡發出，并發往交換機。

在交換機上匹配到 pod1 的 MAC 地址，所以將流量發往 Node1 所對應的 eth0 物理網卡。

流量被 eth0.20 vlan 網卡接收到，并根據 39999 路由表匹配到的路由，將流量從 hybrXXX 網卡打入 pod1 容器網絡棧，完成回包動作。

（3）BGP 模式

同節點通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 veth-pair 網卡，即從 pod1 的 eth0->主機側的 hybrXXX，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到 39999 路由表，并在 39999 路由表中匹配到 Pod2 的路由規則。

流量從 hybrYYY 網卡進入 Pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 veth-pair 網卡，即從 pod2 的 eth0->主機側的 hybrYYY，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到 39999 路由表，并在 39999 路由表中匹配到 Pod1 的路由規則。

流量從 hybrXXX 網卡進入 Pod1 容器網絡棧，完成回包動作。

跨節點通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 veth-pair 網卡，即從 pod1 的 eth0->主機側的 hybrXXX，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到 10001 路由表，并在 10001 路由表中匹配到默認路由。

根據路由，將流量發往 10.0.0.1 所對應的交換機。

在交換機上匹配到 pod2 所對應的特定路由，將流量發往 Node2 eth0 物理網卡。

流量從 hybrYYY 網卡進入 Pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 veth-pair 網卡，即從 pod2 的 eth0->主機側的 hybrYYY，進入主機網絡棧中。

根據目的 IP，流量在主機的策略路由匹配到 10001 路由表，并在 10001 路由表中匹配到默認路由。

根據路由，將流量發往 10.0.0.1 所對應的交換機。

在交換機上匹配到 pod1 所對應的特定路由，將流量發往 Node1 eth0 物理網卡。

流量從 hybrXXX 網卡進入 Pod1 容器網絡棧，完成回包動作。

2.Calico

基本概念：

純三層的數據中心網絡方案。利用 Linux Kernel 使得宿主機實現 vRouter 來負責數據轉發。vRouter 通過 BGP 協議傳播路由信息?；?iptables 還提供了豐富而靈活的網絡策略規則。整體架構Felix：運行在每個容器宿主節點上，主要負責配置路由、ACL 等信息來確保容器的聯通狀態。Brid：把 Felix 寫入 Kernel 的路由信息分發到 Calico 網絡，保證容器間的通信有效性。etcd：分布式的 Key/Value 存儲，負責網絡元數據一致性，確保 Calico 網絡狀態的準確性。RR：路由反射器，默認 Calico 工作在 node-mesh 模式，所有節點互相連接， node-mesh 。模式在小規模部署時工作是沒有問題的，當大規模部署時，連接數會非常大，消耗過多資源，利用 BGP RR ，可以避免這種情況的發生，通過一個或者多個 BGP RR 。來完成集中式的路由分發，減少對網絡資源的消耗以及提高 Calico 工作效率、穩定性。通信路徑

（1）IPIP 模式

同節點通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 veth-pair 網卡，即從 pod1 的 eth0->主機側的 caliXXX，進入主機網絡棧中。

根據目的 IP，流量在路由表中匹配到 Pod2 的路由規則。

流量從 caliYYY 網卡進入 Pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 veth-pair 網卡，即從 pod2 的 eth0->主機側的 caliYYY，進入主機網絡棧中。

根據目的 IP，流量在路由表中匹配到 Pod1 的路由規則。

流量從 caliXXX 網卡進入 Pod1 容器網絡棧，完成回包動作。

跨節點通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 veth-pair 網卡，即從 pod1 的 eth0->主機側的 caliXXX，進入主機網絡棧中。

src: pod1IP

dst: pod2IP

根據目的 IP，流量在路由表中匹配到將流量轉發到 tunl0 網卡上的路由規則。

src: pod1IP

dst: pod2IP

流量從 tunl0 進行 IPIP 封裝(即封裝一個 IP 頭部)，通過 eth0 物理網卡發出。

src: Node1IP

dst: Node2IP

流量從 Node2 的 eth0 網卡進入 Node2 的主機網絡棧。

src: Node1IP

dst: Node2IP

流量進入 tunl0 進行 IPIP 解包。

src: pod1IP

dst: pod2IP

流量從 caliYYY 網卡進入 Pod2 容器網絡棧，完成發包動作。

src: pod1IP

dst: pod2IP

回包過程：

Pod2 流量通過 veth-pair 網卡，即從 pod2 的 eth0->主機側的 caliYYY，進入主機網絡棧中。

src: pod2IP

dst: pod1IP

根據目的 IP，流量在路由表中匹配到將流量轉發到 tunl0 網卡上的路由規則。

src: pod2IP

dst: pod1IP

流量從 tunl0 進行 IPIP 封裝(即封裝一個 IP 頭部)，通過 eth0 物理網卡發出。

src: Node2IP

dst: Node1IP

流量從 Node1 的 eth0 網卡進入 Node1 的主機網絡棧。

src: Node2IP

dst: Node1IP

流量進入 tunl0 進行 IPIP 解包。

src: pod2IP

dst: pod1IP

流量從 caliXXX 網卡進入 Pod1 容器網絡棧，完成回包動作。

src: pod2IP

dst: pod1IP

（2）BGP 模式同節點通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 veth-pair 網卡，即從 pod1 的 eth0->主機側的 caliXXX，進入主機網絡棧中。

根據目的 IP，流量在路由表中匹配到 Pod2 的路由規則。

流量從 caliYYY 網卡進入 Pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 veth-pair 網卡，即從 pod2 的 eth0->主機側的 caliYYY，進入主機網絡棧中。根據目的 IP，流量在路由表中匹配到 Pod1 的路由規則。

流量從 caliXXX 網卡進入 Pod1 容器網絡棧，完成回包動作。

跨節點通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 veth-pair 網卡，即從 pod1 的 eth0->主機側的 caliXXX，進入主機網絡棧中。

根據目的 IP，流量在路由表中匹配到 Pod2 相對應網段的路由規則，并從 Node1 eth0 物理網卡發出。

流量從 Node2 eth0 物理網卡進入，并從 caliYYY 網卡進入 Pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 veth-pair 網卡，即從 pod2 的 eth0->主機側的 caliYYY，進入主機網絡棧中。

根據目的 IP，流量在路由表中匹配到 Pod1 相對應網段的路由規則，并從 Node2 eth0 物理網卡發出。

流量從 Node1 eth0 物理網卡進入，并從 caliXXX 網卡進入 Pod1 容器網絡棧，完成回包動作。

3.Bifrost整體架構veth0-bifrXXX：bifrost 對于 macvlan 實現 service 訪問的一套解決方案，通過 veth-pair 。網卡完成在主機網絡棧中的 kube-proxy + iptables 對于服務流量轉化為對 pod 的訪問。eth0：容器內的 eth0 網卡為主機 vlan 子網卡對應的 macvlan 網卡。通信路徑

（1）MACVLAN 模式

同節點同 vlan 通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 macvlan 網卡，即 pod1 的 eth0 走二層網絡進入 eth0-10 vlan 子網卡。

由于 macvlan 開啟 bridge 模式，能夠匹配到 pod2 的 MAC 地址。

流量從 eth0-10 vlan 子網卡進入 Pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 macvlan 網卡，即 pod2 的 eth0 走二層網絡進入 eth0-10 vlan 子網卡。

由于 macvlan 開啟 bridge 模式，能夠匹配到 pod1 的 MAC 地址。

流量從 eth0-10 vlan 子網卡進入 Pod1 容器網絡棧，完成回包動作。

同節點跨 vlan 通信

Pod1 訪問 Pod2 的通信過程發包過程：

Pod1 流量通過 macvlan 網卡，即 pod1 的 eth0 走默認路由(網關為 5.0.0.1)進入 eth0-5 vlan 子網卡。

由于在 eth0-5 上找到網關 5.0.0.1 的 MAC 地址，所以將流量從 eth0 物理網卡出打到交換機上。

流量在交換機上匹配到了 pod2 的 MAC 地址。

流量進入 Pod2 所在宿主機的物理網卡，并進入相對應的 eth0-10 vlan 子網卡。

流量從 eth0-10 vlan 子網卡進入 Pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 macvlan 網卡，即 pod2 的 eth0 走默認路由(網關為 10.0.0.1)進入 eth0-10 vlan 子網卡。

由于在 eth0-10 上找到網關 10.0.0.1 的 MAC 地址，所以將流量從 eth0 物理網卡出打到交換機上。

流量在交換機上匹配到了 pod1 的 MAC 地址。

流量進入 Pod1 所在宿主機的物理網卡，并進入相對應的 eth0-5 vlan 子網卡。

流量從 eth0-5 vlan 子網卡進入 Pod1 容器網絡棧，完成回包動作。

跨節點通信

Pod1 訪問 Pod2 的通信過程

發包過程：

Pod1 流量通過 macvlan 網卡，即 pod1 的 eth0 走默認路由(網關為 5.0.0.1)進入 eth0-5 vlan 子網卡。

由于在 eth0-5 上找到網關 5.0.0.1 的 MAC 地址，所以將流量從 eth0 物理網卡出打到交換機上。

流量在交換機上匹配到了 pod2 的 MAC 地址。

流量進入 Pod2 所在宿主機的物理網卡，并進入相對應的 eth0-10 vlan 子網卡。

流量從 eth0-10 vlan 子網卡進入 Pod2 容器網絡棧，完成發包動作。

回包過程：

Pod2 流量通過 macvlan 網卡，即 pod2 的 eth0 走默認路由(網關為 10.0.0.1)進入 eth0-10 vlan 子網卡。

由于在 eth0-10 上找到網關 10.0.0.1 的 MAC 地址，所以將流量從 eth0 物理網卡出打到交換機上。

流量在交換機上匹配到了 pod1 的 MAC 地址。

流量進入 Pod1 所在宿主機的物理網卡，并進入相對應的 eth0-5 vlan 子網卡。

流量從 eth0-5 vlan 子網卡進入 Pod1 容器網絡棧，完成回包動作。

四、面臨的問題及未來發展1.IPv4/IPv6 雙棧背景

IP 作為互聯網最基礎的要素，是為計算機網絡相互連接進行通信而設計的協議，正是因為有了 IP 協議，因特網才得以迅速發展成為世界上最大的、開放的計算機通信網絡。IP 協議隨著互聯網的發展，產生了 IPv4 和 IPv6 兩種協議：

IPv4

IPv4 是互聯網協議第四版，是計算機網絡使用的數據報傳輸機制，此協議是第一個被廣泛部署的 IP 協議。每一個連接 Internet 的設備(不管是交換機、PC 還是其他設備)，都會為其分配一個唯一的 IP 地址，如 192.149.252.76，如下圖所示，IPv4 使用 32 位(4 字節)地址，大約可以存儲 43 億個地址，但隨著越來越多的用戶接入到 Internet，全球 IPv4 地址已于 2019 年 11 月已全數耗盡。這也是后續互聯網工程任務組(IEIF)提出 IPv6 的原因之一。

IPv6

IPv6 是由 IEIF 提出的互聯網協議第六版，用來替代 IPv4 的下一代協議，它的提出不僅解決了網絡地址資源匱乏問題，也解決了多種接入設備接入互聯網的障礙。IPv6 的地址長度為 128 位，可支持 340 多萬億個地址。如下圖，3ffe:1900:fe21:4545:0000:0000:0000:0000，這是一個 IPv6 地址，IPv6 地址通常分為 8 組，4 個十六進制數為一組，每組之間用冒號分隔。

IPv4 占主流，IPv6 還未興起時，主要面臨的問題：

IPv4 地址數量已經不再滿足需求，需要 IPv6 地址進行擴展。

隨著國內下一代互聯網發展政策的明確，客戶數據中心需要使用 IPv6 來符合更嚴格的監管。

現狀

	hybridnet	calico IPIP	calico BGP	bifrost
是否支持IPv6/雙棧	是	否	是	否

calico IPIP 不支持 IPv6 的原因:

ipip 是普通的 IPIP 隧道，就是在報文的基礎上再封裝成一個 IPv4 報文，所以不支持 IPv6 的封包。2.多網卡(多通信機制)背景

通常情況下在 K8s 中，一個 Pod 只有一個接口，即單網卡，用于集群網絡中 pod 和 pod 通信。而 Pod 需要和異構網絡進行通信時，可選擇在 Pod 中建立多個接口，即多網卡。

目前的問題：

部分客戶真實 IP 資源緊張，導致無法全部使用 underlay 方案?？蛻粝Ｍ?UDP 網絡和 TCP 網絡分開，導致如基于 TCP 協議的網絡模型無法獨立存在于 UDP 網絡中?，F狀

目前實現多網卡的方案，大致兩種：

在單一 CNI 調用 IPAM 時，通過 CNI config 配置生成相對應的網卡并分配合適的 IP 資源。通過元 CNI 依次調用各個 CNI 來完成相對應的網卡并分配合適的 IP 資源，如 multus 方案。3.網絡流量管控背景

通常在數據中心中，我們將其網絡流量分為兩種類型，一種是數據中心外部用戶和內部服務器之間交互的流量，這樣的流量稱作南北向流量或者縱向流量;另外一種就是數據中心內部服務器之間交互的流量，也叫東西向流量或者橫向流量。

那么在容器云范疇內，我們將東西向流量定義為集群內宿主機和容器、容器間或宿主機間的流量，南北向流量為容器云外部與容器云內部之間交互的流量。

目前的問題：

傳統防火墻在容器云的東西向場景下，難以起到流量管控，需要提供服務間或容器間流量管控的能力?，F狀

	calico	cillum	bifrost-商用版
技術基礎	iptables	ebpf	ebpf
適配性	三層路由且流量經過主機網絡棧	二層且滿足cillum通信方式	主流CNI插件