本文分別介紹Overlay網(wǎng)絡(luò)模型和Underlay網(wǎng)絡(luò)模型。

（一） Overlay網(wǎng)絡(luò)模型

物理網(wǎng)絡(luò)模型中，連通多個(gè)物理網(wǎng)橋上的主機(jī)的一個(gè)簡單辦法是通過媒介直接連接這些網(wǎng)橋設(shè)備，各個(gè)主機(jī)處于同一個(gè)局域網(wǎng)（LAN）之中，管理員只需要確保各個(gè)網(wǎng)橋上每個(gè)主機(jī)的IP地址不相互沖突即可。

類似地，若能夠直接連接宿主機(jī)上的虛擬網(wǎng)橋形成一個(gè)大的局域網(wǎng)，就能在數(shù)據(jù)鏈路層打通各宿主機(jī)上的內(nèi)部網(wǎng)絡(luò)，讓容器可通過自有IP地址直接通信。為避免各容器間的IP地址沖突，一個(gè)常見的解決方案是將每個(gè)宿主機(jī)分配到同一網(wǎng)絡(luò)中的不同子網(wǎng)，各主機(jī)基于自有子網(wǎng)向其容器分配IP地址。

顯然，主機(jī)間的網(wǎng)絡(luò)通信只能經(jīng)由主機(jī)上可對(duì)外通信的網(wǎng)絡(luò)接口進(jìn)行，跨主機(jī)在數(shù)據(jù)鏈路層直接連接虛擬網(wǎng)橋的需求必然難以實(shí)現(xiàn)，除非借助宿主機(jī)間的通信網(wǎng)絡(luò)構(gòu)建的通信“隧道”進(jìn)行數(shù)據(jù)幀轉(zhuǎn)發(fā)。這種于某個(gè)通信網(wǎng)絡(luò)之上構(gòu)建出的另一個(gè)邏輯通信網(wǎng)絡(luò)通常即10.1.2節(jié)提及的Overlay網(wǎng)絡(luò)或Underlay網(wǎng)絡(luò)。圖10-7為Overlay網(wǎng)絡(luò)功能示意圖。

圖10-7 Overlay網(wǎng)絡(luò)功能示意圖

隧道轉(zhuǎn)發(fā)的本質(zhì)是將容器雙方的通信報(bào)文分別封裝成各自宿主機(jī)之間的報(bào)文，借助宿主機(jī)的網(wǎng)絡(luò)“隧道”完成數(shù)據(jù)交換。這種虛擬網(wǎng)絡(luò)的基本要求是各宿主機(jī)只需支持隧道協(xié)議即可，對(duì)于底層網(wǎng)絡(luò)沒有特殊要求。

VXLAN協(xié)議是目前最流行的Overlay網(wǎng)絡(luò)隧道協(xié)議之一，它也是由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ò)展，將“二層域”突破規(guī)模限制形成“大二層域”。

那么，同一大二層域就類似于傳統(tǒng)網(wǎng)絡(luò)中VLAN（虛擬局域網(wǎng)）的概念，只不過在VXLAN網(wǎng)絡(luò)中，它被稱作Bridge-Domain，以下簡稱為BD。類似于不同的VLAN需要通過VLAN ID進(jìn)行區(qū)分，各BD要通過VNI加以標(biāo)識(shí)。

但是，為了確保VXLAN機(jī)制通信過程的正確性，涉及VXLAN通信的IP報(bào)文一律不能分片，這就要求物理網(wǎng)絡(luò)的鏈路層實(shí)現(xiàn)中必須提供足夠大的MTU值，或修改其MTU值以保證VXLAN報(bào)文的順利傳輸。不過，降低默認(rèn)MTU值，以及額外的頭部開銷，必然會(huì)影響到報(bào)文傳輸性能。

VXLAN的顯著的優(yōu)勢(shì)之一是對(duì)底層網(wǎng)絡(luò)沒有侵入性，管理員只需要在原有網(wǎng)絡(luò)之上添加一些額外設(shè)備即可構(gòu)建出虛擬的邏輯網(wǎng)絡(luò)來。這個(gè)額外添加的設(shè)備稱為VTEP（VXLAN Tunnel Endpoints），它工作于VXLAN網(wǎng)絡(luò)的邊緣，負(fù)責(zé)相關(guān)協(xié)議報(bào)文的封包和解包等操作，從作用來說相當(dāng)于VXLAN隧道的出入口設(shè)備。

