湯聞達(dá)

（中匯信息技術(shù)（上海）有限公司 上海市 201210）

1 背景

伴隨著容器技術(shù)的成熟與微服務(wù)理念的普及，業(yè)務(wù)彈性和敏捷交付的訴求催生了一系列云原生技術(shù)。云原生計(jì)算基金會(huì)（Cloud Native Computing Foundation, CNCF）對(duì)云原生做出了如下的定義：云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動(dòng)態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API。結(jié)合標(biāo)準(zhǔn)化自動(dòng)化運(yùn)維，云原生技術(shù)可幫助企業(yè)很方便地對(duì)容器化應(yīng)用做出頻繁且可預(yù)測(cè)的變更。

事實(shí)上，數(shù)據(jù)中心資源無(wú)外乎計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)。云原生與傳統(tǒng)架構(gòu)在承載業(yè)務(wù)應(yīng)用的區(qū)別主要是在計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源管理和編排調(diào)度方式上的差異，而針對(duì)這些差異的理解與消化直接影響了企業(yè)上云業(yè)務(wù)應(yīng)用的運(yùn)行質(zhì)量以及業(yè)務(wù)變更的靈活性。除此以外，對(duì)于那些采用本地部署（on-premises）云平臺(tái)的用戶(hù)，還涉及到數(shù)據(jù)中心基礎(chǔ)設(shè)施的建設(shè)與維護(hù)成本。

1.1 數(shù)據(jù)中心傳統(tǒng)網(wǎng)絡(luò)架構(gòu)與云原生的碰撞

宏觀上看，網(wǎng)絡(luò)資源作為數(shù)據(jù)傳輸?shù)母咚俟泛图~帶，可以數(shù)據(jù)中心網(wǎng)絡(luò)的構(gòu)建也無(wú)外乎由路由交換設(shè)備、服務(wù)器設(shè)備等實(shí)體硬件構(gòu)成，各類(lèi)資源的可達(dá)性和能力優(yōu)勢(shì)完全依賴(lài)于數(shù)據(jù)中心的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。

傳統(tǒng)數(shù)據(jù)中心主要承載的是南北向的網(wǎng)絡(luò)流量（即數(shù)據(jù)中心外到數(shù)據(jù)中心內(nèi)的流量，可以是外部流量到內(nèi)部服務(wù)器，也可以是內(nèi)部服務(wù)器到外部的流量）。相應(yīng)的網(wǎng)絡(luò)架構(gòu)通常是三層結(jié)構(gòu)。思科（Cisco）稱(chēng)之為：分級(jí)的互連網(wǎng)絡(luò)模型（Hierarchical Internetworking Model）。這個(gè)模型主要包含了以下三層：接入層（Access Layer）、匯聚層（Aggregation Layer）和核心層（Core Layer）[1]。接入層交換機(jī)通常位于數(shù)據(jù)中心機(jī)房?jī)?nèi)的機(jī)架頂部，所以它們也被常常稱(chēng)為T(mén)oR（Top of Rack）交換機(jī)，由于它們直接連接著實(shí)際的物理服務(wù)器，可以提供網(wǎng)絡(luò)接入的能力，所以叫做接入層交換機(jī)。匯聚交換機(jī)下連接入層交換機(jī)，用于提供防火墻策略執(zhí)行等能力。核心交換機(jī)一方面為流入整個(gè)數(shù)據(jù)中心的數(shù)據(jù)包提供高速轉(zhuǎn)發(fā)能力，另一方面下連多個(gè)匯聚層交換機(jī)并提供它們之間的連通性。

典型的數(shù)據(jù)中心三層網(wǎng)絡(luò)架構(gòu)如圖1 所示。

