理解Docker网络驱动和他们的用例

应用需求和网络环境是多样的,并且有时候针锋相对。在应用和网络之间有着Docker网络,亲切的叫做 Container 网络模型 或 CNM。CNM代理连接着Docker容器,而且在网络中常见的移除了多样性和复杂性。结果就是可移植性和来自CNM的强有力的网络驱动。这些为了Docker Engine、Swarm和UCP的扩展点接口提供特殊功能,像是多主机网络、网络层加密和服务发现。

自然,下一个问题就是我应该用哪个网络驱动?每个驱动试图权衡并且在根据用例不同有不同的优势。内置网络驱动包含在Docker Engine中,而且插件网络驱动也由网络供应商和社区提供。最常用的内置网络驱动是bridge, overlay 和macvlan。他们一起覆盖了非常广泛的网络用例列表和环境。为了更深入的比较和探讨更多的网络驱动,可以看看 Docker Network Reference Architecture.(https://success.docker.com/Datacenter/Apply/Docker_Reference_Architecture%3A_Designing_Scalable%2C_Portable_Docker_Container_Networks)

Bridge 网络驱动

bridge 网络驱动是的我们列表上的第一个驱动。它很容易理解、使用和故障检测,对开发者和刚使用Docker的人来说一个很好的网络选择。 bridge 驱动在主机内部创建一个私有网络,因此在这个网络中容器可以相互通讯。外部访问容器通过公开端口授权。Docker通过管理条约保护网络,阻止在不同的Docker网络之间连接。

在幕后,Docker Engine创建必要的Linux bridges、内部接口、防火墙规则和主机路由来实现连接。在下面高亮的例子当中,创建了一个Docker bridge网络,其中有2个容器。无需额外的配置,Docker Engine做了必要的装配,为容器提供服务发现功能,并且设置安全规则来阻止连接其他网络。内置IPAM驱动为容器接口提供私有IP地址,来自bridge网络的子网络。

在接下来的例子中,我们用一个虚构的、叫做 pets的app,它由一个web 和db 容器组成。在你自己的UCP或者Swarm集群上随意尝试一下。可以在 `:8000`上访问app。

docker network create -d bridge mybridge
 docker run -d --net mybridge --name db redis
 docker run -d --net mybridge -e DB=db -p 8000:5000 --name web chrch/web

 

20170109222029

 

应用现在在我们主机8000端口上可服务。Docker bridge允许 web用 db 通过它自己的容器名称来连接。bridge驱动自动的执行服务发现是因为它们在同样的网络。所有的端口映射、安全规则和管道工程在Linux bridges之间,是通过网络驱动来处理的,随着容器跨越一个集群来计划和调度。

bridge驱动是本地范围驱动,意味着它只能在一个主机上提供服务发现、IPAM和连接。多主机服务发现需要外部的解决方案,可以映射容器到它们的本地主机。这正是 overlay驱动为何如此棒了。

Overlay 网络驱动

内置Docker overlay网络驱动在多主机网络中彻底地简化了许多复杂性。它是swarm范围驱动,意味着它跨越整个Swarm或UCP集群操作而不是个别主机。通过 overlay驱动,在没有外部供应和组件的Docker内,多主机网络是一等公民。IPAM、服务发现、多主机链接、加密和负载平衡建立在其中。为了操控, overlay驱动在低点终止时间使用加密Swarm控制层来管理大规模集群。

overlay驱动利用VXLAN数据层行业标准,从下层的物理网络(底层)解耦容器网络。这样做的优势是跨越多种云和本地网络提供最大的可移植性。网络策略、可见性、和安全是通过Docker Universal Control Plane (UCP)来集中控制的。

 

20170109222037

 

在这个例子中我们在UCP中创建一个overlay网络,因此当我们在不同主机上时,我们可以连接 web和 db 容器。在一个overlay网络中,为了服务和容器的本地DNS服务发现将确 web可以解决 db ,反之亦然。打开加密,这样默认通讯在容器之间是安全的。此外,可见性和网络的运用在UCP中是受到限制的,通过权限标签。

UCP会计划服务跨越集群,而且UCP会动态的安排overlay网络提供连接到容器,无论他们在哪。当服务由多种容器支持,基于VIP的负载均衡将跨越所有容器分布流量。

用下面的CLI命令,随意运行这个例子防范UCP集群:

docker network create -d overlay --opt encrypted pets-overlay

docker service create --network pets-overlay --name db redis

docker service create --network pets-overlay -p 8000:5000 -e DB=db --name web chrch/web

 

20170109222043

 

在这个例子里,我们仍然在8000端口服务 webapp,但是现在我们跨越了不同主机部署应用。如果我们以前想缩放web容器、Swarm和UCP网络,将会自动负载均衡流量。

overlay 驱动是多功能的驱动,处理许多复杂性和集成,当制作零碎的解决方案时与组织斗争。它为许多网络挑战提供一个现成的解决方案,并在规模上如此。

MACVLAN 驱动

macvlan 驱动是一个最新的内置网络驱动,有一些独特的特征。它是一个轻量级的驱动,因为不是使用任何Linux 桥接或端口映射,它直接连接容器接口到主机接口。在外部的子网络上,用可路由IP地址解决容器。

由于可路由IP地址,容器和资源直接通讯,在一个Swarm集群外存在,没有使用NAT和端口映射。这可以帮助网络可视性和故障排除。此外,直接流量路径在容器之间,主机端口帮助减少潜在因素。 macvlan 是一个本地范围网络驱动,每个主机都要配置。因此,在MACVLAN和外部网络之间有严格的依赖性,这对两者既是约束也是优势,不同于overlay 和 bridge。

macvlan驱动使用父端口概念。这个端口可以作为一个主机端口,例如 eth0、一个界面或甚至一个结合主机适配器–捆绑以太网接口到一个单独本地接口中。在MACVLAN网络配置过程中,一个外部网络的网关地址是需要的,作为MACVLAN网络是从容器到网关的一个L2部分。像所有的Docker网络,MACVLAN网络是相互分割的——在网络中提供访问,但是不是在网络之间。

macvlan 驱动可以通过不同方法配置可以实现不同结果。在下面例子中,我们创建2个MACVLAN网络加入不同的子接口。这种配置风格可以用来延长多种L2 VLANs,通过主机接口直接到容器。默认VLAN网关存在外部网络。

 

20170109222055

 

在这个例子里, db和 web容器链接不同的MACVLAN网络。每个容器位于它各自的外部网络上,通过那个网络提供一个外部IP。使用这个设计,一个操作员可以在主机外控制网络策略和在L2上的部分容器。容器也可以安排在同样的VLAN中,通过把它们配置在同样的MACBLAN上。这只是显示了每个驱动提供的灵活性数量。

在Docker的理念中,可移植性和选择性是重要的用户。Docker容器网络模型为供应商提供一个开放端口和社区来创建网络驱动。Docker的互补发展和SDN技术每天正在提供更多的选项和功能。

工作愉快!

原文:Understanding Docker Networking Drivers And Their Use Cases
作者:Mark Church
来源:Docker
原文链接:https://blog.docker.com/2016/12/understanding-docker-networking-drivers-use-cases/

翻译:博云

分享到:更多 ()