Container网络互联方案汇总

朱雀 2022-05-28 00:27 308阅读 0赞

## 前言 ##

网络的职责是将散落在不同范围的终端实体相互联通，并提供复杂的策略管理能力。根据终端实体散布的范围不同，可以由不同的网络设备和功能进行辅助，而路由和封装是最为常见的网络连接手段。路由方式适合大规模动态扩展并且发送效率较高，但是管理复杂度也更高，单个网络接入点需要感知周围网络的状态；封装方式配置相对简单，但是需要有耗费计算资源的封装步骤，并且不太利于创建动态可扩展的大规模网络。  
  
  
Container网络互联方案也不外乎点对点、路由和封装等方式，这些方式对应的解决方案在可管理性、性能和可扩展性方便各有长短。对于一个container实例，它的网络接入解决方案可以是如下几种之一：

*  none模式
 *  host模式
 *  bridge方式
 *  overlay方式
 *  underlay方式

转载自https://blog.csdn.net/cloudvtech

## none模式 ##

在这种模式下，container实例在建立的时候不具有任何网络虚拟设备和网络功能，可以通过命令行或者类似pipework之类工具对container的network namespace进行网络配置。这种方式下，可以根据需求对container的网络进行定制，但是难以维护。

像kubernetes这样的container管理框架就是以这种方式先建立none模式的container，然后再利用CNI动态配置container的网络。

转载自https://blog.csdn.net/cloudvtech

## host模式 ##

在这种模式下，container实例和宿主机共享一个network namespace。在这种方式下，container可以看到宿主机的所有网络设备、路由和iptables配置，并且和宿主机共享一个网络协议栈，也没有任何针对container网络数据的NAT，所以可以达到几乎native的性能。但是这种方式下面，由于共享主机的网络协议栈，所以多个host network模式的container是无法使用同一个TCP端口的，极大局限了container的immutable部署的能力。而且如果container在使用host network模式的同时还是以privilege方式运行的，那么这个container实例将拥有宿主机网络的管理能力，会带来网络安全隐患。

这种模式可能在特定的需要主机网络能力的应用场景得到运用，比如使用container作为IPVS直接路由方式的director的时候。

##  ##

转载自https://blog.csdn.net/cloudvtech

## bridge方式 ##

在这种方式下，容器运行时会先建立一个Linux bridge，然后在container的启动的时候生成一对虚拟网卡对，分别放在bridge和container的network nampespace里面以建立从container到bridge的网络连接。container里面配置bridge内部管理的网络地址，这些地址并不能被外部网络直接访问。container运行时需要在宿主机的网络上配置iptables的NAT和端口转换来为container提供对外访问的能力和对外提供服务的能力。并且这种模式有效的隔离了container之间的访问，提高了container虚拟化方案的安全性。这种方式最大的不足在于所有进出container的数据包都要经过宿主机IPtables的数据包修改和bridge的端口选择，性能损失比较明显。

这种方式是多数container管理框架都支持的网络模式，配置和管理都相对简单，适合小规模部署或者POC项目的快速部署。

## overlay方式 ##

这种方式是使用网络隧道进行container的互联。网络隧道tunnel可以通过数据包封装和协议的扩展，将低层的协议封装到高层的协议里面进行传输，以延展低层网络的范围。这种隧道的方式需要发送端和接收端都具有对隧道协议的编解码能力，根据隧道对端处于中间节点(如路由器)还是最终接收节点(如主机)的不同，分别有不同的协议来支持(比如GRE tunnel和VxLAN)。

对于container本身来讲，如果需要使用overlay技术和远端的服务进行通信，必须要借助实现overlay技术的具体解决方案，比如flannel、OVS或者Weave等。这些解决方案一般是作为container管理框架网络插件的形式介入container部署和管理过程，为整个overlay方案配置相关的基础设施如bridge、路由、网络策略管理程序(包括必要的overlay网络信息数据库如etcd)和隧道协议编解码程序，为container实例配置网络地址、网关和路由等参数。

其中，flannel是一个支持较多封装和组网方式的overlay解决方案，它支持UDP封装、vxlan封装、host-gw(基于路由)、AliVPC、AWS VPC、GCE、IPIP、IPSec等overlay方案。另外值得一提的是Openshift使用的是基于OVS SDN和VxLAN封装的container网络互联方案。

Overlay方式具有具有很强的兼容性，具有一定的网络扩展能力和较强的动态组网能力，同时overlay方式天然具有子网分割管理的能力，提高了container混合部署的安全性，所以很适合混合云和公有云的复杂部署场景。但是Overlay方式的缺点也很明显，封装的方式会占用大量计算资源，并且部分用户层封装的解决方案存在大量进出内核的内存拷贝路径，较难实现高性能的网络互联。

转载自https://blog.csdn.net/cloudvtech

## underlay方式 ##

对于container而言，underlay方式是将宿主机或者低层的网络设施(如网卡)直接暴露给container，为container提供网络配置的基础环境。

macvlan和ipvlan是比较常见的两种underlay技术，这两种联网方案可以让一个主机网卡可以虚拟出更多的子网卡或者子接口，直接接入主机所在网络,所以与传统的主机上的网络配置方法并没有太大的区别，更易于管理和维护；并且由于这两种技术需要对基础网络有更多的控制和动态管理，所以更适合私有环境下单一类型container组网需求。

直接路由也是常见的underlay技术。这种方式使用现有的网络基础设施，通过建立不同的路由路径，将container互联或者对外暴露服务端口。这种方案可以同任何类型的数据中心、虚拟技术(container或者虚拟机)进行互联，并且借助现有的网络管理系统，可以具有很强的网络策略配置能力。同时这种方案避免了大量数据包封装操作和地址翻译操作，所以具有很强的网络扩展能力和性能。Calico是一个比较出色的基于路由的underlay容器互联方案，它的vRouter可以高效进行container与外部网络时间数据的路由转发操作。

转载自https://blog.csdn.net/cloudvtech

尾声

除了以上方案之外，根据特定系统的能力，还可以使用硬件passthrough的方案，将网络裸硬件直接暴露给container，由单个container实例全权掌握这个硬件的资源，比如支持SR-IOV的网卡可以将物理网卡分割成众多物理子网卡，相互独立，统一维护，可以有效的跨越container主机网络能力限制，达到native接入的效果。

转载自https://blog.csdn.net/cloudvtech