按OSI（Open System Interconnection）七層參考模型，通常情況下的匯聚交換機(jī)是數(shù)據(jù)鏈路層和網(wǎng)絡(luò)層的分界點(diǎn)，匯聚交換機(jī)以下的是數(shù)據(jù)鏈路層，以上是網(wǎng)絡(luò)層。匯聚交換機(jī)和接入交換機(jī)之間通常為了防止數(shù)據(jù)鏈路層環(huán)路或廣播風(fēng)暴破壞網(wǎng)絡(luò)等問(wèn)題，運(yùn)行著生成樹(shù)協(xié)議（Spanning Tree Protocol，STP）。STP 使得對(duì)于一個(gè)VLAN 網(wǎng)絡(luò)只有一個(gè)匯聚層交換機(jī)可用，其他的匯聚層交換機(jī)僅在出現(xiàn)故障時(shí)才被使用（上圖中紅色虛線(xiàn)表示備份線(xiàn)路），也就是說(shuō)匯聚層是一個(gè)“主備”的高可用模式[2]，其余網(wǎng)絡(luò)設(shè)備的能力沒(méi)有被充分利用。通過(guò)應(yīng)用TRILL（Transparent Interconnection of Lots of Links,多鏈路透明互聯(lián)）技術(shù)，在數(shù)據(jù)鏈路層引入IS-IS（Intermediate System-to-Intermediate System，中間系統(tǒng)到中間系統(tǒng)）這樣的可運(yùn)行于鏈路層的路由協(xié)議，可將數(shù)據(jù)鏈路層的簡(jiǎn)單靈活和網(wǎng)絡(luò)層的穩(wěn)定可靠相結(jié)合，實(shí)現(xiàn)針對(duì)已知單播數(shù)據(jù)包轉(zhuǎn)發(fā)的等價(jià)多路徑負(fù)載分擔(dān)，從而規(guī)避應(yīng)用STP 所產(chǎn)生的帶寬利用率低等問(wèn)題[3]。

目前已有大量數(shù)據(jù)中心中在使用這種三層網(wǎng)絡(luò)架構(gòu)，這樣的架構(gòu)可以很方便地支持?jǐn)?shù)據(jù)中心南北向流量。但是近年來(lái)伴隨著互聯(lián)網(wǎng)業(yè)務(wù)的迅猛增長(zhǎng)和日趨完善的應(yīng)用微服務(wù)改造，數(shù)據(jù)中心虛擬化要求著更高的東西向流量（數(shù)據(jù)中心內(nèi)的服務(wù)器之間的流量），甚至跨數(shù)據(jù)中心流量。據(jù)一份來(lái)自思科的網(wǎng)絡(luò)分析報(bào)告描述，預(yù)計(jì)到2021年末，東西向流量將占數(shù)據(jù)中心總流量72%，遠(yuǎn)超南北向流量（15%），數(shù)據(jù)中心間流量（14%）[4]。

需要指出的是，盡管上述傳統(tǒng)三層網(wǎng)絡(luò)架構(gòu)也能夠支持東西向流量，但是效率并不高（即便采用TRILL 技術(shù)），這主要體現(xiàn)在一旦發(fā)生網(wǎng)絡(luò)層的東西向流量傳輸需求，都必須經(jīng)過(guò)核心交換機(jī)完成轉(zhuǎn)發(fā)，這不僅浪費(fèi)了寶貴的核心交換機(jī)資源，多層轉(zhuǎn)發(fā)也增加了傳輸延時(shí)。

1.2 云原生數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)特征

云原生對(duì)于數(shù)據(jù)中心網(wǎng)絡(luò)的需求，可以分別從基礎(chǔ)設(shè)施平臺(tái)以及業(yè)務(wù)需求兩方面來(lái)進(jìn)行分析。從基礎(chǔ)設(shè)施平臺(tái)方面來(lái)看，整個(gè)平臺(tái)正在向分布式彈性化的方向發(fā)展，其在承載上層應(yīng)用有關(guān)性能、可擴(kuò)展性與可靠性方面都有對(duì)應(yīng)的保障要求，并且各個(gè)微服務(wù)間的通信流量均衡與故障應(yīng)對(duì)（如服務(wù)降級(jí)、熔斷、限流）等均需交由平臺(tái)進(jìn)行處理。從業(yè)務(wù)需求方面來(lái)看，傳統(tǒng)單體應(yīng)用正在向微服務(wù)架構(gòu)進(jìn)行演進(jìn)，以充分利用平臺(tái)的彈性可擴(kuò)展能力，這種將計(jì)算與存儲(chǔ)分離的方式對(duì)網(wǎng)絡(luò)資源的調(diào)配要求更高。

