[Kubernetes]谈谈容器跨主机网络

野性酷女 2022-03-10 09:47 322阅读 0赞

继上篇文章:[\[Kubernetes\]浅谈容器网络][Kubernetes],自己给自己挖的坑,这篇文章来谈谈容器跨主机网络.  
要理解容器"跨主通信"的原理,就要来谈谈 Flannel 这个项目.  
Flannel 项目是 CoreOS 公司主推的容器网络方案.提供容器网络功能的,分别是: VXLAN , host-gw , UDP .  
这三种不同的实现,代表了三种容器跨主机网络的主流实现方法.这里主要讲 VXLAN 和 UDP 模式.  
先从 UDP 模式讲起.

*  假设,我有两台宿主机:  
    
    
     *  宿主机 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 容器里的进程发起的 IP 包,其源地址就是 100.96.1.2 , 目的地址就是 100.96.2.3 .由于目的地址 100.96.2.3 并不在 Node 1 的 docker0 网桥的网段里,所以这个 IP 包会被交给默认路由规则,通过容器的网关进入 docker0 网桥,从而出现在宿主机上.  
    这时候,这个 IP 包的下一个目的地,就取决于宿主机上的路由规则了.此时, Flannel 已经在宿主机上创建出一系列的路由规则,以 Node1 为例,来看一下:
    
        # 在 Node 1 上
        $ ip route
        default via 10.168.0.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
        10.168.0.0/24 dev eth0  proto kernel  scope link  src 10.168.0.2
    
    我们能够看到,由于 IP 包的目的地址是 100.96.2.3 ,它现在匹配不到本机 docker0 网桥对应的 100.96.1.0/24 网段,只能匹配到第二条,也就是 100.96.0.0/16 对应的这条路由规则,从而进入到一个叫作 flannel0 的设备中.这个 flannel0 设备是一个 TUN 设备( Tunnel 设备)  
    在 Linux 中, TUN 设备是一种工作在三层( Network Layer )的虚拟网络设备. TUN 设备的功能非常简单,就是:在操作系统内核和用户应用程序之间传递 IP 包.  
    此时, IP 包根据路由表进入 flannel0 设备后,宿主机上的 flanneld进程,就会收到这个 IP 包,然后根据目的地址将它发送给 Node2 宿主机.  
    那么, flanneld 是如何知道这个 IP 地址对应的容器,是运行在 Node2 上面的呢?
    
    在由 Flannel 管理的容器网络中,一台宿主机上的所有容器,都属于该宿主机被分配的一个"子网",在上面举的例子中, Node1 的子网是 100.96.1.0/24 , container-1 的 IP 地址是 100.96.1.2 . Node2 的子网是 100.96.2.0/24 , container-2 的 IP 地址是 100.96.2.3  
    而这些子网与宿主机的对应关系,保存在 Etcd 中.所以, flanneld 进程在处理 IP 包时,可以根据目的 IP 的地址,匹配到对应的子网,在 Etcd 中找到这个子网对应的宿主机的 IP 地址即可.  
    当然,这个请求得以完成的原因是,每台宿主机上的 flanneld ,都监听着一个 8285 端口,所以 flanneld 只要把 UDP 包发往 Node2 的 8285 端口即可.接下来就是 flanneld 会直接把这个 IP 包发送给它所管理的 TUN 设备,即 flannel0 设备.,此时 Linux 内核网络栈就会负责处理这个 IP 包,根据相关规则,把这个 IP 包转发给 docker0 网桥.接下来的流程大家就清楚了(如果忘记了,可以再回去看看:[\[Kubernetes\]浅谈容器网络][Kubernetes]), docker0 网桥会扮演二层交换机的角色,将数据包发送给正确的端口,进而通过 Veth Pair 设备到 container-2 的 Network Namespace 中.  
    以上就是大概的一个流程.  
    来一张图,看看会不会理解的更好一些:  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70]  
    我们能够看到, Flannel UDP 模式提供的其实是一个三层的 Overlay 网络,即:它首先对发出端的 IP 包进行 UDP 封装,然后在接收端进行解封装拿到原始的 IP 包,进而把这个 IP 包转发给目标容器.  
    但是UDP模式有严重的性能问题,相比于两台宿主机之间的直接通信,基于 Flannel UDP 模式的容器通信多了一个额外的步骤,即 flanneld 的处理过程.因为这个过程中,由于使用到了 flannel0 这个 TUN 设备,所以仅仅在发出 IP 包的这个过程中,就需要经过用户态与内核态之间的数据拷贝,具体如下所示:  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70 1]  
    但是我们在进行系统级编程时,有一个非常重要的优化原则,就是要减少用户态到内核态的切换次数,并且把核心的处理逻辑都放在内核态进行.
    
    基于这个问题,咱们来看看 VXLAN 模式.  
    VXLAN(即 Virtual Extensible LAN 虚拟可扩展局域网),是 Linux 内核本身就支持的一种网络虚拟化技术,因此 VXLAN 完全可以在内核态上实现上述封装和解封装的工作,从而通过与前面类似的"隧道"机制,构建出覆盖网络( Overlay Network ).  
    VXLAN 的覆盖网络的设计思想是:在现有的三层网络上,“覆盖"一层虚拟的,由内核 VXLAN 模块负责维护的二级网络,使得连接在这个 VXLAN 二层网络上的"主机”(虚拟机或者容器都可以)之间,可以像在同一个局域网( LAN )里那样自由通信,当然,实际上这些"主机"可能分布在不同的宿主机上,甚至是分布在不同的物理机房里.而为了能够在二层网络上打通"隧道", VXLAN 会在宿主机上设置一个特殊的网络设备作为"隧道"的两端,这个设备就叫作 VTEP(即: VXLAN Tunnel End Point 虚拟隧道端点). VTEP 设备的作用,和 flanneld 进程非常相似,只是它进行封装和解封装的对象,是二层数据帧,并且这个工作的执行流程,是在内核中完成的.来看一下示意图:  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70 2]  
    图中每台宿主机上名叫 flannel.1 的设备,就是 VXLAN 所需的 VTEP 设备,它既有 IP 地址,也有 MAC 地址.而接下来 Flannel VXLAN 模式的具体工作方式,就和实际网络中工作的方式差不多了.  
    VXLAN 模式组建的覆盖网络,其实就是一个由不同宿主机上的 VTEP 设备,也就是 flannel.1 设备组成的虚拟二层网络,对于 VTEP 设备来说,它发出的"内部数据帧"就仿佛是一直在这个虚拟的二层网络上流动一样,而这也正是「覆盖网络」的含义.
    
    以上内容来自我学习<深入剖析Kubernetes>专栏文章之后的一些见解,有偏颇之处,还望指出.  
    感谢您的阅读~

[Kubernetes]: https://blog.csdn.net/zll_0405/article/details/88375625
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70]: /images/20220310/ced44fb58603454eaf199de4c08f39b2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70 1]: /images/20220310/d8d14fcb3e36465b90b804204b8081d0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70 2]: /images/20220310/c5d39f536f5e44979ec9662dc213c0d0.png