摘要：模式容器直接使用宿主機(jī)的網(wǎng)絡(luò)配置，包括網(wǎng)卡，路由等，這種方案下，從網(wǎng)絡(luò)層面來(lái)看，容器就不是容器了，只是一個(gè)宿主機(jī)上的進(jìn)程端口而已。

注：本篇僅僅是對(duì)各個(gè)網(wǎng)絡(luò)方案的簡(jiǎn)介和思考。需要深入學(xué)習(xí)如何部署和使用的同學(xué)請(qǐng)自行度娘~

docker的使用者十分廣泛，不止有網(wǎng)易蜂巢，daocloud，時(shí)速云這類的已經(jīng)成熟化的公有云服務(wù)，許多中小型企業(yè)內(nèi)部也在試圖將docker容器應(yīng)用到內(nèi)部的運(yùn)維工作中。

在成熟的容器服務(wù)架構(gòu)中，往往會(huì)依賴IaaS層去實(shí)現(xiàn)更好的隔離效果，一個(gè)很明顯的例子就是網(wǎng)絡(luò)的連通性和隔離性。許多企業(yè)使用neutron作為這方面的支持并且能獲得不錯(cuò)的效果。

而中小型企業(yè)內(nèi)部，甚至一些個(gè)人用戶的docker環(huán)境就很少考慮租戶隔離了，連通性和性能是這類用戶的至高需求。
比如下面這段對(duì)話：
“我們部門這套業(yè)務(wù)是基于dubbo的架構(gòu)來(lái)開發(fā)的，現(xiàn)在其中的服務(wù)A要放你們?nèi)萜鳝h(huán)境里面跑。”
“可以啊，來(lái)來(lái)來(lái)，我?guī)湍愦蜱R像，我?guī)湍闩埽獛讉€(gè)實(shí)例？OK沒問題。”
“你們?nèi)萜骷豪锏姆?wù)，我們的dubbo注冊(cè)中心都訪問不到啊！搞什么鬼？”
“不好意思不好意思，我們的容器IP是虛擬的IP，你沒法主動(dòng)訪問我們的。不過(guò)我們用了k8s，可以把整個(gè)服務(wù)以一個(gè)IP：port的形式提供給注冊(cè)中心，你看我們還幫你們做了負(fù)載均衡。”
“我們不需要你們幫我們做負(fù)載均衡，我們就想把容器當(dāng)虛擬機(jī)一樣用嘛~”
“這...”

實(shí)際上，對(duì)于每一個(gè)初步接觸docker的人來(lái)說(shuō)，網(wǎng)絡(luò)是絕對(duì)的痛點(diǎn)，要搭建一套能讓容器跨機(jī)器的集群，是玩轉(zhuǎn)容器，建設(shè)CaaS的第一步。這里簡(jiǎn)單介紹一下幾種使用較為普遍的容器網(wǎng)絡(luò)方案，并詳細(xì)講述筆者在“遠(yuǎn)古時(shí)期”的網(wǎng)絡(luò)方案解決思路。

容器直接使用宿主機(jī)的網(wǎng)絡(luò)配置，包括網(wǎng)卡，路由等，這種方案下，從網(wǎng)絡(luò)層面來(lái)看，容器就不是容器了，只是一個(gè)宿主機(jī)上的進(jìn)程（端口）而已。
使用這種模式的性能損耗最少（直接用宿主機(jī)的網(wǎng)卡，能有什么損耗）。但是除非在容器中我們做好端口的自動(dòng)化配置，否則端口被占用了，容器就啟動(dòng)不了。

flannel已經(jīng)日趨成熟，從原本的udp，vxlan支持，到后來(lái)的aws，host-gw，gce網(wǎng)絡(luò)。這里主要說(shuō)udp，vxlan，host-gw。
udp和vxlan在flannel中其實(shí)只是封裝協(xié)議的不同而已。筆者了解不多，不敢多做解釋，不過(guò)這兩種方式的性能其實(shí)是差不多的（很多人會(huì)覺得vxlan性能更好）。flannel實(shí)現(xiàn)的是一個(gè)三層網(wǎng)絡(luò)。但是udp,vxlan協(xié)議是通過(guò)隧道方式進(jìn)行跨機(jī)互聯(lián)，簡(jiǎn)單地說(shuō)就是：
容器a的數(shù)據(jù)包pkg->宿主機(jī)A的docker0->路由到宿主機(jī)A的flannel0網(wǎng)卡->被封裝->宿主機(jī)A的物理網(wǎng)卡->宿主機(jī)B的物理網(wǎng)卡->路由到宿主機(jī)B的flannel0網(wǎng)卡->被解封->通過(guò)暴露出來(lái)的目的容器IP找到docker0->docker0轉(zhuǎn)給容器的虛擬網(wǎng)卡

