Flannel和Calico網絡插件工做流程對比

Flannel和Calico網絡插件對比

 

Calico簡介

Calico是一個純三層的網絡插件，calico的bgp模式相似於flannel的host-gw

Calico方便集成 OpenStack這種 IaaS雲架構，爲openstack虛擬機、容器、裸機提供多主機間通訊。

 

calico 架構

calico包括以下重要組件：Felix，etcd，BGP Client，BGP Route Reflector。下面分別說明一下這些組件：

• Felix：主要負責路由配置以及ACLS規則的配置以及下發，它存在在每一個node節點上。
• etcd：分佈式鍵值存儲，主要負責網絡元數據一致性，確保Calico網絡狀態的準確性，能夠與kubernetes共用；
• BGPClient(BIRD), 主要負責把 Felix寫入 kernel的路由信息分發到當前 Calico網絡，確保 workload間的通訊的有效性；
• BGPRoute Reflector(BIRD), 大規模部署時使用，摒棄全部節點互聯的mesh模式，經過一個或者多個 BGPRoute Reflector 來完成集中式的路由分發；

 

 

calico 原理

calico是一個純三層的虛擬網絡，它沒有複用docker的docker0網橋，而是本身實現的， calico網絡不對數據包進行額外封裝，不須要NAT和端口映射，擴展性和性能都很好。Calico網絡提供了DockerDNS服務， 容器之間能夠經過hostname訪問，Calico在每個計算節點利用Linux Kernel實現了一個高效的vRouter（虛擬路由）來負責數據轉發，它會爲每一個容器分配一個ip，每一個節點都是路由，把不一樣host的容器鏈接起來，從而實現跨主機間容器通訊。而每一個vRouter經過BGP協議（邊界網關協議）負責把本身節點的路由信息向整個Calico網絡內傳播——小規模部署能夠直接互聯，大規模下可經過指定的BGProute reflector來完成；Calico基於iptables還提供了豐富而靈活的網絡策略，保證經過各個節點上的ACLs來提供多租戶隔離、安全組以及其餘可達性限制等功能。

 

calico網絡模式

一、ipip模式

把一個IP數據包又套在一個IP包裏，即把IP層封裝到IP層的一個 tunnel，它的做用其實基本上就至關於一個基於IP層的網橋，通常來講，普通的網橋是基於mac層的，根本不須要IP，而這個ipip則是經過兩端的路由作一個tunnel，把兩個原本不通的網絡經過點對點鏈接起來；

 

calico以ipip模式部署完畢後，node上會有一個tunl0的網卡設備，這是ipip作隧道封裝用的,也是一種overlay模式的網絡。當咱們把節點下線，calico容器都中止後，這個設備依然還在，執行 probe -r ipip 命令能夠將它刪除。

9: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 inet 10.233.110.0/32 brd 10.233.110.0 scope global tunl0 valid_lft forever preferred_lft forever

 

官方提供的calico.yaml模板裏，默認打開了ip-ip功能，該功能會在node上建立一個設備tunl0，容器的網絡數據會通過該設備被封裝一個ip頭再轉發。這裏，calico.yaml中經過修改calico-node的環境變量：CALICO_IPV4POOL_IPIP來實現ipip功能的開關：默認是Always，表示開啓；Off表示關閉ipip。

# kubectl get daemonsets. calico-node -n kube-system -o yaml | grep -iA 1 ipip - name: CALICO_IPV4POOL_IPIP value: "Always"

 

補充：

Linux支持的五種ip隧道，能夠經過ip tunnel help查看

[root@yq01-aip-aikefu06e1a866 ~]# ip tunnel help Usage: ip tunnel { add | change | del | show | prl | 6rd } [ NAME ] [ mode { ipip | gre | sit | isatap | vti } ] [ remote ADDR ] [ local ADDR ]

• ipip：即 IPv4 in IPv4，在 IPv4 報文的基礎上再封裝一個 IPv4 報文。
• gre：即通用路由封裝（Generic Routing Encapsulation），定義了在任意一種網絡層協議上封裝其餘任意一種網絡層協議的機制，IPv4 和 IPv6 都適用。
• sit：和 ipip 相似，不一樣的是 sit 是用 IPv4 報文封裝 IPv6 報文，即 IPv6 over IPv4。
• isatap：即站內自動隧道尋址協議（Intra-Site Automatic Tunnel Addressing Protocol），和 sit 相似，也是用於 IPv6 的隧道封裝。
• vti：即虛擬隧道接口（Virtual Tunnel Interface），是 cisco 提出的一種 IPsec 隧道技術。

