編者按：本文系SDNLAB技術分享系列，本次分享來自SDN撕X羣（羣主：大貓貓）羣直播，咱們但願經過SDNLAB提供的平臺傳播知識，傳遞價值，歡迎加入咱們的行列。html
分享嘉賓
--------------------------------------------------------------------------------------------------
分享介紹：張晨：目前就讀於北京郵電大學FNL實驗室，網絡與交換國家重點實驗室。目前主要研究方向：軟件定義網絡，網絡虛擬化，雲數據中心網絡。目前任職於Brocade。
--------------------------------------------------------------------------------------------------前端
容器這一兩年火的不行，能夠說是獨領IT風騷，一時風光無二。相比於虛擬機來講，容器更輕，一臺服務器上能夠運行成百上千的容器，這意味着更爲密集的計算資源，所以基於容器運行工做負載的模式深受雲服務提供商們的青睞。linux
然而對於雲管理員來講，管理容器確是一件至關頭疼的事情，容器的生命週期更短了，容器的數量更多了，容器間的關係更復雜了。爲了簡化大規模容器集羣的運維，各路容器管理與編排平臺應運而生，Docker社區開發了Swarm+Machine+Compose的集羣管理套件，Twitter主推Apache的Mesos，Google則開源了本身的Kubernetes。這些平臺爲大規模的容器集羣提供了資源調度、服務發現、擴容縮容等功能，然而這些功能都是策略向的，真正要實現大規模的容器集羣，網絡纔是最基礎的一環。git
相比於虛擬機網絡，容器網絡主要具備如下特色，以及相應的技術挑戰：github
不過，因爲容器自身的特徵使得它與應用的綁定更爲緊密，從交付模式來看更傾向於PaaS而非IaaS，所以容器網絡並無成爲業界關注的焦點。起步較晚，再加上上述諸多的技術挑戰，使得容器網絡相比於OpenStack Neutron來講發展的狀況要落後很多。Docker在開始的很長一段時間內只支持使用linux bridge+iptables進行single-host的部署，自動化方面也只有pipework這類shell腳本。docker
幸運的是，目前業界已經意識到了可擴展、自動化的網絡對於大規模容器環境的重要性：docker收購了容器shell
網絡的創業公司socketplane，隨即將網絡管理從docker daemon中獨立出來造成libnetwork，並在docker 1.9中提供了多種network driver，並支持了multi-host；一些專業的容器網絡（如flannel、weave、calico等）也開始與各個容器編排平臺進行集成；OpenStack社區也成立了專門的子項目Kuryr提供Neutron network driver（如DragonFlow、OVN、Midolnet等）與容器的對接。數據庫
這一節咱們來介紹容器網絡的基礎，包括容器的接入，容器間的組網，以及幾種容器網絡的通用模型。後端
1.和host共享network namespace安全
這種接入模式下，不會爲容器建立網絡協議棧，即容器沒有獨立於host的network namespace，可是容器的其餘namespace（如IPC、PID、Mount等）仍是和host的namespace獨立的。容器中的進程處於host的網絡環境中，與host共用L2-L4的網絡資源。該方式的優勢是，容器可以直接使用host的網絡資源與外界進行通訊，沒有額外的開銷（如NAT），缺點是網絡的隔離性差，容器和host所使用的端口號常常會發生衝突。
2.和host共享物理網卡
2與1的區別在於，容器和host共享物理網卡，但容器擁有獨立於host的network namespace，容器有本身的MAC地址、IP地址、端口號。這種接入方式主要使用SR-IOV技術，每一個容器被分配一個VF，直接經過PCIe網卡與外界通訊，優勢是旁路了host kernel不佔任何計算資源，並且IO速度較快，缺點是VF數量有限且對容器遷移的支持不足。
3.和另一個容器共享network namespace
與1相似，容器沒有獨立的network namespace，可是以該方式新建立的容器將與一個已經存在的容器共享其network namespace（包括MAC、IP以及端口號等），網絡角度上二者將做爲一個總體對外提供服務，不過兩個容器的其餘namespace（如IPC、PID、Mount等）是彼此獨立的。這種方式的優勢是，network namespace相聯繫的容器間的通訊高效便利，缺點是因爲其餘的namespace仍然是彼此獨立的，所以容器間沒法造成一個業務邏輯上的總體。
4.Behind the POD
這種方式是Google在Kubernetes中的設計中提出來的。Kubernetes中，POD是指一個能夠被建立、銷燬、調度、管理的最小的部署單元，一個POD有一個基礎容器以及一個或一組應用容器，基礎容器對應一個獨立的network namespace並擁有一個其它POD可見的IP地址（以IP A.B.C.D指代），應用容器間則共享基礎容器的network namespace（包括MAC、IP以及端口號等），還能夠共享基礎容器的其它的namespace（如IPC、PID、Mount等）。POD做爲一個總體鏈接在host的vbridge/vswitch上，使用IP地址A.B.C.D與其它POD進行通訊，不一樣host中的POD處於不一樣的subnet中，同一host中的不一樣POD處於同一subnet中。這種方式的優勢是一些業務上密切相關的容器能夠共享POD的所有資源（它們通常不會產生資源上的衝突），而這些容器間的通訊高效便利，缺點是同一POD下的容器必須位於同一host中，從而限制了位置的靈活性。
5.鏈接在的vbridge/vswitch上
這種方式是最爲常見的，容器擁有獨立的network namespace，經過veth-pair鏈接到vswitch上。這種方式對於網絡來講是最爲直接的，在vswitch看來，經過這種方式鏈接的容器與虛擬機並無任何區別。vbridge/vswitch的實現有不少，包括linux bridge，Open vSwitch，macvlan等。這種方式的優勢是vbridge/vswitch可實現的功能比較豐富，尤爲是Open vSwitch能夠支持VLAN、Tunnel、SDN Controller等，缺點是可能會形成不少額外的開銷。
6.嵌套部署在VM中
這種方式在生產環境也比較常見，因爲一臺host中每每部署着多方的容器，存在安全隱患，所以許多用戶會選擇先啓動本身的虛擬機，而後在本身的虛擬機上運行容器。這種方式實際上是一種嵌套虛擬化，所以本質上來講，這種方式下容器的接入對於host能夠是徹底透明的，容器在虛擬機內部的接入能夠採用上述1-5中任意的方法。不過這對於雲平臺來講就意味着失去了對容器接入的管理能力，爲了保留這一能力，每每須要在虛擬機內部和host中分別部署vswitch並實現級聯，由虛擬機內部的vswitch用來接入容器並對其進行特定的標記（雲平臺分配），以便host中的vswitch進行識別。一種常見的方式是使用Open vSwitch對容器標記vlan id。
1.Flat
Flat主要可分爲L2 Flat和L3 Flat。L2 Flat指各個host中全部的容器都在virtual+physical網絡造成的VLAN大二層中，容器能夠在任意host間進行遷移而不用改變其IP地址。L3 Flat指各個host中全部的容器都在virtual+physical網絡中可路由，且路由以/32位的形式存在，使得容器在host間遷移時不須要改變IP地址。L2/L3 Flat下，不一樣租戶的IP地址不能夠Overlap，L3 Flat下容器的IP編址也不可與physical網絡Overlap。L3 Flat簡單示意以下。
2.L3 Hierarchy
L3 Hierarchy中各個host中全部的容器都在virtual+physical網絡中可路由，且路由在不一樣層次上（VM/Host/Leaf/Spine）以聚合路由的形式存在，即處於相同CIDR的容器須要在物理位置上被組織在一塊兒，所以容器在host間遷移時須要改變IP地址。L3 Hierarchy下，不一樣租戶的IP地址不能夠Overlap，容器的IP編址也不可與physical網絡Overlap。下圖是L3 Hierarchy中的IP地址規劃示例。
3.Overlay
Overlay主要可分爲L2 over L3和L3 over L3，少部分實現L2/L3 over UDP。L2 over L3中，容器能夠跨越L3 Underlay進行L2通訊，容器能夠在任意host間進行遷移而不用改變其IP地址。L3 over L3中，容器能夠跨越L3 Underlay進行L3通訊，容器在host間進行遷移時可能須要改變IP地址（取決於Overlay是L3 Flat仍是L3 Hierarchy）。L2/L3 Overlay下，不一樣租戶的IP地址也能夠Overlap，容器的IP編址也能夠與Underlay網絡Overlap。L2 over L3（VxLAN實現）以下圖所示。
1.CNM
CNM（Container Network Model）是Cisco的一位工程師提出的一個容器網絡模型（https://github.com/docker/docker/issues/9983），docker 1.9在libnetwork中實現了CNM（https://github.com/docker/libnetwork/blob/master/docs/design.md#the-container-network-model）。CNM的示意以下，主要創建在三類組件上Sandbox、Endpoint和Network。
Libnetwork對於CNM的實現包括如下5類對象：
2.CNI
CNI（Container Networking Interface）是CoreOS爲Rocket（docker以外的另外一種容器引擎）提出的一種plugin-based的容器網絡接口規範（https://github.com/containernetworking/cni/blob/master/SPEC.md），CNI十分符合Kubernetes中的網絡規劃思想，Kubernetes採用了CNI做爲默認的網絡接口規範，目前CNI的實現有Weave、Calico、Romana、Contiv等。
CNI沒有像CNM同樣規定模型的術語，CNI的實現依賴於兩種plugin：CNI Plugin負責將容器connect/disconnect到host中的vbridge/vswitch，IPAM Plugin負責配置容器namespace中的網絡參數。
CNI要求CNI Plugin支持容器的Add/Delete操做，操做所需的參數規範以下：
其中，Network configuration的schema以下：
爲了減輕CNI Plugin的負擔，ipam由CNI Plugin調用IPAM Plugin來實現，IPAM Plugin負責配置容器namespace中的網絡參數。IPAM的實施分爲兩種，一種是host-local，在subnet CIDR中選擇一個可用的IP地址做爲容器的IP，route entry（可選）在host本地配置完成。另外一種是dhcp，容器發送dhcp消息請求網絡參數。
Add操做後，會返回如下兩個結果：
IPs assigned to the interface：IPv4地址/IPv6地址/同時返回IPv4和IPv6地址
DNS information：nameservers+domain+search domains+options
Docker是當下最爲火熱的容器引擎，爲實現大規模集羣，docker推出了Swarm+Machine+Compose的集羣管理套件。然而，docker的原生網絡在很長一段時間內都是基於linux bridge+iptables實現的，這種方式下容器的可見性只存在於主機內部，這嚴重地限制了容器集羣的規模以及可用性。其實，社區很早就意識到了這個問題，不過因爲缺少專業的網絡團隊支持，所以docker的跨主機通訊問題始終沒有獲得很好的解決。另外，手動配置docker網絡是一件很麻煩的事情，儘管有pipework這樣的shell腳本工具，可是以腳本的自動化程度而言，用來運維大規模的docker網絡仍是too naïve。
2015年3月，docker收購了一家 SDN初創公司socketplane，隨即於5月宣佈將網絡管理功能從libcontainer和docker daemon中抽離出來做爲一個單獨的項目libnetwork，由原socketplane團隊成員接手，基於GO語言進行開發。2015年11月發佈的docker 1.9中libnetwork架構初步造成，支持多種nework driver並提供跨主機通訊，並在後續的1.十、1.11兩個版本中修復了大量bug。目前，libnetwork處於0.6版本。
（1）Docker0
Docker 1.9以前，網絡的實現主要由docker daemon來完成，當docker daemon啓動時默認狀況下會建立docker0，爲docker0分配IP地址，並設置一些iptables規則。而後經過docker run命令啓動容器，該命令能夠經過—net選項來選擇容器的接入方式（參見「容器的網絡模型」），docker 1.9以前的版本支持以下4種接入方式。
後3種沒什麼好說的，下面介紹一下bridge方式。Docker0由linux bridge實現，容器經過veth設備接入docker0，本地容器都處於同一subnet中，彼此間通訊經過docker0交換，與外界通訊以docker0的IP地址做爲網關。Docker0的IP地址能夠看作是內置鏈接在linux bridge上的設備（相似於ovs br上的同名internal port），位於host的root namespace中，容器與外界的通訊要依賴於host中的Iptables MASQUERADE規則來作SNAT，容器對外提供服務要依賴於host中的Iptables dnat規則來暴露端口。所以這種方案下，容器間的跨主機通訊其實用的都是host的socket，容器自己的IP地址和端口號對其它host上的容器來講都是不可見的。
這個方案很是原始，除了不能支持直接可見的跨主機通訊之外，NAT還會致使不少其它不合意的結果，如端口衝突等。另外，對於一些複雜的需求，如IPAM、多租戶、SDN等均沒法提供支持。
（2）Pipework
容器就是namespace，docker0就是linux bridge，再加上一些iptables規則，實際上容器組網就是調用一些已有的命令行而已。不過，當容器數量不少，或者是頻繁地啓動、關閉時，一條條命令行去配就顯得不是很合意了。因而，Docker公司的工程師Jerome Patazzoni就寫了一個shell腳原本簡化容器網絡的配置，主要就是對docker/ip nets/ip link/brctl這些命令行的二次封裝。Jerome Patazzoni本身認爲pipework是SDN tools for container，雖然有點too naïve了，可是從實用性的角度來看，確實倒也能夠知足一些自動化運維的須要。
固然pipework相比於docker0，除了提供了命令行的封裝之外，仍是具有一些其餘的優點的，好比支持多樣的network driver如OVS和macvlan，支持在host上開dhcp-server爲容器自動分配IP地址，支持免費ARP，等等。
具體的實現這裏就不講了，由於這東西其實徹底說不上高深，總共加起來也就400多行代碼，連接在這裏（https://github.com/jpetazzo/pipework/blob/master/pipework）。
（3）Libnetwork
Socketplane是一家作容器網絡的startup，2014年4季度建立，2015年3月份就被docker收購了，能夠看到當時docker對於原生的網絡管理組件的需求是有多麼迫切，並且socketplane團隊的這幫子人是SDN科班出身的，docker也總算有了搞網絡的正規軍。不過，socketplane和libnetwork的設計在架構上仍是有很大不一樣的，咱們先來看看socketplane的設計。
架構上，數據平面是OVS VxLAN，南向協議是OVSDB，控制平面是基於consul的分佈式k/v store，北向是socketplane CLI。控制平面的部署細節上，consul是放在一個socketplane容器中的，該容器經過host模式與host共享network namespace，consul經過eth0去作服務發現和狀態同步，狀態主要就是指容器與host IP的映射關係了。數據平面的流表狀況，就是match MAC+IP，actions就是送到本地的容器或者遠端的tunnel peer上，有點奇怪的是socketplane沒有使用tunnel_id，而是用了vlan_id標識vnet，這與RFC 7348是有衝突的。另外，根據爲數很少的資料來看，socketplane在被收購前只完成了L2的east-west，尚未考慮routing和south-north。
能夠看到，socketplane的設計並不複雜。可是被收購進docker後，麻煩事可就多了——首先，數據平面決計不能演化爲ovs monopolic，linux bridge要有，第三方driver也得玩得轉；其次，控制平面k/v store也要可插拔，起碼要支持zookeeper和etcd，最好還要把自家的集羣工具swarm集成進來；另外，要考慮老用戶的習慣，原有的網絡設計該保留還要保留；最後，還要遵循社區提出的容器網絡模型CNM（https://github.com/docker/docker/issues/9983）。
因而，docker網絡在1.9變成了下面這個樣子（圖中只畫了一個host），libkv提供swarm的服務發現，以及overlay network的k/v store，每一個host上開啓docker daemon並加入swarm cluster，libcontainer負責管理容器，libnetwork負責管理網絡。libnetwork支持5種網絡模式，none/host/bridge/overlay/remote，圖中從左到右依次顯示了後4種，其中overlay和一些remote能夠支持multi-host。
Overlay是libnetwork默認的multi-host網絡模式，經過VxLAN完成跨主機。Libnetwork會把overlay driver放在單獨的network namespace中，默認的overlay driver爲linux bridge。當容器（Sandbox）接入overlay（Network）時，會被分到兩個網卡（Endpoint），eth0連在vxlan_driver上，eth1連在docker_gwbridge上。Vxlan_driver主要負責L2的通訊，包括本地流量和跨主機流量，docker_gwbridge的實現原理和docker0同樣，負責處理Service的通訊，包括不一樣網絡容器間，以及容器與Internet間兩類流量。Eth0和eth1各有一個IP地址，分屬於不一樣網段，eth0默認以10開頭，eth1默認以172開頭，L2和L3的通訊直接經過容器內部的路由表分流，送到不一樣的設備上處理。
Remote是libnetwork爲了支持其它的Driver而設計的一種pluggble框架，這些Driver不要求必定支持multi-host。除了一些第三方的Driver外（如weave、calico等），目前libnetwork還原生提供了對macvlan driver和ipvlan driver的支持。固然，就像Neutron的ML2同樣，爲了打造生態，plugin driver的接口仍是要libnetwork本身來規範的，具體請參考https://github.com/docker/libnetwork/blob/master/docs/remote.md。
既然說是引入SDN，那麼API的規範對於libnetwork來講就十分重要了，不過目前libnetwork的接口封裝還處於至關初級的階段，基本上就是對Network和Endpoint的建立、刪除以及鏈接（https://github.com/docker/libnetwork/blob/master/docs/design.md）， 並無提供很友好的業務API。
對於libnetwork的介紹就是這些了。儘管libnetwork實現了千呼萬喚的multi-host，也爲docker網絡帶來了必定的靈活性與自動化，但就目前來講，它的API尚不夠友好，Driver的生態還不夠成熟，並且並不具有任何高級的網絡服務。所以，libnetwork相比於老大哥neutron來講，仍然存在着較大的差距。
其實，早在docker社區將libnetwork提上日程以前，就已經有很多人在爲容器的multi-host操心了。除了socketplane之外，如CoreOS爲k8s的網絡模型設計的flannel，經過P2P的控制平面構建overlay的weave net，經過BGP RR構建Flat L3的Calico，等等。最近，又有兩個開源項目開始琢磨新的容器組網辦法，一個是經過優化IPAM邏輯來構建Hierarchy L3的Romana，另外一個是Cisco ACI派系的Contiv。固然，網絡規模不大時，直接手配OVS也是個可行的方案。
這一節咱們就來對上述容器網絡選手來一個閱兵，先來介紹它們的架構，再來對它們作一個簡單的對比。
1.Flannel
在k8s的網絡設計中，服務以POD爲單位，每一個POD的IP地址，容器經過Behind the POD方式接入網絡（見「容器的網絡模型」），一個POD中可包含多個容器，這些容器共享該POD的IP地址。另外，k8s要求容器的IP地址都是全網可路由的，那麼顯然docker0+iptables的NAT方案是不可行的。
實現上述要求其實有不少種組網方法，Flat L3是一種（如Calico），Hierarchy L3（如Romana）是一種，另外L3 Overlay也是能夠的，CoreOS就採用L3 Overlay的方式設計了flannel， 並規定每一個host下各個POD屬於同一個subnet，不一樣的host/VM下的POD屬於不一樣subnet。咱們來看flannel的架構，控制平面上host本地的flanneld負責從遠端的ETCD集羣同步本地和其它host上的subnet信息，併爲POD分配IP地址。數據平面flannel經過UDP封裝來實現L3 Overlay，既能夠選擇通常的TUN設備又能夠選擇VxLAN設備（注意，因爲圖來源不一樣，請忽略具體的IP地址）。
Flannel可說的很少，作得比較早，技術選型也十分紅熟，已經能夠用於大規模部署。下面是控制信道上通訊內容的一個實例。
2.Weave
Weave是Weaveworks公司的容器網絡產品，你們都叫慣了weave，實際上目前該產品的名字叫作Weave Nets，由於Weaveworks如今並非一家只作網絡的公司，最近它又作了兩款其它的容器管理產品，GUI+集羣。不過，爲你們所熟悉的仍是它網絡口的產品。
不一樣於其它的multi-host方案，Weave能夠支持去中心化的控制平面，各個host上的wRouter間經過創建Full Mesh的TCP連接，並經過Gossip來同步控制信息。這種方式省去了集中式的K/V Store，可以在必定程度上減低部署的複雜性，Weave將其稱爲「data centric」，而非RAFT或者Paxos的「algorithm centric」。
不過，考慮到docker libnetwork是集中式的K/V Store做爲控制平面，所以Weave爲了集成docker，它也提供了對集中式控制平面的支持，可以做爲docker remote driver與libkv通訊。
數據平面上，Weave經過UDP封裝實現L2 Overlay，封裝支持兩種模式，一種是運行在user space的sleeve mode，另外一種是運行在kernal space的 fastpath mode。Sleeve mode經過pcap設備在Linux bridge上截獲數據包並由wRouter完成UDP封裝，支持對L2 traffic進行加密，還支持Partial Connection，可是性能損失明顯。Fastpath mode即經過OVS的odp封裝VxLAN並完成轉發，wRouter不直接參與轉發，而是經過下發odp 流表的方式控制轉發，這種方式能夠明顯地提高吞吐量，可是不支持加密等高級功能。
這裏要說一下Partial Connection的組網。在多DC的場景下一些DC Sites沒法直連，好比Peer 1與Peer 5間的隧道通訊，中間勢必要通過Peer 3，那麼Peer 3就必需要支持作隧道的中間轉發。目前sleeve mode的實現是經過多級封裝來完成的，目前fastpath上尚未實現。
上面主要介紹的是weave對multi-host L2的實現。關於Service的發佈，weave作的也比較完整。首先，wRouter集成了DNS功能，可以動態地進行服務發現和負載均衡，另外，與libnetwork 的overlay driver相似，weave要求每一個POD有兩個網卡，一個就連在lb/ovs上處理L2 流量，另外一個則連在docker0上處理Service流量，docker0後面仍然是iptables做NAT。
3.Calico
Calico是一個專門作DC網絡的開源項目。當業界都癡迷於Overlay的時候，Calico實現multi-host容器網絡的思路確能夠說是返璞歸真——pure L3，pure L3是指容器間的組網都是經過IP來完成的。這是由於，Calico認爲L3更爲健壯，且對於網絡人員更爲熟悉，而L2網絡因爲控制平面太弱會致使太多問題，排錯起來也更加困難。那麼，若是可以利用好L3去設計DC的話就徹底沒有必要用L2。
不過對於應用來講，L2無疑是更好的網絡，尤爲是容器網絡對二層的需求則更是強烈。業界廣泛給出的答案是L2 over L3，而Calico認爲Overlay技術帶來的開銷（CPU、吞吐量）太大，若是能用L3去模擬L2是最好的，這樣既能保證性能、又能讓應用滿意、還能給網絡人員省事，看上去是件一舉多得的事。用L3去模擬L2的關鍵就在於打破傳統的Hierarchy L3概念，IP再也不之前綴收斂，你們乾脆都把32位的主機路由發佈到網絡上，那麼Flat L3的網絡對於應用來講即和L2如出一轍。
這個思路不簡單，刨了L3存在必要性的老底兒，實際上若是不用考慮可擴展性、也不考慮private和public，IP地址和MAC地址標識endpoint的功能上確實是徹底冗餘的，即便考慮可擴展性，一個用L3技術造成的大二層和一個用L2技術造成的大二層並無本質上的差距。並且，L3有成熟的、完善的、被廣泛承認接受的控制平面，以及豐富的管理工具，運維起來要容易的多。
因而，Calico給出了下面的設計。L3選擇的是BGP，控制平面是開源的Bird作BGP RR，etcd集羣+Felix作業務數據同步，數據平面直接是Linux kernel作vRouter，FIB全是/32的v4或者/128的v6。具體來講，etcd接受業務數據，Felix向etcd同步後向host本地的路由表注入32/128位的主機路由，以及iptables的安全規則，而後Bird BGP Client將host的本地路由發送給Bird BGP RR，而後再由RR發佈到其它host。
這個架構沒什麼好說的，技術成熟、高性能、易維護，看起來是生產級別的容器網絡環境最好的選擇。可是，也有不如意的地方：
不過，這都不是什麼嚴重的問題。但有一點嚴重的是，Calico控制平面的上述設計中，物理網絡最好是L2 Fabric，這樣vRouter間都是直接可達的，路由不須要把物理設備當作下一跳。若是是L3 Fabric，控制平面的問題立刻就來了：下一跳是物理設備，那麼它的IP是多少？物理設備若是要存32位的路由，能存多少？
這絕對是個難題。所以，爲了解決以上問題，Calico不得不採起了妥協，爲了支持L3 Fabric，Calico推出了IPinIP的選項，可是這明顯屬於本身打本身的臉，這麼玩的話還不如用VxLAN來的實在呢。不過，對於使用L2 Fabric、沒有多租戶需求的企業來講，用Calico上生產環境應該是不錯的選擇。
4.Romana
說完了Calico的Flat L3，再來看看Romana給出的Hierarchy L3的方案。Romana是Panic Networks在2016年新提出的開源項目，旨在解決Overlay方案給網絡帶來的開銷，雖然目標和Calico基本一致，可是採起的思路卻大相徑庭，Romana但願用Hierarchy L3來組織DC的網絡——沒有大二層什麼事兒了。
固然，Romana想要的是SDN的Hierarchy L3，所以控制平面的路由比較好控制了，不用搞RR這種東西了，不過IPAM的問題就比較關鍵了。IP地址有32位，哪些用來規劃leaf-spine？哪些用來規劃host？哪些用來規劃VM？哪些用來規劃POD？若是要多租戶，哪些用來規劃Tenant/Segment？能夠說，這些若是有規劃好的可能，並且均可以動態調整，那麼Romana會是個「很SDN」的方案。
不過，這可不是說笑的，想要規劃好談何容易啊？問題歸根結底我認爲有以下幾點：
能夠看一看Romana的slides裏面給的IPAM實例，255 hosts、255 tenants、255 endpoints，對於對於IDC、雲服務提供商、容器用戶，是否是都顯得侷促了一些呢？
所以從網絡設計的角度來講，我的目前尚未想到Romana可以支持大規模容器網絡的理由，至於項目具體會發展成什麼樣子，仍需觀察。
下面來看一看它的架構。倒也畫的比較簡單，managers是控制端，agent在設備端。控制端幾個組件的功能，看了名字也就知道了，這裏再也不解釋。設備端接受調度，給容器配IP，在host上配路由，也沒什麼好說的了。
5.Contiv
Cisco在2015年搞的開源項目，準備把ACI那一套EPG的東西用到容器網絡中來，號稱要作容器的micro-segment。具體的沒什麼能講的，由於Github上確實也尚未什麼東西，並且Cisco作開源向來是奔着讓人捉摸不透去的。Cisco的人說會集成到docker libnetwork中去，但項目的模樣能不能出來，還得看將來的進展。項目連接在這：https://github.com/contiv/netplugin。
眼看着容器一步一步火起來，幾乎搶走了虛擬機的全部風頭，OpenStack也按耐不住要作集成了。有Magnum作Swarm、K8S這些COE（Container Orchestration Engine）的前端，OpenStack就有了編排大規模容器集羣的入口，而除了編排之外，網絡側的集成也是一個大頭。其實從network driver的角度來看，容器和虛擬機倒也沒什麼特別大的差異，那麼再搞一套Neutron for Container顯然是沒有必要（也不現實）的了。因而，Kuryr項目應運而生，旨在將現有Neutron的network driver銜接到容器網絡中。
Kuryr是捷克語「信使」的意思，顧名思義，就是要把容器網絡的API轉化成Neutron API傳遞給Neutron，而後仍然由Neutron來調度後端的network driver來爲容器組網。要作成這件事情，主要得解決三個問題：
第一個問題，通俗點說就是要作好翻譯工做。以docker libnetwork舉例，用戶調了libnetwork的API要新建一個（CNM模型中的）Network對象，那Kuryr就得翻譯成Neutron能聽得懂的API——幫我起一個（Neutron）Subnet。這要求Kuryr做爲remote driver，因而Neutron和Neutron driver對於libnetwork就是徹底透明的了。
上面舉了一個好理解的例子，很差辦的是當兩側的模型不一致，尤爲是左邊有新概念的時候。好比，如今要爲部署在VM中的Nested Container搞一個Security Group，可是Neutron目前只能管到host上，是看不見這個藏起來的傢伙的，那這時就要對Neutron作擴展了，思路就是爲Neutron Port新擴展一個屬性來標記VM中這個Nested Container，這樣作識別的時候帶上這個標記就好了。
從實現上來說，Kuryr要負責管理兩側的資源實例的ID的映射關係，以保證操做的一致性，不然會直接帶來用戶間的網絡入侵。另外，IPAM如今在兩側都被獨立出來了，IPAM的API也要能銜接的上。
至於第二個問題，拍腦殼想彷佛是不該該存在的。可是，目前絕大多數Neutron network driver在綁定端口時的動做只有更新數據庫，並不會爲容器作plug。這個作法的緣由在於，以前在處理虛擬機的時候，plug被看做是虛擬機啓動時自帶的動做，所以plug就放在了Nova的poweron函數裏面。改network driver天然是很差的，因而Kuryr就得負責起處理這個歷史遺留問題的任務了。
第三個問題可就是學問了。講道理的話，業務的API沒問題了，容器也都接入網絡了，而轉發的邏輯都是network driver寫好的，跟接的是容器仍是虛擬機也沒有一毛錢關係，那不就應該萬事大吉了嗎？但是現實確頗有可能不是這樣的，好比：因爲容器做爲工做負載，其特徵與虛擬機徹底不一樣，所以業務對兩者需求也是截然不同。容器都是批量批量的起，並且它們的生命週期可能很短——須要來回來去的起，而Neutron的API都是走軟件的消息總線的，而過於密集的API操做頗有可能會形成消息總線崩潰掉。一個新建容器的API等了1分鐘失敗了，那麼可能業務的需求就過去了（好比搶票），這個損失天然是不可接受的。
相似的問題可能都在潛伏着，若是Kuryr要走上生產環境，可就須要Gal Sagie多動腦筋了。
雖然Kuryr是OpenStack中比較新的項目，但目前Kuryr進展的還不錯，對libnetwork和k8S的集成都有demo出來了。一旦Kuryr成熟後，這意味着Neutron下面的各路vendor們均可以不費吹灰之力直接上容器了，這對於Weave、Calico這些靠容器起家的vendor不可算是個好消息。
看來，雲網絡vendor間的競爭最後也都將演變爲OpenStack、K8S、Mesos這些大部頭對於DCOS的爭奪了，畢竟胳膊擰不過大腿啊。
-------------------------------------------------------------------------------------------------
SDN撕X羣（微信羣），主要就是曝SDN真相的，感興趣的就加微信wx928579866 ，或者微信tangahr , 暗號是：SDN撕X羣。 要想圍觀SDNers V.S. Networkers請必定加此羣。
編者按：本文系SDNLAB技術分享系列，本次分享來自SDN撕X羣（羣主：大貓貓）羣直播，咱們但願經過SDNLAB提供的平臺傳播知識，傳遞價值，歡迎加入咱們的行列。
分享嘉賓
--------------------------------------------------------------------------------------------------
分享介紹：張晨：目前就讀於北京郵電大學FNL實驗室，網絡與交換國家重點實驗室。目前主要研究方向：軟件定義網絡，網絡虛擬化，雲數據中心網絡。目前任職於Brocade。
--------------------------------------------------------------------------------------------------
容器這一兩年火的不行，能夠說是獨領IT風騷，一時風光無二。相比於虛擬機來講，容器更輕，一臺服務器上能夠運行成百上千的容器，這意味着更爲密集的計算資源，所以基於容器運行工做負載的模式深受雲服務提供商們的青睞。
然而對於雲管理員來講，管理容器確是一件至關頭疼的事情，容器的生命週期更短了，容器的數量更多了，容器間的關係更復雜了。爲了簡化大規模容器集羣的運維，各路容器管理與編排平臺應運而生，Docker社區開發了Swarm+Machine+Compose的集羣管理套件，Twitter主推Apache的Mesos，Google則開源了本身的Kubernetes。這些平臺爲大規模的容器集羣提供了資源調度、服務發現、擴容縮容等功能，然而這些功能都是策略向的，真正要實現大規模的容器集羣，網絡纔是最基礎的一環。
相比於虛擬機網絡，容器網絡主要具備如下特色，以及相應的技術挑戰：
不過，因爲容器自身的特徵使得它與應用的綁定更爲緊密，從交付模式來看更傾向於PaaS而非IaaS，所以容器網絡並無成爲業界關注的焦點。起步較晚，再加上上述諸多的技術挑戰，使得容器網絡相比於OpenStack Neutron來講發展的狀況要落後很多。Docker在開始的很長一段時間內只支持使用linux bridge+iptables進行single-host的部署，自動化方面也只有pipework這類shell腳本。
幸運的是，目前業界已經意識到了可擴展、自動化的網絡對於大規模容器環境的重要性：docker收購了容器網絡的創業公司socketplane，隨即將網絡管理從docker daemon中獨立出來造成libnetwork，並在docker 1.9中提供了多種network driver，並支持了multi-host；一些專業的容器網絡（如flannel、weave、calico等）也開始與各個容器編排平臺進行集成；OpenStack社區也成立了專門的子項目Kuryr提供Neutron network driver（如DragonFlow、OVN、Midolnet等）與容器的對接。
這一節咱們來介紹容器網絡的基礎，包括容器的接入，容器間的組網，以及幾種容器網絡的通用模型。
1.和host共享network namespace
這種接入模式下，不會爲容器建立網絡協議棧，即容器沒有獨立於host的network namespace，可是容器的其餘namespace（如IPC、PID、Mount等）仍是和host的namespace獨立的。容器中的進程處於host的網絡環境中，與host共用L2-L4的網絡資源。該方式的優勢是，容器可以直接使用host的網絡資源與外界進行通訊，沒有額外的開銷（如NAT），缺點是網絡的隔離性差，容器和host所使用的端口號常常會發生衝突。
2.和host共享物理網卡
2與1的區別在於，容器和host共享物理網卡，但容器擁有獨立於host的network namespace，容器有本身的MAC地址、IP地址、端口號。這種接入方式主要使用SR-IOV技術，每一個容器被分配一個VF，直接經過PCIe網卡與外界通訊，優勢是旁路了host kernel不佔任何計算資源，並且IO速度較快，缺點是VF數量有限且對容器遷移的支持不足。
3.和另一個容器共享network namespace
與1相似，容器沒有獨立的network namespace，可是以該方式新建立的容器將與一個已經存在的容器共享其network namespace（包括MAC、IP以及端口號等），網絡角度上二者將做爲一個總體對外提供服務，不過兩個容器的其餘namespace（如IPC、PID、Mount等）是彼此獨立的。這種方式的優勢是，network namespace相聯繫的容器間的通訊高效便利，缺點是因爲其餘的namespace仍然是彼此獨立的，所以容器間沒法造成一個業務邏輯上的總體。
4.Behind the POD
這種方式是Google在Kubernetes中的設計中提出來的。Kubernetes中，POD是指一個能夠被建立、銷燬、調度、管理的最小的部署單元，一個POD有一個基礎容器以及一個或一組應用容器，基礎容器對應一個獨立的network namespace並擁有一個其它POD可見的IP地址（以IP A.B.C.D指代），應用容器間則共享基礎容器的network namespace（包括MAC、IP以及端口號等），還能夠共享基礎容器的其它的namespace（如IPC、PID、Mount等）。POD做爲一個總體鏈接在host的vbridge/vswitch上，使用IP地址A.B.C.D與其它POD進行通訊，不一樣host中的POD處於不一樣的subnet中，同一host中的不一樣POD處於同一subnet中。這種方式的優勢是一些業務上密切相關的容器能夠共享POD的所有資源（它們通常不會產生資源上的衝突），而這些容器間的通訊高效便利，缺點是同一POD下的容器必須位於同一host中，從而限制了位置的靈活性。
5.鏈接在的vbridge/vswitch上
這種方式是最爲常見的，容器擁有獨立的network namespace，經過veth-pair鏈接到vswitch上。這種方式對於網絡來講是最爲直接的，在vswitch看來，經過這種方式鏈接的容器與虛擬機並無任何區別。vbridge/vswitch的實現有不少，包括linux bridge，Open vSwitch，macvlan等。這種方式的優勢是vbridge/vswitch可實現的功能比較豐富，尤爲是Open vSwitch能夠支持VLAN、Tunnel、SDN Controller等，缺點是可能會形成不少額外的開銷。
6.嵌套部署在VM中
這種方式在生產環境也比較常見，因爲一臺host中每每部署着多方的容器，存在安全隱患，所以許多用戶會選擇先啓動本身的虛擬機，而後在本身的虛擬機上運行容器。這種方式實際上是一種嵌套虛擬化，所以本質上來講，這種方式下容器的接入對於host能夠是徹底透明的，容器在虛擬機內部的接入能夠採用上述1-5中任意的方法。不過這對於雲平臺來講就意味着失去了對容器接入的管理能力，爲了保留這一能力，每每須要在虛擬機內部和host中分別部署vswitch並實現級聯，由虛擬機內部的vswitch用來接入容器並對其進行特定的標記（雲平臺分配），以便host中的vswitch進行識別。一種常見的方式是使用Open vSwitch對容器標記vlan id。
1.Flat
Flat主要可分爲L2 Flat和L3 Flat。L2 Flat指各個host中全部的容器都在virtual+physical網絡造成的VLAN大二層中，容器能夠在任意host間進行遷移而不用改變其IP地址。L3 Flat指各個host中全部的容器都在virtual+physical網絡中可路由，且路由以/32位的形式存在，使得容器在host間遷移時不須要改變IP地址。L2/L3 Flat下，不一樣租戶的IP地址不能夠Overlap，L3 Flat下容器的IP編址也不可與physical網絡Overlap。L3 Flat簡單示意以下。
2.L3 Hierarchy
L3 Hierarchy中各個host中全部的容器都在virtual+physical網絡中可路由，且路由在不一樣層次上（VM/Host/Leaf/Spine）以聚合路由的形式存在，即處於相同CIDR的容器須要在物理位置上被組織在一塊兒，所以容器在host間遷移時須要改變IP地址。L3 Hierarchy下，不一樣租戶的IP地址不能夠Overlap，容器的IP編址也不可與physical網絡Overlap。下圖是L3 Hierarchy中的IP地址規劃示例。
3.Overlay
Overlay主要可分爲L2 over L3和L3 over L3，少部分實現L2/L3 over UDP。L2 over L3中，容器能夠跨越L3 Underlay進行L2通訊，容器能夠在任意host間進行遷移而不用改變其IP地址。L3 over L3中，容器能夠跨越L3 Underlay進行L3通訊，容器在host間進行遷移時可能須要改變IP地址（取決於Overlay是L3 Flat仍是L3 Hierarchy）。L2/L3 Overlay下，不一樣租戶的IP地址也能夠Overlap，容器的IP編址也能夠與Underlay網絡Overlap。L2 over L3（VxLAN實現）以下圖所示。
1.CNM
CNM（Container Network Model）是Cisco的一位工程師提出的一個容器網絡模型（https://github.com/docker/docker/issues/9983），docker 1.9在libnetwork中實現了CNM（https://github.com/docker/libnetwork/blob/master/docs/design.md#the-container-network-model）。CNM的示意以下，主要創建在三類組件上Sandbox、Endpoint和Network。
Libnetwork對於CNM的實現包括如下5類對象：
2.CNI
CNI（Container Networking Interface）是CoreOS爲Rocket（docker以外的另外一種容器引擎）提出的一種plugin-based的容器網絡接口規範（https://github.com/containernetworking/cni/blob/master/SPEC.md），CNI十分符合Kubernetes中的網絡規劃思想，Kubernetes採用了CNI做爲默認的網絡接口規範，目前CNI的實現有Weave、Calico、Romana、Contiv等。
CNI沒有像CNM同樣規定模型的術語，CNI的實現依賴於兩種plugin：CNI Plugin負責將容器connect/disconnect到host中的vbridge/vswitch，IPAM Plugin負責配置容器namespace中的網絡參數。
CNI要求CNI Plugin支持容器的Add/Delete操做，操做所需的參數規範以下：
其中，Network configuration的schema以下：
爲了減輕CNI Plugin的負擔，ipam由CNI Plugin調用IPAM Plugin來實現，IPAM Plugin負責配置容器namespace中的網絡參數。IPAM的實施分爲兩種，一種是host-local，在subnet CIDR中選擇一個可用的IP地址做爲容器的IP，route entry（可選）在host本地配置完成。另外一種是dhcp，容器發送dhcp消息請求網絡參數。
Add操做後，會返回如下兩個結果：
IPs assigned to the interface：IPv4地址/IPv6地址/同時返回IPv4和IPv6地址
DNS information：nameservers+domain+search domains+options
Docker是當下最爲火熱的容器引擎，爲實現大規模集羣，docker推出了Swarm+Machine+Compose的集羣管理套件。然而，docker的原生網絡在很長一段時間內都是基於linux bridge+iptables實現的，這種方式下容器的可見性只存在於主機內部，這嚴重地限制了容器集羣的規模以及可用性。其實，社區很早就意識到了這個問題，不過因爲缺少專業的網絡團隊支持，所以docker的跨主機通訊問題始終沒有獲得很好的解決。另外，手動配置docker網絡是一件很麻煩的事情，儘管有pipework這樣的shell腳本工具，可是以腳本的自動化程度而言，用來運維大規模的docker網絡仍是too naïve。
2015年3月，docker收購了一家 SDN初創公司socketplane，隨即於5月宣佈將網絡管理功能從libcontainer和docker daemon中抽離出來做爲一個單獨的項目libnetwork，由原socketplane團隊成員接手，基於GO語言進行開發。2015年11月發佈的docker 1.9中libnetwork架構初步造成，支持多種nework driver並提供跨主機通訊，並在後續的1.十、1.11兩個版本中修復了大量bug。目前，libnetwork處於0.6版本。
（1）Docker0
Docker 1.9以前，網絡的實現主要由docker daemon來完成，當docker daemon啓動時默認狀況下會建立docker0，爲docker0分配IP地址，並設置一些iptables規則。而後經過docker run命令啓動容器，該命令能夠經過—net選項來選擇容器的接入方式（參見「容器的網絡模型」），docker 1.9以前的版本支持以下4種接入方式。
後3種沒什麼好說的，下面介紹一下bridge方式。Docker0由linux bridge實現，容器經過veth設備接入docker0，本地容器都處於同一subnet中，彼此間通訊經過docker0交換，與外界通訊以docker0的IP地址做爲網關。Docker0的IP地址能夠看作是內置鏈接在linux bridge上的設備（相似於ovs br上的同名internal port），位於host的root namespace中，容器與外界的通訊要依賴於host中的Iptables MASQUERADE規則來作SNAT，容器對外提供服務要依賴於host中的Iptables dnat規則來暴露端口。所以這種方案下，容器間的跨主機通訊其實用的都是host的socket，容器自己的IP地址和端口號對其它host上的容器來講都是不可見的。
這個方案很是原始，除了不能支持直接可見的跨主機通訊之外，NAT還會致使不少其它不合意的結果，如端口衝突等。另外，對於一些複雜的需求，如IPAM、多租戶、SDN等均沒法提供支持。
（2）Pipework
容器就是namespace，docker0就是linux bridge，再加上一些iptables規則，實際上容器組網就是調用一些已有的命令行而已。不過，當容器數量不少，或者是頻繁地啓動、關閉時，一條條命令行去配就顯得不是很合意了。因而，Docker公司的工程師Jerome Patazzoni就寫了一個shell腳原本簡化容器網絡的配置，主要就是對docker/ip nets/ip link/brctl這些命令行的二次封裝。Jerome Patazzoni本身認爲pipework是SDN tools for container，雖然有點too naïve了，可是從實用性的角度來看，確實倒也能夠知足一些自動化運維的須要。
固然pipework相比於docker0，除了提供了命令行的封裝之外，仍是具有一些其餘的優點的，好比支持多樣的network driver如OVS和macvlan，支持在host上開dhcp-server爲容器自動分配IP地址，支持免費ARP，等等。
具體的實現這裏就不講了，由於這東西其實徹底說不上高深，總共加起來也就400多行代碼，連接在這裏（https://github.com/jpetazzo/pipework/blob/master/pipework）。
（3）Libnetwork
Socketplane是一家作容器網絡的startup，2014年4季度建立，2015年3月份就被docker收購了，能夠看到當時docker對於原生的網絡管理組件的需求是有多麼迫切，並且socketplane團隊的這幫子人是SDN科班出身的，docker也總算有了搞網絡的正規軍。不過，socketplane和libnetwork的設計在架構上仍是有很大不一樣的，咱們先來看看socketplane的設計。
架構上，數據平面是OVS VxLAN，南向協議是OVSDB，控制平面是基於consul的分佈式k/v store，北向是socketplane CLI。控制平面的部署細節上，consul是放在一個socketplane容器中的，該容器經過host模式與host共享network namespace，consul經過eth0去作服務發現和狀態同步，狀態主要就是指容器與host IP的映射關係了。數據平面的流表狀況，就是match MAC+IP，actions就是送到本地的容器或者遠端的tunnel peer上，有點奇怪的是socketplane沒有使用tunnel_id，而是用了vlan_id標識vnet，這與RFC 7348是有衝突的。另外，根據爲數很少的資料來看，socketplane在被收購前只完成了L2的east-west，尚未考慮routing和south-north。
能夠看到，socketplane的設計並不複雜。可是被收購進docker後，麻煩事可就多了——首先，數據平面決計不能演化爲ovs monopolic，linux bridge要有，第三方driver也得玩得轉；其次，控制平面k/v store也要可插拔，起碼要支持zookeeper和etcd，最好還要把自家的集羣工具swarm集成進來；另外，要考慮老用戶的習慣，原有的網絡設計該保留還要保留；最後，還要遵循社區提出的容器網絡模型CNM（https://github.com/docker/docker/issues/9983）。
因而，docker網絡在1.9變成了下面這個樣子（圖中只畫了一個host），libkv提供swarm的服務發現，以及overlay network的k/v store，每一個host上開啓docker daemon並加入swarm cluster，libcontainer負責管理容器，libnetwork負責管理網絡。libnetwork支持5種網絡模式，none/host/bridge/overlay/remote，圖中從左到右依次顯示了後4種，其中overlay和一些remote能夠支持multi-host。
Overlay是libnetwork默認的multi-host網絡模式，經過VxLAN完成跨主機。Libnetwork會把overlay driver放在單獨的network namespace中，默認的overlay driver爲linux bridge。當容器（Sandbox）接入overlay（Network）時，會被分到兩個網卡（Endpoint），eth0連在vxlan_driver上，eth1連在docker_gwbridge上。Vxlan_driver主要負責L2的通訊，包括本地流量和跨主機流量，docker_gwbridge的實現原理和docker0同樣，負責處理Service的通訊，包括不一樣網絡容器間，以及容器與Internet間兩類流量。Eth0和eth1各有一個IP地址，分屬於不一樣網段，eth0默認以10開頭，eth1默認以172開頭，L2和L3的通訊直接經過容器內部的路由表分流，送到不一樣的設備上處理。
Remote是libnetwork爲了支持其它的Driver而設計的一種pluggble框架，這些Driver不要求必定支持multi-host。除了一些第三方的Driver外（如weave、calico等），目前libnetwork還原生提供了對macvlan driver和ipvlan driver的支持。固然，就像Neutron的ML2同樣，爲了打造生態，plugin driver的接口仍是要libnetwork本身來規範的，具體請參考https://github.com/docker/libnetwork/blob/master/docs/remote.md。
既然說是引入SDN，那麼API的規範對於libnetwork來講就十分重要了，不過目前libnetwork的接口封裝還處於至關初級的階段，基本上就是對Network和Endpoint的建立、刪除以及鏈接（https://github.com/docker/libnetwork/blob/master/docs/design.md）， 並無提供很友好的業務API。
對於libnetwork的介紹就是這些了。儘管libnetwork實現了千呼萬喚的multi-host，也爲docker網絡帶來了必定的靈活性與自動化，但就目前來講，它的API尚不夠友好，Driver的生態還不夠成熟，並且並不具有任何高級的網絡服務。所以，libnetwork相比於老大哥neutron來講，仍然存在着較大的差距。
其實，早在docker社區將libnetwork提上日程以前，就已經有很多人在爲容器的multi-host操心了。除了socketplane之外，如CoreOS爲k8s的網絡模型設計的flannel，經過P2P的控制平面構建overlay的weave net，經過BGP RR構建Flat L3的Calico，等等。最近，又有兩個開源項目開始琢磨新的容器組網辦法，一個是經過優化IPAM邏輯來構建Hierarchy L3的Romana，另外一個是Cisco ACI派系的Contiv。固然，網絡規模不大時，直接手配OVS也是個可行的方案。
這一節咱們就來對上述容器網絡選手來一個閱兵，先來介紹它們的架構，再來對它們作一個簡單的對比。
1.Flannel
在k8s的網絡設計中，服務以POD爲單位，每一個POD的IP地址，容器經過Behind the POD方式接入網絡（見「容器的網絡模型」），一個POD中可包含多個容器，這些容器共享該POD的IP地址。另外，k8s要求容器的IP地址都是全網可路由的，那麼顯然docker0+iptables的NAT方案是不可行的。
實現上述要求其實有不少種組網方法，Flat L3是一種（如Calico），Hierarchy L3（如Romana）是一種，另外L3 Overlay也是能夠的，CoreOS就採用L3 Overlay的方式設計了flannel， 並規定每一個host下各個POD屬於同一個subnet，不一樣的host/VM下的POD屬於不一樣subnet。咱們來看flannel的架構，控制平面上host本地的flanneld負責從遠端的ETCD集羣同步本地和其它host上的subnet信息，併爲POD分配IP地址。數據平面flannel經過UDP封裝來實現L3 Overlay，既能夠選擇通常的TUN設備又能夠選擇VxLAN設備（注意，因爲圖來源不一樣，請忽略具體的IP地址）。
Flannel可說的很少，作得比較早，技術選型也十分紅熟，已經能夠用於大規模部署。下面是控制信道上通訊內容的一個實例。
2.Weave
Weave是Weaveworks公司的容器網絡產品，你們都叫慣了weave，實際上目前該產品的名字叫作Weave Nets，由於Weaveworks如今並非一家只作網絡的公司，最近它又作了兩款其它的容器管理產品，GUI+集羣。不過，爲你們所熟悉的仍是它網絡口的產品。
不一樣於其它的multi-host方案，Weave能夠支持去中心化的控制平面，各個host上的wRouter間經過創建Full Mesh的TCP連接，並經過Gossip來同步控制信息。這種方式省去了集中式的K/V Store，可以在必定程度上減低部署的複雜性，Weave將其稱爲「data centric」，而非RAFT或者Paxos的「algorithm centric」。
不過，考慮到docker libnetwork是集中式的K/V Store做爲控制平面，所以Weave爲了集成docker，它也提供了對集中式控制平面的支持，可以做爲docker remote driver與libkv通訊。
數據平面上，Weave經過UDP封裝實現L2 Overlay，封裝支持兩種模式，一種是運行在user space的sleeve mode，另外一種是運行在kernal space的 fastpath mode。Sleeve mode經過pcap設備在Linux bridge上截獲數據包並由wRouter完成UDP封裝，支持對L2 traffic進行加密，還支持Partial Connection，可是性能損失明顯。Fastpath mode即經過OVS的odp封裝VxLAN並完成轉發，wRouter不直接參與轉發，而是經過下發odp 流表的方式控制轉發，這種方式能夠明顯地提高吞吐量，可是不支持加密等高級功能。
這裏要說一下Partial Connection的組網。在多DC的場景下一些DC Sites沒法直連，好比Peer 1與Peer 5間的隧道通訊，中間勢必要通過Peer 3，那麼Peer 3就必需要支持作隧道的中間轉發。目前sleeve mode的實現是經過多級封裝來完成的，目前fastpath上尚未實現。
上面主要介紹的是weave對multi-host L2的實現。關於Service的發佈，weave作的也比較完整。首先，wRouter集成了DNS功能，可以動態地進行服務發現和負載均衡，另外，與libnetwork 的overlay driver相似，weave要求每一個POD有兩個網卡，一個就連在lb/ovs上處理L2 流量，另外一個則連在docker0上處理Service流量，docker0後面仍然是iptables做NAT。
3.Calico
Calico是一個專門作DC網絡的開源項目。當業界都癡迷於Overlay的時候，Calico實現multi-host容器網絡的思路確能夠說是返璞歸真——pure L3，pure L3是指容器間的組網都是經過IP來完成的。這是由於，Calico認爲L3更爲健壯，且對於網絡人員更爲熟悉，而L2網絡因爲控制平面太弱會致使太多問題，排錯起來也更加困難。那麼，若是可以利用好L3去設計DC的話就徹底沒有必要用L2。
不過對於應用來講，L2無疑是更好的網絡，尤爲是容器網絡對二層的需求則更是強烈。業界廣泛給出的答案是L2 over L3，而Calico認爲Overlay技術帶來的開銷（CPU、吞吐量）太大，若是能用L3去模擬L2是最好的，這樣既能保證性能、又能讓應用滿意、還能給網絡人員省事，看上去是件一舉多得的事。用L3去模擬L2的關鍵就在於打破傳統的Hierarchy L3概念，IP再也不之前綴收斂，你們乾脆都把32位的主機路由發佈到網絡上，那麼Flat L3的網絡對於應用來講即和L2如出一轍。
這個思路不簡單，刨了L3存在必要性的老底兒，實際上若是不用考慮可擴展性、也不考慮private和public，IP地址和MAC地址標識endpoint的功能上確實是徹底冗餘的，即便考慮可擴展性，一個用L3技術造成的大二層和一個用L2技術造成的大二層並無本質上的差距。並且，L3有成熟的、完善的、被廣泛承認接受的控制平面，以及豐富的管理工具，運維起來要容易的多。
因而，Calico給出了下面的設計。L3選擇的是BGP，控制平面是開源的Bird作BGP RR，etcd集羣+Felix作業務數據同步，數據平面直接是Linux kernel作vRouter，FIB全是/32的v4或者/128的v6。具體來講，etcd接受業務數據，Felix向etcd同步後向host本地的路由表注入32/128位的主機路由，以及iptables的安全規則，而後Bird BGP Client將host的本地路由發送給Bird BGP RR，而後再由RR發佈到其它host。
這個架構沒什麼好說的，技術成熟、高性能、易維護，看起來是生產級別的容器網絡環境最好的選擇。可是，也有不如意的地方：
不過，這都不是什麼嚴重的問題。但有一點嚴重的是，Calico控制平面的上述設計中，物理網絡最好是L2 Fabric，這樣vRouter間都是直接可達的，路由不須要把物理設備當作下一跳。若是是L3 Fabric，控制平面的問題立刻就來了：下一跳是物理設備，那麼它的IP是多少？物理設備若是要存32位的路由，能存多少？
這絕對是個難題。所以，爲了解決以上問題，Calico不得不採起了妥協，爲了支持L3 Fabric，Calico推出了IPinIP的選項，可是這明顯屬於本身打本身的臉，這麼玩的話還不如用VxLAN來的實在呢。不過，對於使用L2 Fabric、沒有多租戶需求的企業來講，用Calico上生產環境應該是不錯的選擇。
4.Romana
說完了Calico的Flat L3，再來看看Romana給出的Hierarchy L3的方案。Romana是Panic Networks在2016年新提出的開源項目，旨在解決Overlay方案給網絡帶來的開銷，雖然目標和Calico基本一致，可是採起的思路卻大相徑庭，Romana但願用Hierarchy L3來組織DC的網絡——沒有大二層什麼事兒了。
固然，Romana想要的是SDN的Hierarchy L3，所以控制平面的路由比較好控制了，不用搞RR這種東西了，不過IPAM的問題就比較關鍵了。IP地址有32位，哪些用來規劃leaf-spine？哪些用來規劃host？哪些用來規劃VM？哪些用來規劃POD？若是要多租戶，哪些用來規劃Tenant/Segment？能夠說，這些若是有規劃好的可能，並且均可以動態調整，那麼Romana會是個「很SDN」的方案。
不過，這可不是說笑的，想要規劃好談何容易啊？問題歸根結底我認爲有以下幾點：
能夠看一看Romana的slides裏面給的IPAM實例，255 hosts、255 tenants、255 endpoints，對於對於IDC、雲服務提供商、容器用戶，是否是都顯得侷促了一些呢？
所以從網絡設計的角度來講，我的目前尚未想到Romana可以支持大規模容器網絡的理由，至於項目具體會發展成什麼樣子，仍需觀察。
下面來看一看它的架構。倒也畫的比較簡單，managers是控制端，agent在設備端。控制端幾個組件的功能，看了名字也就知道了，這裏再也不解釋。設備端接受調度，給容器配IP，在host上配路由，也沒什麼好說的了。
5.Contiv
Cisco在2015年搞的開源項目，準備把ACI那一套EPG的東西用到容器網絡中來，號稱要作容器的micro-segment。具體的沒什麼能講的，由於Github上確實也尚未什麼東西，並且Cisco作開源向來是奔着讓人捉摸不透去的。Cisco的人說會集成到docker libnetwork中去，但項目的模樣能不能出來，還得看將來的進展。項目連接在這：https://github.com/contiv/netplugin。
眼看着容器一步一步火起來，幾乎搶走了虛擬機的全部風頭，OpenStack也按耐不住要作集成了。有Magnum作Swarm、K8S這些COE（Container Orchestration Engine）的前端，OpenStack就有了編排大規模容器集羣的入口，而除了編排之外，網絡側的集成也是一個大頭。其實從network driver的角度來看，容器和虛擬機倒也沒什麼特別大的差異，那麼再搞一套Neutron for Container顯然是沒有必要（也不現實）的了。因而，Kuryr項目應運而生，旨在將現有Neutron的network driver銜接到容器網絡中。
Kuryr是捷克語「信使」的意思，顧名思義，就是要把容器網絡的API轉化成Neutron API傳遞給Neutron，而後仍然由Neutron來調度後端的network driver來爲容器組網。要作成這件事情，主要得解決三個問題：
第一個問題，通俗點說就是要作好翻譯工做。以docker libnetwork舉例，用戶調了libnetwork的API要新建一個（CNM模型中的）Network對象，那Kuryr就得翻譯成Neutron能聽得懂的API——幫我起一個（Neutron）Subnet。這要求Kuryr做爲remote driver，因而Neutron和Neutron driver對於libnetwork就是徹底透明的了。
上面舉了一個好理解的例子，很差辦的是當兩側的模型不一致，尤爲是左邊有新概念的時候。好比，如今要爲部署在VM中的Nested Container搞一個Security Group，可是Neutron目前只能管到host上，是看不見這個藏起來的傢伙的，那這時就要對Neutron作擴展了，思路就是爲Neutron Port新擴展一個屬性來標記VM中這個Nested Container，這樣作識別的時候帶上這個標記就好了。
從實現上來說，Kuryr要負責管理兩側的資源實例的ID的映射關係，以保證操做的一致性，不然會直接帶來用戶間的網絡入侵。另外，IPAM如今在兩側都被獨立出來了，IPAM的API也要能銜接的上。
至於第二個問題，拍腦殼想彷佛是不該該存在的。可是，目前絕大多數Neutron network driver在綁定端口時的動做只有更新數據庫，並不會爲容器作plug。這個作法的緣由在於，以前在處理虛擬機的時候，plug被看做是虛擬機啓動時自帶的動做，所以plug就放在了Nova的poweron函數裏面。改network driver天然是很差的，因而Kuryr就得負責起處理這個歷史遺留問題的任務了。
第三個問題可就是學問了。講道理的話，業務的API沒問題了，容器也都接入網絡了，而轉發的邏輯都是network driver寫好的，跟接的是容器仍是虛擬機也沒有一毛錢關係，那不就應該萬事大吉了嗎？但是現實確頗有可能不是這樣的，好比：因爲容器做爲工做負載，其特徵與虛擬機徹底不一樣，所以業務對兩者需求也是截然不同。容器都是批量批量的起，並且它們的生命週期可能很短——須要來回來去的起，而Neutron的API都是走軟件的消息總線的，而過於密集的API操做頗有可能會形成消息總線崩潰掉。一個新建容器的API等了1分鐘失敗了，那麼可能業務的需求就過去了（好比搶票），這個損失天然是不可接受的。
相似的問題可能都在潛伏着，若是Kuryr要走上生產環境，可就須要Gal Sagie多動腦筋了。
雖然Kuryr是OpenStack中比較新的項目，但目前Kuryr進展的還不錯，對libnetwork和k8S的集成都有demo出來了。一旦Kuryr成熟後，這意味着Neutron下面的各路vendor們均可以不費吹灰之力直接上容器了，這對於Weave、Calico這些靠容器起家的vendor不可算是個好消息。
看來，雲網絡vendor間的競爭最後也都將演變爲OpenStack、K8S、Mesos這些大部頭對於DCOS的爭奪了，畢竟胳膊擰不過大腿啊。
參考資料：
docker的四種網絡模式 - Frankiee - 博客園SDNLAB技術分享（十五）：容器網絡大觀 | SDNLAB | 專一網絡創新技術Search Results for 張晨 | SDNLAB | 專一網絡創新技術 - Page 3新聞 | SDNLAB | 專一網絡創新技術雲數據中心網絡虛擬化——大二層技術巡禮之大二層技術小結 | SDNLAB | 專一網絡創新技術wp-content/uploads/2016/06/Docker-figure-12.png (475×365)Calico + Flannel = Tigera, a New Container Networking StartupPipework、Weave、Flannel各自的優點和區別 - DockOne.ioflannel以及calico，時速雲選其一仍是兩個方案都在用？有測試報告嗎？_百度知道容器周邊開源工具新秀：Sysdig和Calico-CSDN.NETBattlefield: Calico, Flannel, Weave and Docker Overlay Network | Arthur Chunqi Li's BlogCalico在Docker中的搭建 - tingfengainiaini - 博客園Calico在Kubernetes中的搭建 - tingfengainiaini - 博客園calico for kubernetes - tingfengainiaini - 博客園時速雲Pod 之間通訊是否是也是用的flannel？_百度知道Calico首頁、文檔和下載 - 虛擬機和容器網絡 - 開源中國社區BGP協議的做用是_百度知道