封裝解封的過(guò)程導(dǎo)致flannel會(huì)有20-30%的損耗。

host-gw是一個(gè)比較新鮮的方式，在slaver節(jié)點(diǎn)屬于同一個(gè)二層網(wǎng)絡(luò)，且可以自由配置slaver節(jié)點(diǎn)網(wǎng)絡(luò)的前提下，我們使用host-gw，會(huì)使得slaver節(jié)點(diǎn)上創(chuàng)建出一系列路由規(guī)則，通過(guò)這套路由規(guī)則，將容器發(fā)出的數(shù)據(jù)包轉(zhuǎn)發(fā)給相應(yīng)的機(jī)器。這種模式性能會(huì)更好。
flannel的主要缺點(diǎn)在于，既沒有租戶隔離（即：一套環(huán)境里，每一個(gè)容器都可以訪問到其他任何容器），也沒有對(duì)外開放（集群外沒有搭建flannel的機(jī)器ping不通容器）。

calico是一種容器級(jí)路由和防火墻工具，它能夠在容器級(jí)別上為每個(gè)容器實(shí)例或k8s的Pod實(shí)例指定訪問規(guī)則，達(dá)到服務(wù)間可控的訪問。
Calico的原理是通過(guò)修改每個(gè)主機(jī)節(jié)點(diǎn)上的iptables和路由表規(guī)則，實(shí)現(xiàn)容器間數(shù)據(jù)路由和訪問控制，并通過(guò)Etcd協(xié)調(diào)節(jié)點(diǎn)配置信息的。因此Calico服務(wù)本身和許多分布式服務(wù)一樣，需要運(yùn)行在集群的每一個(gè)節(jié)點(diǎn)上。
calico已經(jīng)并入了k8s的CNI插件。在每一個(gè)slaver節(jié)點(diǎn)上啟動(dòng)一個(gè)calico容器，去劫持docker的創(chuàng)建命令，接管容器網(wǎng)絡(luò)的配置。
calico吸引人的地方在于：他有一套自己的管理體系，給不同的子網(wǎng)絡(luò)增加了標(biāo)簽，可以通過(guò)這種方式實(shí)現(xiàn)容器網(wǎng)絡(luò)的隔離；同時(shí)業(yè)內(nèi)認(rèn)為他的性能也是很好的，基本接近裸機(jī)的網(wǎng)絡(luò)性能，然而筆者在自己的環(huán)境中測(cè)試了幾次，效果并不盡如人意，。

接下來(lái)說(shuō)下橋接+IPAM模式。這個(gè)方案針對(duì)的是一種比較特殊的使用場(chǎng)景：

docker有許多用法，微服務(wù)是其中一種，通過(guò)docker技術(shù)圈內(nèi)愛好者的交流，我們了解到確實(shí)有一些企業(yè)試圖，或者已經(jīng)將容器當(dāng)做虛擬機(jī)在用。上文中的對(duì)話就是這個(gè)使用場(chǎng)景之一，這種場(chǎng)景下的網(wǎng)絡(luò)問題總結(jié)為：同一個(gè)網(wǎng)絡(luò)環(huán)境中的機(jī)器里，非docker機(jī)器主動(dòng)連接docker機(jī)器上的容器是連不通的。

解決方法：
1.給這個(gè)網(wǎng)絡(luò)環(huán)境中非docker的機(jī)器也部署虛擬網(wǎng)絡(luò)，將flannel，calico這類組件在全網(wǎng)絡(luò)范圍內(nèi)做分布式的部署。（考慮到機(jī)器數(shù)量，可能存在的VM，VM會(huì)有起停操作，這個(gè)方案基本不可行）
2.給容器一個(gè)和宿主機(jī)器同一層網(wǎng)絡(luò)的IP，即二層網(wǎng)絡(luò)IP，路由到宿主機(jī)的物理網(wǎng)卡，進(jìn)行轉(zhuǎn)發(fā)。