二、BGP模式

邊界網關協議（BorderGateway Protocol, BGP）是互聯網上一個核心的去中心化的自治路由協議。它經過維護IP路由表或‘前綴’表來實現自治系統（AS）之間的可達性，屬於矢量路由協議。BGP不使用傳統的內部網關協議（IGP）的指標，而是基於路徑、網絡策略或規則集來決定路由。所以，它更適合被稱爲矢量性協議，而不是路由協議，通俗的說就是將接入到機房的多條線路（如電信、聯通、移動等）融合爲一體，實現多線單IP；

BGP 機房的優勢：服務器只須要設置一個IP地址，最佳訪問路由是由網絡上的骨幹路由器根據路由跳數與其它技術指標來肯定的，不會佔用服務器的任何系統。

 

Flannel

flannel 架構

flannel的udp模式和vxlan模式都是屬於隧道方式，也就是在udp的基礎之上，構建虛擬網絡，而後經過一個封包解包的過程來實現數據的傳輸。

 

flannel的幾種模式

    flannel經過在每個節點上啓動一個叫flannel的進程，負責爲每個節點上的子網劃分，並將相關配置信息（如各節點的子網網段、外部IP等）保存到etcd中，而具體的網絡報文轉發交給backend實現。

    flanneld能夠在啓動時經過配置文件指定不一樣的backend進行網絡通訊，目前比較 成熟的backend有UDP、VXLAN和host-gateway三種。目前，VXLAN是官方比較推崇的一種backend實現方式。

    UDP模式和VXLAN模式基於三層網絡層便可實現，而host-gateway模式就必需要求集羣全部機器在同一個廣播域，也就是須要在二層網絡同一個交換機下才能實現。

    host-gateway通常用於對網絡性能要求比較高的場景，但須要基礎網絡架構的支持；UDP則用於測試及通常比較老的不支持VXLAN的Linux內核。

 

一、UDP模式

採用UDP模式時，須要在flanneld的配置文件中指定Backend.Type爲UDP，可經過直接修改flanneld的ConfigMap的方式實現。

# kubectl get cm kube-flannel-cfg -n kube-system -o yaml kubectl net-conf.json: | { "Network": "10.233.64.0/18", "Backend": { "Type": "udp" } }

經過ip addr 命令能夠發現節點上會多出一個flannel 0的網絡接口，在UDP模式中，flanneld的主要做用爲：

（1）UDP包封包解包

（2）節點上路由表的動態更新

 

工做流程圖：

熟悉Linux的應該知道，Linux頻繁內核態-用戶態的切換，會形成頻繁的上下文切換，會引起性能問題，因此從上面能夠看到container的數據包，從離開src container後，通過了屢次內核態-用戶態的切換，而且，數據包是由用戶態的flannel進行進行封包/解包的，從而致使了比較大的性能損耗，這也是爲何生產基本不會用這個方案，由於性能實在很是差。

 

二、VXLAN模式

一樣須要在Backend.Type修改成VXLAN

net-conf.json: | { "Network": "10.233.64.0/18", "Backend": { "Type": "vxlan" } }

VXLAN模式下，會建立一個名爲flannel 1的VTEP設備，數據的轉發由內核完成，並非flanned，flanned僅動態設置ARP和FDB表項

 

流程圖：

vxlan自己就是內核特性，使用vxlan會在服務器中建立一個vtep設備(flannel 1)，設備的封包/解包操做都在該設備下操做，因此直接在內核態操做，不須要CPU上下文切換，且和UDP直接三層封包不同，vxlan是直接對二層數據幀進行封包。

 

三、host-gateway模式

同上須要在Backend.Type修改成host-gw。

因爲host-gw是純路由模式，flannel須要經過etcd維護全部的靜態路由,核心是IP包在封裝成楨的時候，使用路由表的"下一跳"設置上的MAC地址，這樣能夠通過二層網絡到達目的宿主機。這就要求全部的服務器在同一個二層網絡下，這就使host-gw模式沒法適用於集羣規模較大且須要對節點進行網段劃分的場景。

host-gw另一個限制則是隨着集羣中節點規模的增大，flanneld維護主機上成千上萬條路由表的動態更新也是一個不小的壓力，所以在路由方式下，路由表規則的數量是限制網絡規模的一個重要因素。

 

流程圖：

在性能上，host-gw因爲沒有封包/解包，故性能最好