Flannel-UDP在kubernetes中如何工作，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
Kubernetes是用于大规模管理容器化应用程序出色的编排工具。但是，您可能知道，使用kubernetes并非易事，尤其是后端网络实现。我在网络中遇到了许多问题，花了我很多时间弄清楚它是如何工作的。
我想以最简单的实现为例，来解释kubernetes的网络工作。
下图显示了kubernetes集群的简单图像：
Kubernetes管理Linux机器集群（可能是ECS之类的云VM或物理服务器），在每台主机上，kubernetes运行任意数量的Pod，在每个Pod中可以有任意数量的容器。用户的应用程序正在这些容器之一中运行。
对于kubernetes，Pod是最小的管理单元，并且一个Pod中的所有容器共享相同的网络名称空间，这意味着它们具有相同的网络接口并且可以使用*localhost*相互连接
在官方文件中说kubernetes网络模式要求：
我们可以按照上述要求将所有容器替换为Pod，因为容器与Pod网络共享。
基本上，这意味着所有Pod都应该能够与群集中的其他Pod自由通信，即使它们位于不同的主机中，并且它们也使用自己的IP地址相互识别，就像基础主机不存在一样。此外，主机也应该能够使用自己的IP地址与任何Pod通信，而无需任何地址转换。
Kubernetes不提供任何默认的网络实现，而是仅定义模型，并由其他工具来实现。如今有很多实现，Flannel是其中之一，也是最简单的之一。在以下各节中，我将解释Flannel的UDP模式实现。
Flannel是由CoreOS创建的，用于Kubernetes网络，也可以用作其他目的的通用软件定义网络解决方案。
为了满足kubernetes的网络要求，flannel的想法很简单：创建另一个在主机网络之上运行的扁平网络，这就是所谓的覆盖网络overlay network。在此覆盖网络中，所有容器（Pod）将被分配一个IP地址，它们通过直接调用彼此的IP地址来相互通信。
为了帮助解释，我在AWS上使用了一个小型的测试kubernetes集群，该集群中有3个Kubernetes节点。网络如下所示：
此群集中有三个网络：
AWS VPC网络：所有实例都在一个VPC子网中172.20.32.0/19。它们已经在此范围内分配了ip地址，所有主机都可以彼此连接，因为它们位于同一LAN中。
Flannel overlay network：flannel创建了另一个网络100.96.0.0/16，它是一个更大的网络，可以容纳65536个地址，并且遍及所有kubernetes节点，将在此范围内为每个Pod分配一个地址，稍后我们将看到flannel如何实现此目的。
主机内docker网络：在每个主机内部，flannel为该主机中的所有pod分配了一个网络100.96.x.0/24，它可以容纳256地址。docker桥接接口docker0将使用此网络创建新容器。
通过这种设计，每个容器都有其自己的IP地址，都属于覆盖子网100.96.0.0/16。同一主机内的容器可以通过docker bridge网络接口Docker0相互通信，这很简单，因此在本文中我将跳过。为了在主机上与覆盖网络中的其他容器进行跨主机通信，flannel使用内核路由表和UDP封装来实现该功能，以下各节对此进行了说明。
假设具有IP地址的节点1中的容器（我们将其称为容器1）100.96.1.2要使用IP地址连接到节点2中的容器（我们将其称为容器2）100.96.2.3，让我们看看覆盖网络如何启用数据包通过。
第一个container-1使用创建一个IP数据包src: 100.96.1.2 -> dst: 100.96.2.3，该数据包将作为容器的网关进入docker0网桥。
在每个主机中，flannel运行一个名为的守护进程flanneld，它在内核的路由表中创建一些路由规则，这是节点1的路由表的样子：
admin@ip-172-20-33-102:~$ ip route
default via 172.20.32.1 dev eth0
100.96.0.0/16 dev flannel0 proto kernel scope link src 100.96.1.0
100.96.1.0/24 dev docker0 proto kernel scope link src 100.96.1.1
172.20.32.0/19 dev eth0 proto kernel scope link src 172.20.33.102
如我们所见，数据包的目标地址100.96.2.3位于更大的覆盖网络中100.96.0.0/16，因此它与第二条规则匹配，现在内核知道应该将数据包发送到flannel0。
flannel0TUN是由我们的flanneld守护进程创建的TUN设备，TUN是在Linux内核中实现的软件接口，它可以在用户程序和内核之间传递原始ip数据包。它在两个方向上起作用：
flannel0设备时，该数据包将直接发送到内核，内核将根据其路由表对数据包进行路由flannel0设备时，内核会将数据包直接发送到创建该设备的
flanneld进程，该进程是守护进程。当内核将数据包发送到TUN设备时，它将直接进入flanneld进程，它看到目标地址为100.96.2.3，尽管从图中可以看出该地址属于在Node 2上运行的容器，但是如何flanneld知道呢？
Flannel碰巧将某些信息存储在名为etcd的键值存储服务中，如果您知道kubernetes，则不应感到惊讶。在flannel，我们可以将其视为常规键值存储。
Flannel将子网映射信息存储到etcd服务中，我们可以使用以下etcdctl命令查看它：
admin@ip-172-20-33-102:~$ 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
admin@ip-172-20-33-102:~$ etcdctl get /coreos.com/network/subnets/100.96.2.0-24
{"PublicIP":"172.20.54.98"}
因此，每个flanneld进程查询etcd都知道每个子网属于哪个主机，并将目标ip地址与etcd中存储的所有子网密钥进行比较。在本例中，该地址100.96.2.3将与子网匹配100.96.2.0-24，并且如我们所见，存储在此键中的值表示Node ip为172.20.54.98。
现在flanneld知道了目的地址，然后将原始IP数据包包装到UDP数据包中，以其自己的主机ip作为源地址，而目标主机的IP作为目的地址。在每个主机中，该flanneld进程将侦听默认的UDP端口:8285。因此，只需要将UDP数据包的目标端口设置为8285，然后通过网络发送它。
UDP数据包到达目标主机后，内核的IP堆栈会将数据包发送到flanneld进程，因为那是用户进程在UDP端口上侦听:8285。然后flanneld将获得UDP数据包的有效负载，该数据包是由原始容器生成的原始IP数据包，只需将其写入TUN设备flannel0，然后该数据包将直接传递到内核，这就是TUN的工作方式。
与节点1相同，路由表将决定此数据包的去向，让我们看一下节点2的路由表：
admin@ip-172-20-54-98:~$ ip route
default via 172.20.32.1 dev eth0
100.96.0.0/16 dev flannel0 proto kernel scope link src 100.96.2.0
100.96.2.0/24 dev docker0 proto kernel scope link src 100.96.2.1
172.20.32.0/19 dev eth0 proto kernel scope link src 172.20.54.98
IP数据包的目标地址是100.96.2.3，内核将采用最精确的匹配，这是第三条规则。数据包将发送到docker0设备。就像docker0桥接设备一样，此主机中的所有容器都连接到该桥接器，最终目的地容器2将看到并接收到该数据包。
最终，我们的数据包完成了一种传递到目标的方式，当contianer-2将数据包发送回容器1时，反向路由将以完全相同的方式工作。这就是跨主机容器通信的工作方式。
在以上解释中，我们遗漏了一点。这就是我们如何配置docker使用较小的子网100.96.x.0/24？
碰巧flanneld会将其子网信息写入主机中的文件中：
admin@ip-172-20-33-102:~$ cat /run/flannel/subnet.env
FLANNEL_NETWORK=100.96.0.0/16
FLANNEL_SUBNET=100.96.1.1/24
FLANNEL_MTU=8973
FLANNEL_IPMASQ=true
该信息将用于配置docker守护程序的选项，因此docker可以将FLANNEL_SUBNET用作其桥接网络，然后主机容器网络将起作用：
dockerd --bip = $ FLANNEL_SUBNET --mtu = $ FLANNEL_MTU
较新版本的flannel不建议将UDP封装用于生产，它表示仅应将其用于调试和测试目的。原因之一是性能。
尽管flannel0TUN设备提供了一种通过内核获取和发送数据包的简单方法，但它会降低性能：必须将数据包从用户空间来回复制到内核空间：
如上所述，必须从原始容器进程发送数据包，然后在用户空间和内核空间之间复制3次，这将显着增加网络开销，因此，如果可以的话，应避免在生产中使用UDP。
Flannel是kubernetes网络模型的最简单实现之一。它使用现有的Docker网络和带有守护进程的额外Tun设备进行UDP封装。我解释了核心部分的详细信息：跨主机容器通信，并简要提到了性能损失。
看完上述内容，你们掌握Flannel-UDP在kubernetes中如何工作的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
