作者 |   陳赟豪(環(huán)河)

一、背景

1.容器網(wǎng)絡(luò)為何出現(xiàn)

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

這些位置在容器中可以理解為 IP 地址，容器網(wǎng)絡(luò)便是如此。在上面這個例子里，即描述了容器網(wǎng)絡(luò)本節(jié)點內(nèi)部互通場景，又描述了跨節(jié)點的通信場景。

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

再從技術(shù)的角度來談容器網(wǎng)絡(luò)的由來，首先要從容器本質(zhì)說起，它是由以下幾點來實現(xiàn)的：

• cgroup：實現(xiàn)資源的可配額。
• overlay fs：實現(xiàn)文件系統(tǒng)的安全性和便攜性。
• namespace：實現(xiàn)資源的隔離性。

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

Network：網(wǎng)絡(luò)設(shè)備、網(wǎng)絡(luò)協(xié)議棧、網(wǎng)絡(luò)端口等；

PID：進程；

Mount：掛載點；

UTS：主機名和域名；

USR：用戶和用戶組；

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

2.容器網(wǎng)絡(luò)的基本要求

IP-per-Pod，每個 Pod 都擁有一個獨立 IP 地址，Pod 內(nèi)所有容器共享一個網(wǎng)絡(luò)命名空間。

集群內(nèi)所有 Pod 都在一個直接連通的扁平網(wǎng)絡(luò)中，可通過 IP 直接訪問。

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

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

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

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

二、網(wǎng)絡(luò)插件介紹

1.網(wǎng)絡(luò)插件概述

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

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

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

但是 K8s 在設(shè)計網(wǎng)絡(luò)的時候，采用的準則就一點：“靈活”!那怎么才能靈活呢?那就是 K8s 自身沒有實現(xiàn)太多跟網(wǎng)絡(luò)相關(guān)的操作，而是制定了一個規(guī)范：

• 有配置文件，能夠提供要使用的網(wǎng)絡(luò)插件名，以及該插件所需信息。
• 讓 CRI 調(diào)用這個插件，并把容器的運行時信息，包括容器的命名空間，容器 ID 等信息傳給插件。
• 不關(guān)心網(wǎng)絡(luò)插件內(nèi)部實現(xiàn)，只需要最后能夠輸出網(wǎng)絡(luò)插件提供的 pod IP 即可。

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

不過恰恰因為 K8s 自己“啥也不干”，所以大家可以自由發(fā)揮，自由實現(xiàn)不同的 CNI 插件，即網(wǎng)絡(luò)插件。除了社區(qū)大名鼎鼎的 Calico、Bifrost 網(wǎng)絡(luò)插件，阿里也開發(fā)了一款功能和性能極優(yōu)的網(wǎng)絡(luò)插件 Hybridnet。

• Hybridnet

Hybridnet 是專為混合云設(shè)計的開源容器網(wǎng)絡(luò)解決方案，與 Kubernetes 集成，并被以下 PaaS 平臺使用:

• 阿里云 ACK 發(fā)行版
• 阿里云 AECP
• 螞蟻金服 SOFAStack

Hybridnet 專注于高效的大規(guī)模集群、異構(gòu)基礎(chǔ)設(shè)施和用戶友好性。

• Calico

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

工作負載之間的網(wǎng)絡(luò)連接

工作負載之間的網(wǎng)絡(luò)安全策略

• Bifrost

Bifrost 是一個可為 Kubernetes 啟用 L2 網(wǎng)絡(luò)的開源解決方案，支持以下特性。

Bifrost 中的網(wǎng)絡(luò)流量可以通過傳統(tǒng)設(shè)備進行管理和監(jiān)控。

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

2.通信路徑介紹

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

• VXLAN

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

• IPIP

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

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

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

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

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

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

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

Underlay 方案：由交換機和路由器等設(shè)備組成，借助以太網(wǎng)協(xié)議、路由協(xié)議和 VLAN 協(xié)議等驅(qū)動的網(wǎng)絡(luò)。

• BGP

邊界網(wǎng)關(guān)協(xié)議BGP(Border Gateway Protocol)是一種實現(xiàn)自治系統(tǒng)AS(Autonomous System)之間的路由可達，并選擇最佳路由的距離矢量路由協(xié)議。

• Vlan

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

3.網(wǎng)絡(luò)插件的原理

