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网络模式

1、ipip模式

把一个IP数据包又套在一个IP包里，即把IP层封装到IP层的一个 tunnel，它的作用其实基本上就相当于一个基于IP层的网桥，一般来说，普通的网桥是基于mac层的，根本不需要IP，而这个ipip则是通过两端的路由做一个tunnel，把两个本来不通的网络通过点对点连接起来；

 

网络走向：pod1 cali0->caliXXXX->tunl0->node1 eth0->node2 eth0->tunl0->caliXXXX->pod2 cali0

 

calico以ipip模式部署完毕后，node上会有一个tunl0的网卡设备，这是ipip做隧道封装用的,也是一种overlay模式的网络。当我们把节点下线，calico容器都停止后，这个设备依然还在，执行 modprobe -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 隧道技术。

2、BGP模式

边界网关协议（BorderGateway Protocol, BGP）是互联网上一个核心的去中心化的自治路由协议。它通过维护IP路由表或‘前缀’表来实现自治系统（AS）之间的可达性，属于矢量路由协议。BGP不使用传统的内部网关协议（IGP）的指标，而是基于路径、网络策略或规则集来决定路由。因此，它更适合被称为矢量性协议，而不是路由协议，通俗的说就是将接入到机房的多条线路（如电信、联通、移动等）融合为一体，实现多线单IP；

BGP 机房的优点：服务器只需要设置一个IP地址，最佳访问路由是由网络上的骨干路由器根据路由跳数与其它技术指标来确定的，不会占用服务器的任何系统。

网络走向：pod1 cali0->caliXXXX->node1 eth0->node2 eth0-> caliXXXX->pod2 cali0

 

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内核。

 

1、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）节点上路由表的动态更新

 

工作流程图：

网络走向：pod1 eth0->veth->flannel0->flanneld->node1 eth0-> node2 eth0->flanneld->flannel0->veth->pod2 eth0

 

熟悉Linux的应该知道，Linux频繁内核态-用户态的切换，会造成频繁的上下文切换，会引发性能问题，所以从上面可以看到container的数据包，从离开src container后，经过了多次内核态-用户态的切换，并且，数据包是由用户态的flannel进行进行封包/解包的，从而导致了比较大的性能损耗，这也是为什么生产基本不会用这个方案，因为性能实在非常差。

 

2、VXLAN模式

同样需要在Backend.Type修改为VXLAN

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

VXLAN模式下，会创建一个名为flannel 1的VTEP设备，数据的转发由内核完成，并不是flanned，flanned仅动态设置ARP和FDB表项

 

流程图：

网络走向：pod1 eth0->veth->flannel.1->node1 eth0-> node2 eth0->flannel.1->veth->pod2 eth0

 

vxlan本身就是内核特性，使用vxlan会在服务器中创建一个vtep设备(flannel 1)，设备的封包/解包操作都在该设备下操作，所以直接在内核态操作，不需要CPU上下文切换，且和UDP直接三层封包不一样，vxlan是直接对二层数据帧进行封包。

 

3、host-gateway模式

同上需要在Backend.Type修改为host-gw。

由于host-gw是纯路由模式，flannel需要通过etcd维护所有的静态路由,核心是IP包在封装成桢的时候，使用路由表的"下一跳"设置上的MAC地址，这样可以经过二层网络到达目的宿主机。这就要求所有的服务器在同一个二层网络下，这就使host-gw模式无法适用于集群规模较大且需要对节点进行网段划分的场景。

host-gw另外一个限制则是随着集群中节点规模的增大，flanneld维护主机上成千上万条路由表的动态更新也是一个不小的压力，因此在路由方式下，路由表规则的数量是限制网络规模的一个重要因素。

 

流程图：

在性能上，host-gw由于没有封包/解包，故性能最好