這篇文章主要是彌補自己網路方面的知識，不提供參考意見


關於SDN和容器


作為近年來比較熱的一個概念，眾所周知SDN是Software Defined Network的縮寫，即軟體定義網路。但不同的人對SDN有不同的理解。在廣義上，只要是你通過軟體實現了一個東西，然後那個東西能夠靈活地去達到網路上面的部署和伸縮，這就可以被認為是SDN。


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


Docker自己的網路方案比較簡單，就是每個宿主機上會跑一個非常純粹的Linux Bridge，這個Bridge可以認為是一個二層的交換機，但它的能力有限，只能做一些簡單的學習和轉發。然後出來的流量，出網橋的流量會走IPTABLES，做NAT的地址轉換，然後靠路由轉發去做一個宿主之間的通訊。


但是當真正用它的網路模型部署一個比較複雜的業務時，會存在很多問題，比如容器重啟之後IP就變了；或者是由於每臺宿主機會分配固定的網段，因此同一個容器遷到不同宿主機時，它的IP可能會發生變化，因為它是在不同的網段；同時，NAT的存在會造成兩端在通訊時看到對方的地址是不真實的，因為它被NAT過；並且NAT本身也是有效能損耗等。這些問題都對使用Docker自己的網路方案造成了障礙。


由於容器技術給傳統的虛擬化網路提出了一些新的挑戰，所以圍繞Docker產生了很多不同的網路解決方案，以彌補Docker在這些方面的不足。


現有的主要Docker網路方案


基於實現方式分類


隧道方案

通過隧道，或者說Overlay Networking的方式：


Weave：UDP廣播，本機建立新的BR，通過PCAP互通。
Open vSwitch(OVS)：基於VxLAN和GRE協議，但是效能方面損失比較嚴重。
Flannel：UDP廣播，VxLan。
隧道方案在IaaS層的網路中應用也比較多，大家共識是隨著節點規模的增長複雜度會提升，而且出了網路問題跟蹤起來比較麻煩，大規模叢集情況下這是需要考慮的一個點。


路由方案


通過路由來實現，比較典型的代表有：


Calico：基於BGP協議的路由方案，支援很細緻的ACL控制，對混合雲親和度比較高。
Macvlan：從邏輯和Kernel層來看隔離性和效能最優的方案，基於二層隔離，所以需要二層路由器支援，大多數雲服務商不支援，所以混合雲上比較難以實現。
路由方案一般是從3層或者2層實現隔離和跨主機容器互通的，出了問題也很容易排查。


基於網路模型分類


Docker Libnetwork Container Network Model(CNM)陣營


Docker Swarm overlay
Macvlan & IP network drivers
Calico
Contiv（from Cisco）
Docker Libnetwork的優勢就是原生，而且和Docker容器生命週期結合緊密；缺點也可以理解為是原生，被Docker“綁架”。


Container Network Interface(CNI)陣營


Kubernetes
Weave
Macvlan
Flannel
Calico
Contiv
Mesos CNI
CNI的優勢是相容其他容器技術(e.g. rkt)及上層編排系統(Kuberneres & Mesos)，而且社群活躍勢頭迅猛，Kubernetes加上CoreOS主推；缺點是非Docker原生。


從上的可以看出，有一些第三方的網路方案是同時屬於兩個陣營的。


本文主要介紹了Docker容器平臺中的libnetwork，flannel，calico，weave這幾種跨主機通訊方案，並對各個方案的原理進行闡述。


Libnetwork


Libnetwork是從1.6版本開始將Docker的網路功能從Docker核心程式碼中分離出去，形成一個單獨的庫。Libnetwork的目標是定義一個健壯的容器網路模型，提供一個一致的程式設計介面和應用程式的網路抽象。


Libnetwork通過外掛的形式為Docker提供網路功能，使得使用者可以根據自己的需求實現自己的Driver來提供不同的網路功能。從1.9版本開始，docker已經實現了基於Libnetwork和libkv庫的網路模式-多主機的Overlay網路。


Libnetwork所要實現的網路模型基本是這樣的：使用者可以建立一個或多個網路(一個網路就是一個網橋或者一個VLAN)，一個容器可以加入一個或多個網路。 同一個網路中容器可以通訊，不同網路中的容器隔離。


Libnetwork實現了一個叫做Container Network Model (CNM)的東西，也就是說希望成為容器的標準網路模型、框架。其包含了下面幾個概念：




Sandbox。Sandbox包含容器網路棧的配置，包括容器介面，路由表，DNS配置等的管理。 linux network namespace是常見的一種sandbox的實現。Sandbox中包含眾多網路中的若干Endpoint。


Endpoint。Neutron中和Endpoint相對的概念應該是VNIC，也就是虛擬機器的虛擬網絡卡（也可以看成是VIF）。Endpoint的常見實現包括veth pair、Openvswitch的internal port。當Sandbox要和外界通訊的時候就是通過Endpoint連線到外界的，最簡單的情況就是連線到一個Bridge上。