• calico 利用 IPIP 等隧道技術(shù)或者宿主機間建立 BGP 連接完成容器路由的互相學(xué)習(xí)解決了跨節(jié)點通信的問題。
• hybridnet 利用 vxlan 隧道技術(shù)、宿主機間建立 BGP 連接完成容器路由的互相學(xué)習(xí)或者 ARP 代理來解決跨節(jié)點通信的問題。
• bifrost 通過內(nèi)核 macvlan 模塊利用交換機 vlan 的能力來解決容器通信問題。

4.網(wǎng)絡(luò)插件分類及對比

• 網(wǎng)絡(luò)插件分類

• 網(wǎng)絡(luò)插件對比

• SNAT: 對數(shù)據(jù)包的源 IP 地址進行轉(zhuǎn)化。
• podIP：由 podIP 直接通信。
• veth pair：在 Linux 下，可以創(chuàng)建一對 veth pair 的網(wǎng)卡，從一邊發(fā)送包，另一邊就能收到，對于容器流量來說會通過主機側(cè)的 veth 。 pair 網(wǎng)卡進入主機網(wǎng)絡(luò)棧，即會過主機的 iptables 規(guī)則后再由物理網(wǎng)卡發(fā)出。
• macvlan子接口：macvlan 子接口和原來的宿主機主接口是完全獨立的，可以單獨配置 MAC 地址和 IP 地址，對外通信時，容器流量不會進入主機網(wǎng)絡(luò)棧，既不會過主機的iptables規(guī)則，只會經(jīng)過二層由物理網(wǎng)卡發(fā)出。

5.網(wǎng)絡(luò)插件應(yīng)用場景

針對數(shù)據(jù)中心復(fù)雜的網(wǎng)絡(luò)情況，我們要按需求出發(fā)去選擇相對應(yīng)的容器網(wǎng)絡(luò)方案。

• 希望對數(shù)據(jù)中心物理網(wǎng)絡(luò)較少侵入性，可選擇使用隧道方案。

• 需支持雙棧，則可選 hybridnet vxlan 方案。
• 只支持單棧 IPv4，則可選 calico IPIP，calico vxlan 方案。

• 希望數(shù)據(jù)中心支持并使用 BGP

• 宿主機處于同網(wǎng)段內(nèi)，則可選 calico BGP 方案(支持雙棧)。
• 宿主機處于不同網(wǎng)段內(nèi)，則可選 hybridnet bgp 方案(支持雙棧)。

• 對于業(yè)務(wù)的高性能和低延遲的追求，出現(xiàn)了 macvlan，ipvlan l2 等方案。
• 公有云場景下，可選用 terway 方案，或者其他 ipvlan l3 方案，或者隧道方案。
• 也有為了滿足全場景而開發(fā)的方案，如 hybridnet、multus 等，Multus 一款為支持其他 CNI 能力的開源容器網(wǎng)絡(luò)插件。

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

三、網(wǎng)絡(luò)插件架構(gòu)及通信路徑

1.Hybridnet

整體架構(gòu)

• Hybridnet-daemon：控制每個節(jié)點上的數(shù)據(jù)平面配置，例如 Iptables 規(guī)則，策略路由等。

通信路徑

（1）VXLAN 模式

• 同節(jié)點通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

Pod1 流量通過 veth-pair 網(wǎng)卡，即從 pod1 的 eth0->主機側(cè)的 hybrXXX，進入主機網(wǎng)絡(luò)棧中。

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

流量從 hybrYYY 網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

Pod2 流量通過 veth-pair 網(wǎng)卡，即從pod2的eth0->主機側(cè)的hybrYYY，進入主機網(wǎng)絡(luò)棧中。

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

流量從 hybrXXX 網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

• 跨節(jié)點通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

Pod1 流量通過 veth-pair 網(wǎng)卡，即從 pod1 的 eth0->主機側(cè)的 hybrXXX，進入主機網(wǎng)絡(luò)棧中。

根據(jù)目的 IP，流量在主機的策略路由匹配到 40000 路由表，并在 40000 路由表中匹配到 Pod2 所在網(wǎng)段需要發(fā)往 eth0.vxlan20 網(wǎng)卡的路由規(guī)則。

eth0.vxlan20 設(shè)備的轉(zhuǎn)發(fā)表中記錄了對端 vtep 的 mac 地址和 remoteip 的對應(yīng)關(guān)系。

流量經(jīng)過 eth0.vxlan20 網(wǎng)卡，封裝一個 UDP 的頭部。

