专栏名称: 分布式实验室
最专业的Docker文章,最权威的Docker新闻。关注容器生态圈的发展。
目录
相关文章推荐
51好读  ›  专栏  ›  分布式实验室

三种容器网络方案

分布式实验室  · 公众号  · 后端  · 2016-10-20 08:04

正文


任何云端部署容器的关键之一是管理容器间的网络。在研究编写我们最新的电子书《Networking, Security & Storage with Docker & Containers》(http://thenewstack.io/ebookseries/)期间,我们总结了三种通过插件集成容器网络的方式。前一篇文章中,我们介绍了容器网络模型(CNM)和容器网络接口(CNI),这篇文章中我们会介绍它们的起源和另一个领域:Apache Mesos生态。

CNM与Libnetwork

Docker的可扩展性设计模型使得我们可以通过向daemon代码添加扩展库的方式来扩展系统的功能,这涉及一个代码库,类似于Docker运行时,但库仅用作补充。这个库是libnetwork,最初由SocketPlane团队开发作为Docker第三方项目发布,SocketPlane公司在2015年3月份被Docker收购。

本质上讲,libnetwork提供了一种支架,开发人员可以基于它编写网络驱动。libnetwork的约束规则称为容器网络模型(CNM),CNM被认为是容器的一个权利法案。权利之一是平等地访问网络中所有其它容器;分割,隔离和流量分配是通过划分网络地址来实现的。服务发现模型为容器提供了一个互相通信的方法。

libnetwork目的是实现和使用任何类型的网络技术来连接、发现容器。对任何网络覆盖方案,它没有指定一个首选方案。Calico就是一个独立、开源、供应商中立的Layer 3网络覆盖方案。开发人员最近将Calico的calicoctl库修改为可寻址,可以作为Docker的一个插件。

ClusterHQ是第一批为数据库实现持久性容器系统的公司之一,产品名为Flocker。Flocker使用libnetwork库和Weaveworks的Weave Net网络覆盖方案。ClusterHQ产品副总裁Mohit Bhatnagar告诉我们:“我认为我们正处于一个临界点,最初那些用容器部署无状态服务的客户出现了部署有状态服务的潜在需求。而有状态服务需求的客户数量,令非常惊喜。”

Docker方案的关键架构区别在于正在扩展的部分。在Docker架构中,Docker Engine的守护程序运行在要暂存应用程序的主机服务器上,Docker Swarm重新配置了Docker Engine的网络视图,将其替换为集群中运行的服务器的混合网络视图。Swarm实际上是编排器,但插件可以在较低层扩展Docker Engine。

容器网络接口

Kubernetes项目发布了实现网络可扩展性的指南(http://kubernetes.io/docs/user-guide/networkpolicies/)。(指南认为)网络扩展应该不借助网络地址转换(NAT)就能寻址到容器的IP,并且允许以相同的方式解决自己的寻址问题。基本上,只要组件是IP可寻址的,组建就可以很好地运行在Kubernetes上。在这种背景下,理论上任何你想实现的功能不需要必须绑定到Kubernetes上,把它作为Kubernetes的扩展组件就可以了。

Google技术经理Tim Hockin解释到:“我们一直关注我们在Kubernetes网络上所做的,显然,核心系统没有办法处理每一个网络用例。世界上的每个网络都像雪花一样独一无二,我们没有办法全部实现到我们的系统中。我们必须把它外部化,插件化是我们的方式。”

CoreOS后来发布了自家的容器网络接口(CNI),它比CNM更基础,因为它只有两个命令:创建容器、删除容器。配置文件放在JSON中,通过json文件实例化容器内容和分配IP地址。因为这遵循Kubernetes的网络指南,Google发布的指南对CNI友好。因此,Flannel和Weave Net已经使用CNI实现各自的Kubernetes插件。

Hockin承认这些扩展把灵活新颖的网络连接带到Kubernetes环境中,但是它们也带来了损耗。“一般Kubernetes对overlay网络的观点是,如果你真的必须使用overlay,那就使用它们吧。这会给他们带来更多的复杂性、管理和沟通成本。我们发现越来越多的Kubernetes用户直接使用Layer 3路由,相比overlay方案,Layer3减少了他们的时间成本。”

在重新评估了可扩展框架当前状态后,ClusterHQ得出结论:模型的选择将取决于,或许完全取决于集成到容器的工作量。ClusterHQ工程和运营高级副总裁Sandeepan Banerjee解释到:“如果你的作业以前运行在VM上,VM有IP地址并且可以与项目中的其他VM通信,CNI模型和Kubernetes以及Weave是你的最佳选择。”Banerjee然后引用Kubernetes的no-NAT约定作为关键理由。他又继续讲到“如果你之前不了解这些,但是你想充分尝试Docker,包括Docker的网络库、编排框架Swarm等,你可能会发现Docker提供的解决方案很强大,它有很多优势、对overlay网络也很灵活。”







请到「今天看啥」查看全文