VTEP代表著一類支持VXLAN協(xié)議的交換機(jī)，而支持VXLAN協(xié)議的操作系統(tǒng)也可將一臺(tái)主機(jī)模擬為VTEP，Linux內(nèi)核自3.7版本開始通過vxlan內(nèi)核模塊原生支持此協(xié)議。

于是，各主機(jī)上由虛擬網(wǎng)橋構(gòu)建的LAN便可借助vxlan內(nèi)核模塊模擬的VTEP設(shè)備與其他主機(jī)上的VTEP設(shè)備進(jìn)行對(duì)接，形成隧道網(wǎng)絡(luò)。同一個(gè)二層域內(nèi)的各VTEP之間都需要建立VXLAN隧道，因此跨主機(jī)的容器間直接進(jìn)行二層通信的VXLAN隧道是各VTEP之間的點(diǎn)對(duì)點(diǎn)隧道，如圖10-8所示。

對(duì)于Flannel來說，這個(gè)VTEP設(shè)備就是各節(jié)點(diǎn)上生成flannel.1網(wǎng)絡(luò)接口，其中的“1”是VXLAN中的BD標(biāo)識(shí)VNI，因而同一Kubernetes集群上所有節(jié)點(diǎn)的VTEP設(shè)備屬于VNI為1的同一個(gè)BD。

圖10-8 Linux VTEP

類似VLAN的工作機(jī)制，相同VXLAN VNI在不同VTEP之間的通信要借助二層網(wǎng)關(guān)來完成，而不同VXLAN之間，或者VXLAN同非VXLAN之間的通信則需經(jīng)由三層網(wǎng)關(guān)實(shí)現(xiàn)。VXLAN支持使用集中式和分布式兩種形式的網(wǎng)關(guān)：前者支持流量的集中管理，配置和維護(hù)較為簡單，但轉(zhuǎn)發(fā)效率不高，且容易出現(xiàn)瓶頸和網(wǎng)關(guān)可用性問題；后者以各節(jié)點(diǎn)為二層或三層網(wǎng)關(guān)，消除了瓶頸。

然而，VXLAN網(wǎng)絡(luò)中的容器在首次通信之前，源VTEP又如何得知目標(biāo)服務(wù)器在哪一個(gè)VTEP，并選擇正確的路徑傳輸通信報(bào)文呢？

常見的解決思路一般有兩種：多播和控制中心。

多播是指同一個(gè)BD內(nèi)的各VTEP加入同一個(gè)多播域中，通過多播報(bào)文查詢目標(biāo)容器所在的目標(biāo)VTEP。

而控制中心則在某個(gè)共享的存儲(chǔ)服務(wù)上保存所有容器子網(wǎng)及相關(guān)VTEP的映射信息，各主機(jī)上運(yùn)行著相關(guān)的守護(hù)進(jìn)程，并通過與控制中心的通信獲取相關(guān)的映射信息。Flannel默認(rèn)的VXLAN后端采用的是后一種方式，它把網(wǎng)絡(luò)配置信息存儲(chǔ)在etcd系統(tǒng)上。

Linux內(nèi)核自3.7版本開始支持vxlan模塊，此前的內(nèi)核版本可以使用UDP、IPIP或GRE隧道技術(shù)。事實(shí)上，考慮到當(dāng)今公有云底層網(wǎng)絡(luò)的功能限制，Overlay網(wǎng)絡(luò)反倒是一種最為可行的容器網(wǎng)絡(luò)解決方案，僅那些更注重網(wǎng)絡(luò)性能的場(chǎng)景才會(huì)選擇Underlay網(wǎng)絡(luò)。

（二）Underlay網(wǎng)絡(luò)模型

Underlay網(wǎng)絡(luò)就是傳統(tǒng)IT基礎(chǔ)設(shè)施網(wǎng)絡(luò)，由交換機(jī)和路由器等設(shè)備組成，借助以太網(wǎng)協(xié)議、路由協(xié)議和VLAN協(xié)議等驅(qū)動(dòng)，它還是Overlay網(wǎng)絡(luò)的底層網(wǎng)絡(luò)，為Overlay網(wǎng)絡(luò)提供數(shù)據(jù)通信服務(wù)。容器網(wǎng)絡(luò)中的Underlay網(wǎng)絡(luò)是指借助驅(qū)動(dòng)程序?qū)⑺拗鳈C(jī)的底層網(wǎng)絡(luò)接口直接暴露給容器使用的一種網(wǎng)絡(luò)構(gòu)建技術(shù)，較為常見的解決方案有MAC VLAN、IP VLAN和直接路由等。