經(jīng)過查詢路由，與本機處于同網(wǎng)段，通過 mac 地址查詢獲取到對端物理網(wǎng)卡的 mac 地址，經(jīng)由 Node1 eth0 物理網(wǎng)卡發(fā)送。

流量從 Node2 eth0 物理網(wǎng)卡進入，并經(jīng)過 eth0.vxlan20 網(wǎng)卡解封一個 UDP 的頭部。

根據(jù) 39999 路由表，流量從hybrYYY網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

Pod2 流量通過 veth-pair 網(wǎng)卡，即從 pod2 的 eth0->主機側(cè)的 hybrYYY，進入主機網(wǎng)絡(luò)棧中。

根據(jù)目的 IP，流量在主機的策略路由匹配到 40000 路由表，并在 40000 路由表中匹配到 Pod1 所在網(wǎng)段需要發(fā)往 eth0.vxlan20 網(wǎng)卡的路由規(guī)則。

eth0.vxlan20 設(shè)備的轉(zhuǎn)發(fā)表中記錄了對端 vtep 的 mac 地址和 remoteip 的對應(yīng)關(guān)系。

流量經(jīng)過 eth0.vxlan20 網(wǎng)卡，封裝一個 UDP 的頭部。

經(jīng)過查詢路由，與本機處于同網(wǎng)段，通過 mac 地址查詢獲取到對端物理網(wǎng)卡的 mac 地址，經(jīng)由 Node2 eth0 物理網(wǎng)卡發(fā)送。

流量從 Node1 eth0 物理網(wǎng)卡進入，并經(jīng)過 eth0.vxlan20 網(wǎng)卡解封一個 UDP 的頭部。

根據(jù) 39999 路由表，流量從 hybrXXX 網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

（2）VLAN 模式

• 同節(jié)點通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

Pod1 流量通過 veth-pair 網(wǎng)卡，即從 pod1 的 eth0->主機側(cè)的 hybrXXX，進入主機網(wǎng)絡(luò)棧中。

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

流量從 hybrYYY 網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

Pod2 流量通過 veth-pair 網(wǎng)卡，即從 pod2 的 eth0->主機側(cè)的 hybrYYY，進入主機網(wǎng)絡(luò)棧中。

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

流量從 hybrXXX 網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

• 跨節(jié)點通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

Pod1 流量通過 veth-pair 網(wǎng)卡，即從 pod1 的 eth0->主機側(cè)的 hybrXXX，進入主機網(wǎng)絡(luò)棧中。

根據(jù)目的 IP，流量在主機的策略路由匹配到 10001 路由表，并在 10001 路由表中匹配到 Pod2 相對應(yīng)的路由規(guī)則。

根據(jù)路由規(guī)則，流量從 eth0.20 網(wǎng)卡所對應(yīng)的 eth0 物理網(wǎng)卡發(fā)出，并發(fā)往交換機。

在交換機上匹配到 pod2 的 MAC 地址，所以將流量發(fā)往 Node2 所對應(yīng)的 eth0 物理網(wǎng)卡。

流量被 eth0.20 vlan 網(wǎng)卡接收到，并根據(jù) 39999 路由表匹配到的路由，將流量從 hybrYYY 網(wǎng)卡打入 pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

Pod2 流量通過 veth-pair 網(wǎng)卡，即從 pod2 的 eth0->主機側(cè)的 hybrYYY，進入主機網(wǎng)絡(luò)棧中。

根據(jù)目的 IP，流量在主機的策略路由匹配到 10001 路由表，并在 10001 路由表中匹配到 Pod1 相對應(yīng)的路由規(guī)則。

根據(jù)路由規(guī)則，流量從 eth0.20 網(wǎng)卡所對應(yīng)的 eth0 物理網(wǎng)卡發(fā)出，并發(fā)往交換機。

在交換機上匹配到 pod1 的 MAC 地址，所以將流量發(fā)往 Node1 所對應(yīng)的 eth0 物理網(wǎng)卡。

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

（3）BGP 模式

• 同節(jié)點通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

Pod1 流量通過 veth-pair 網(wǎng)卡，即從 pod1 的 eth0->主機側(cè)的 hybrXXX，進入主機網(wǎng)絡(luò)棧中。

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

流量從 hybrYYY 網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