圖1：典型數(shù)據(jù)中心三層網(wǎng)絡(luò)架構(gòu)

圖2：Spine-Leaf 網(wǎng)絡(luò)拓?fù)?/p>

圖3：宿主機(jī)docker0 網(wǎng)橋網(wǎng)絡(luò)拓?fù)涫疽?/p>

圖4：兩個(gè)宿主機(jī)上容器基于Flannel UDP 模式的通信過(guò)程

從業(yè)界實(shí)踐上來(lái)看，一種基于Clos 網(wǎng)絡(luò)模型的扁平化網(wǎng)絡(luò)架構(gòu)Spine-Leaf 可以為數(shù)據(jù)中心提供高帶寬、低延遲、非阻塞的端到端連接。并且，它能夠在性能、高可用等方面為上述需求的滿(mǎn)足提供一定的支撐作用。圖2 是一個(gè)典型的兩級(jí)Spine-Leaf 網(wǎng)絡(luò)拓?fù)洹?/p>

在以上的兩級(jí)Clos[5]拓?fù)渲?，每個(gè)低層級(jí)的交換機(jī)（Leaf）都會(huì)連接到每個(gè)高層級(jí)的交換機(jī)（Spine）。與三層網(wǎng)絡(luò)架構(gòu)類(lèi)似，這里L(fēng)eaf 層由接入交換機(jī)組成，用于連接服務(wù)器等設(shè)備。Spine 層負(fù)責(zé)將所有的Leaf 連接起來(lái)，這里每個(gè)Leaf 都會(huì)連接到每個(gè)Spine。任意一個(gè)Spine 發(fā)生故障，都不會(huì)影響到整個(gè)網(wǎng)絡(luò)的正常運(yùn)轉(zhuǎn)，且吞吐性能只會(huì)有輕微的下降。與三層網(wǎng)絡(luò)架構(gòu)不同的是，Leaf 交換機(jī)與Spine 交換機(jī)間的網(wǎng)絡(luò)流量都是網(wǎng)絡(luò)層以上的流量，因此可充分利用到網(wǎng)絡(luò)層等價(jià)多路徑路由特性，實(shí)現(xiàn)網(wǎng)絡(luò)鏈路的負(fù)載均衡。同時(shí)，在任意Leaf-Spine 鏈路發(fā)生故障時(shí)，實(shí)現(xiàn)快速切換。在上述基礎(chǔ)上，網(wǎng)絡(luò)擴(kuò)容與接入資源的擴(kuò)容只需對(duì)應(yīng)增加一個(gè)Spine 交換機(jī)和Leaf 交換機(jī)即可，這樣可很方便解決鏈路擁塞問(wèn)題，且實(shí)現(xiàn)了無(wú)阻塞的網(wǎng)絡(luò)架構(gòu)。

在Spine-Leaf 架構(gòu)中，任意一個(gè)服務(wù)器到另一個(gè)服務(wù)器的連接，都會(huì)經(jīng)過(guò)相同數(shù)量的設(shè)備（除非這兩個(gè)服務(wù)器在同一Leaf 下面）。因?yàn)橐粋€(gè)數(shù)據(jù)包只需要經(jīng)過(guò)一個(gè)Spine 和另一個(gè)Leaf 就可以到達(dá)目的地，這就使得整個(gè)網(wǎng)絡(luò)中任意的端到端連接延遲是可預(yù)測(cè)的。因此，當(dāng)數(shù)據(jù)中心的物理設(shè)備間通過(guò)Spine-Leaf 網(wǎng)絡(luò)架構(gòu)互聯(lián)后，即可較為高效地處理數(shù)據(jù)中心的東西向網(wǎng)絡(luò)流量，并同時(shí)保證低的、可預(yù)測(cè)的網(wǎng)絡(luò)間延遲，從而為部署于物理機(jī)器上的各個(gè)應(yīng)用容器提供靈活、高性能的通信。