Network。Network是一組可以互相通訊的Endpoints集合，組內endpoint可以相互通訊。不同組內endpoint是不能通迅的，是完全隔離的。常見的實現包括linux bridge,vlan等。


目前已經實現瞭如下Driver：


Host：主機網路，只用這種網路的容器會使用主機的網路，這種網路對外界是完全開放的，能夠訪問到主機，就能訪問到容器。


Bridge：橋接網路，這個Driver就是Docker現有網路Bridge模式的實現。除非建立容器的時候指定網路，不然容器就會預設的使用橋接網路。屬於這個網路的容器之間可以相互通訊，外界想要訪問到這個網路的容器需使用橋接網路。


Null： Driver的空實現，類似於Docker容器的None模式。使用這種網路的容器會完全隔離。


Overlay： Overlay驅動可以實現通過vxlan等重疊網路封裝技術跨越多個主機的網路，目前Docker已經自帶該驅動。


Remote：Remote驅動包不提供驅動，但提供了融合第三方驅動的介面。


flannel


Flannel之前的名字是Rudder，它是由CoreOS團隊針對Kubernetes設計的一個過載網路工具，它的主要思路是：預先留出一個網段，每個主機使用其中一部分，然後每個容器被分配不同的ip；讓所有的容器認為大家在同一個直連的網路，底層通過UDP/VxLAN等進行報文的封裝和轉發。


Flannel類似於weave、vxlan，提供了一個可配置的虛擬承載網路。Flannel以一個daemon形式執行，負責子網的分配，flannel使用etcd儲存、交換網路配置、狀態等資訊。


flannel基本原理


flannel預設使用8285埠作為UDP封裝報文的埠，VxLan使用8472埠。


容器直接使用目標容器的ip訪問，預設通過容器內部的eth0傳送出去。
報文通過veth pair被髮送到vethXXX。
vethXXX是直接連線到虛擬交換機docker0的，報文通過虛擬bridge docker0傳送出去。
查詢路由表，外部容器ip的報文都會轉發到flannel0虛擬網絡卡，這是一個P2P的虛擬網絡卡，然後報文就被轉發到監聽在另一端的flanneld。
flanneld通過etcd維護了各個節點之間的路由表，把原來的報文UDP封裝一層，通過配置的iface傳送出去。
報文通過主機之間的網路找到目標主機。
報文繼續往上，到傳輸層，交給監聽在8285埠的flanneld程式處理。
資料被解包，然後傳送給flannel0虛擬網絡卡。
查詢路由表，發現對應容器的報文要交給docker0。
docker0找到連到自己的容器，把報文傳送過去。

Calico


Calico是一個純3層的資料中心網路方案，而且無縫整合像OpenStack這種IaaS雲架構，能夠提供可控的VM、容器、裸機之間的IP通訊。


它基於BPG協議和Linux自己的路由轉發機制，不依賴特殊硬體，沒有使用NAT或Tunnel等技術。能夠方便的部署在物理伺服器、虛擬機器或者容器環境下。同時它自帶的基於Iptables的ACL管理元件非常靈活，能夠滿足比較複雜的安全隔離需求。


Calico在每一個計算節點利用Linux Kernel實現了一個高效的vRouter來負責資料轉發，而每個vRouter通過BGP協議負責把自己上執行的workload的路由資訊像整個Calico網路內傳播—小規模部署可以直接互聯，大規模下可通過指定的BGP route reflector來完成。


這樣保證最終所有的workload之間的資料流量都是通過IP路由的方式完成互聯的。


基本原理






Calico的方案如上圖所示。它把每個作業系統的協議棧認為是一個路由器，然後把所有的容器認為是連在這個路由器上的網路終端，在路由器之間跑標準的路由協議—BGP的協議，然後讓它們自己去學習這個網路拓撲該如何轉發。所以Calico方案其實是一個純三層的方案，也就是說讓每臺機器的協議棧的三層去確保兩個容器，跨主機容器之間的三層連通性。


Calico架構






結合上面這張圖，我們來過一遍Calico的核心元件：


Felix:Calico Agent，跑在每臺需要執行Workload的節點上，主要負責配置路由及ACLS等資訊來確保Endpoint的連通狀態。
etcd:分散式鍵值儲存，主要負責網路元資料一致性，確保Calico網路狀態的準確性。
BGP Client（BIRD）: 主要負責把Felix寫入Kernel的路由資訊分發到當前Calico網路，確保Workload間的通訊的有效性。
BGP Route Reflector（BIRD）：大規模部署時使用，摒棄所有節點互聯的mesh模式，通過一個或者多個BGP Route Reflector來完成集中式的路由分發。
每個節點上會執行兩個主要的程式，一個是它自己的叫Felix，它會監聽ECTD中心的儲存，從它獲取事件，比如說使用者在這臺機器上加了一個IP，或者是分配了一個容器等。接著會在這臺機器上創建出一個容器，並將其網絡卡、IP、MAC都設定好，然後在核心的路由表裡面寫一條，註明這個IP應該到這張網絡卡。


