隨著容器的火熱發(fā)展，數(shù)人云 越來越多的客戶對容器網(wǎng)絡(luò)特性要求也開始越來越高，比如：
一容器一IP
多主機(jī)容器互聯(lián)
網(wǎng)絡(luò)隔離
ACL
對接 SDN 等等
這次主要跟大家聊聊 Docker 的網(wǎng)絡(luò)方案，首先是現(xiàn)有容器網(wǎng)絡(luò)方案介紹， 接下來重點講解 Calico 的特性及技術(shù)點，作為引申和對比再介紹下 Contiv 的特性, 最后給出對比測試結(jié)果。
現(xiàn)有的主要 Docker 網(wǎng)絡(luò)方案
首先簡單介紹下現(xiàn)有的容器網(wǎng)絡(luò)方案，網(wǎng)上也看了好多對比，大家之前都是基于實現(xiàn)方式來分，
隧道方案
通過隧道, 或者說 overlay network 的方式：
Weave，UDP 廣播，本機(jī)建立新的 BR，通過 PCAP 互通。
Open vSwitch(OVS)，基于 VxLAN 和 GRE 協(xié)議，但是性能方面損失比較嚴(yán)重。
Flannel，UDP 廣播，VxLan。
隧道方案在 IaaS 層的網(wǎng)絡(luò)中應(yīng)用也比較多，大家共識是隨著節(jié)點規(guī)模的增長復(fù)雜度會提升， 而且出了網(wǎng)絡(luò)問題跟蹤起來比較麻煩，大規(guī)模集群情況下這是需要考慮的一個點。
路由方案
還有另外一類方式是通過路由來實現(xiàn)，比較典型的代表有：
Calico，基于 BGP 協(xié)議的路由方案，支持很細(xì)致的 ACL 控制，對混合云親和度比較高。
Macvlan，從邏輯和 Kernel層來看隔離性和性能最優(yōu)的方案，基于二層隔離，所以需要二層路由器支持，大多數(shù)云服務(wù)商不支持，所以混合云上比較難以實現(xiàn)。
路由方案一般是從 3 層或者 2 層實現(xiàn)隔離和跨主機(jī)容器互通的，出了問題也很容易排查。
我覺得 Docker 1.9 以后再討論容器網(wǎng)絡(luò)方案，不僅要看實現(xiàn)方式，而且還要看網(wǎng)絡(luò)模型的“站隊”，比如說你到底是要用 Docker 原生的 “CNM”，還是CoreOS，谷歌主推的 “CNI”。
Docker libnetwork Container Network Model (CNM) 陣營
Docker Swarm overlay
Macvlan & IP network drivers
Calico
Contiv (from Cisco)
Docker libnetwork 的優(yōu)勢就是原生，而且和 Docker 容器生命周期結(jié)合緊密；缺點也可以理解為是原生，被 Docker “綁架”。
Container Network Interface (CNI) 陣營
Kubernetes
Weave
Macvlan
Flannel
Calico
Contiv
Mesos CNI
CNI 的優(yōu)勢是兼容其他容器技術(shù)(e.g. rkt)及上層編排系統(tǒng)(K8s & Mesos)，而且社區(qū)活躍勢頭迅猛，Kubernetes 加上 CoreOS 主推；缺點是非 Docker 原生。
而且從上的也可以看出，有一些第三方的網(wǎng)絡(luò)方案是“腳踏兩只船”的， 我個人認(rèn)為目前這個狀態(tài)下也是合情理的事兒，但是長期來看是存在風(fēng)險的, 或者被淘汰，或者被收購。
Calico
接下來重點介紹 Calico，原因是它在 CNM 和 CNI 兩大陣營都扮演著比較重要的角色。即有著不俗的性能表現(xiàn)，提供了很好的隔離性，而且還有不錯的 ACL 控制能力。
Calico 是一個純3層的數(shù)據(jù)中心網(wǎng)絡(luò)方案，而且無縫集成像 OpenStack 這種 IaaS 云架構(gòu)，能夠提供可控的 VM、容器、裸機(jī)之間的 IP 通信。
通過將整個互聯(lián)網(wǎng)的可擴(kuò)展 IP 網(wǎng)絡(luò)原則壓縮到數(shù)據(jù)中心級別，Calico 在每一個計算節(jié)點利用 Linux kernel 實現(xiàn)了一個高效的 vRouter 來負(fù)責(zé)數(shù)據(jù)轉(zhuǎn)發(fā)，而每個 vRouter 通過 BGP 協(xié)議負(fù)責(zé)把自己上運(yùn)行的 workload 的路由信息像整個 Calico 網(wǎng)絡(luò)內(nèi)傳播 － 小規(guī)模部署可以直接互聯(lián)，大規(guī)模下可通過指定的 BGP route reflector 來完成。
這樣保證最終所有的 workload 之間的數(shù)據(jù)流量都是通過 IP 路由的方式完成互聯(lián)的。
Calico 節(jié)點組網(wǎng)可以直接利用數(shù)據(jù)中心的網(wǎng)絡(luò)結(jié)構(gòu)（無論是 L2 或者 L3），不需要額外的 NAT，隧道或者 overlay network。
如上圖所示，這樣保證這個方案的簡單可控，而且沒有封包解包，節(jié)約 CPU 計算資源的同時，提高了整個網(wǎng)絡(luò)的性能。
此外，Calico 基于 iptables 還提供了豐富而靈活的網(wǎng)絡(luò) policy, 保證通過各個節(jié)點上的 ACLs 來提供 workload 的多租戶隔離、安全組以及其他可達(dá)性限制等功能。
Calico 架構(gòu)
結(jié)合上面這張圖，我們來過一遍 Calico 的核心組件：
Felix，Calico agent，跑在每臺需要運(yùn)行 workload 的節(jié)點上，主要負(fù)責(zé)配置路由及 ACLs 等信息來確保
endpoint 的連通狀態(tài)；etcd，分布式鍵值存儲，主要負(fù)責(zé)網(wǎng)絡(luò)元數(shù)據(jù)一致性，確保 Calico 網(wǎng)絡(luò)狀態(tài)的準(zhǔn)確性；
BGP Client(BIRD), 主要負(fù)責(zé)把 Felix 寫入 kernel 的路由信息分發(fā)到當(dāng)前 Calico 網(wǎng)絡(luò)，確保
workload 間的通信的有效性；BGP Route Reflector(BIRD), 大規(guī)模部署時使用，摒棄所有節(jié)點互聯(lián)的 mesh 模式，通過一個或者多個 BGP
Route Reflector 來完成集中式的路由分發(fā)；
Calico Docker network 核心概念
從這里開始我們將“站隊” CNM, 通過 Calico Docker libnetwork plugin 的方式來體驗和討論 Calico 容器網(wǎng)絡(luò)方案。
先來看一下 CNM 模型：
從上圖可以知道，CNM 基于3個主要概念：
Sandbox，包含容器網(wǎng)絡(luò)棧的配置，包括 interface，路由表及 DNS配置，對應(yīng)的實現(xiàn)如：Linux Network
Namespace；一個 Sandbox 可以包含多個 Network；Endpoint，做為 Sandbox 接入 Network 的介質(zhì)，對應(yīng)的實現(xiàn)如：veth pair，TAP；一個 Endpoint
只能屬于一個 Network，也只能屬于一個 Sandbox；Network，一組可以相互通信的 Endpoints；對應(yīng)的實現(xiàn)如：Linux bridge，VLAN；Network 有大量
Endpoint 資源組成；
除此之外，CNM 還需要依賴另外兩個關(guān)鍵的對象來完成 Docker 的網(wǎng)絡(luò)管理功能，他們分別是：
NetworkController, 對外提供分配及管理網(wǎng)絡(luò)的 APIs，Docker libnetwork 支持多個活動的網(wǎng)絡(luò)
driver，NetworkController 允許綁定特定的 driver 到指定的網(wǎng)絡(luò)；Driver，網(wǎng)絡(luò)驅(qū)動對用戶而言是不直接交互的，它通過插件式的接入來提供最終網(wǎng)絡(luò)功能的實現(xiàn)；Driver(包括 IPAM) 負(fù)責(zé)一個
network 的管理，包括資源分配和回收；
有了這些關(guān)鍵的概念和對象，配合 Docker 的生命周期，通過 APIs 就能完成管理容器網(wǎng)絡(luò)的功能，具體的步驟和實現(xiàn)細(xì)節(jié)這里不展開討論了， 有興趣的可以移步 Github： https://github.com/docker/libn ... gn.md
接下來再介紹兩個 Calico 的概念：
Pool, 定義可用于 Docker Network 的 IP 資源范圍，比如：10.0.0.0/8 或者 192.168.0.0/16；
Profile，定義 Docker network Policy 的集合，由 tags 和 rules 組成；每個 Profile
默認(rèn)擁有一個和 Profile 名字相同的 Tag，每個 Profile 可以有多個 Tag，以 List 形式保存;
Profile 樣例：
Inbound rules:1 allow from tag WEB
2 allow tcp to ports 80,443Outbound rules:1 allow
Demo
基于上面的架構(gòu)及核心概念，我們通過一個簡單的例子，直觀的感受下 Calico 的網(wǎng)絡(luò)管理。
Calico 以測試為目的集群搭建，步驟很簡單，這里不展示了， 大家可以直接參考 Github： https://github.com/projectcali ... ME.md
這里默認(rèn)已經(jīng)有了 Calico 網(wǎng)絡(luò)的集群，IP 分別是：192.168.99.102 和 192.168.99.103
calicoctl status 截圖：
同時，已經(jīng)有兩個 IP Pool 創(chuàng)建好，分別是：10.0.0.0/26 和 192.168.0.0/16
calicoctl pool show 截圖：
當(dāng)前集群也已經(jīng)通過使用 calico driver 和 IPAM 創(chuàng)建了不同的 docker network，本次 demo 只需要使用 dataman
docker network ls 截圖：
calicoctl profile show 截圖：
下面我們使用 dataman 這個網(wǎng)絡(luò)，在兩臺 slave 機(jī)器上各啟動一個容器：
數(shù)人云 下發(fā)容器的 Marathon json file:
{
"id": "/nginx-calico",
"cmd": null,
"cpus": 0.1,
"mem": 64,
"disk": 0,
"instances": 2,
"container": {
"type": "DOCKER",
"volumes": [],
"docker": {
"image": "nginx",
"network": "HOST",
"privileged": false,
"parameters": [
{
"key": "net",
"value": "dataman"
}
],
"forcePullImage": false}},
"portDefinitions": [
{
"port": 10000,
"protocol": "tcp",
"labels": {}
}]
}
兩臺 slave 容器 IP 截圖：
從上圖可以看出，兩個 slave 上的容器 IP 分別是：slave 10.0.0.48, slave2 192.168.115.193
Slave 容器連通性測試截圖：
IP 路由實現(xiàn)
根據(jù)上面這個 Calico 數(shù)據(jù)平面概念圖，結(jié)合我們的例子，我們來看看 Calico 是如何實現(xiàn)跨主機(jī)互通的：
兩臺 slave route 截圖：
對照兩臺 slave 的路由表，我們就知道，如果 slave 1 上的容器(10.0.0.48)想要發(fā)送數(shù)據(jù)到 slave 2 上的容器(192.168.115.193)， 那它就會 match 到最后一條路由規(guī)則，將數(shù)據(jù)包轉(zhuǎn)發(fā)給 slave 2(192.168.99.103)，那整個數(shù)據(jù)流就是：
container -> kernel -> (cali2f0e)slave 1 -> one or more hops -> (192.168.99.103)slave 2 -> kernel -> (cali7d73)container
這樣，跨主機(jī)的容期間通信就建立起來了，而且整個數(shù)據(jù)流中沒有 NAT、隧道，不涉及封包。
安全策略 ACL
Calico 的 ACLs Profile 主要依靠 iptables 和 ipset 來完成，提供的是可針對每個容器級別的規(guī)則定義。
具體的實現(xiàn)我們可以通過 iptables 命令查看對應(yīng)的 chain 和 filter 規(guī)則, 這里我們就不展開討論了。
Contiv
Contiv 是 Cisco 開源出來的針對容器的基礎(chǔ)架構(gòu)，主要功能是提供基于 Policy 的網(wǎng)絡(luò)和存儲管理，是面向微服務(wù)的一種新基架。
Contiv 能夠和主流的容器編排系統(tǒng)整合，包括：Docker Swarm, Kubernetes, Mesos and Nomad。
如上圖所示，Contiv 比較“誘人”的一點就是，它的網(wǎng)絡(luò)管理能力，既有L2(vlan)、L3(BGP), 又有 Overlay(VxLAN), 而且還能對接 Cisco 自家的 SDN 產(chǎn)品 ACI?？梢哉f有了它就可以無視底層的網(wǎng)絡(luò)基礎(chǔ)架構(gòu)，向上層容器提供一致的虛擬網(wǎng)絡(luò)了。
Contiv netplugin 特性
多租戶網(wǎng)絡(luò)混部在同一臺主機(jī)上
集成現(xiàn)有 SDN 方案
能夠和非容器環(huán)境兼容協(xié)作，不依賴物理網(wǎng)絡(luò)具體細(xì)節(jié)
即時生效的容器網(wǎng)絡(luò) policy/ACL/QoS 規(guī)則
網(wǎng)絡(luò)方案性能對比測試
最后附上我們使用 qperf 做的簡單性能測試結(jié)果，我們選取了 vm-to-vm, host, calico-bgp, calico-ipip 以及 swarm overlay 進(jìn)行了對比。
其實 Contiv 也測試了，但是因為 Contiv 的測試環(huán)境和其他方案使用的不同，不具有直接可比性，所以沒有放入對比圖里。 直觀感受就是基于 OVS 的方案確實不理想，后面有時間會統(tǒng)一環(huán)境繼續(xù)進(jìn)行測試對比，包括 Contiv 的 L3/L2方案以及引入 MacVLAN、flannel 等。
測試環(huán)境：VirtualBox VMs，OS：Centos 7.2，kernel 3.10，2 vCPU，2G Mem。
帶寬對比結(jié)果如下：
時延對比結(jié)果如下：
qperf 命令：
# server 端$ qperf
client 端
持續(xù) 10s 發(fā)送 64k 數(shù)據(jù)包，tcp_bw 表示帶寬，tcp_lat 表示延遲
$ qperf -m 64K -t 10 192.168.2.10 tcp_bw tcp_lat
從 1 開始指數(shù)遞增數(shù)據(jù)包大小
$ qperf -oo msg_size:1:64k:*2 192.168.2.10 tcp_bw tcp_lat
總結(jié)
隨著容器的落地，網(wǎng)絡(luò)方案必將成為“兵家”必爭之地，我們 數(shù)人云 是輕量級 PaaS 容器集群管理云平臺，在網(wǎng)絡(luò)方案選擇上的考慮是：
性能，Calico 和 MacVLAN 都有著不錯的表現(xiàn)；Contiv L3(BGP) 理論上性能也不會差；
普適性，Calico 對底層的基本要求就是 IP 層可達(dá)；MacVLAN 不適應(yīng)于公有云；Contiv 對底層的兼容性可能更好；
可編程性，保證整個網(wǎng)絡(luò)管理過程能夠程序化、API 化，這樣方便集成到產(chǎn)品里，不需要手動運(yùn)維；Calico 和 Contiv 都有相應(yīng)的模塊；
未來發(fā)展，這個就是我說的“站隊”，Docker 的 CNM 和 CoreOS、K8S 的 CNI，現(xiàn)在還看不清，Calico 和Contiv 都是支持的;
綜上，個人推薦關(guān)注和嘗試下 Calico 或者 Contiv 做為容器的網(wǎng)絡(luò)方案，有問題或者收獲，歡迎隨時交流分享。
QA
Q1：從你發(fā)的 Marathon json 文件來看，你們是對 mesos 底層的網(wǎng)絡(luò)做了擴(kuò)展嗎？容器網(wǎng)絡(luò)通過"parameters"傳遞下去的嗎？
A: 就是利用 Marathon 支持的 Docker parameters 下發(fā)，等同于 docker run —net dataman xxx
Q2：felix 根據(jù)配置的 pool 地址段配置路由，bgp client 通告路由？請問 bgp 的鄰居關(guān)系是怎么建立的？是依靠 etcd 里的信息？
A1: 是的，felix 配置本地 kernel 路由，bgp client 負(fù)責(zé)分發(fā)路由信息
A2: bgp 小規(guī)模部署采取 mesh 方式建立，所有節(jié)點互聯(lián) n^2 的聯(lián)系，大規(guī)模部署推薦 部署一個或多個 BGP route reflector，專門負(fù)責(zé)路由信息分發(fā)。
Q3：Weave有UDP和Fast Data Path兩種方式，F(xiàn)ast Data Path應(yīng)該用的也是vxlan，關(guān)于這一塊不知道有沒有和其余采用vxlan的方案做過性能對比測試？
A: 不好意思，Weave 的我們都沒有測試，但看到有人測過，好像 Fast Data Path 也是沒有 Calico 和 Macvlan 好的。
Q4: 請問在dataman這個網(wǎng)絡(luò)中路由信息是如何更新的？我們知道BGP是可以自己發(fā)現(xiàn)收斂網(wǎng)絡(luò)的，那么在網(wǎng)絡(luò)控制層面是如何設(shè)計的？
A1：隨著使用 dataman 這個網(wǎng)絡(luò)的容器的添加或者刪除，felix 負(fù)責(zé)更新本地路由，BGP client 負(fù)責(zé)向外分發(fā)；
A2: calico 的 BGP 和廣域網(wǎng)的 BGP 還是有不同，它只是使用 private AS num，相對自治，網(wǎng)絡(luò)控制層面都是可以程序控制的。
Q5：請問calico如何解決多租戶里地址沖突的問題？
A: 多租戶容器混部在同一主機(jī)上時，所使用的 network 最好不要用同一個 Pool 里的就好，這樣就不可能有沖突了；
Q6：如果集群的容器很多，那么相應(yīng)的路由表的規(guī)則也會增多，這樣會不會對網(wǎng)絡(luò)性能造成影響？
A: 網(wǎng)絡(luò)性能不會有太大影響，因為容器多流量多網(wǎng)絡(luò)壓力本來就大，倒是會增加系統(tǒng)負(fù)載，畢竟要配置路由規(guī)則，同步網(wǎng)絡(luò)信息；這部分我們也很關(guān)心，但還沒有具體的測試結(jié)果；
Q7 : 還有就是路由信息是存放在etcd中嗎？如何保證路由表的讀取性能和維護(hù)路由表的信息更新？
A1：生效的路由肯定是本地的，endpoint 等信息是在 etcd 的；
A2: 這兩個問題都是 calico 自身要解決的問題，這部分我們也很關(guān)心，但還沒有具體的測試結(jié)果；
Q8：calico基于iptable做轉(zhuǎn)發(fā)，的確有性能上的優(yōu)勢。但缺點是隨著容器數(shù)量的增長（比如1w），轉(zhuǎn)發(fā)規(guī)則也按比例增長，對于龐大的路由表管理，會是個潛在問題嗎？
A：我看到有人，好像是宜信的，測試過 10W，對于單臺主機(jī)我覺得差不多算是上限了，但我們還沒有具體的測試結(jié)果；
Q9：目前你們實際生產(chǎn)上跑過多少容器基于calico？
A：目前處于實驗性階段，只在內(nèi)部測試系統(tǒng)小規(guī)模測試中。。。
Q10：Calico下跨多個路由 hop 的情況，中間路由不需要學(xué)習(xí)這么多的容器路由表嗎？
A：不需要，中間過程是依賴節(jié)點之間原有的網(wǎng)絡(luò)建設(shè)的，只要兩個節(jié)點互通，所有的 hop 都不需要知道 calico 內(nèi)部的容器路由信息；
Q11：還有一個問題，就是網(wǎng)絡(luò)管理問題。目前從設(shè)備廠商網(wǎng)站看有幾個支持vxlan控制器的。這些控制器能不能與容器ovs協(xié)同？ 目前來看我們這里買國外產(chǎn)品還是比較困難的
A：這個肯定是問題，我覺得作為平臺方，我們能做的很少，如果要改變，肯定是要 SDN 設(shè)備廠商發(fā)力，就像是各家都會去為 Openstack 適配設(shè)備提供 driver 一樣，但是也需要 Docker 或者說容器編排系統(tǒng)能做到如同 Openstack 那樣的行業(yè)標(biāo)準(zhǔn)級。
Q12：calico能和flannel整合么？coreos上kubelet里同時出現(xiàn)了calico和flannel
A：calico 在 Docker Con 2016 應(yīng)該是高調(diào)擁抱了 flannel，兩個整合出了一個叫 canal 的項目，有興趣可以去找找看。
Q13: 我想問一下老師，你這vxlan的標(biāo)簽是calico打的對吧？
A：Calico 沒有 vxlan，Calico 的 tag 會對應(yīng)到 ipset，iptables 用來 match filter 規(guī)則。
Q14：請問宿主記有多個網(wǎng)卡怎么搞？
A：宿主機(jī)多網(wǎng)卡 目前 mesos 和 calico 都不支持，但是 數(shù)人云 同時也在考慮接管方式，目前還沒有成熟的東西可以分享。
Q15：嘗試過把bird換掉嗎，用這個的貌似不是很多
A：bird 屬于 calico 的組件選擇，我們目前階段還是不會對開源組件進(jìn)行深度定制的。
Q16：rr和L3之間試過不用bgp嗎
A：還沒有，我們這邊還相對早期，沒有深度改裝和調(diào)優(yōu)；你們?nèi)绻邢嚓P(guān)想法歡迎一起交流下。
