[[159869]]

Docker的橫空出世很大程度上推動了容器技術(shù)的熱度和發(fā)展。容器技術(shù)和傳統(tǒng)的虛擬化技術(shù)有很大的不同，具體包括：首先是相對于傳統(tǒng)的虛擬機，以前一個虛擬機里做的事情，要打散成很多個容器去做，它們各自的職能會更少；第二點是會造成以前一個虛機的IP會變成很多個容器的多個IP，容器之間的關(guān)系會變得更加復雜；第三點是整個網(wǎng)絡(luò)中的網(wǎng)絡(luò)端點數(shù)量呈現(xiàn)一個上升的趨勢；第四點是容器的生命周期其實會更短。此外，容器由于其輕量級的優(yōu)勢，可能會被不停地調(diào)度，從一臺機器調(diào)度到另外一臺機器，根據(jù)資源的負載均衡，容器的生命周期其實是比虛機要短的。以上幾點其實都是給傳統(tǒng)的虛擬化網(wǎng)絡(luò)提出的一些新的挑戰(zhàn)。

本文是對七牛資深架構(gòu)師徐兆魁在2015全球架構(gòu)師峰會上所做的同題目演講的整理，主要分為三個部分。第一部分簡單介紹SDN的內(nèi)涵以及它和容器之間的關(guān)系。第二部分介紹一些現(xiàn)有圍繞容器的一些開源的SDN的解決方案，包括Flannel、Calico和Weave。第三部分是七牛在這部分的一些實踐和案例的分享。

關(guān)于SDN和容器

作為近年來比較熱的一個概念，眾所周知SDN是Software Defined Network的縮寫，即軟件定義網(wǎng)絡(luò)。但不同的人對SDN有不同的理解。在廣義上，只要是你通過軟件實現(xiàn)了一個東西，然后那個東西能夠靈活地去達到網(wǎng)絡(luò)上面的部署和伸縮，這就可以被認為是SDN。在后文中會對Flannel、Calico、Weave這三個解決方案進行分析，并從控制層和轉(zhuǎn)發(fā)層來著重探討它們的技術(shù)實現(xiàn)，雖然它們并沒有宣稱自己是SDN的解決方案。

由于容器技術(shù)給傳統(tǒng)的虛擬化網(wǎng)絡(luò)提出了一些新的挑戰(zhàn)，所以圍繞Docker產(chǎn)生了很多不同的網(wǎng)絡(luò)解決方案，以彌補Docker在這些方面的不足。

圍繞容器的開源的SDN解決方案

Docker自己的網(wǎng)絡(luò)方案比較簡單，就是每個宿主機上會跑一個非常純粹的Linux Bridge，這個Bridge可以認為是一個二層的交換機，但它的能力有限，只能做一些簡單的學習和轉(zhuǎn)發(fā)。然后出來的流量，出網(wǎng)橋的流量會走IPTABLES，做NAT的地址轉(zhuǎn)換，然后靠路由轉(zhuǎn)發(fā)去做一個宿主之間的通信。但是當真正用它的網(wǎng)絡(luò)模型部署一個比較復雜的業(yè)務(wù)時，會存在很多問題，比如容器重啟之后IP就變了；或者是由于每臺宿主機會分配固定的網(wǎng)段，因此同一個容器遷到不同宿主機時，它的IP可能會發(fā)生變化，因為它是在不同的網(wǎng)段；同時，NAT的存在會造成兩端在通訊時看到對方的地址是不真實的，因為它被NAT過；并且NAT本身也是有性能損耗等。這些問題都對使用Docker自己的網(wǎng)絡(luò)方案造成了障礙。

Flannel

 

圖1

Flannel是CoreOS團隊針對Kubernetes設(shè)計的一個覆蓋網(wǎng)絡(luò)（Overlay Network）工具，如圖1所示。它們的控制平面其實很簡單，如圖2所示。

圖2

