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

一、背景

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

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

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

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

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

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

IPC ：System V IPC 和 POSIX 消息隊(duì)列；

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

PID：進(jìn)程；

Mount：掛載點(diǎn)；

UTS：主機(jī)名和域名；

USR：用戶和用戶組；

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)于 K8s 來講，網(wǎng)絡(luò)屬于最重要的功能之一，因?yàn)闆]有一個(gè)良好的網(wǎng)絡(luò)，集群不同節(jié)點(diǎn)之間甚至同一個(gè)節(jié)點(diǎn)之間的 pod 就無法良好的運(yùn)行起來。

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

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

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

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

• Hybridnet

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

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

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

• Calico

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

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

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

• Bifrost

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

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

支持 macvlan 對(duì)于 service 流量的訪問。

2.通信路徑介紹

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

• VXLAN

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

• IPIP

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

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

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

sit: sit 模式主要用于 IPv4 報(bào)文封裝 IPv6 報(bào)文，即 IPv6 over IPv4。

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

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

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

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

• BGP

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

• Vlan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.Hybridnet

整體架構(gòu)

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

通信路徑

（1）VXLAN 模式

• 同節(jié)點(diǎn)通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

回包過程：

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

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

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

• 跨節(jié)點(diǎn)通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

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

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

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

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

回包過程：

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

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

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

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

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

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

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

（2）VLAN 模式

• 同節(jié)點(diǎn)通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

回包過程：

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

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

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

• 跨節(jié)點(diǎn)通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

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

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

回包過程：

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

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

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

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

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

（3）BGP 模式

• 同節(jié)點(diǎn)通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

回包過程：

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

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

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

• 跨節(jié)點(diǎn)通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

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

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

回包過程：

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

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

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

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

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

2.Calico

基本概念：

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

整體架構(gòu)

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

通信路徑

（1）IPIP 模式

• 同節(jié)點(diǎn)通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

回包過程：

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

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

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

• 跨節(jié)點(diǎn)通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

src: pod1IP

dst: pod2IP

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

src: pod1IP

dst: pod2IP

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

src: Node1IP

dst: Node2IP

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

src: Node1IP

dst: Node2IP

流量進(jìn)入 tunl0 進(jìn)行 IPIP 解包。

src: pod1IP

dst: pod2IP

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

src: pod1IP

dst: pod2IP

回包過程：

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

src: pod2IP

dst: pod1IP

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

src: pod2IP

dst: pod1IP

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

src: Node2IP

dst: Node1IP

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

src: Node2IP

dst: Node1IP

流量進(jìn)入 tunl0 進(jìn)行 IPIP 解包。

src: pod2IP

dst: pod1IP

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

src: pod2IP

dst: pod1IP

（2）BGP 模式

• 同節(jié)點(diǎn)通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

回包過程：

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

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

• 跨節(jié)點(diǎn)通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

回包過程：

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

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

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

3.Bifrost

整體架構(gòu)

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

通信路徑

（1）MACVLAN 模式

• 同節(jié)點(diǎn)同 vlan 通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

回包過程：

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

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

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

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

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

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

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

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

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

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

回包過程：

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

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

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

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

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

• 跨節(jié)點(diǎn)通信

Pod1 訪問 Pod2 的通信過程

發(fā)包過程：

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

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

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

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

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

回包過程：

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

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

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

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

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

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

1.IPv4/IPv6 雙棧

背景

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

• IPv4

IPv4 是互聯(lián)網(wǎng)協(xié)議第四版，是計(jì)算機(jī)網(wǎng)絡(luò)使用的數(shù)據(jù)報(bào)傳輸機(jī)制，此協(xié)議是第一個(gè)被廣泛部署的 IP 協(xié)議。每一個(gè)連接 Internet 的設(shè)備(不管是交換機(jī)、PC 還是其他設(shè)備)，都會(huì)為其分配一個(gè)唯一的 IP 地址，如 192.149.252.76，如下圖所示，IPv4 使用 32 位(4 字節(jié))地址，大約可以存儲(chǔ) 43 億個(gè)地址，但隨著越來越多的用戶接入到 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 的地址長(zhǎng)度為 128 位，可支持 340 多萬億個(gè)地址。如下圖，3ffe:1900:fe21:4545:0000:0000:0000:0000，這是一個(gè) IPv6 地址，IPv6 地址通常分為 8 組，4 個(gè)十六進(jìn)制數(shù)為一組，每組之間用冒號(hào)分隔。

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

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

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

現(xiàn)狀

calico IPIP 不支持 IPv6 的原因:

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

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

背景

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

目前的問題：

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

現(xiàn)狀

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

• 在單一 CNI 調(diào)用 IPAM 時(shí)，通過 CNI config 配置生成相對(duì)應(yīng)的網(wǎng)卡并分配合適的 IP 資源。
• 通過元 CNI 依次調(diào)用各個(gè) CNI 來完成相對(duì)應(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)宿主機(jī)和容器、容器間或宿主機(jī)間的流量，南北向流量為容器云外部與容器云內(nèi)部之間交互的流量。

目前的問題：

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

現(xiàn)狀

參考資料

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

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

2、Qunar容器平臺(tái)網(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ǔ)知識(shí)

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

6、VLAN基礎(chǔ)知識(shí)

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