利发娱乐官方

客服熱線:400-820-2885 800-820-2885

INDUSTRY INFORMATION行業資訊

干貨 | 夜來Docker聲 新型容器網絡方案知多少
作者: 來源: 2018-11-28

自從Docker容器出現以來,容器的網絡通信就一直是大家關注的焦點,也是生產環境的迫切需求。容器網絡從早期只是主機內部的網絡,現已迅速發展成跨主機的網絡,即新型容器網絡。本文將重點介紹幾種新型容器網絡及其典型代表。

Docker容器固有4種網絡模式:

早期的容器網絡,就是主機內部的網絡,想要把服務暴露出去需要通過iptables做端口映射。下面簡單介紹一下docker原生的幾種網絡模式以及如何通過這幾種模式實現容器之間的互聯。

1. Bridge模式
Bridge模式,顧名思義就是Linux的網橋模式,網橋類似于物理交換機的功能,docker在安裝完成后,便會在系統上默認創建一個Linux網橋, 名稱為docker0 并為其分配一個子網,默認為172.17.0.0/16,針對有docker創建的每一個容器,均為其創建一個虛擬的以太網設備(veth peer)。其中一端關聯到網橋上,另一端映射到容器類的網絡空間中。然后從這個虛擬網段中分配一個IP地址給這個接口。 其網絡模型如下: 

image001.png

跨主機訪問示意:

image002.png 

2.HOST模式
Host模式顧名思義就是共用主機的網絡,它的網絡命名空間和主機是同一個,使用宿主機Namespace、IP和端口。


3.Container模式
使用已經存在容器的網絡的Namespace,相當于多個容器使用同一個網絡協議棧,k8s中的pod中多個容器之間的網絡和存儲的貢獻就是使用這種模式。

4.None模式
在容器創建時,不指定任何網絡模式。由用戶自己在適當的時候去指定。下面我們就手動使用none模式來實現兩個容器之間的互通。

# 為了和之前的docker0網橋不沖突 先創建一個網段
> docker network create –driver=bridge –subnet=10.168.0.1/24 example
# 查看Linux的網絡信息會發現有一個名叫example的網橋
> brctl show

# 創建一個容器 使用none模式的網絡
> docker run –net=none –idt alpine:3.4 sh test1
# 查看此時的容器的pid
> pid = docker inspect –f  '{{.State.Pid}}'
# 在主機上來看 容器就是一個進程,進程id就是剛才通過docker inspect獲取到的
# 連接test1的命名空間 方面操作
> ln –s /proc/$pid/ns/net /var/run/netns/$pid
# 列出所有的網絡命名空間
> ip netns list

# 現在我們創建一個veth peer 可以把veth對理解成一個網線的兩頭,數據從一個數據流入,必然從另一個數據流出。如果我們把veth的一頭“插入”test1這個容器的命名空間中,另一臺接在網橋上是不是就可以實現容器想通呢,答案是肯定的。
# 創建veth peer
> ip link add vethhost-1 type veth peer name vethcontainer-1
> ip link set vethhost-1 up
> ip link set vethcontainer-1 up
# 將vethcontainer-1放入test1這個空間中
> ip link set vethcontainer-1netns $pid
# 給此接口分配一個ip地址
> ip netns exec $pid ip addr 10.168.0.2/24 dev  vethcontainer-1
# 將veth peer的另一端接入網橋
> brctl addif example  vethhost-1

# 按著上述方法再次創建一個容器,分配一個不同的地址便可以實現容器之間的訪問。


通過對docker固有的網絡模型介紹可以看出,docker本身的網絡功能還不是特別的完善,對于容器間跨主機通信,網絡隔離等功能均不能很好的實現。
無論是之前的虛擬技術,還是現在的容器化技術,網絡一直都是一個比較復雜難以解決的問題,docker官方也意識到這個問題的存在,所以在推出自己方案的同時,積極擁抱第三方解決方案。


新型容器網絡方案及典型代表

新型容器網絡指跨主機的網絡,分為兩大類——隧道方案和路由方案。 Overlay,OVS,Flannel和Weave網絡方案都是隧道方案的典型,路由方案典型代表包括Calico和Macvlan。


一個簡單的各種方案對比圖

表格.png

  
微目錄
 壹.隧道方案
     1. Weave網絡方案
     2. OVS網絡方案
     3. Flannel網絡方案
     4. Overlay網絡方案
 貳.路由方案
     1. Calico網絡方案
     2. Macvlan 網絡方案