2 云原生容器網(wǎng)絡(luò)的需求與實(shí)現(xiàn)

云原生架構(gòu)以容器和Kubernetes 為核心調(diào)度組件構(gòu)建了一整套微服務(wù)生態(tài)系統(tǒng)。愛(ài)因斯坦曾經(jīng)說(shuō)過(guò)：“如果沒(méi)有界定范疇和一般概念，思考就像在真空中呼吸，是不可能的。”容器技術(shù)的大規(guī)模靈活運(yùn)用同樣離不開(kāi)底層宿主機(jī)間網(wǎng)絡(luò)性能的支撐。云原生容器網(wǎng)絡(luò)立足于前文描述的數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)，聚焦于微觀的技術(shù)實(shí)現(xiàn)，目的是為泛在的容器提供堅(jiān)實(shí)的網(wǎng)絡(luò)通信基礎(chǔ)。

2.1 容器網(wǎng)絡(luò)的需求

盡管運(yùn)行于宿主機(jī)上的容器可以直接使用宿主機(jī)網(wǎng)絡(luò)棧，從而為容器提供良好的網(wǎng)絡(luò)性能，但這樣做會(huì)不可避免地引入共享網(wǎng)絡(luò)資源的問(wèn)題，比如端口沖突等。和虛擬機(jī)的使用類(lèi)似，大多數(shù)情況下都希望容器能擁有獨(dú)占的網(wǎng)絡(luò)資源。但在擁有獨(dú)占網(wǎng)絡(luò)資源后，依然面臨兩個(gè)問(wèn)題：一是各個(gè)容器間如何進(jìn)行有效通信？二是容器和其他非容器應(yīng)用（宿主機(jī)、非宿主機(jī)等）如何通信？

Pod 是Kubernetes 的原子，是構(gòu)建應(yīng)用程序的最小可部署對(duì)象。單個(gè)Pod 代表集群中正在運(yùn)行的工作負(fù)載，其一般封裝一個(gè)或多個(gè)容器（比如基于Docker 運(yùn)行時(shí)的容器）。

Kubernetes 使用了一種“IP-per-Pod”網(wǎng)絡(luò)模型：它為每一個(gè)Pod 分配了一個(gè)IP 地址，Pod 內(nèi)部的容器共享同一個(gè)網(wǎng)絡(luò)空間（相同的網(wǎng)絡(luò)設(shè)備和IP），且一個(gè)Pod 的IP 地址并不會(huì)隨著Pod 中的一個(gè)容器的起停而改變。

Kubernetes 中的網(wǎng)絡(luò)要解決的核心問(wèn)題就是為每臺(tái)容器宿主機(jī)的進(jìn)行IP 地址網(wǎng)段的劃分，以及容器IP 地址的分配。主要概括為：

（1）每個(gè)Pod 擁有集群內(nèi)唯一的IP 地址

（2）不同宿主機(jī)節(jié)點(diǎn)的容器IP 地址劃分不會(huì)重復(fù)

（3）宿主機(jī)節(jié)點(diǎn)的不同Pod 可以互相通信

（4）不同宿主機(jī)節(jié)點(diǎn)的Pod 可以與跨節(jié)點(diǎn)的主機(jī)互相通信

Kubernetes 提出了針對(duì)Pod 的網(wǎng)絡(luò)模型，但是并沒(méi)有提供具體實(shí)現(xiàn)細(xì)節(jié)。因此，任何滿(mǎn)足Kubernetes 網(wǎng)絡(luò)模型接口的都可視作一種有效的容器網(wǎng)絡(luò)技術(shù)實(shí)現(xiàn)。容器網(wǎng)絡(luò)插件則是針對(duì)Pod 的網(wǎng)絡(luò)模型，通過(guò)不同的方法，實(shí)現(xiàn)不同宿主機(jī)上的容器通信目標(biāo)。

2.2 主流網(wǎng)絡(luò)插件解決方案

2.2.1 虛擬化協(xié)議棧