1. MAC VLAN

MAC VLAN支持在同一個(gè)以太網(wǎng)接口上虛擬出多個(gè)網(wǎng)絡(luò)接口，每個(gè)虛擬接口都擁有唯一的MAC地址，并可按需配置IP地址。通常這類虛擬接口被網(wǎng)絡(luò)工程師稱作子接口，但在MAC VLAN中更常用上層或下層接口來表述。與Bridge模式相比，MAC VLAN不再依賴虛擬網(wǎng)橋、NAT和端口映射，它允許容器以虛擬接口方式直接連接物理接口。圖10-9給出了Bridge與MAC VLAN網(wǎng)絡(luò)對(duì)比示意圖。

圖10-9 Bridge與MAC VLAN網(wǎng)絡(luò)對(duì)比

MAC VLAN有Private、VEPA、Bridge和Passthru幾種工作模式，它們各自的工作特性如下。

Private：禁止構(gòu)建在同一物理接口上的多個(gè)MAC VLAN實(shí)例（容器接口）彼此間的通信，即便外部的物理交換機(jī)支持“發(fā)夾模式”也不行。

VPEA：允許構(gòu)建在同一物理接口上的多個(gè)MAC VLAN實(shí)例（容器接口）彼此間的通信，但需要外部交換機(jī)啟用發(fā)夾模式，或者存在報(bào)文轉(zhuǎn)發(fā)功能的路由器設(shè)備。

Bridge：將物理接口配置為網(wǎng)橋，從而允許同一物理接口上的多個(gè)MAC VLAN實(shí)例基于此網(wǎng)橋直接通信，而無須依賴外部的物理交換機(jī)來交換報(bào)文；此為最常用的模式，甚至還是Docker容器唯一支持的模式。

Passthru：允許其中一個(gè)MAC VLAN實(shí)例直接連接物理接口。

由上述工作模式可知，除了Passthru模式外的容器流量將被MAC VLAN過濾而無法與底層主機(jī)通信，從而將主機(jī)與其運(yùn)行的容器完全隔離，其隔離級(jí)別甚至高于網(wǎng)橋式網(wǎng)絡(luò)模型，這對(duì)于有多租戶需求的場(chǎng)景尤為有用。

由于各實(shí)例都有專用的MAC地址，因此MAC VLAN允許傳輸廣播和多播流量，但它要求物理接口工作于混雜模式，考慮到很多公有云環(huán)境中并不允許使用混雜模式，這意味著MAC VLAN更適用于本地網(wǎng)絡(luò)環(huán)境。

需要注意的是，MAC VLAN為每個(gè)容器使用一個(gè)唯一的MAC地址，這可能會(huì)導(dǎo)致具有安全策略以防止MAC欺騙的交換機(jī)出現(xiàn)問題，因?yàn)檫@類交換機(jī)的每個(gè)接口只允許連接一個(gè)MAC地址。另外，有些物理網(wǎng)卡存在可支撐的MAC地址數(shù)量上限。

2. IP VLAN

IP VLAN類似于MAC VLAN，它同樣創(chuàng)建新的虛擬網(wǎng)絡(luò)接口并為每個(gè)接口分配唯一的IP地址，不同之處在于，每個(gè)虛擬接口將共享使用物理接口的MAC地址，從而不再違反防止MAC欺騙的交換機(jī)的安全策略，且不要求在物理接口上啟用混雜模式，如圖10-10所示。

圖10-10 MAC VLAN對(duì)比IP VLAN

IP VLAN有L2和L3兩種模型，其中IP VLAN L2的工作模式類似于MAC VLAN Bridge模式，上層接口（物理接口）被用作網(wǎng)橋或交換機(jī)，負(fù)責(zé)為下層接口交換報(bào)文；

而IP VLAN L3模式中，上層接口扮演路由器的角色，負(fù)責(zé)為各下層接口路由報(bào)文，如圖10-11所示。

