前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >容器网络介绍分析

容器网络介绍分析

作者头像
灯塔大数据
发布2020-09-16 14:08:49
1.3K0
发布2020-09-16 14:08:49
举报
文章被收录于专栏:灯塔大数据灯塔大数据

本文部分内容译自《An Analysis and Empirical Study of Container Networks》

01

引言

随着云计算技术发展,容器(Container)作为一种轻量级的虚拟化形式,已逐步成为云上应用交付的标准。当企业建设容器云平台时,会碰到一系列挑战,根据CNCF的调查报告指出,容器的网络和安全实现成为容器云平台建设最主要的挑战,当企业开始将重要的企业核心应用迁移至容器平台,缺乏足够的网络和安全管控将会给业务上线带来潜在的巨大威胁。

一般而言,容器网络可归为两大类:单主机网络(Single-Host)和多主机网络(Multi-Host)。单主机和多主机场景下都有多种网络模式,本篇将先对单主机容器网络模式进行介绍,之后对多主机容器网络模式进行介绍,最后进行总结。

02

单主机容器网络

None Mode

这个模式下的容器只有一个loopback接口,不能连接到本机或其他网络上的容器;但它具有良好的隔离性和安全性,适合不需要网络连接的服务,如:离线数据计算、批处理、备份任务等。

Bridge Mode

桥接模式是Docker容器在单机情况下的默认模式。桥接模式会给每个新创建的容器分配独立的命名空间(Namespace)、IP地址,同时文件系统、进程等也是隔离的,另外会将对应的容器的网络接到某个指定的虚拟网桥上(如:启动Docker服务时默认创建的docker0上)。单独的桥接模式不能把容器连接到外部网络,必须依赖其他网络服务,如NAT、Overlay等。

Container Mode

容器模式涉及多个容器,它们共享同一个网络命名空间。在一组容器中,一个容器被指定为代理、并配置为桥接模式,其他组内的容器通过代理的以太(veth)接口连接到外网。即所有组内的容器共享同一个网络,整个组只指定一个IP地址,组内的单个容器通过组IP加端口号来辨认。

容器模式被许多容器管理框架采用,例如:Kubernetes中的一个Pod包含一组容器,同一Pod里的容器共享相同的网络空间及IP地址,相互之间通过组IP加端口号来进行访问。

Host Mode

Host模式网络允许同一主机上的所有容器共享主机操作系统(OS)的Namespace,即该模式下同一主机上的所有容器彼此可见且容器间通过进程通信,正因如此,Host模式的安全级别在四种模式中最低。

图1: 单主机四种容器网络模式总结

图1对单主机上四种容器网络模式的特点进行总结,从上至下,网络逐渐变得高效,但安全隔离级别逐渐降低。

03

多主机容器网络

Host Mode

正如单主机模式下Host模式,多主机Host模式下的容器也共享主机的网络栈和Namespace。因此,不同主机上的两个Host模式的容器可以很容易的进行通信,就像两个主机上使用IP进行通信的两个进程一样。尽管Host模式的网络配置较为简单,但只有两个Host模式的容器能够相互通信,如:一个桥接模式的容器可以使用目的主机IP发包给另一个不同主机上的Host模式的容器,但反之不行,且Host模式对同个主机上的容器不进行安全隔离。

Network Address Translation

(NAT)

NAT模式是Docker 1.9之前最常用的多主机容器网络技术。NAT技术将容器的的私有IP地址到它的端口号之间的关系映射到NAT表中,通信时必须使用主机的公有IP地址加端口号来确定一个特定容器。

NAT不需要复杂的配置和第三方软件支持,它是一个实现不同主机上容器连通性的简单方法。此外,由于NAT允许容器使用期宿主机的IP地址,所以在大规模容器部署时不需要大量的公有IP地址。在使用NAT模式时,需要对每个发送和接收的包进行地址转换,因此会有些开销和性能下降;另外,容器的公有IP地址和他们的宿主机IP绑定,导致很难实现动态网络。

Overlay Network

Overlay网络是指在不改变现有网络基础设施的前提下,通过某种约定通信协议,把二层报文封装在IP报文之上形成新的数据格式,以此建立节点之间定制化的连接。

比起NAT,Overlay网络提供了隔离的地址空间,并允许容器使用私有的地址进行通信。但Overlay网络也有如下两个缺点:1、封包和解包较为耗时,且延长了网络栈;2、封包时改变了原始包的大小,当底层网络限制了最大传输单元(Maximum transmission unit,MTU)时,封包时的空间开销可能会导致要发送的包的数量增加。

在Docker提供Overlay原生支持前有很多第三方解决方案被提出来,如Weave、Flannel、Calico(IPIP)等;Docker在1.9版本之后提供原生Overlay网络,且是多主机网络的默认方案;

Routing

以支持边界路由协议(Border Gateway Protocol,BGP)的Calico为例,它在主机的内核中实现了一个虚拟路由器,使用BGP来进行包的路由。作为网络层的解决方案,Calico相比起NAT和Overlay开销并不大,但也有一些限制,如:Calico只支持部分网络协议,如TCP、UDP、ICMP,适用性有限;其次,在短生命周期的容器组成的动态网络中,更新BGP中的路由信息也是开销很大的。

图2对可用的多主机容器网络进行总结,包括各方式支持的协议、是否有KV(Key Value)存储、安全性等。

图2:多主机容器网络总结

04

总结

为容器化应用选择合适的网络是一件很有挑战的事情,需要考虑到很多因素。如果用户在单机上运行容器,需要在性能、安全、隔离之间进行权衡,若安全和隔离是最重要的,桥接模式就是最好的选择;如果容器需要频繁和其他容器相互通信,且一些容器需要访问其他容器的命名空间来监控管理,容器模式是最好的选择。如果用户在多主机上构建容器网络,从性能的角度考虑,Calico(BGP)是最好的选择。

此外,还有很多因素影响网络性能,如:网络启动时间、CPU开销、网络包的大小等,用户在选择网络模式时应综合这些因素进行选择。

文章作者 | 中国电信股份有限公司研究院 任宏丹

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-09-14,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 融智未来 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档