虛擬化協(xié)議棧主要目的在于從一臺(tái)物理主機(jī)中分離出多個(gè)TCP/IP 協(xié)議棧進(jìn)行資源隔離使用。Network Namespace 是實(shí)現(xiàn)網(wǎng)絡(luò)虛擬化的重要功能，網(wǎng)絡(luò)空間有獨(dú)自的網(wǎng)絡(luò)棧信息，路由表，防火墻策略等。采用Network Namespace 網(wǎng)絡(luò)虛擬化技術(shù)后，容器進(jìn)程就能使用自己 Network Namespace 里的協(xié)議棧，即：擁有屬于自己的 IP 地址和端口。

2.2.2 虛擬化網(wǎng)橋

在采用NetworkNamespace+Veth 技術(shù)后，容器即擁有了自身獨(dú)立的IP 地址和端口。但當(dāng)宿主機(jī)啟動(dòng)多個(gè)容器時(shí)，一個(gè)顯而易見(jiàn)的問(wèn)題就是：各個(gè)被Network Namespace 隔離的容器進(jìn)程如何進(jìn)行端到端交互？如若讓眾多容器采用基于Veth 技術(shù)的“網(wǎng)線(xiàn)”的Container-to-Container Mesh 全互聯(lián)實(shí)現(xiàn)，這顯然是較為“臃腫”的。

可以把每一個(gè)容器看做一臺(tái)主機(jī)，那么它們的聯(lián)通需求即是實(shí)現(xiàn)多臺(tái)主機(jī)之間的通信，通過(guò)網(wǎng)橋即可實(shí)現(xiàn)這樣的虛擬交換功能。具體來(lái)說(shuō)，通過(guò)將網(wǎng)橋的每個(gè)端口都用Veth 連接對(duì)應(yīng)的容器NetworkNamespace，然后根據(jù) MAC 地址學(xué)習(xí)來(lái)將數(shù)據(jù)包轉(zhuǎn)發(fā)到網(wǎng)橋的不同端口上，從而可實(shí)現(xiàn)一個(gè)宿主機(jī)內(nèi)部的不同容器通信需求。

以Docker 為例，它會(huì)在宿主機(jī)上創(chuàng)建一個(gè)名為 docker0 的網(wǎng)橋，然后所有的容器都借助于這個(gè)網(wǎng)橋進(jìn)行通信[6]。圖3 展示了在一臺(tái)宿主機(jī)上基于docker0 網(wǎng)橋的容器網(wǎng)絡(luò)拓?fù)洹?/p>

2.2.3 虛擬化路由

事實(shí)上，Docker 通過(guò)Veth 虛擬網(wǎng)絡(luò)設(shè)備以及Linux bridge 實(shí)現(xiàn)了同一臺(tái)主機(jī)上的容器網(wǎng)絡(luò)通信，在容器向外部網(wǎng)絡(luò)通信的部分可通過(guò)宿主機(jī)的Netfilter/iptables 進(jìn)行NAT 實(shí)現(xiàn)，但跨主機(jī)間的容器互訪(fǎng)依然存在阻礙?？缰鳈C(jī)容器通信所需要解決的問(wèn)題即不同宿主機(jī)上網(wǎng)橋間的聯(lián)通性問(wèn)題，目前主要有如下兩個(gè)方向?qū)ι鲜鰡?wèn)題進(jìn)行解決。

方向一：在底層網(wǎng)絡(luò)設(shè)備中默認(rèn)加入容器IP 地址的管理，需要感知容器實(shí)體的存在，一般依靠結(jié)合SDN 設(shè)備進(jìn)行實(shí)現(xiàn)。

方向二：不修改底層網(wǎng)絡(luò)設(shè)備配置，而是復(fù)用既有的Underlay平面網(wǎng)絡(luò)，以O(shè)verlay 或通過(guò)自動(dòng)化生成主機(jī)路由的方式解決容器跨主機(jī)通信，主要表現(xiàn)形式如下：