一、隧道方案
隧道方案對底層的網絡沒有過高的要求,一般來說,只要是在一個三層可達網絡里,就能構建出一個基于隧道的容器網絡。問題也很明顯,隨著節點規模的增長復雜度會提升,而且出了網絡問題跟蹤起來比較麻煩,大規模集群情況下這是需要考慮的一個點。

典型代表:
1)Weave:UDP廣播,本機建立新的BR,通過PCAP互通。
2)Open vSwitch(OVS):基于VxLAN和GRE協議
3)Flannel:UDP廣播、VxLan。
4)Overlay: docker 官方開發,v1.9后推出 


1、Weave網絡方案
Weave容器網絡由Zett.io公司開發,它能夠創建一個虛擬網絡,用于連接部署在多臺主機上的Docker容器。外部設備能夠訪問Weave網絡上的應用程序容器所提供的服務,同時已有的內部系統也能夠暴露到應用程序容器上。

 image003.pngWeave容器網絡運行原理

Weave容器網絡具有以下特性:
1)Weave網絡中不同主機上的Docker可以彼此通信。除此之外,Dockers可以通過Weave DNS發現模塊實現的主機名發現彼此。
2)Weave可以穿越防火墻并在部分連接的網絡中操作。同時weave支持流量加密,允許主機通過不可信網絡彼此連接。
3)與其他解決方案不同,Weave不依賴分布式存儲(例如etcd和consul)來交換路由信息,而是自己構建路由網絡,并且當新對等體添加和退出時實現謠言協議以交換網絡拓撲。


2、OVS網絡方案
Open vSwitch是一個由Nicira Networks主導的開源項目,通過運行在虛擬化平臺上的虛擬交換機,為本臺物理機上的容器或者虛擬機提供二層網絡接入。Open vSwitch的目標,是做一個具有產品級質量的多層虛擬交換機。通過可編程擴展,可以實現大規模網絡的自動化(配置、管理、維護)。


image005.png


image006.png


OVS容器網絡具有以下特點:
1)通過open vswitch模擬一個交換機;
2)非常適合虛機環境;
3)可以直接和SDN集成;
4)不改變現有物理拓撲;
5)封包解包消耗內存;
6)使用了隧道技術,增加運維難度。
7)  ovs 在創建點對點的GRE通道需要手動創建

3、Flannel網絡方案
Flannel容器網絡,是由CoreOS主導的解決方案。Flannel為每一個主機的Docker daemon分配一個IP段,通過etcd維護一個跨主機的路由表,容器之間IP是可以互相連通的,當兩個跨主機的容器要通信的時候。會在主機上修改數據包的header,修改目的地址和源地址,經過路由表發送到目標主機后解包。封包的方式,可以支持udp、vxlan、host-gw等,但是如果一個容器要暴露服務,還是需要映射IP到主機側的。


image007.png

 
Flannel容器網絡具有以下特性:
1)對Mesos框架支持不好;
2)每臺主機一個CIDR,三層互通,CIDR不靈活會造成大量IP浪費;
3)主機間有多種封包方式,udp、vxlan、host-gw等;
4)容器間IP聯通但對外服務需要映射到主機IP和端口;
5)主機IP網段固定,無法實現容器IP在不同主機間遷移。

4、Overlay網絡方案
Overlay網絡,指在不改變現有網絡基礎設施的前提下,通過某種約定通信協議,把二層報文封裝在IP報文之上的新的數據格式。這樣不但能夠充分利用成熟的IP路由協議進程數據分發,而且在Overlay技術中采用擴展的隔離標識位數,能夠突破VLAN的4000數量限制,支持高達16M的用戶,并在必要時可將廣播流量轉化為組播流量,避免廣播數據泛濫。因此,Overlay網絡實際上是目前最主流的容器跨節點數據傳輸和路由方案。
 

image008.png


Overlay容器網絡具有以下特性:
1)需要升級Docker1.9以上(overlay是docker 1.9版本才加入的特性);
2)不改變現在物理網絡拓撲;
3)靈活性高,性能損耗高(至少30%以上);
4)封包解包消耗內存;
5)使用了隧道技術,增加運維難度。