Pod2 流量通過 veth-pair 網(wǎng)卡，即從 pod2 的 eth0->主機側(cè)的 hybrYYY，進入主機網(wǎng)絡(luò)棧中。

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

流量從 hybrXXX 網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

• 跨節(jié)點通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

Pod1 流量通過 veth-pair 網(wǎng)卡，即從 pod1 的 eth0->主機側(cè)的 hybrXXX，進入主機網(wǎng)絡(luò)棧中。

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

根據(jù)路由，將流量發(fā)往 10.0.0.1 所對應(yīng)的交換機。

在交換機上匹配到 pod2 所對應(yīng)的特定路由，將流量發(fā)往 Node2 eth0 物理網(wǎng)卡。

流量從 hybrYYY 網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

Pod2 流量通過 veth-pair 網(wǎng)卡，即從 pod2 的 eth0->主機側(cè)的 hybrYYY，進入主機網(wǎng)絡(luò)棧中。

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

根據(jù)路由，將流量發(fā)往 10.0.0.1 所對應(yīng)的交換機。

在交換機上匹配到 pod1 所對應(yīng)的特定路由，將流量發(fā)往 Node1 eth0 物理網(wǎng)卡。

流量從 hybrXXX 網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

2.Calico

基本概念：

• 純?nèi)龑拥臄?shù)據(jù)中心網(wǎng)絡(luò)方案。
• 利用 Linux Kernel 使得宿主機實現(xiàn) vRouter 來負責(zé)數(shù)據(jù)轉(zhuǎn)發(fā)。
• vRouter 通過 BGP 協(xié)議傳播路由信息。
• 基于 iptables 還提供了豐富而靈活的網(wǎng)絡(luò)策略規(guī)則。

整體架構(gòu)

• Felix：運行在每個容器宿主節(jié)點上，主要負責(zé)配置路由、ACL 等信息來確保容器的聯(lián)通狀態(tài)。
• Brid：把 Felix 寫入 Kernel 的路由信息分發(fā)到 Calico 網(wǎng)絡(luò)，保證容器間的通信有效性。
• etcd：分布式的 Key/Value 存儲，負責(zé)網(wǎng)絡(luò)元數(shù)據(jù)一致性，確保 Calico 網(wǎng)絡(luò)狀態(tài)的準確性。
• RR：路由反射器，默認 Calico 工作在 node-mesh 模式，所有節(jié)點互相連接， node-mesh 。 模式在小規(guī)模部署時工作是沒有問題的，當(dāng)大規(guī)模部署時，連接數(shù)會非常大，消耗過多資源，利用 BGP RR ，可以避免這種情況的發(fā)生，通過一個或者多個 BGP RR 。 來完成集中式的路由分發(fā)，減少對網(wǎng)絡(luò)資源的消耗以及提高 Calico 工作效率、穩(wěn)定性。

通信路徑

（1）IPIP 模式

• 同節(jié)點通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

Pod1 流量通過 veth-pair 網(wǎng)卡，即從 pod1 的 eth0->主機側(cè)的 caliXXX，進入主機網(wǎng)絡(luò)棧中。

根據(jù)目的 IP，流量在路由表中匹配到 Pod2 的路由規(guī)則。

流量從 caliYYY 網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

Pod2 流量通過 veth-pair 網(wǎng)卡，即從 pod2 的 eth0->主機側(cè)的 caliYYY，進入主機網(wǎng)絡(luò)棧中。

根據(jù)目的 IP，流量在路由表中匹配到 Pod1 的路由規(guī)則。

流量從 caliXXX 網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

• 跨節(jié)點通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

Pod1 流量通過 veth-pair 網(wǎng)卡，即從 pod1 的 eth0->主機側(cè)的 caliXXX，進入主機網(wǎng)絡(luò)棧中。

src: pod1IP

dst: pod2IP

根據(jù)目的 IP，流量在路由表中匹配到將流量轉(zhuǎn)發(fā)到 tunl0 網(wǎng)卡上的路由規(guī)則。

src: pod1IP

dst: pod2IP

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

src: Node1IP

dst: Node2IP

流量從 Node2 的 eth0 網(wǎng)卡進入 Node2 的主機網(wǎng)絡(luò)棧。

src: Node1IP

dst: Node2IP

流量進入 tunl0 進行 IPIP 解包。

src: pod1IP

dst: pod2IP

流量從 caliYYY 網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

src: pod1IP

dst: pod2IP

回包過程：

