【K8S】详解容器网络中的overlay、underlay

目录

overlay网络模型

underlay

总结：

---

overlay网络模型

接上文https://blog.csdn.net/qq_39965059/article/details/125948740?spm=1001.2014.3001.5502

在分布式pod中，K8S上的所有pod默认会从同一平面网络得到全局一个唯一IP地址和一个虚拟网络接口，无论是否都处于一个namespace，各个pod之间都可使用各自的IP地址直接进行通信。为了满足分布式pod必须位于同一个平面网络内，Netplugin目前常用的实现方案有：Overlay Network ,Underlay Network两类。

那么就有一个问题，对于一个K8S集群来说，容器数量是很多的，为了避免各个容器间网络的冲突，一个常见的解决方案是给每个宿主机分配同一个网络中的不同子网，再让宿主机根据自有子网向其内容器分配ip。

而主机间的网络通信只能经由主机上可以对外通信的网口进行，跨主机在数据链路层直接连接虚拟网桥难以实现，必须借助主机间通信隧道进行数据帧的转发。这种于某个通信网络上构建出另一个逻辑通信网络通常被称为overlay或者underlay网络。

隧道转发的本质是将容器双方的报文分别封装成各自宿主机的报文，通过宿主机之间的隧道完成数据交换，这种虚拟网络的基本要求就是宿主机只需要支持隧道转发协议即可。

目前流行的overlay网络隧道转发协议有VXLAN，他采用L2 over L4 的报文封装模式，将二层报文用三层协议封装，可以实现二层网络在三层范围内进行扩展，将“二层域“扩展为”大二层域“。下图给出了VXLAN隧道网络。

注意：在VXLAN网络中，一个网络被称为一个Bridge-Domain，即BD，类似于传统局域网VLAN里的VLAN。而在传统局域网VLAN里，各VLAN之间要通过VLAN ID来区分，在VXLAN网络中，各BD通过VNI加以标识。另外，为了保证通信报文的正确性，VXLAN通信的报文一律不可以分片，这就要求物理网络的数据链路层提供 足够大的MTU（以太网MTU默认是1500），或者修改MTU值使得VXLAN报文能够顺利传输，但是，修改降低MTU会影响报文传输性能。

VXLAN的优势是对底层网络没有侵入性，无需更改底层网络，只需要在原有网络基础加一个额外的设备来负责VXLAN相关协议报文的封装、解封即可，这个设备就是VTEP（VXLAN Tunnel Endpoints），它工作与VXLAN网络边缘，相当于VXLAN通信隧道的出入口设备。

VETP代表一些支持VXLAN协议的交换机，VETP也可以由一些支持VXLAN协议的操作系统模拟出来，linux内核从3.7开始通过vxlan模块原生支持此协议，于是，各个主机上由虚拟网络构建的LAN便可以借助vxlan内核模块模拟的VETP设备和其他主机上的VETP设备进行对接，形成隧道网络。对于flannel来说，这个VETP就是各个节点生成的flannel1.1接口，其中"1"代表是VXLAN的BD表示VNI，即同一k8s集群上，VETP设备的 VNI为1的是同一个Bridge-Domain.

相同VXLAN 相同VNI在不同VETP间的通信，是在同一个VNI内，通常借助二层网关即可完成，而在相同VXLAN 不同VNI的VETP间，或者VXLAN同非VXLAN的通信需要借助三层网络设备。VXLAN支持使用集中式和分布式的两种形式的网关，前者支持流量集中管理，配置和维护简单，但是转发效率不高且容器出现瓶颈；后者以各个节点为二层或者三层网关，消除了瓶颈。

VXLAN网络内的容器在首次通信时，是如何知道对方容器的VETP呢？如何选择一个正确的路径传输报文的？

一般有两种方法：多播和控制中心

多播：将同一BD内的所有VETP放在一个多播域里，通过发送多播报文来查询目标容器的VETP。

控制中心：控制中心（大脑）在某个共享的存储服务上保存所有VETP和容器网关的映射信息，各个主机上运行的相关的守护进程会通过和控制中心的通信来获得相关的映射信息。fannel默认使用控制中心的方式，它将网络配置信息存储在etcd里。

linux内核3.7之前的版本支持UDP,IPIP,GRE隧道技术，由于当今公有云底层网络的限制，overlay网络是一种可行的容器网络解决方案，对于一些注重网络性能的场景，则会使用underlay网络。

underlay

Underlay网络就是传统IT基础设施网络，由交换机和路由器等设备组成，借助以太网协议、路由协议和VLAN协议等驱动，它还是Overlay网络的底层网络，为Overlay网络提供数据通信服务。容器网络中的Underlay网络是指借助驱动程序将宿主机的底层网络接口直接暴露给容器使用的一种网络构建技术，较为常见的解决方案有MAC VLAN、IP VLAN和直接路由等。