2.3 兩組患者心理狀態(tài)對(duì)比 干預(yù)前，兩組患者SAS、SDS評(píng)分比較，差異無(wú)統(tǒng)計(jì)學(xué)意義（P＞0.05）。干預(yù)后，觀察組患者評(píng)分低于對(duì)照組，（P＜0.05）。見(jiàn)表3。

（1）Overlay，通過(guò)隧道機(jī)制把容器發(fā)出的數(shù)據(jù)包封裝在通過(guò)宿主機(jī)網(wǎng)絡(luò)的數(shù)據(jù)包中，并復(fù)用既有的Underlay 網(wǎng)絡(luò)傳輸?shù)侥繕?biāo)主機(jī)，目標(biāo)主機(jī)再拆包轉(zhuǎn)發(fā)給對(duì)應(yīng)的容器中。Overlay 隧道如VXLAN、IPIP 等，目前使用Overlay 技術(shù)的主流容器網(wǎng)絡(luò)有Flannel、Weave 等。

（2）Routing，通過(guò)動(dòng)態(tài)修改宿主機(jī)的路由表信息，把宿主機(jī)當(dāng)作容器的網(wǎng)關(guān)，調(diào)整路由規(guī)則轉(zhuǎn)發(fā)到指定的主機(jī)，達(dá)到容器間的網(wǎng)絡(luò)層互通。目前通過(guò)路由技術(shù)實(shí)現(xiàn)容器跨主機(jī)通信的網(wǎng)絡(luò)有Flannel host-gw、Calico BGP 等。

本文接下來(lái)以同時(shí)兼顧Overlay 與Routing 的Flannel 解決方案描述容器的跨主機(jī)通信機(jī)制。

Flannel 的設(shè)計(jì)分為兩個(gè)方面，一個(gè)是容器IP 的分配機(jī)制，另一個(gè)是容器間的通訊機(jī)制。Flannel 提供了一種全局的網(wǎng)絡(luò)地址分配機(jī)制，并使用外置的etcd 數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)網(wǎng)段和節(jié)點(diǎn)之間的映射關(guān)系，F(xiàn)lannel 通過(guò)配置各個(gè)節(jié)點(diǎn)上的容器只能在分配到當(dāng)前節(jié)點(diǎn)的網(wǎng)段里選擇IP 地址，從而實(shí)現(xiàn)IP 地址分配的全局唯一性。

在容器間通訊的具體實(shí)現(xiàn)上，F(xiàn)lannel 利用各種backend 例如UDP，VXLAN，host-gw 等等，通過(guò)不同手段實(shí)現(xiàn)跨主機(jī)轉(zhuǎn)發(fā)容器間的網(wǎng)絡(luò)流量，完成容器間的跨主機(jī)路由通信。

Flannel 的UDP backend 方案里會(huì)在每臺(tái)宿主機(jī)上生成flannel0設(shè)備，它是一個(gè)TUN 設(shè)備。TUN 設(shè)備可以在操作系統(tǒng)內(nèi)核態(tài)和用戶(hù)態(tài)應(yīng)用程序之間數(shù)據(jù)。當(dāng)內(nèi)核將一個(gè)數(shù)據(jù)包發(fā)送給flannel0 設(shè)備之后，flannel0 就會(huì)把這個(gè)數(shù)據(jù)包交給創(chuàng)建這個(gè)設(shè)備的應(yīng)用程序進(jìn)行處理，這里就是flannel 的守護(hù)進(jìn)程——flanneld。而如果 flanneld 進(jìn)程向 flannel0 設(shè)備發(fā)送了一個(gè)數(shù)據(jù)包，那么這個(gè)數(shù)據(jù)包就會(huì)根據(jù)宿主機(jī)的路由表進(jìn)行處理。

圖4 展示了兩個(gè)宿主機(jī)上容器的通信過(guò)程。