每個機器上面的Flannel進程會監(jiān)聽ETCD，向ETCD申請每個節(jié)點可用的IP地址段，并且從ETCD拿到其他所有宿主機的網(wǎng)段信息，這樣它就可以做一些路由。對于它的轉(zhuǎn)發(fā)平面（圖3）——轉(zhuǎn)發(fā)平面主要表現(xiàn)數(shù)據(jù)流的流向——它在Docker進來的網(wǎng)橋基礎(chǔ)之上，又創(chuàng)建了一個新的叫VXLAN的設(shè)備（圖4），VXLAN是一個隧道的方案，它可以把一個二層的包，前面加一個包頭，然后再把整個包作為物理網(wǎng)絡(luò)的一個包，去物理網(wǎng)絡(luò)里面去路由，流轉(zhuǎn)。

圖3

圖4

為什么會要有這個東西呢？因為通常虛擬網(wǎng)絡(luò)的IP和MAC在物理的網(wǎng)絡(luò)其實是不認識的。因為識別IP需要物理網(wǎng)絡(luò)支持，這個其實是個隧道的方案。

總結(jié)一下Flannel方案，可以看出它并沒有實現(xiàn)隔離，并且它也是按照網(wǎng)段做IP分配，即一個容器從一臺主機遷到另外一臺主機的時候，它的地址一定會變化。

Calico

圖5

Calico的思路比較新，如圖5所示。它把每個操作系統(tǒng)的協(xié)議棧認為是一個路由器，然后把所有的容器認為是連在這個路由器上的網(wǎng)絡(luò)終端，在路由器之間跑標準的路由協(xié)議——BGP的協(xié)議，然后讓它們自己去學習這個網(wǎng)絡(luò)拓撲該如何轉(zhuǎn)發(fā)。所以Calico方案其實是一個純?nèi)龑拥姆桨?，也就是說讓每臺機器的協(xié)議棧的三層去確保兩個容器，跨主機容器之間的三層連通性。對于控制平面（圖6），它每個節(jié)點上會運行兩個主要的程序，一個是它自己的叫Felix，左邊那個，它會監(jiān)聽ECTD中心的存儲，從它獲取事件，比如說用戶在這臺機器上加了一個IP，或者是分配了一個容器等。接著會在這臺機器上創(chuàng)建出一個容器，并將其網(wǎng)卡、IP、MAC都設(shè)置好，然后在內(nèi)核的路由表里面寫一條，注明這個IP應該到這張網(wǎng)卡。綠色部分是一個標準的路由程序，它會從內(nèi)核里面獲取哪一些IP的路由發(fā)生了變化，然后通過標準BGP的路由協(xié)議擴散到整個其他的宿主機上，讓外界都知道這個IP在這里，你們路由的時候得到這里來。

圖6

關(guān)于Calico這里討論一個問題，因為它跑的是純?nèi)龑拥膮f(xié)議，所以其實它對物理架構(gòu)有一定的侵入性。Calico官方稱，你可以跑在一個大二層的網(wǎng)絡(luò)里面。所謂大二層就是沒有任何三層的網(wǎng)關(guān)，所有的機器、宿主機、物理機在二層是可達的。這個方案其實有一定的弊端，事實上在很多有經(jīng)驗的網(wǎng)絡(luò)工程師眼里，一個大二層其實是一個單一的故障率，也就是說任何一個都會有一定的硬件風險會讓整個大二層癱瘓。

另外，Calico跑在了一個三層網(wǎng)關(guān)的物理網(wǎng)絡(luò)上時，它需要把所有機器上的路由協(xié)議和整個物理網(wǎng)絡(luò)里面的路由器的三層路全部用BGP打通。這其實會帶來一個問題，這里的容器數(shù)量可能是成千上萬的，然后你讓所有物理的路由學習到這些知識，其實會給物理集群里的BGP路由帶來一定的壓力，這個壓力我雖然沒有測過，但據(jù)專業(yè)的網(wǎng)絡(luò)工程師告知，當網(wǎng)絡(luò)端點數(shù)達到足夠大的時候，它自我學習和發(fā)現(xiàn)拓撲以及收斂的過程是需要很多的資源和時間的。

轉(zhuǎn)發(fā)平面（圖7）是Calico的優(yōu)點。因為它是純?nèi)龑拥霓D(zhuǎn)發(fā)，中間沒有任何的NAT，沒有任何的overlay，所以它的轉(zhuǎn)發(fā)效率可能是所有方案中最高的，因為它的包直接走原生TCP/IP的協(xié)議棧，它的隔離也因為這個棧而變得好做。因為TCP/IP的協(xié)議棧提供了一整套的防火墻的規(guī)則，所以它可以通過IPTABLES的規(guī)則達到比較復雜的隔離邏輯。