1、MAC VLAN

MAC VLAN支持在同一个以太网接口上虚拟出多个网络接口（一接口虚多网口），每个虚拟接口都拥有唯一的MAC地址，并可按需配置IP地址。与Bridge模式相比，MAC VLAN不再依赖虚拟网桥、NAT和端口映射，它允许容器以虚拟接口方式直接连接物理接口。下图给出了Bridge与MAC VLAN网络对比示意图。

MAC VLAN有Private、VEPA、Bridge和Passthru几种工作模式，它们各自的工作特性如下。

• Private：禁止构建在同一物理接口上的多个MAC VLAN实例（容器接口）彼此间的通信，即便外部的物理交换机支持“发夹模式”也不行。
• VPEA：允许构建在同一物理接口上的多个MAC VLAN实例（容器接口）彼此间的通信，但需要外部交换机启用发夹模式，或者存在报文转发功能的路由器设备。
• Bridge：将物理接口配置为网桥，从而允许同一物理接口上的多个MAC VLAN实例基于此网桥直接通信，而无须依赖外部的物理交换机来交换报文；此为最常用的模式，甚至还是Docker容器唯一支持的模式。
• Passthru：允许其中一个MAC VLAN实例直接连接物理接口。

由上述工作模式可知，除了Passthru模式外的容器流量将被MAC VLAN过滤而无法与底层主机通信，从而将主机与其运行的容器完全隔离，其隔离级别甚至高于网桥式网络模型，这对于有多租户需求的场景尤为有用。由于各实例都有专用的MAC地址，因此MAC VLAN允许传输广播和多播流量，但它要求物理接口工作于混杂模式，考虑到很多公有云环境中并不允许使用混杂模式，这意味着MAC VLAN更适用于本地网络环境。

需要注意的是，MAC VLAN为每个容器使用一个唯一的MAC地址，这可能会导致具有安全策略以防止MAC欺骗的交换机出现问题，因为这类交换机的每个接口只允许连接一个MAC地址。另外，有些物理网卡存在可支撑的MAC地址数量上限。

            补充：MAC洪泛攻击：交换机中存在着一张记录着MAC地址的表，为了完成数据的快速转发，该表具有自动学习机制；泛洪攻击即是攻击者利用这种学习机制不断发送不同的MAC地址给交换机，填满整个MAC表，此时交换机只能进行数据广播，攻击者凭此获得信息。

2、IP VLAN

IP VLAN类似于MAC VLAN，它同样创建新的虚拟网络接口并为每个接口分配唯一的IP地址，不同之处在于，每个虚拟接口将共享使用物理接口的MAC地址，可以在开启了防止MAC欺骗交换机的上使用，且不需要在物理接口上启用混杂模式。MAC VLAN 和IP VLAN区别如下图所示

补充：关于混杂模式：

网卡工作模式有 4 种, 分别是:

广播 (Broadcast) 模式

多播 (Multicast) 模式

单播模式(Unicast)

混杂模式(Promiscuous).

在混杂模式下的网卡能够接收一切通过它的数据, 而不管该数据目的地址是否是它. 如果通过程序将网卡的工作模式设置为 "混杂模式", 那么网卡将接受所有流经它的数据帧

IP VLAN有L2和L3两种模型：

其中IP VLAN L2的工作模式类似于MAC VLAN Bridge模式，上层接口（物理接口）被用作网桥或交换机，负责为下层接口交换报文；而IP VLAN L3模式中，上层接口扮演路由器的角色，负责为各下层接口路由报文.

L2和L3区别如下：

虽然支持多种网络模型，但MAC VLAN和IP VLAN不能同时在同一物理接口上使用。Linux内核文档中强调，MAC VLAN和IP VLAN具有较高的相似度，因此，通常仅在必须使用IP VLAN的场景中才不使用MAC VLAN。一般说来，强依赖于IP VLAN的场景有如下几个：

• Linux主机连接到的外部交换机或路由器启用了防止MAC地址欺骗的安全策略；
• 虚拟接口的需求数量超出物理接口能够支撑的容量上限，并且将接口置于混杂模式会给性能带来较大的负面影响；
• 将虚拟接口放入不受信任的网络名称空间中可能会导致恶意的滥用

3、直接路由

“直接路由”模型放弃了跨主机容器在L2的连通性，而专注于通过路由协议提供容器在L3的通信方案。这种解决方案因为更易于集成到现在的数据中心的基础设施之上，便捷地连接容器和主机，并在报文过滤和隔离方面有着更好的扩展能力及更精细的控制模型，因而成为容器化网络较为流行的解决方案之一。