bird是一個標準的路由程式，它會從核心裡面獲取哪一些IP的路由發生了變化，然後通過標準BGP的路由協議擴散到整個其他的宿主機上，讓外界都知道這個IP在這裡，你們路由的時候得到這裡來。


由於Calico是一種純三層的實現，因此可以避免與二層方案相關的資料包封裝的操作，中間沒有任何的NAT，沒有任何的overlay，所以它的轉發效率可能是所有方案中最高的，因為它的包直接走原生TCP/IP的協議棧，它的隔離也因為這個棧而變得好做。因為TCP/IP的協議棧提供了一整套的防火牆的規則，所以它可以通過IPTABLES的規則達到比較複雜的隔離邏輯。


Calico優劣勢


Calico的優勢
網路拓撲直觀易懂，平行式擴充套件，可擴充套件性強
容器間網路三層隔離，無需要擔心arp風暴
基於iptable/linux kernel包轉發效率高，損耗低
更容易的程式語言(python)
社群活躍，正式版本較成熟
Calico的劣勢
calico僅支援TCP, UDP, ICMP andICMPv6協議，如果你想使用L4協議，你只能選擇Flannel,Weave或Docker Overlay Network。
Calico沒有加密資料路徑。 用不可信網路上的Calico建立覆蓋網路是不安全的。
沒有IP重疊支援。 雖然Calico社群正在開發一個實驗功能，將重疊IPv4包放入IPv6包中。 但這只是一個輔助解決方案，並不完全支援技術上的IP重疊。
Weave


Weave是由Zett.io公司開發的，它能夠建立一個虛擬網路，用於連線部署在多臺主機上的Docker容器，這樣容器就像被接入了同一個網路交換機，那些使用網路的應用程式不必去配置埠對映和連結等資訊。


外部裝置能夠訪問Weave網路上的應用程式容器所提供的服務，同時已有的內部系統也能夠暴露到應用程式容器上。Weave能夠穿透防火牆並執行在部分連線的網路上，另外，Weave的通訊支援加密，所以使用者可以從一個不受信任的網路連線到主機。


Weave實現原理








容器的網路通訊都通過route服務和網橋轉發。








Weave會在主機上建立一個網橋,每一個容器通過veth pair連線到該網橋上，同時網橋上有個Weave router的容器與之連線，該router會通過連線在網橋上的介面來抓取網路包(該介面工作在Promiscuous模式)。


在每一個部署Docker的主機(可能是物理機也可能是虛擬機器)上都部署有一個W(即Weave router)，它本身也可以以一個容器的形式部署)。Weave run的時候就可以給每個veth的容器端分配一個ip和相應的掩碼。veth的網橋這端就是Weave router容器，並在Weave launch的時候分配好ip和掩碼。


Weave網路是由這些weave routers組成的對等端點(peer)構成，每個對等的一端都有自己的名字，其中包括一個可讀性好的名字用於表示狀態和日誌的輸出，一個唯一識別符號用於執行中相互區別，即使重啟Docker主機名字也保持不變，這些名字預設是mac地址。


每個部署了Weave router的主機都需要將TCP和UDP的6783埠的防火牆設定開啟，保證Weave router之間控制面流量和資料面流量的通過。控制面由weave routers之間建立的TCP連線構成，通過它進行握手和拓撲關係資訊的交換通訊。 這個通訊可以被配置為加密通訊。而資料面由Weave routers之間建立的UDP連線構成，這些連線大部分都會加密。這些連線都是全雙工的，並且可以穿越防火牆。


Weave優劣勢


Weave優勢
支援主機間通訊加密。
支援container動態加入或者剝離網路。
支援跨主機多子網通訊。
Weave劣勢
只能通過weave launch或者weave connect加入weave網路。
各方案對比


Flannel和overlay方案均使用承載網路，承載網路的優勢和劣勢都是非常明顯。
優勢有：對底層網路依賴較少，不管底層是物理網路還是虛擬網路，對層疊網路的配置管理影響較少；配置簡單，邏輯清晰，易於理解和學習，非常適用於開發測試等對網路效能要求不高的場景。


劣勢主要包括：網路封裝是一種傳輸開銷，對網路效能會有影響，不適用於對網路效能要求高的生產場景；由於對底層網路結構缺乏瞭解，無法做到真正有效的流量工程控制，也會對網路效能產生影響；某些情況下也不能完全做到與下層網路無關，例如隧道封裝會對網路的MTU限制產生影響。


Calico方案因為沒有隧道封裝的網路開銷，會帶來相對較高的網路效能。不支援多租戶，由於沒有封裝所有的容器只能通過真實的IP來區分自己，這就要求所有租戶的容器統一分配一個地址空間。Calico基於三層轉發的原理對物理架構可能會有一定的要求和侵入性。


weave可以穿透防火牆，安全性較高，流量是被加密的，允許主機連線通過一個不被信任的網路，同樣會有承載網路的帶來的優缺點。