Pod2 流量通過 veth-pair 網(wǎng)卡，即從 pod2 的 eth0->主機側(cè)的 caliYYY，進入主機網(wǎng)絡(luò)棧中。

src: pod2IP

dst: pod1IP

根據(jù)目的 IP，流量在路由表中匹配到將流量轉(zhuǎn)發(fā)到 tunl0 網(wǎng)卡上的路由規(guī)則。

src: pod2IP

dst: pod1IP

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

src: Node2IP

dst: Node1IP

流量從 Node1 的 eth0 網(wǎng)卡進入 Node1 的主機網(wǎng)絡(luò)棧。

src: Node2IP

dst: Node1IP

流量進入 tunl0 進行 IPIP 解包。

src: pod2IP

dst: pod1IP

流量從 caliXXX 網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

src: pod2IP

dst: pod1IP

（2）BGP 模式

• 同節(jié)點通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

Pod1 流量通過 veth-pair 網(wǎng)卡，即從 pod1 的 eth0->主機側(cè)的 caliXXX，進入主機網(wǎng)絡(luò)棧中。

根據(jù)目的 IP，流量在路由表中匹配到 Pod2 的路由規(guī)則。

流量從 caliYYY 網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

• Pod2 流量通過 veth-pair 網(wǎng)卡，即從 pod2 的 eth0->主機側(cè)的 caliYYY，進入主機網(wǎng)絡(luò)棧中。
• 根據(jù)目的 IP，流量在路由表中匹配到 Pod1 的路由規(guī)則。

流量從 caliXXX 網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

• 跨節(jié)點通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

Pod1 流量通過 veth-pair 網(wǎng)卡，即從 pod1 的 eth0->主機側(cè)的 caliXXX，進入主機網(wǎng)絡(luò)棧中。

根據(jù)目的 IP，流量在路由表中匹配到 Pod2 相對應(yīng)網(wǎng)段的路由規(guī)則，并從 Node1 eth0 物理網(wǎng)卡發(fā)出。

流量從 Node2 eth0 物理網(wǎng)卡進入，并從 caliYYY 網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

Pod2 流量通過 veth-pair 網(wǎng)卡，即從 pod2 的 eth0->主機側(cè)的 caliYYY，進入主機網(wǎng)絡(luò)棧中。

根據(jù)目的 IP，流量在路由表中匹配到 Pod1 相對應(yīng)網(wǎng)段的路由規(guī)則，并從 Node2 eth0 物理網(wǎng)卡發(fā)出。

流量從 Node1 eth0 物理網(wǎng)卡進入，并從 caliXXX 網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

3.Bifrost

整體架構(gòu)

• veth0-bifrXXX：bifrost 對于 macvlan 實現(xiàn) service 訪問的一套解決方案，通過 veth-pair 。 網(wǎng)卡完成在主機網(wǎng)絡(luò)棧中的 kube-proxy + iptables 對于服務(wù)流量轉(zhuǎn)化為對 pod 的訪問。
• eth0：容器內(nèi)的 eth0 網(wǎng)卡為主機 vlan 子網(wǎng)卡對應(yīng)的 macvlan 網(wǎng)卡。

通信路徑

（1）MACVLAN 模式

• 同節(jié)點同 vlan 通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

Pod1 流量通過 macvlan 網(wǎng)卡，即 pod1 的 eth0 走二層網(wǎng)絡(luò)進入 eth0-10 vlan 子網(wǎng)卡。

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

流量從 eth0-10 vlan 子網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

Pod2 流量通過 macvlan 網(wǎng)卡，即 pod2 的 eth0 走二層網(wǎng)絡(luò)進入 eth0-10 vlan 子網(wǎng)卡。

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

流量從 eth0-10 vlan 子網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

• 同節(jié)點跨 vlan 通信

Pod1 訪問 Pod2 的通信過程發(fā)包過程：

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

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

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

流量進入 Pod2 所在宿主機的物理網(wǎng)卡，并進入相對應(yīng)的 eth0-10 vlan 子網(wǎng)卡。

流量從 eth0-10 vlan 子網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

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

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

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

流量進入 Pod1 所在宿主機的物理網(wǎng)卡，并進入相對應(yīng)的 eth0-5 vlan 子網(wǎng)卡。

流量從 eth0-5 vlan 子網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

• 跨節(jié)點通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

流量進入 Pod2 所在宿主機的物理網(wǎng)卡，并進入相對應(yīng)的 eth0-10 vlan 子網(wǎng)卡。