所以，事實(shí)上Flannel UDP 模式即是在不同宿主機(jī)上的兩個(gè)容器之間打通了一條Overlay“隧道”，它使得任意兩個(gè)容器可直接透明地進(jìn)行IP 通信，且無(wú)需考慮容器和宿主機(jī)在網(wǎng)絡(luò)中的位置?？紤]到該模式采用了flannel0 這個(gè)TUN 設(shè)備，它在數(shù)據(jù)包傳輸過(guò)程中頻繁存在用戶(hù)態(tài)與內(nèi)核態(tài)的數(shù)據(jù)拷貝，性能較差，因此基于VXLAN（Virtual Extensible LAN）的模式應(yīng)運(yùn)而生，它可以完全在內(nèi)核態(tài)實(shí)現(xiàn)上述封裝和解封裝的工作。

Routing 的形式主要體現(xiàn)在flannel 的host-gw 模式。在實(shí)際運(yùn)作中，host-gw 工作模式就是將每個(gè)宿主機(jī)承載的flannel 子網(wǎng)的“下一跳”設(shè)置成了該子網(wǎng)對(duì)應(yīng)的宿主機(jī)的 IP 地址。具體來(lái)說(shuō)，hostgw 模式通過(guò)在宿主機(jī)上添加一個(gè)路由規(guī)則：<目的容器IP 地址段> via <網(wǎng)關(guān)的IP 地址> dev eth0。而這個(gè)路由規(guī)則的更新則是通過(guò)在各個(gè)宿主機(jī)上部署代理進(jìn)程動(dòng)態(tài)地將容器網(wǎng)絡(luò)的變化信息“翻譯”為到主機(jī)的路由表信息，從而實(shí)現(xiàn)在所有的宿主機(jī)上都擁有整個(gè)容器網(wǎng)絡(luò)的路由信息。

由于host-gw 模式完全是依靠宿主機(jī)的路由機(jī)制，因此它的效率與虛擬機(jī)直接的通信相差無(wú)幾。但這種網(wǎng)絡(luò)方案得以正常工作的核心，是為每個(gè)容器的IP 地址，找到它所對(duì)應(yīng)的，“下一跳”的網(wǎng)關(guān)。所以說(shuō)，F(xiàn)lannel host-gw 模式必須要求集群宿主機(jī)之間在數(shù)據(jù)鏈路層之間是連通的，這也限制了集群的規(guī)模。不僅如此，大規(guī)模的路由表查詢(xún)也會(huì)進(jìn)一步影響容器網(wǎng)絡(luò)的性能。因此，host-gw 模式在宿主機(jī)本身存在跨網(wǎng)段情況下的實(shí)現(xiàn)有一定的局限性。

為了同時(shí)兼顧性能和支持宿主機(jī)跨網(wǎng)段，可為flannel 的VXLAN 指定DirectRouting 參數(shù)，當(dāng)兩個(gè)容器所在宿主機(jī)節(jié)點(diǎn)在同一個(gè)網(wǎng)段中時(shí)，可直接通過(guò)物理網(wǎng)卡的網(wǎng)關(guān)路由轉(zhuǎn)發(fā)，而不用額外對(duì)數(shù)據(jù)包進(jìn)行隧道封裝。當(dāng)且僅當(dāng)所在宿主機(jī)跨網(wǎng)段時(shí)，才使用VXLAN 模式。

3 總結(jié)與展望

數(shù)據(jù)中心網(wǎng)絡(luò)在云計(jì)算基礎(chǔ)設(shè)施中具有關(guān)鍵地位，其性能的高低一定程度上影響著企業(yè)云計(jì)算的服務(wù)質(zhì)量。以容器、微服務(wù)、Kubernetes為主要核心的云原生架構(gòu)，是當(dāng)下設(shè)計(jì)具有彈性、可擴(kuò)展、高可用業(yè)務(wù)系統(tǒng)架構(gòu)的主要聚焦點(diǎn)。由于該架構(gòu)中的實(shí)施往往伴隨著數(shù)據(jù)中心東西向網(wǎng)絡(luò)帶寬的高要求，因此，其涉及的有關(guān)網(wǎng)絡(luò)拓?fù)?、資源規(guī)劃和分配方式等需要配合以云原生的方式演進(jìn)與適應(yīng)，從而為“應(yīng)用系統(tǒng)上云”的工作打下堅(jiān)實(shí)基礎(chǔ)。