圖7

Weave

圖8

Weave方案比較有趣，如圖8所示。首先它會在每臺機器上跑一個自己寫的Router程序起到路由器的作用，然后在路由器之間建立一個全打通的PC連接，接著在這張TCP的連接網(wǎng)里面互相跑路由協(xié)議，形成一個控制平面（圖9）?？梢钥闯觯目刂破矫婧虲alico一致，而轉(zhuǎn)發(fā)平面（圖10）則是走隧道的，這一點和Flannel一致，所以Weave被認為是結(jié)合了Flannel和Calico這兩個方案的特點。

圖9

圖10

圖11所示是它的服務(wù)發(fā)現(xiàn)與負載均衡的一個簡單的方案，它在每個容器會起兩個網(wǎng)卡，一個網(wǎng)卡連著自己起的可以跟其他宿主機聯(lián)通的網(wǎng)橋；另一個網(wǎng)卡綁在原生Docker的一個網(wǎng)橋上，并在這個網(wǎng)橋上監(jiān)聽一個DNS的服務(wù)，這個DNS實際上嵌在Router里面，即它可以從Router里學習到一些服務(wù)的后端的一些配置。所以這時容器如果發(fā)起DNS查詢，實際上會被路由導到宿主機上，DNS Server上，然后DNS server做一些響應。它們官方負載均衡也是靠這個，但是這其實是一個短板，因為我們更偏向于四層或者是七層更精細的負載均衡。

在隔離方面，Weave的方案比較粗糙，只是子網(wǎng)級的隔離（圖12）。比如說有兩個容器都處在10.0.1-24網(wǎng)段，那么它會在所有的容器里面加一條路由說該網(wǎng)段會走左邊的網(wǎng)橋出去，但是所有非此網(wǎng)段的流量會走Docker0，這個時候Docker0和其他是不聯(lián)通的，所以它就達到一個隔離的效果。

圖11

圖12

三個方案總結(jié)

總結(jié)一下：

1. Flannel僅僅作為單租戶的容器互聯(lián)方案還是很不錯的，但需要額外的組件去實現(xiàn)更高級的功能，例如服務(wù)發(fā)現(xiàn)與負載均衡。

2. Calico有著良好的性能和隔離策略，但其基于三層轉(zhuǎn)發(fā)的原理對物理架構(gòu)可能會有一定的要求和侵入性。

3. Weave自帶DNS，一定程度上能解決服務(wù)發(fā)現(xiàn)，但因隔離功能有限，若作為多租戶的聯(lián)通方案還稍加欠缺。

4. 另外，Calico和Weave都使用了路由協(xié)議作為控制面，而自主路由學習在大規(guī)模網(wǎng)絡(luò)端點下的表現(xiàn)其實是未經(jīng)驗證的，曾咨詢過相關(guān)的網(wǎng)絡(luò)工程師，大規(guī)模端點的拓撲計算和收斂往往需要一定的時間和計算資源。

七牛的具體實踐

業(yè)務(wù)需求

七牛實際上一直在擁抱容器帶來的變革，擁抱新型的微服務(wù)架構(gòu)理念。所以構(gòu)建了一套容器平臺，這么做的目的，一方面想推進通過將已有業(yè)務(wù)容器化簡化研發(fā)和上線流程，另一方面也想通過這個方式去滿足用戶的一些計算需求，畢竟計算和數(shù)據(jù)離得越近越好。

所以我們業(yè)務(wù)上對網(wǎng)絡(luò)的需求是：

1. 首先一點，是能夠運行在底層異構(gòu)的基礎(chǔ)網(wǎng)絡(luò)上，這一點對于推進已有業(yè)務(wù)的容器化來說是很重要的，否則會涉及到基礎(chǔ)網(wǎng)絡(luò)的大規(guī)模變更，這是無法接受的。

2. 我們試圖構(gòu)造一個對容器遷移友好的網(wǎng)絡(luò)結(jié)構(gòu)，允許容器在必要情況下發(fā)生調(diào)度。

