数据中心工具———虚拟网络方案Calico初探

特点与对比

Calico是一个基于BGP协议的虚拟网络工具,在数据中心中的虚拟机、容器或者裸金属机器(在这里都称为workloads)只需要一个IP地址就可以使用Calico实现互连。

项目主页:https://www.projectcalico.org/

Workloads间的网络隔离是通过iptables实现的。相比其他基于模拟的二层网络,Calico更加简单,有以下几项有趣的特点:

1.在Calico中的数据包并不需要进行封包和解封。

2.Calico中的数据包,只要被policy允许,就可以在不同租户中的workloads间传递或直接接入互联网或从互联网中进到Calico网络中,并不需要像overlay方案中,数据包必须经过一些特定的节点去修改某些属性。

3.因为是直接基于三层网络进行数据传输,troubleshoot会更加容易,同时用户也可以直接用一般的工具进行操作与管理,比如ping、Whireshark等,无需考虑解包之类的事情。

4.网络安全策略使用ACL定义,基于iptables实现,比起overlay方案中的复杂机制更直观和容易操作。

笔者之前写过一些文章关于Docker1.9开始有的的原生网络、Weave Net的文章,这些方案都是基于overlay技术,笔者更早之前做的用在Docker1.4上的基于OVS和Pipework的Docker互连方案同样是用了VXLAN/GRE才能实现跨节点互连。这些方案中,都有一些自己的特色:

笔者的OVS网络方案:

使用Pipework在容器和普通网桥或者OVS间构建一个连接(使用了veth pairs),如果使用了普通网桥,则要把网桥挂在OVS上,如果容器直接和OVS连接则可以实现VLAN划分。最后在每台机器的OVS上配置GRE或者VXLAN连接,最后借助STP避免广播风暴。

这个方案问题其实很明显:只有交换没有路由,互连仅限同一网络范围;自动化程度不高;重启容器后配置会丢失。

虽然路由可以通过部署一个VyOS容器解决,但是这种可以称之为“简单粗暴”的overlay方案还是问题多多。

Docker1.9后基于libnetwork的方案:

这个方案自1.9后正式进入可用阶段,在这个方案中,有三个概念至关重要:

1.Sandbox:一个沙盒包含容器网络栈的信息,作为一个网络配置的隔离环境,可以包含多个Endpoint与Network。

2.Endpoint:Endpoint存在于Sandbox中,作为网络通讯的接口,每个Endpoint都属于一个Network并且只属于一个Sandbox。

3.Network:实际上就是一个Endpoint组(我们可以把Network看成一个网络范围,里面的Endpoint就是范围里的IP地址),组内Endpoint可以互相通讯,Network间互相隔离。在如今的Docker中,用户可以自定义plugin,Docker将用户请求传给libnetwork,libnetwork调用plugin,在把plugin的结果返回给Docker。

libnetwork在实现上,不同节点间的网络信息是通过kv store交换和同步的,简化了网络的创建步骤,不用再一台一台地设置。

Docker network虽然是基于overlay的方案,但是是与Docker Engine最无缝结合的方案,并且支持自定义plugin,扩展性非常好,不过出于对多种容器的兼容,在Kubernetes中并没有使用该方案。

Weave Net

这个方案在Docker的早期已经开始存在,其原理也很简单:在每台主机上都有几个容器运行weave router等相关服务被用于数据处理(Calico舍去了这些特定“节点”)。其他容器接入一个特定的网桥(可以自动或手动设置IP),weave容器通过pcap捕抓那些要传给其他主机的数据包,并通过weave routers,基于UDP将加密或没加密后的包传给目标主机,再由目标主机的weave router发给挂载在网桥上的容器。

这个方案使用了mac地址和拓扑信息改善了跨主机网络的性能,同时能支持加密和穿越防火墙,但是因为overlay的封包解包而带来的性能下降是无法避免的。