一个常用的直接路由解决方案如下图所示，每个主机上的各容器在二层通过网桥连通，网关指向当前主机上的网桥接口地址。跨主机的容器间通信，需要依据主机上的路由表指示完成报文路由，因此每个主机的物理接口地址都有可能成为另一个主机路由报文中的“下一跳”，这就要求各主机的物理接口必须位于同一个L2网络中（host x host y的eth0接口位于一个L2内）。

于是，在较大规模的主机集群中，问题的关键便转向如何更好地为每个主机维护路由表信息。常见的解决方案有：

①Flannel host-gw使用存储总线etcd和工作在每个节点上的flanneld进程动态维护路由；存在的缺点：当K8S集群规模较大时，其维护的路由信息也会很大。相比之下，calio使用BGP协议自动维护路由条目，比fannel以etcd总线上报，查询，更新配置的工作方法更加高效和维护，也更加适用于大型网络。

②Calico使用BGP（Border Gateway Protocol）协议在主机集群中自动分发和学习路由信息。与Flannel不同的是，Calico并不会为容器在主机上使用网桥，而是仅为每个容器生成一对veth设备，留在主机上的那一端会在主机上生成目标地址，作为当前容器的路由条目.

补充：BGP协议：

用于连接不同AS（自治区域），属于外部路由协议（EGP,exterior Gateway Protocol ），是距离矢量路由协议（DV,distance-vector）。DV算法路由器并不了解拓扑结构，类似于路牌。距离矢量路由协议还有：RIP，EIGRP

OSPF和IS-IS是基于链路状态的路由协议（LS，link-state），LS基于最短路径优先算法，类似于地图，需要了解完整的拓扑结构。

关于EGP,IGP（interior Gateway Protocol ）有什么协议见下图：

总结：

Underlay 网络性能优于 Overlay 网络。

Overlay 网络利用隧道技术，将数据包封装到 UDP 中进行传输。因为涉及数据包的封装和解封，存在额外的 CPU和网络开销。虽然几乎所有 Overlay 网络方案底层都采用 Linux kernel 的 vxlan 模块，这样可以尽量减少开销，但这个开销与 Underlay 网络相比还是存在的。所以 Macvlan、Flannel host-gw、Calico 的性能会优于 Docker overlay、Flannel vxlan 和 Weave。

Overlay 较 Underlay 可以支持更多的二层网段，能更好地利用已有网络，以及有避免物理交换机 MAC 表耗尽等优势，所以在方案选型的时候需要综合考虑。

不同环境中所支持的底层能力是不同的。

• 虚拟化环境

（例如 OpenStack）中的网络限制较多，比如不允许机器之间直接通过二层协议访问，必须要带有 IP 地址这种三层的才能去做转发，限制某一个机器只能使用某些 IP 等。在这种被做了强限制的底层网络中，只能去选择 Overlay 的插件，常见的有 Flannel-vxlan, Calico-ipip, Weave 等等；

• 物理机环境

中底层网络的限制较少，比如说我们在同一个交换机下面直接做一个二层的通信。对于这种集群环境，我们可以选择 Underlay 或者路由模式的插件。Underlay 意味着我们可以直接在一个物理机上插多个网卡或者是在一些网卡上做硬件虚拟化；路由模式就是依赖于 Linux 的路由协议做一个打通。这样就避免了像 vxlan 的封包方式导致的性能降低。这种环境下我们可选的插件包括 clico-bgp, flannel-hostgw, sriov 等等；

• 公有云环境

也是虚拟化，因此底层限制也会较多。但每个公有云都会考虑适配容器，提升容器的性能，因此每家公有云可能都提供了一些 API 去配置一些额外的网卡或者路由这种能力。在公有云上，我们要尽量选择公有云厂商提供的 CNI 插件以达到兼容性和性能上的最优。比如 Aliyun 就提供了一个高性能的 Terway 插件。

环境限制考虑完之后，我们心中应该都有一些选择了，知道哪些能用、哪些不能用。在这个基础上，我们再去考虑功能上的需求。

Flannel 我们讨论了两种 backend：vxlan 和 host-gw。vxlan 与 Docker overlay 类似，属于 overlay 网络。host-gw 将主机作为网关，依赖三层 IP 转发，不需要像 vxlan 那样对包进行封装，属于 underlay 网络。Weave 是 VxLAN 实现，属于 overlay 网络。各方案的网络模型描述如下：

  参考：《kubernetes进阶实战》

Overlay和Underlay网络协议区别及概述讲解 - 记忆流年 - 博客园