IP VLAN L2模型與MAC VLAN Bridge模型都支持ARP協(xié)議和廣播流量，它們擁有直接接入網(wǎng)橋設(shè)備的網(wǎng)絡(luò)接口，能夠通過802.1d數(shù)據(jù)包進(jìn)行泛洪和MAC地址學(xué)習(xí)。但I(xiàn)P VLAN L3模式下，網(wǎng)絡(luò)棧在容器內(nèi)處理，不支持多播或廣播流量，從這個(gè)意義上講，它的運(yùn)行模式與路由器的報(bào)文處理機(jī)制相同。

雖然支持多種網(wǎng)絡(luò)模型，但MAC VLAN和IP VLAN不能同時(shí)在同一物理接口上使用。Linux內(nèi)核文檔中強(qiáng)調(diào)，MAC VLAN和IP VLAN具有較高的相似度，因此，通常僅在必須使用IP VLAN的場(chǎng)景中才不使用MAC VLAN。一般說來，強(qiáng)依賴于IP VLAN的場(chǎng)景有如下幾個(gè)：

Linux主機(jī)連接到的外部交換機(jī)或路由器啟用了防止MAC地址欺騙的安全策略；

虛擬接口的需求數(shù)量超出物理接口能夠支撐的容量上限，并且將接口置于混雜模式會(huì)給性能帶來較大的負(fù)面影響；

將虛擬接口放入不受信任的網(wǎng)絡(luò)名稱空間中可能會(huì)導(dǎo)致惡意的濫用。

圖10-11 IP VLAN的L2和L3模型

需要注意的是，Linux內(nèi)核自4.2版本后才支持IP VLAN網(wǎng)絡(luò)驅(qū)動(dòng)，且在Linux主機(jī)上使用ip link命令創(chuàng)建的802.1q配置接口不具有持久性，因此需依賴管理員通過網(wǎng)絡(luò)啟動(dòng)腳本保持配置。

3. 直接路由

“直接路由”模型放棄了跨主機(jī)容器在L2的連通性，而專注于通過路由協(xié)議提供容器在L3的通信方案。這種解決方案因?yàn)楦子诩傻浆F(xiàn)在的數(shù)據(jù)中心的基礎(chǔ)設(shè)施之上，便捷地連接容器和主機(jī)，并在報(bào)文過濾和隔離方面有著更好的擴(kuò)展能力及更精細(xì)的控制模型，因而成為容器化網(wǎng)絡(luò)較為流行的解決方案之一。

一個(gè)常用的直接路由解決方案如圖10-12所示，每個(gè)主機(jī)上的各容器在二層通過網(wǎng)橋連通，網(wǎng)關(guān)指向當(dāng)前主機(jī)上的網(wǎng)橋接口地址。跨主機(jī)的容器間通信，需要依據(jù)主機(jī)上的路由表指示完成報(bào)文路由，因此每個(gè)主機(jī)的物理接口地址都有可能成為另一個(gè)主機(jī)路由報(bào)文中的“下一跳”，這就要求各主機(jī)的物理接口必須位于同一個(gè)L2網(wǎng)絡(luò)中。

于是，在較大規(guī)模的主機(jī)集群中，問題的關(guān)鍵便轉(zhuǎn)向如何更好地為每個(gè)主機(jī)維護(hù)路由表信息。常見的解決方案有：

①Flannel host-gw使用存儲(chǔ)總線etcd和工作在每個(gè)節(jié)點(diǎn)上的flanneld進(jìn)程動(dòng)態(tài)維護(hù)路由；

②Calico使用BGP（Border Gateway Protocol）協(xié)議在主機(jī)集群中自動(dòng)分發(fā)和學(xué)習(xí)路由信息。與Flannel不同的是，Calico并不會(huì)為容器在主機(jī)上使用網(wǎng)橋，而是僅為每個(gè)容器生成一對(duì)veth設(shè)備，留在主機(jī)上的那一端會(huì)在主機(jī)上生成目標(biāo)地址，作為當(dāng)前容器的路由條目。

圖10-12直接路由虛擬網(wǎng)絡(luò)示意圖

顯然，較Overlay來說，無論是MAC VLAN、IP VLAN還是直接路由機(jī)制的Underlay網(wǎng)絡(luò)模型的實(shí)現(xiàn)，它們因無須額外的報(bào)文開銷而通常有著更好的性能表現(xiàn)，但對(duì)底層網(wǎng)絡(luò)有著更多的限制條件。

編輯：jq