Calico作为一个没有使用到overlay技术的网络方案,不仅能用在Docker上,而且还能用在OpenStack上,有一定的研究价值。目前Calico的主要应用场景是IDC内部,目前国内的宜信已经把Calico用在实际环境中,感兴趣的读者可以搜索相关分享。

深入原理

数据路径

Calico中的基本数据路径的原理其实很简单

Calico实现了数据中心中workloads间和workloads与互联网间的数据传输而无需封包解包的流程。来自或进入workload的IP包都是用workload的宿主的路由表进行路由,用iptables实现防火墙的功能。在Calico中,数据包有可能跨多个节点传输,但是无需对那些中间节点进行配置。对于一个被送到workload的数据包,最后的一跳是从该workload的宿主到workload自身:

下面是官方的例子:

在该宿主上有一个workload(其IP地址为10.65.0.24),宿主可以通过一个TAP接口tapa429fb36-04访问它。至于其他workload(10.65.0.21、10.65.0.23和

10.65.0.24),则运行在其他两个宿主172.18.203.126和172.18.203.129上,所以workload间的路由经过这些节点。

Calico中使用一个叫Felix的工具设置路由,当要为workload准备连接功能,就会通过BGP客户端生成间接路由。

一般情况下都会设置策略用来隔离不同租户间的workload,所以每个宿主上都有iptables来限制数据的传输。

寻址和连通性

下图演示了IP地址如何分配给workload和与互联网连接的机制:

在图中,workload与宿主间通过TAP(一般是OpenStack用)连接,workload有两张虚拟网卡,10.65.0.18和那个IPv6的地址2001:db8:a41:2/64是无法被外界(数据中心外)访问的,而另外一张网卡则可以被外界访问。在实际使用中,只要为虚拟网卡配置一个合适的IP地址(该地址属于那些可以被数据中心外部访问的网络范围)就可以被外网访问。

关于宿主与workload间的连接,应该是OpenStack与宿主间用TAP,Docker与宿主间用veth pair。

目前Calico(stable)中,分配给workload的地址的所属范围是由数据中心的运营商提供的,但由于这些范围是被共享的,所以有可能存在一个范围内的地址会被分配到不同租户的workload,整个IPv4和IPv6地址空间是平坦的。所以大体上,遵从于安全策略,在该空间的地址都可以互相访问。在后面的版本中似乎会加入私有网络地址范围的支持,不过如今的stable还是保持现状。

前面提到了Calico网络可以被外网访问,而网内的workload间也可以互相访问,但这些都由数据中心运营商决定,决定是否分享网络,这给了运营商足够的灵活性。

安全策略

Calico中,也像libnetwork一样存在一个Endpoint的概念而且非常相近。Calico的策略依据一些包含规则和标签的security profiles来进行定义。

Endpoint是什么?

Endpoint是那些与VM、容器连接的接口(比如veth pair、TAP等),Calico会把那些已经定义好的security profiles应用在endpoint上,可能会同时存在多个profiles。

在默认情况下,如果没有为endpoint配置profile或丢失配置,则默认丢弃任何进出workload的数据包以确保安全

Rule是什么?

Security profile(下称SF)包含一个rules元素,每个endpoint都属于一个或多个SF,这些profile会把当中的rules应用到endpoint上。

规则分为inbound和outbound两组,不难理解这样分组的原因。而每个rule包含条件和行动(和Openflow类似),目前主要有以下的匹配条件:

1.protocol

2.源或目标CIDR

3.源或目标标签(Tags)

4.源或目标端口

5.ICMP类型和Code

支持的行动有deny和allow,分别是拒绝和接受网包,规则按顺序匹配,前面一旦有匹配的规则则不再理会后面的规则,当无法找到匹配项时,默认执行deny。

Tag是什么?

每个SF都有一些关联的tag。一个SF包含tag A,则视SF中的endpoint B为A的成员。

假设有个workload运行着一个redis需要让其他workload访问,此时操作者可以创建一个tag命名为“redis”并把那些连接redis workload的接口都归为“redis”的成员。如果他配置了该tag inbound策略为allow,那么该策略会应用到所有属于该“redis”的接口,即使该workload有多块虚拟网卡,都不用一张一张地配置rule。