二、路由方案
路由技術從三層或者兩層實現跨主機容器互通,沒有NAT,效率比較高,和目前的網絡能夠融合在一起,每一個容器都可以像虛擬機一樣分配一個業務的IP。如果幾萬新的容器IP沖擊到路由表里,導致下層的物理設備沒辦法承受;而且每一個容器都分配一個業務IP,業務IP消耗會很快。

典型代表:
1)Calico:基于BGP協議的路由方案,支持很細致的ACL控制。
2)Macvlan:從邏輯和Kernel層來看隔離性和性能最優的方案,基于二層隔離,所以需要二層路由器支持,大多數云服務商不支持,所以混合云上比較難以實現


1、Calico網絡方案
Calico容器網絡基于BGP協議,完全通過三層路由實現。由linux主機內核維護路由表,通過路由轉發實現容器間通信,這種實現方式沒有封包解包操作,所以性能損耗非常小,從技術上來看是一種很優越的方案。
 

image009.png

>Felix,calico agent,在每臺需要運行workload的節點上,主要負責配置路由及ACLs等信息來確保endpoint的連通狀態;
>Etcd,分布式鍵值存儲,主要負責網絡元數據一致性,確保calico網絡狀態的準確性;
>BGP client,主要是負責felix寫入kernel的路由信息分發到當前calico網絡,確保workload間的通信的有效性;
>BGP Route Reflector,大規模部署時使用,摒棄所有節點互聯的mesh模式;通過一個或者多個BGP Route Reflector來完成集中式的路由分發。

Calico容器網絡具有以下特性:
1)需要路由器開啟BGP協議支持;
2)純粹的三層實現;
3)擴展性非常好,沒有隧道技術,性能損耗非常小;
4)外界可以直接通過路由訪問IP,也可以主機上做端口映射;
5)隨著容器數量增加,Linux的iptable表數量會很大,可能會對機器性能有影響
6) 需要開啟BGP協議,對于網絡改動比較大,如果不想改動網絡,也可以嘗試其ipip方式。


2、Macvlan 網絡方案
Macvlan 是 linux kernel 比較新的特性,允許在主機的一個網絡接口上配置多個虛擬的網絡接口,這些網絡 interface 有自己獨立的 mac 地址,也可以配置上 ip 地址進行通信。macvlan 下的虛擬機或者容器網絡和主機在同一個網段中,共享同一個廣播域。macvlan 和 bridge 比較相似,但因為它省去了 bridge 的存在,所以配置和調試起來比較簡單,而且效率也相對高。除此之外,macvlan 自身也完美支持 VLAN。

Macvlan的幾種支持的模式
1)private mode:過濾掉所有來自其他 macvlan 接口的報文,因此不同 macvlan 接口之間無法互相通信;
2)vepa(Virtual Ethernet Port Aggregator) mode: 需要主接口連接的交換機支持 VEPA/802.1Qbg 特性。所有發送出去的報文都會經過交換機,交換機作為再發送到對應的目標地址(即使目標地址就是主機上的其他 macvlan 接口),也就是 hairpin mode 模式,這個模式用在交互機上需要做過濾、統計等功能的場景;
3)bridge mode:通過虛擬的交換機將主接口的所有 macvlan 接口連接在一起,這樣的話,不同 macvlan 接口之間能夠直接通信,不需要將報文發送到主機之外。這個模式下,主機外是看不到主機上 macvlan interface 之間通信的報文的。
Docker在1.12之后增加了macvlan的網絡模式, 目前此模式還在試驗階段,也僅僅支持macvlan的橋接模式。其拓撲圖如下:


image010.png

 
Macvlan容器網絡具有以下特性:
Macvlan 將所有的容器連接在二層網絡上,所有的容器相當于在一個交換機上連接,沒有封包解包,甚至沒有nat表轉換,理論上來說應該是所有網絡方案中,性能損失最小的一個。
但是macvlan在docker中目前只在試驗階段,網絡隔離也很簡單,一個docker主機只能創建一個macvlan網絡,導致所有的應用只能在一個網段中,這一點來看還不能滿足多租戶的網絡使用。 當大量的容器連接到交換機時,可能會產生ARP風暴。

通過上面的介紹及對比,天璣總結了以下幾點:
1)Overlay等依賴隧道技術的解決方案對信息損失會比較大
2)使用BGP對現有網絡改動大,但性能損耗比較小。基于Linux的iptable表對網絡訪問控制策略很豐富。
3)使用macvlan的方式網絡性能最好,但是網絡隔離暫時不能很好的支持。

歡迎容器圈內人士補充!