我們知道docker1.9以后增加了network特性，docker daemon可以自己創(chuàng)建一個(gè)network，通過(guò)選擇network給容器配置網(wǎng)絡(luò)。
在二層網(wǎng)絡(luò)的基礎(chǔ)上，我們?cè)谒拗鳈C(jī)建立一個(gè)網(wǎng)橋，橋接了物理網(wǎng)卡和docker network（當(dāng)然了type必須是bridge）。設(shè)置好路由規(guī)則和gateway，docker容器創(chuàng)建時(shí)橋接到相應(yīng)的network上，就可以正常地訪問二層網(wǎng)絡(luò)內(nèi)的任何機(jī)器/容器。
同樣的，因?yàn)檫@種方式下容器創(chuàng)建后IP是一個(gè)二層網(wǎng)絡(luò)內(nèi)的IP，所以外部機(jī)器可以很方便地訪問容器。這是一種全暴露的網(wǎng)絡(luò)模式。做到了完全的連通，但沒辦法做到網(wǎng)絡(luò)的隔離。

那IPAM又是什么鬼？

假設(shè)這種情況：橋接模式下，容器和宿主機(jī)是同一個(gè)網(wǎng)段，比如172.16.1.0/24,假設(shè)該網(wǎng)段中的.1~.10都是宿主機(jī)，我們?cè)?1的宿主機(jī)上創(chuàng)建的容器，其IP必定是172.16.1.2,172.16.1.3，...會(huì)發(fā)現(xiàn)容器的IP和宿主機(jī)重復(fù)了。這就麻煩了，要么我們就連不上容器，要么我們就連不上IP為172.16.1.2的宿主機(jī)。（簡(jiǎn)單地說(shuō)下原因：每個(gè)宿主機(jī)彼此并不知悉對(duì)方的IP和MAC信息，我們創(chuàng)建的那個(gè)網(wǎng)橋也沒有這方面的記錄，容器啟動(dòng)時(shí)，網(wǎng)橋上已經(jīng)記錄了本機(jī)的IP：172.16.1.1，但沒有記錄172.16.1.2，所以就會(huì)給容器分配172.16.1.2這個(gè)IP）

那就開發(fā)一個(gè)服務(wù)用于管理IP吧,docker原生支持network plugin，其中一個(gè)插件就是IPAM,即ip分配管理服務(wù)。docker network創(chuàng)建/銷毀容器時(shí)會(huì)使用IPAM去申請(qǐng)/釋放一個(gè)合法的IP。如果沒有指定IPAM插件，docker daemon會(huì)自動(dòng)配置的網(wǎng)段中選一個(gè)IP，其邏輯是按數(shù)字從小到大進(jìn)行分配。

我們開發(fā)一個(gè)IPAM，通過(guò)IPAM來(lái)進(jìn)行IP的申請(qǐng)和釋放，并在整個(gè)集群中建立一個(gè)IP的管理中心，維護(hù)整個(gè)容器集群的IP資源。保證一個(gè)IP只能同時(shí)被最多一個(gè)容器使用。

這種方案的性能看起來(lái)應(yīng)該是和flannel host-gw，calico差不多的，因?yàn)槠浔举|(zhì)還是路由轉(zhuǎn)發(fā)，不同之處是給容器分配了二層網(wǎng)絡(luò)IP，所有容器都暴露了，因此這種模式下網(wǎng)絡(luò)就難以做租戶隔離（容器更像一個(gè)瘦VM了~），而這種情況下，dubbo的服務(wù)可以直接在容器上部署，k8s的service特性，kube-proxy組件基本可以酌情棄用。

綜上所述：

host 損耗小 靈活度低，IP資源不足 沒有隔離

flannel udp/vxlan 損耗較大 靈活，IP資源充足 有內(nèi)外網(wǎng)隔離，沒有租戶隔離

flannel host-gw 損耗較小 靈活，ip資源充足 有內(nèi)外網(wǎng)隔離，沒有租戶隔離

calico 損耗較小 靈活，ip資源充足 有內(nèi)外網(wǎng)隔離，有租戶隔離

橋接+ipam 損耗很小 開發(fā)成本大，二層網(wǎng)絡(luò)IP資源有限 無(wú)任何隔離

展望：calico可能會(huì)是最適合容器云的網(wǎng)絡(luò)方案，因?yàn)樽鈶舻木W(wǎng)絡(luò)隔離是生產(chǎn)化過(guò)程中絕對(duì)不可缺少的。如果僅在內(nèi)部小規(guī)模使用，追求簡(jiǎn)單配置，可以使用flannel，如果將容器vm化，可以考慮使用橋接+ipam。