1. 概述
容器技术的兴起为应用部署和运行带来了极大的便利，但同时也给网络通信带来了新的挑战。在传统的单机环境下，容器之间的网络通信相对简单，通常通过Docker默认的网桥模式就可以实现。然而，当我们将容器部署到分布式的集群环境中时，跨主机的容器网络通信就成为了一个亟待解决的问题。
在Docker的默认配置下，不同宿主机上的容器是无法直接通过IP地址进行互相访问的。这是因为每个宿主机上的Docker网络都是独立的，它们各自管理着自己的私有网段。这种隔离虽然在安全性方面有所裨益，但也阻碍了容器之间的直接通信。
为了解决这个"跨主通信"的难题，容器社区提出了多种网络方案。这些方案的核心目标是在不同宿主机上的容器之间建立一个虚拟的网络，使得它们能够像在同一个局域网内一样进行通信。这就是所谓的"覆盖网络"（Overlay Network）技术。
实现覆盖网络面临着诸多技术挑战：首先，需要在不同的宿主机之间建立某种形式的"隧道"，以便容器的网络数据包能够穿越宿主机网络；其次，需要设计一种机制来管理和分配容器的IP地址，确保在整个集群范围内不会发生地址冲突；再者，还需要考虑如何处理容器的动态创建和销毁，以及如何保证网络性能和安全性。
在众多的容器网络方案中，Flannel项目脱颖而出，成为了解决这些挑战的一个重要尝试。Flannel提供了多种网络模式，其中UDP模式和VXLAN模式是两种典型的实现。这两种模式都试图通过不同的技术手段，在现有的物理网络之上，构建一个虚拟的、跨主机的容器网络。
UDP模式通过在用户态进行数据包的封装和解封装，实现了一个简单直接但性能较低的解决方案。而VXLAN模式则利用了Linux内核提供的网络虚拟化技术，在内核态完成数据包的处理，从而大幅提升了网络性能。
这些网络方案的出现，不仅解决了容器跨主机通信的问题，还为构建大规模容器集群奠定了基础。它们使得我们可以将容器视为一个个独立的计算单元，而不必过多关心它们的物理位置，从而极大地提高了系统的灵活性和可扩展性。
然而，每种网络方案都有其特定的适用场景和局限性。选择合适的容器网络方案，需要我们理解其工作原理，权衡各种因素，如性能、复杂度、可维护性等。只有这样，才能在实际的生产环境中构建出高效、可靠的容器网络。
2. Flannel 项目简介
2.1 Flannel 的三种后端实现
Flannel 项目作为一个容器网络方案的框架，其核心功能由不同的后端实现提供。目前，Flannel 支持三种主要的后端实现，分别是 VXLAN、host-gw 和 UDP。这三种实现方式代表了容器跨主网络的主流实现方法。
VXLAN（Virtual Extensible LAN）是 Linux 内核原生支持的网络虚拟化技术。它通过在现有的三层网络上覆盖一层虚拟的二层网络，实现了跨主机的容器通信。VXLAN 模式能够在内核态完成封装和解封装工作，因此性能较好，逐渐成为了主流的容器网络方案。
host-gw（host gateway）模式是一种直接利用宿主机作为网关的实现方式。它通过在各个宿主机上添加路由规则，将目标容器所在宿主机的 IP 地址设置为网关，从而实现容器跨主机通信。这种模式性能较高，但要求所有宿主机都在同一个二层网络内。
UDP 模式是 Flannel 最早支持的一种实现方式。它通过在用户态将容器间通信的数据包封装在 UDP 包中进行传输。虽然实现简单直观，但由于涉及频繁的用户态与内核态切换，以及数据的多次拷贝，导致性能较差。因此，UDP 模式目前已被弃用。
这三种后端实现各有特点：
- VXLAN 模式兼顾了性能和通用性，适用于大多数场景。
- host-gw 模式在特定网络环境下可以提供最佳性能。
- UDP 模式虽然性能较差，但其简单的实现原理有助于理解容器网络的基本概念。
Flannel 通过提供这些不同的后端实现，使得用户可以根据自己的网络环境和性能需求选择最适合的方案。在实际部署时，VXLAN 和 host-gw 是更为常见的选择，而 UDP 模式主要用于学习和调试目的。
2.2 Flannel 的其他网络模式简介
除了前面介绍的UDP和VXLAN模式外，Flannel还支持其他几种网络模式，以适应不同的网络环境和性能需求。本节将详细介绍这些模式的工作原理、优缺点及适用场景。
2.2.1 host-gw 模式
host-gw（host gateway）模式是Flannel提供的一种高性能网络模式。在这种模式下，Flannel不再使用覆盖网络，而是直接利用宿主机作为网关来转发跨主机的容器流量。
【工作原理】：当容器需要与其他宿主机上的容器通信时，数据包会先发送到本机的网桥设备。然后，根据路由表，数据包会被转发到目标容器所在的宿主机。目标宿主机接收到数据包后，再将其转发给目标容器。
【优点】：
- 性能高：由于不需要额外的封装和解封装过程，host-gw模式的性能接近于原生网络。
- 配置简单：不需要额外的网络设备或协议支持。
缺点：
- 要求所有宿主机在同一个二层网络：这限制了其在跨数据中心或云环境中的应用。
- 路由表膨胀：随着节点数量的增加，每个节点上的路由表会变得很大。
【适用场景】：host-gw模式特别适合于所有宿主机都在同一个二层网络的场景，例如小型到中型的单数据中心部署。
2.2.2 IPIP 模式
IPIP（IP in IP）模式是一种简单的IP封装协议。在这种模式下，Flannel使用IPIP隧道来封装和传输容器流量。
工作原理：当跨主机的容器通信时，源宿主机会将原始的IP数据包封装在另一个IP数据包中。外层IP包的源地址是源宿主机的IP，目的地址是目标容器所在宿主机的IP。当目标宿主机收到这个封装的数据包时，会解封装出原始的IP包，然后转发给目标容器。
这个过程可以用以下图表示：
【优点】：
- 简单：IPIP协议相对简单，易于实现和理解。
- 兼容性好：可以穿越不支持VXLAN的网络。
【缺点】：
- 性能开销：虽然比UDP模式好，但仍有一定的封装开销。
- MTU问题：IPIP封装会减小有效载荷的MTU，可能需要进行MTU调整。
适用场景：IPIP模式适合于需要跨越不同子网或数据中心的场景，特别是在底层网络不支持VXLAN的情况下。
2.2.3 Alloc 模式
Alloc模式是一种特殊的网络模式，它实际上并不提供数据平面功能。在这种模式下，Flannel只负责分配子网，而不负责数据包的转发。
【工作原理】：Flannel为每个节点分配一个子网，但不创建任何隧道或执行任何封装。网络管理员需要自行配置适当的路由规则来实现跨节点通信。
【优点】：
- 灵活性高：网络管理员可以完全控制数据包的路由方式。
- 无额外开销：由于Flannel不参与数据转发，所以没有额外的性能开销。
【缺点】：
- 配置复杂：需要手动配置路由规则，增加了管理难度。
- 可能需要额外的网络设备支持：根据具体的路由方案，可能需要配置交换机或路由器。
适用场景：Alloc模式适合于对网络控制要求较高的场景，或者已经有成熟的网络方案，只需要Flannel来协助进行IP地址管理的情况。
2.2.4 AWS VPC 模式
AWS VPC模式是专门为Amazon Web Services（AWS）环境设计的网络模式。它利用AWS的VPC路由表来实现容器网络。
工作原理：Flannel会为每个节点分配一个子网，然后更新AWS VPC路由表，将这个子网的流量路由到对应的EC2实例。当容器需要跨节点通信时，数据包会根据VPC路由表直接发送到目标节点。
这个过程可以用以下图表示：
【优点】：
- 性能好：直接利用AWS的网络基础设施，无需额外的封装。
- 集成度高：与AWS服务紧密集成，便于管理和监控。
【缺点】：
- 特定于AWS：不能在其他云平台或本地数据中心使用。
- 可能增加AWS的网络费用：频繁更新路由表可能会产生额外的费用。
【适用场景】：AWS VPC模式专门适用于在AWS上部署Kubernetes集群的场景，特别是对网络性能有较高要求的应用。
通过提供这些不同的网络模式，Flannel展现了其设计的灵活性和适应性。网络管理员可以根据具体的部署环境、性能需求和管理便利性来选择最适合的模式。理解这些模式的工作原理和特点，对于优化容器网络性能、解决网络问题以及设计大规模容器部署方案都有重要意义。
3. UDP 模式工作原理
3.1 跨主机容器通信示例
为了理解Flannel的UDP模式工作原理，我们来看一个具体的跨主机容器通信示例。假设我们有两台宿主机：Node 1和Node 2，其中：
- 在Node 1上，我们有一个名为container-1的容器，其IP地址为
100.96.1.2。对应的docker0网桥地址是100.96.1.1/24。 - 在Node 2上，我们有另一个名为container-2的容器，其IP地址为
100.96.2.3。对应的docker0网桥地址是100.96.2.1/24。
现在，我们的任务是让container-1能够访问container-2。
当container-1发起对container-2的访问请求时，数据包的流动过程如下：
- container-1发出一个IP包，源地址为
100.96.1.2，目的地址为100.96.2.3。 - 这个IP包首先到达Node 1的docker0网桥。由于目的地址100.96.2.3不在docker0网桥的网段内，所以这个IP包会被转发给默认路由。
- 根据Node 1上的路由规则，这个IP包会被送往一个名为flannel0的设备。flannel0是一个TUN设备，它在三层网络上工作。
- flannel0设备会将这个IP包交给用户态的flanneld进程处理。
- flanneld进程通过查询Etcd，得知目的IP地址
100.96.2.3所在的子网对应的宿主机是Node 2，其IP地址为10.168.0.3。 - flanneld将原始的IP包封装在一个UDP包里，然后发送给Node 2的8285端口（flanneld默认监听的端口）。
- 当这个UDP包到达Node 2后，会被Node 2上的flanneld进程接收和解包，还原出原始的IP包。
- Node 2的flanneld将还原出的IP包交给本机的flannel0设备。
- flannel0设备将IP包转发给docker0网桥。
- docker0网桥根据目的IP地址，将包转发给container-2。
通过这个过程，Flannel在不同宿主机上的两个容器之间建立了一个"隧道"，使得它们可以直接使用IP地址进行通信，而无需关心容器和宿主机的具体分布情况。
这种UDP封装的方式虽然实现了跨主机的容器通信，但由于涉及多次用户态与内核态的切换，以及数据的多次拷贝，因此性能较差。这也是为什么UDP模式后来被VXLAN等更高效的模式所取代的原因。
3.2 路由规则和 TUN 设备
在Flannel的UDP模式中，路由规则和TUN设备扮演着关键角色，它们共同构建了容器跨主机通信的基础架构。
首先，让我们来看看Flannel在宿主机上创建的路由规则。以Node 1为例，我们可以通过以下命令查看路由表：
ip route
输出可能如下所示：
default via 10.168.0.1 dev eth0 100.96.0.0/16 dev flannel0 proto kernel 100.96.1.0/24 dev docker0 proto kernel 10.168.0.0/24 dev eth0 proto kernel
这些路由规则的含义如下：
- 默认路由指向宿主机的物理网卡eth0。
- 目的地址为100.96.0.0/16网段的数据包会被发往flannel0设备。
- 目的地址为100.96.1.0/24网段的数据包会被发往docker0网桥。
- 目的地址为10.168.0.0/24网段的数据包会被发往eth0网卡。
当容器发出的数据包到达宿主机时，Linux内核会根据这些路由规则决定数据包的下一步去向。对于跨主机通信的情况，数据包会被路由到flannel0设备。
flannel0是一个TUN设备，它是Linux内核提供的一种虚拟网络设备。TUN设备的特殊之处在于它工作在网络层（第三层），主要用于处理IP数据包。当一个IP数据包被发送到TUN设备时，它不会被转发到物理网络，而是被递交给创建该设备的用户空间程序。
在Flannel的架构中，flannel0设备与用户空间的flanneld进程紧密配合。它们之间的工作流程如下：
- 当一个IP数据包被路由到flannel0设备时，Linux内核将这个数据包从内核空间传递到用户空间的flanneld进程。
- flanneld进程接收到这个IP数据包后，会根据数据包的目的IP地址查询Etcd，确定目标容器所在的宿主机。
- 然后，flanneld将原始的IP数据包封装在一个UDP包中，并将这个UDP包发送到目标宿主机。
- 在目标宿主机上，flanneld进程接收到UDP包后，解封装出原始的IP数据包，并将其写入本机的flannel0设备。
- 目标宿主机的Linux内核接收到这个IP数据包，然后根据本机的路由规则将其转发到正确的容器。
这种设计允许Flannel在不修改Linux内核的情况下，实现了跨主机的容器通信。TUN设备充当了用户空间和内核空间之间的桥梁，使得flanneld可以接管容器间通信的路由过程。
然而，这种设计也带来了性能上的开销。每个数据包都需要经过多次用户空间和内核空间的切换，以及多次数据拷贝，这inevitably会影响网络性能。这也是为什么Flannel的UDP模式虽然实现简单，但在实际生产环境中较少使用的原因。
尽管如此，UDP模式为我们展示了容器网络方案需要解决的核心问题，以及解决这些问题的基本思路。这为理解更高效的网络方案，如VXLAN模式，奠定了基础。
3.3 子网概念和 Etcd 存储
在Flannel的网络架构中，子网（Subnet）是一个核心概念。每台宿主机都被分配一个独立的子网，该子网内的所有容器都属于这个子网。这种设计使得容器网络的管理变得更加简单和高效。
在我们之前的例子中，Node 1的子网是100.96.1.0/24，而Node 2的子网是100.96.2.0/24。这意味着Node 1上的所有容器都会获得100.96.1.0/24网段内的IP地址，而Node 2上的所有容器则会获得100.96.2.0/24网段内的IP地址。
Flannel使用Etcd作为分布式存储系统来保存这些子网信息。Etcd是一个高可用的键值存储系统，它在Flannel的网络方案中扮演着重要角色。Flannel将子网与宿主机的对应关系存储在Etcd中，这样集群中的所有节点都可以获取到这些信息。
我们可以通过以下命令来查看Etcd中存储的子网信息：
etcdctl ls /coreos.com/network/subnets
输出可能如下所示：
/coreos.com/network/subnets/100.96.1.0-24 /coreos.com/network/subnets/100.96.2.0-24 /coreos.com/network/subnets/100.96.3.0-24
这个输出显示了当前集群中所有已分配的子网。每个子网都对应一个宿主机。
我们可以进一步查看某个具体子网的详细信息：
etcdctl get /coreos.com/network/subnets/100.96.2.0-24
输出可能如下所示：
{"PublicIp":"10.168.0.3"}
这个输出告诉我们，子网100.96.2.0/24对应的宿主机的公网IP地址是10.168.0.3。
Flannel的flanneld进程会定期从Etcd中读取这些信息，并据此更新本机的路由表和ARP表。当一个容器需要与另一个宿主机上的容器通信时，flanneld就可以根据这些信息来确定目标容器所在的宿主机，并正确地封装和转发数据包。
这种基于Etcd的子网管理方式有几个显著的优点：
动态性：当新的宿主机加入集群或现有宿主机离开集群时，子网分配信息可以动态更新。
一致性：所有节点都可以从Etcd获取到一致的网络拓扑信息，确保了整个集群网络配置的一致性。
可扩展性：这种方式可以轻松支持大规模集群，因为Etcd本身就是为高可用和大规模设计的。
灵活性：通过修改Etcd中的数据，可以灵活地调整网络配置，而无需重启整个集群。
然而，这种设计也带来了一些挑战。最主要的是，Etcd成为了整个网络的一个关键依赖。如果Etcd集群出现问题，可能会影响到整个容器网络的正常运行。因此，在生产环境中，通常需要部署高可用的Etcd集群，并定期进行备份。
总的来说，Flannel通过Etcd存储子网信息的方式，巧妙地解决了容器跨主机通信时的寻址问题。这为实现高效的容器网络奠定了基础，也为后续的VXLAN等更高效的网络模式提供了必要的支持。
3.4 UDP 封装和解封装过程
在Flannel的UDP模式中，封装和解封装过程是实现容器跨主机通信的核心。这个过程涉及到数据包在不同网络层之间的转换，以及在宿主机之间的传输。理解UDP模式的封装和解封装过程对于理解容器网络的工作原理非常有帮助。它为我们展示了容器网络方案需要解决的核心问题，以及解决这些问题的基本思路。这为理解更高效的网络方案，如VXLAN模式，奠定了基础。让我们详细探讨UDP模式中，封装和解封装过程的过程。
首先，当源容器（例如container-1）发送一个数据包到目标容器（例如container-2）时，这个原始的IP数据包会经过docker0网桥，然后根据路由规则被转发到flannel0设备。flannel0作为一个TUN设备，会将这个数据包从内核空间传递到用户空间的flanneld进程。
flanneld进程接收到这个原始IP数据包后，会进行UDP封装。封装过程包括以下步骤：
flanneld首先检查数据包的目的IP地址，确定目标容器所在的宿主机。
flanneld然后创建一个新的UDP数据包。这个UDP数据包的源IP地址是当前宿主机的IP地址，目的IP地址是目标容器所在宿主机的IP地址。UDP端口通常是8285。
原始的IP数据包被放入这个UDP数据包的负载部分。
flanneld将封装好的UDP数据包交给宿主机的网络栈，由宿主机的网络栈负责将这个UDP包发送出去。
这个封装过程可以用以下伪代码表示：
原始IP包 = 从flannel0接收() 目标宿主机IP = 查询Etcd(原始IP包.目的IP) UDP包 = 创建UDP包( 源IP=本机IP, 目的IP=目标宿主机IP, 源端口=随机端口, 目的端口=8285, 负载=原始IP包 ) 发送(UDP包)
当封装好的UDP包到达目标宿主机后，解封装过程开始。这个过程基本上是封装过程的逆操作：
- 目标宿主机的网络栈接收到UDP包，发现目的端口是8285，于是将这个包交给监听在8285端口的flanneld进程。
- flanneld进程接收到UDP包后，从UDP包的负载中提取出原始的IP数据包。
- flanneld将提取出的原始IP包写入本机的flannel0设备。
- Linux内核接收到这个IP包，根据路由规则将其转发给docker0网桥。
- docker0网桥根据IP包的目的地址，将包转发给目标容器。
这个解封装过程可以用以下伪代码表示：
UDP包 = 从8285端口接收() 原始IP包 = 提取负载(UDP包) 写入flannel0(原始IP包)
通过这种封装和解封装的过程，Flannel实现了容器跨主机通信。原始的IP包被封装在UDP包中，利用宿主机网络进行传输，然后在目标宿主机上被解封装，最终送达目标容器。
然而，这个过程也带来了性能开销。每次通信都需要进行封装和解封装，涉及到用户空间和内核空间的多次切换，以及数据的多次拷贝。这就是为什么UDP模式在实际生产环境中较少使用，而更多地被用于学习和调试目的。
3.5 UDP 模式的性能问题分析
UDP模式的简单性和直观性使其成为理解容器网络原理的良好起点。通过分析UDP模式的性能问题，我们可以更好地理解容器网络面临的挑战，以及为什么需要更高效的网络实现方式。这种理解对于设计和优化容器网络至关重要。Flannel的UDP模式虽然实现简单直观，但在实际应用中存在严重的性能问题。这些问题主要源于其工作原理和实现方式。
UDP模式的主要性能问题来自于频繁的用户态和内核态切换。在UDP模式下，每个数据包都需要经历多次用户态和内核态之间的切换。当一个数据包从容器发出时，它首先在内核态被路由到flannel0设备。然后，flannel0作为一个TUN设备，将数据包从内核态传递到用户态的flanneld进程。flanneld进程在用户态对数据包进行封装后，再将封装后的数据包传回内核态进行发送。在接收端，这个过程会再次重复。这种频繁的状态切换会带来显著的性能开销。
其次，UDP模式涉及多次数据拷贝。每次在用户态和内核态之间传递数据时，都需要进行一次内存拷贝。这不仅增加了处理延迟，还消耗了额外的CPU资源和内存带宽。在高吞吐量的场景下，这些额外的数据拷贝可能会成为严重的性能瓶颈。
另外，UDP封装本身也会引入额外的开销。每个原始IP包都需要被封装到一个UDP包中，这增加了数据包的大小，从而降低了网络的有效载荷比例。这种开销在传输大量小数据包时尤为明显。
此外，UDP模式依赖于用户态的flanneld进程来处理所有的网络流量。这意味着所有的网络操作都需要经过这个单一的进程，可能会成为性能瓶颈，尤其是在高并发的情况下。
为了更直观地理解UDP模式的性能问题，我们可以分析一个数据包在发送过程中的处理步骤：
Container
Kernel
Flannel0
Flanneld
UDP
Network
发送IP包
路由到Flannel0
传递到用户态
UDP封装
传递回内核态
发送UDP包
Container
Kernel
Flannel0
Flanneld
UDP
Network
从这个流程图中我们可以清楚地看到，一个简单的数据包发送过程涉及多次用户态和内核态的切换，以及多次数据拷贝。
这些性能问题在实际应用中的表现可能如下：
- 较高的网络延迟：由于每个数据包都需要经过多次处理和状态切换，网络延迟会显著增加。
- CPU使用率升高：频繁的状态切换和数据拷贝会消耗大量的CPU资源。
- 吞吐量受限：由于单个flanneld进程需要处理所有流量，在高并发情况下可能会成为瓶颈。
- 内存带宽压力：多次数据拷贝会增加内存带宽的使用。
- 网络效率降低：UDP封装增加了数据包大小，降低了网络的有效载荷比例。
正是由于这些性能问题，UDP模式在实际生产环境中很少被使用。相比之下，VXLAN模式通过在内核态实现封装和解封装，大大减少了用户态和内核态的切换，同时也减少了数据拷贝的次数，因此能够提供更好的性能。
容器跨主机通信：Flannel网络实现机制分析（二）：https://developer.aliyun.com/article/1582133