3. 我們認為服務(wù)發(fā)現(xiàn)和負載均衡對業(yè)務(wù)來說是個基礎(chǔ)而普適的需求，尤其是在倡導微服務(wù)架構(gòu)的今天，一個設(shè)計良好的組件應該是可水平伸縮的，因此對于組件的調(diào)用方，服務(wù)發(fā)現(xiàn)和負載均衡是非常必要的功能。當然有人會說這個功能和網(wǎng)絡(luò)層無關(guān)，而應由應用層去實現(xiàn)，這個說法挺有道理，但后面我會講到由網(wǎng)絡(luò)層直接支持這兩個功能的好處。

4. 為了滿足七牛本身已有的一些對隔離有要求的服務(wù)，并滿足上層更豐富的權(quán)限模型和業(yè)務(wù)邏輯，我們試圖將隔離性做的更加靈活。

在這幾個需求的驅(qū)動下，我們最終嘗試跳出傳統(tǒng)網(wǎng)絡(luò)模型的束縛，嘗試去構(gòu)造一個更加扁平而受控的網(wǎng)絡(luò)結(jié)構(gòu)。

轉(zhuǎn)發(fā)平面

首先，在轉(zhuǎn)發(fā)層面，為了包容異構(gòu)的基礎(chǔ)網(wǎng)絡(luò)，我們選擇了使用Open vSwitch構(gòu)造L2 overlay模型，通過在OVS之間聯(lián)通vxlan隧道來實現(xiàn)虛擬網(wǎng)絡(luò)的二層互通。如圖13所示。但隧道通常是有計算成本的，隧道需要對虛擬二層幀進行頻繁解封包動作，而通用的cpu其實并不擅長這些。我們通過將vxlan的計算量offload到硬件網(wǎng)卡上，從而將一張萬兆網(wǎng)卡的帶寬利用率從40%提升到95%左右。

選擇overlay的另一個理由是，據(jù)我們目前所了解到，當下硬件的設(shè)備廠商在對SDN的支持上通常更偏向于overlay模型。

圖13

控制平面

而在控制層面，我們思考了容器和傳統(tǒng)虛機的一些不同：

前面提到，微服務(wù)架構(gòu)下，每個容器的職責相對虛機來說更加細化和固定，而這會造成容器與容器間的依賴關(guān)系也相對固定。那么每臺宿主機上的容器可能產(chǎn)生的outbound其實也是可推演的。如果進一步想的話，其實推演出來的理論范圍通常會遠大于容器實際產(chǎn)生的 outbound。所以我們嘗試使用被動的方式實現(xiàn)控制指令的注入。因此我們引入了OpenFlow作為控制面的協(xié)議。OpenFlow作為目前SDN 控制平面的協(xié)議標準，它有著很強的表達能力。從包匹配的角度看，它幾乎可匹配包頭中的任意字段，并支持多種流老化策略。此外，擴展性也很好，支持第三方的 Vendor 協(xié)議，可以實現(xiàn)標準協(xié)議中無法提供的功能OpenFlow可以按Table組織流表，并可在表間跳轉(zhuǎn)（這一點其實和IPTABLES很像，但OpenFlow的語義會更加豐富）。配合OpenFlow的這種Table組織方式，可以實現(xiàn)相對復雜的處理邏輯。如圖14所示。

圖14

選擇了OpenFlow，我們的控制平面會顯得很中規(guī)中矩，也就是邏輯上的集中式控制，沒有weave/calico的P2P那么炫酷。在這樣的結(jié)構(gòu)下，當ovs遇到未知報文時，會主動提交包信息給Controller，Controller會根據(jù)包信息判斷后，給ovs下發(fā)合適的流表規(guī)則。為了實現(xiàn)負載均衡和高可用，我們給每組ovs配置多個Controller。如圖15所示。

例如:

1. 對于非法流量Controller會讓ovs簡單丟棄，并在將來一段時間內(nèi)不要再詢問。

2. 對于合法流量，Controller會告訴ovs如何路由這個包并最終到達正確的目的地。

圖15

 

服務(wù)發(fā)現(xiàn)和負載均衡

關(guān)于服務(wù)發(fā)現(xiàn)和負載均衡，我們提供了以下幾個對象模型：

