我们专注服务于当下互联网基础设施建设与云计算、大数据时代的各种需求!

Docker网络方案-Calico

  • Calico,基于BGP协议的路由方案,支持很细致的ACL控制,对混合云亲和度比较高。

Calico是一个纯3层的数据中心网络方案,而且无缝集成像OpenStack这种IaaS云架构,能够提供可控的VM、容器、裸机之间的IP通信。通过将整个互联网的可扩展IP网络原则压缩到数据中心级别,Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发,而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个Calico网络内传播——小规模部署可以直接互联,大规模下可通过指定的BGP route reflector来完成。

这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。

cni

Calico节点组网可以直接利用数据中心的网络结构(无论是L2或者L3),不需要额外的NAT,隧道或者Overlay Network。

如上图所示,这样保证这个方案的简单可控,而且没有封包解包,节约CPU计算资源的同时,提高了整个网络的性能。

此外,Calico基于iptables还提供了丰富而灵活的网络Policy,保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。

Calico架构

结合上面这张图,我们来过一遍Calico的核心组件:

  • Felix,Calico Agent,跑在每台需要运行Workload的节点上,主要负责配置路由及ACLs等信息来确保Endpoint的连通状态;
  • etcd,分布式键值存储,主要负责网络元数据一致性,确保Calico网络状态的准确性;
  • BGP Client(BIRD), 主要负责把Felix写入Kernel的路由信息分发到当前Calico网络,确保Workload间的通信的有效性;
  • BGP Route Reflector(BIRD),大规模部署时使用,摒弃所有节点互联的 mesh 模式,通过一个或者多个BGP Route Reflector来完成集中式的路由分发。

    Calico Docker Network 核心概念

    从这里开始我们将“站队” CNM,通过Calico Docker libnetwork plugin的方式来体验和讨论Calico容器网络方案。

    先来看一下CNM模型:

    从上图可以知道,CNM基于3个主要概念:

    • Sandbox,包含容器网络栈的配置,包括Interface,路由表及DNS配置,对应的实现如:Linux Network Namespace;一个Sandbox可以包含多个Network;
    • Endpoint,做为Sandbox接入Network的介质,对应的实现如:veth pair、TAP;一个Endpoint只能属于一个Network,也只能属于一个Sandbox;
    • Network,一组可以相互通信的Endpoints;对应的实现如:Linux bridge、VLAN;Network有大量Endpoint资源组成。

    除此之外,CNM还需要依赖另外两个关键的对象来完成Docker的网络管理功能,他们分别是:

    • NetworkController,对外提供分配及管理网络的APIs,Docker Libnetwork支持多个活动的网络driver,NetworkController允许绑定特定的driver到指定的网络;
    • Driver,网络驱动对用户而言是不直接交互的,它通过插件式的接入来提供最终网络功能的实现;Driver(包括IPAM)负责一个Network的管理,包括资源分配和回收。

    有了这些关键的概念和对象,配合Docker的生命周期,通过APIs就能完成管理容器网络的功能,具体的步骤和实现细节这里不展开讨论了, 有兴趣的可以移步 Github:https://github.com/docker/libnetwork/blob/master/docs/design.md。

    接下来再介绍两个Calico的概念:

    • Pool,定义可用于Docker Network的IP资源范围,比如:10.0.0.0/8或者192.168.0.0/16;
    • Profile,定义Docker Network Policy的集合,由tags和rules组成;每个 Profile默认拥有一个和Profile名字相同的Tag,每个Profile可以有多个Tag,以List形式保存。 Profile样例:

    Inbound rules: 1 allow from tag WEB
    2 allow tcp to ports 80,443
    Outbound rules:
    1 allow
    Demo

    基于上面的架构及核心概念,我们通过一个简单的例子,直观的感受下Calico的网络管理。

    Calico以测试为目的集群搭建,步骤很简单,这里不展示了, 大家可以直接参考Github:https://github.com/projectcalico/calico-containers/blob/master/docs/calico-with-docker/docker-network-plugin/README.md。

    这里默认已经有了Calico网络的集群,IP分别是:192.168.99.102和192.168.99.103。

    calicoctl status截图:

    同时,已经有两个IP Pool创建好,分别是:10.0.0.0/26和192.168.0.0/16。

    calicoctl pool show截图:

    当前集群也已经通过使用calico driver和IPAM创建了不同的Docker Network,本次Demo只需要使用DataMan。

    Docker Network ls 截图:

    calicoctl profile show截图:

    下面我们使用DataMan这个网络,在两台slave机器上各启动一个容器:

    数人云下发容器的Marathon json file:

    code { "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路由实现

    根据上面这个Calico数据平面概念图,结合我们的例子,我们来看看Calico是如何实现跨主机互通的:

    两台slave route截图:

    对照两台slave的路由表,我们就知道,如果slave 1上的容器(10.0.0.48)想要发送数据到slave 2 上的容器(192.168.115.193), 那它就会match到最后一条路由规则,将数据包转发给slave 2(192.168.99.103),那整个数据流就是:

    container -> kernel -> (cali2f0e)slave 1 -> one or more hops -> (192.168.99.103)slave 2 -> kernel -> (cali7d73)container

    这样,跨主机的容期间通信就建立起来了,而且整个数据流中没有NAT、隧道,不涉及封包。

    安全策略ACL

    Calico的ACLs Profile主要依靠iptables和ipset来完成,提供的是可针对每个容器级别的规则定义。

    具体的实现我们可以通过iptables命令查看对应的chain和filter规则, 这里我们就不展开讨论了。

    Contiv

    http://contiv.github.io

    Contiv是Cisco开源出来的针对容器的基础架构,主要功能是提供基于Policy的网络和存储管理,是面向微服务的一种新基架。

    Contiv能够和主流的容器编排系统整合,包括:Docker Swarm、Kubernetes、Mesos and Nomad。

    如上图所示,Contiv比较“诱人”的一点就是,它的网络管理能力,既有L2(VLAN)、L3(BGP),又有 Overlay(VxLAN),而且还能对接Cisco自家的 SDN 产品 ACI。可以说有了它就可以无视底层的网络基础架构,向上层容器提供一致的虚拟网络了。

    Contiv Netplugin特性

    • 多租户网络混部在同一台主机上;
    • 集成现有SDN方案;
    • 能够和非容器环境兼容协作,不依赖物理网络具体细节;
    • 即时生效的容器网络Policy/ACL/QoS规则。

    网络方案性能对比测试

    最后附上我们使用qperf做的简单性能测试结果,我们选取了vm-to-vm、host、calico-bgp、calico-ipip以及Swarm Overlay进行了对比。

    其实Contiv也测试了,但是因为Contiv的测试环境和其他方案使用的不同,不具有直接可比性,所以没有放入对比图里。 直观感受就是基于OVS的方案确实不理想,后面有时间会统一环境继续进行测试对比,包括Contiv的L3/L2方案以及引入MacVLAN、Flannel等。

    测试环境:VirtualBox VMs,OS:Centos 7.2,kernel 3.10,2 vCPU,2G Mem。

    带宽对比结果如下:

    时延对比结果如下:

    qperf 命令:

    总结

    随着容器的落地,网络方案必将成为“兵家”必争之地,我们 数人云 是轻量级 PaaS 容器集群管理云平台,在网络方案选择上的考虑是:

    • 性能,Calico和MacVLAN都有着不错的表现;Contiv L3(BGP)理论上性能也不会差;
    • 普适性,Calico对底层的基本要求就是IP层可达;MacVLAN不适应于公有云;Contiv对底层的兼容性可能更好;
    • 可编程性,保证整个网络管理过程能够程序化、API化,这样方便集成到产品里,不需要手动运维;Calico和Contiv都有相应的模块;
    • 未来发展,这个就是我说的“站队”,Docker的CNM和CoreOS、Kubernetes的CNI,现在还看不清,Calico和Contiv都是支持的。