流量從 eth0-10 vlan 子網(wǎng)卡進入 Pod2 容器網(wǎng)絡(luò)棧，完成發(fā)包動作。

回包過程：

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

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

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

流量進入 Pod1 所在宿主機的物理網(wǎng)卡，并進入相對應(yīng)的 eth0-5 vlan 子網(wǎng)卡。

流量從 eth0-5 vlan 子網(wǎng)卡進入 Pod1 容器網(wǎng)絡(luò)棧，完成回包動作。

四、面臨的問題及未來發(fā)展

1.IPv4/IPv6 雙棧

背景

IP 作為互聯(lián)網(wǎng)最基礎(chǔ)的要素，是為計算機網(wǎng)絡(luò)相互連接進行通信而設(shè)計的協(xié)議，正是因為有了 IP 協(xié)議，因特網(wǎng)才得以迅速發(fā)展成為世界上最大的、開放的計算機通信網(wǎng)絡(luò)。IP 協(xié)議隨著互聯(lián)網(wǎng)的發(fā)展，產(chǎn)生了 IPv4 和 IPv6 兩種協(xié)議：

• IPv4

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

• IPv6

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

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

IPv4 地址數(shù)量已經(jīng)不再滿足需求，需要 IPv6 地址進行擴展。

隨著國內(nèi)下一代互聯(lián)網(wǎng)發(fā)展政策的明確，客戶數(shù)據(jù)中心需要使用 IPv6 來符合更嚴格的監(jiān)管。

現(xiàn)狀

calico IPIP 不支持 IPv6 的原因:

• ipip 是普通的 IPIP 隧道，就是在報文的基礎(chǔ)上再封裝成一個 IPv4 報文，所以不支持 IPv6 的封包。

2.多網(wǎng)卡(多通信機制)

背景

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

目前的問題：

• 部分客戶真實 IP 資源緊張，導(dǎo)致無法全部使用 underlay 方案。
• 客戶希望把 UDP 網(wǎng)絡(luò)和 TCP 網(wǎng)絡(luò)分開，導(dǎo)致如基于 TCP 協(xié)議的網(wǎng)絡(luò)模型無法獨立存在于 UDP 網(wǎng)絡(luò)中。

現(xiàn)狀

目前實現(xiàn)多網(wǎng)卡的方案，大致兩種：

• 在單一 CNI 調(diào)用 IPAM 時，通過 CNI config 配置生成相對應(yīng)的網(wǎng)卡并分配合適的 IP 資源。
• 通過元 CNI 依次調(diào)用各個 CNI 來完成相對應(yīng)的網(wǎng)卡并分配合適的 IP 資源，如 multus 方案。

3.網(wǎng)絡(luò)流量管控

背景

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

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

目前的問題：

• 傳統(tǒng)防火墻在容器云的東西向場景下，難以起到流量管控，需要提供服務(wù)間或容器間流量管控的能力。

現(xiàn)狀

參考資料

1、calico vxlan ipv4 overlay組網(wǎng)跨主機通信分析

https://www.jianshu.com/p/5edd6982e3be

2、Qunar容器平臺網(wǎng)絡(luò)之道：Calico

http://dockone.io/article/2434328

3、最好的vxlan介紹

https://www.jianshu.com/p/cccfb481d548

4、揭秘 IPIP 隧道

https://morven.life/posts/networking-3-ipip/

5、BGP基礎(chǔ)知識

https://blog.csdn.net/qq_38265137/article/details/80439561

6、VLAN基礎(chǔ)知識

https://cshihong.github.io/2017/11/05/VLAN%E5%9F%BA%E7%A1%80%E7%9F%A5%E8%AF%86/

7、Overlay和Underlay網(wǎng)絡(luò)協(xié)議區(qū)別及概述講解

https://www.cnblogs.com/fengdejiyixx/p/15567609.html#%E4%BA%8Cunderlay%E7%BD%91%E7%BB%9C%E6%A8%A1%E5%9E%8B

8、東西向流量牽引方案小結(jié)

http://blog.nsfocus.net/east-west-flow-sum/

9、容器網(wǎng)絡(luò)接口(CNI)

https://jimmysong.io/kubernetes-handbook/concepts/cni.html

10、K8s 網(wǎng)絡(luò)之深入理解 CNI

https://zhuanlan.zhihu.com/p/450140876