1. Container，容器實例，多個Container構(gòu)成一個Pod（實體）。

2. Pod，每個Pod共享一個網(wǎng)絡(luò)棧，IP地址和端口空間（實體）。

3. Service，多個相同Pod副本構(gòu)成一個Service，擁有一個Service IP（邏輯）。

4. 安全組，多個Service構(gòu)成一個安全組（邏輯）。

其中，可動態(tài)伸縮的關(guān)系是一個Service與其后端Pod的映射，這一步是靠平臺的自動服務(wù)發(fā)現(xiàn)來完成。只要發(fā)起對Service IP的訪問，那么Service本身就會完成服務(wù)發(fā)現(xiàn)和負載均衡的功能。后端Pod如果發(fā)生變動，調(diào)用方完全無需感知。

從實現(xiàn)上來說，我們將這個功能實現(xiàn)到了每個宿主機上，每個宿主機上的這個組件會直接代理本機產(chǎn)生的Service流量，這樣可以避免額外的內(nèi)網(wǎng)流量開銷。

功能上，我們實現(xiàn)了IP級的負載均衡，什么意思，就是每個Service IP的可訪問端口與后端Pod實際監(jiān)聽的端口是一致的，比如后端Pod監(jiān)聽了12345，那么直接訪問Service IP的12345端口，即可直接訪問，而無需額外的端口配置。

這里對比一下常見的幾種負載均衡：

1. 比DNS均衡更加精細。

2. 比端口級的負載均衡器更容易使用，對業(yè)務(wù)入侵更小。

另外，7層的負載均衡實際上有很大的想象空間，我們實現(xiàn)了大部分Nginx的常用配置，使用者可以靈活配置。業(yè)務(wù)甚至還可以指定后端進行訪問。

安全組

在隔離層面，我們在邏輯上劃分了安全組，多個service組成一個安全組，安全組之間可以實現(xiàn)靈活的訪問控制。相同安全組內(nèi)的容器可以互相不受限制的訪問。其中最常見的一個功能是，將安全組A中的某些特定的Service Export給另一組安全組B。Export后，安全組B內(nèi)的容器則可以訪問這些導出的Service，而不能訪問A中的其他Service。如圖16所示。

圖16

介紹完了我們網(wǎng)絡(luò)的基礎(chǔ)功能，這里通過分析兩個七牛的實際案例來說明這樣的結(jié)構(gòu)是如何推動業(yè)務(wù)的架構(gòu)演變的。

案例分析1——七牛文件處理FOP架構(gòu)演變

第一個是七牛的文件處理架構(gòu)（File OPeration），如圖17所示。文件處理功能一直是七牛非常創(chuàng)新、也是很核心的一個功能，用戶在上傳了一個文件后，通過簡單地在資源url中添加一些參數(shù)，就能直接下載到按參數(shù)處理后的文件，例如你可以在一個視頻文件的url中添加一些參數(shù)，最終下載到一張在視頻某一幀上打了水印并旋轉(zhuǎn)90度并裁剪成40x40大小的圖片。

圖17

而支撐這樣一個業(yè)務(wù)的架構(gòu)，在早期是非常笨拙的。圖17左側(cè)是業(yè)務(wù)的入口，右側(cè)是實際進行計算的各種worker集群，里面包含了圖片處理，視頻處理，文檔處理等各種處理實例。

1. 集群信息寫死在入口配置中，后端配置變更不夠靈活。

2. 業(yè)務(wù)入口成為流量穿透的組件（業(yè)務(wù)的指令流與數(shù)據(jù)流混雜在一起）。

3. 突發(fā)請求情況下，應對可能不及時。

后面負責文件處理的同事將架構(gòu)進化成了這樣（如圖18）。

1. 增加Discovery組件，用于集群中worker信息的自動發(fā)現(xiàn)，每個worker被添加進集群都會主動注冊自己。

2. 業(yè)務(wù)入口從Discovery獲取集群信息，完成對請求的負載均衡。

3. 每個計算節(jié)點上新增Agent組件，用于向Discovery組件上報心跳和節(jié)點信息，并緩存處理后的結(jié)果數(shù)據(jù)（將數(shù)據(jù)流從入口分離），另外也負責節(jié)點內(nèi)的請求負載均衡（實例可能會有多個）。