如果读者用过VyOS的Zone-based firewall就会觉得这种配置方式很熟悉,在VyOS中,可以把不同的接口划分到不同的zone中,如果没有为zone配置策略,默认会丢掉网包。用户可以创建防火墙策略并应用为区域数据流动策略,zone中的所有接口会自动应用防火墙策略。这样一来的确是简化了配置。

结语

Calico作为一款针对数据中心的虚拟网络工具,借助BGP、路由表和iptables,实现了一个无需解包封包的三层网络,并且有调试简单的特点。虽然目前还有些小缺陷,比如stable版本还无法支持私有网络,但希望在后面的版本中会更加强大。

本文大体上对Calico的原理和特点进行了介绍,后面的文章我会着手研究Calico的应用实践。

本人水平有限,如果有任何错误或疏漏之处,还请多多包涵。

参考资料:

http://docs.projectcalico.org/en/stable/home.html

http://www.sdnlab.com/16002.html

http://www.sdnlab.com/15994.html

http://www.sdnlab.com/13111.html

原文发布于微信公众号 - SDNLAB(SDNLAB)

原文发表时间:2016-06-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏翻译

Universe入门

Universe是一个用于衡量和训练AI的软件平台,适合世界上的所有游戏,网站和应用程序。本项目是一个universe开源库,它为 每个Universe环境提供...

6786
来自专栏Java帮帮-微信公众号-技术文章全总结

在Windows上用Java代码模仿破解WIFI密码【大牛经验】

本文纯属技术探索,与真正的破解还有很大差距,请广大网友切勿利用本文内容做出任何危害网络安全的行为。若有违法行为,均与本人无关。

5182
来自专栏linux、Python学习

60个DevOps开源工具,你在用哪些?

你喜欢免费的东西吗?获得开发者社区支持的自动化,开源的工具是大家梦寐以求的。这里列举了 60 多款最棒的开源工具,可以帮助你很好的实行 DevOps。

1570
来自专栏北京马哥教育

最棒的60个DevOps开源工具

你喜欢免费的东西吗?获得开发者社区支持的自动化,开源的工具是大家梦寐以求的。这里列举了 60+ 款最棒的开源工具,可以帮助你很好的实行 DevOps。 大图点...

8286
来自专栏西枫里博客

百度熊掌号折腾手记

熊掌号出来有一段时间了,西枫里博客早早的就申请好了熊掌号。久久没有启用,放置了一段时间后,第一次启用熊掌号,发现博客程序中对缩略图定义的尺寸不符合要求,另外考虑...

1572
来自专栏Jerry的SAP技术分享

写在Github被微软收购之际 - Github的那些另类用法

这几天朋友圈被微软75亿美元收购Github的新闻刷屏了。Jerry也来贡献一篇和Github相关的文章。

2597
来自专栏FreeBuf

“撬锁”实战:绕过云锁提权某游戏私服

朋友给我了我一个游戏私服的shell,说是提权不下服务器,让我帮忙看看。本文仅为大家提供一个思路,这个方法可能很多人知道但是并没有公布到网络。我今天写出来只是为...

1585
来自专栏刺客博客

博客主机搬迁遇到的问题记录

1824
来自专栏阮一峰的网络日志

双因素认证(2FA)教程

所谓认证(authentication)就是确认用户的身份,是网站登录必不可少的步骤。 密码是最常见的认证方法,但是不安全,容易泄露和冒充。 ? 越来越多的地方...

48410
来自专栏FreeBuf

跨平台版中国菜刀Cknife发布

Burp已经成了绿帽子门必不可少的工具,相信大家都装有Java环境,本软件支持1.7+以及所有安装了环境的系统。1.6后续会考虑兼容。 一直都有想写一款真正...

6327

扫码关注云+社区

领取腾讯云代金券