4. 此時業(yè)務(wù)入口只需負責分發(fā)指令流，但仍然需要對請求做節(jié)點級別的負載均衡。

圖18

圖19描述的是文件處理架構(gòu)遷移到容器平臺后的早期結(jié)構(gòu)，較遷移之前有如下變更。

1. 每個Agent對應一個計算worker，并按工種獨立成Service，比如Image Service，Video Service。

2. 取消業(yè)務(wù)的Discovery服務(wù)，轉(zhuǎn)由平臺自身的服務(wù)發(fā)現(xiàn)功能。

3. 每個Agent的功能退化：

l   無需和Discovery維護心跳，也不在需要上報節(jié)點信息。

l   由于后端只有一個worker，因此也不需要有節(jié)點內(nèi)的負載均衡邏輯。 

4. 業(yè)務(wù)入口無需負載均衡，只需無腦地請求容器平臺提供的入口地址即可。

圖19

圖20是遷移后發(fā)生的另一次演變，實際上上一個階段中，每個Agent仍然和計算實例綁定在一起，而這么做其實只是為了方便業(yè)務(wù)的無痛遷移，因為Agent本身的代碼會有一些邏輯上的假設(shè)。

這張圖中，我們進一步分離了Agent和worker，Agent獨立成一個Service，所有的worker 按工種獨立成Service，這么分離的目的在于，Agent是可能會有文件內(nèi)容緩存、屬于有狀態(tài)的服務(wù)，而所有的worker是真正干活、無狀態(tài)的服務(wù)。分離之后的好處在于，worker的數(shù)量可以隨時調(diào)整和伸縮，而不影響Agent中攜帶的狀態(tài)。

好處：

1. 可以看到，相比于最早的架構(gòu)，業(yè)務(wù)方只需集中精力開發(fā)業(yè)務(wù)本身，而無需重復造輪子，實現(xiàn)各種復雜的服務(wù)發(fā)現(xiàn)和各種負載均衡的代碼。

2. 另外，自從部署到容器平臺之后，平臺的調(diào)度器會自動更具節(jié)點的資源消耗狀況做實例的遷移，這樣使得計算集群中每個節(jié)點的資源消耗更加均衡。

案例分析2——用戶自定義文件處理UFOP架構(gòu)演變

另一個案例是七牛的用戶自定義文件處理。

用戶自定義文件處理（User-defined File OPeration，UFOP）是七牛提供的用于運行用戶上傳的文件處理程序的框架。他的作用實際上和前面介紹的是一致的，只是允許用戶自定義他的計算實例。例如七?，F(xiàn)有的鑒黃服務(wù)，就是一個第三方的worker，可以用于識別出一個圖片是否包含黃色內(nèi)容。而正是由于引入了用戶的程序，所以UFOP在架構(gòu)上和官方的 FOP的不同在于，UFOP對隔離有要求。

圖20是原本UFOP的架構(gòu)，事實上，這里已經(jīng)使用了容器技術(shù)進行資源上的隔離，所有的容器通過Docker Expose將端口映射到物理機，然后通過一個集中式的注冊服務(wù)，將地址和端口信息注冊到一個中心服務(wù)，然后入口分發(fā)服務(wù)通過這個中心服務(wù)獲取集群信息做請求的負載均衡。

而在網(wǎng)絡(luò)的隔離上，由于Docker自身的弱隔離性，這個架構(gòu)中選擇了禁止所有的容器間通信，而只允許入口過來的流量。這個隔離尺度一定程度上限制了用戶自定義程序的靈活性。

圖20

而在遷移到容器平臺后，由于有靈活的安全組控制，不同用戶上傳的處理程序天然就是隔離的，而用戶可以創(chuàng)建多種職責不同的Service來完成更復雜的處理邏輯。如圖21所示。

另外，遷移后的程序?qū)碛型暾亩丝诳臻g，進一步放開了用戶自定義處理程序的靈活性。

圖21

以上內(nèi)容是七牛首度公開關(guān)于多租戶虛擬網(wǎng)絡(luò)方面的探索和實踐，并總結(jié)了我們對這一領(lǐng)域的觀察和思考，還有很多更為細節(jié)的點值得探討，望以后能與大家做更充分的交流。