KubeEdge EdgeMesh v1.15 边缘CNI特性原理及功能详解

作者：达益鑫 |南开大学，刘家伟、吴锟 |DaoCloud，王杰章 |华为云

▍特性研发背景以及原理

KubeEdge EdgeMesh 边缘 CNI 特性针对于边缘容器网络复杂异构环境提供与云上一致的容器网络体验，包括：

1. 云边统一的容器网络资源管理分配

2.基于分布式中继及穿透能力的 PodIP 级别跨子网流量转发服务

特性开发背景

EdgeMesh 致力于研究和解决边缘计算场景下网络连通、服务协同、流量治理等相关的一系列问题，其中在异构复杂的边缘网络环境内，不同物理区域的容器在面对动态变迁的网络环境以及短生命周期且跳跃变迁的服务位置，一部分服务可能需要使用 PodIP 进行跨网段通信，而主流的 CNI 方案主要针对于云上稳定且集成式的网络环境，并不支持跨子网流量的转发，致使这些 CNI 方案并不能够很好地适应边缘复杂异构的环境，最终导致容器即便在同一个集群内却没有享用一个平面的网络通信服务。

针对这个需求，EdgeMesh 进行逐步的优化。首先实现的是网络底层的中继以及穿透服务功能开发，即 EdgeMesh 高可用特性。在分布式网络场景当中，该特性能够为节点提供基于 Service 的中继流量以及网络穿透服务，但还没有完全支持对 PodIP 层次流量的转发和穿透能力。换句话说在云边混合的场景当中 ，EdgeMesh 能够为跨网段的 Service 流量提供穿透服务，但并没有涉足到容器网络的资源管理和 IP 层的连通性功能，仍旧依赖于集群原本的 CNI 方案。

这个局限性导致 EdgeMesh 无法为更加底层的网络 IP 流量提供服务，意味着 EdgeMesh 并不能够完全覆盖混合云边的场景需求，对于那些需要穿透和中继服务的 PodIP 流量，老版本的 EdgeMesh 爱莫能助。

那么为什么主流的 CNI 方案无法兼容边缘环境，EdgeMesh 又是如何理解这个需求的呢？

关键问题在于主流的 CNI 方案大多建立于至少三层可通的环境要求之下，具体来说 CNI 自身管理创建网络资源的时候，并不能够感知底层网络的状态，其管理能力高度依赖于 Kubernetes 系统提供的 Node IP 地址，而这个地址的连通性是由底层的网络设备来维持的，如果宿主机不能通过该 Node IP 访问到目标，那么容器网络的虚拟 IP 就更没有办法联通了，原理也将在下文详述。这也意味着 Kubernetes 系统所给的 Node IP 在边缘这样底层网络并不稳定的环境下无法保障稳定的底层通信服务。

EdgeMesh 基于上述理解，对这个需求进行细化的分析：

• 边缘网络拓扑结构变动性强，且物理隔离场景较多，致使容器网络环境难以呈现出云上那样稳定的底层设施特征，比如边缘环境中自动驾驶场景或者是快递运输场景等。在这样的环境中，物理节点本身并不是绑定固定地址，甚至涉及到 5G 信号核心网注册切换等通信上的流程问题，使得 IP 地址和网络拓扑并不具备完全意义上的寻址能力，通俗说某个节点可能在上一时刻在 A 区域但是过了一会他就行驶到 B 区域了，这样动态变化切换的场景是以往 CNI 架构不曾考虑的。

• CNI 的连通性是基于 Kubernetes 的 Node IP 维持的，更加深入理解这个结论：主流的 CNI 相信 Kubernetes 系统设置的 IP 地址是可以联通的，所以这些主流的 CNI 方案管理虚拟网络往往都使用这样的方法：宿主机操作系统中的一个切换装置，通过让自己作为虚拟网络资源和实际物理网络环境的中继；正如下图所示， CNI 只是通过 k8s 系统，在各个节点上创建了虚假的地址，通过信息协同的方式让拥有这些虚假地址的数据包可以正常在单机节点上传送给目标，但根本还是依赖于 Node IP 可以访问联通，毕竟如果数据包不能够正常到达目标节点，CNI 利用操作系统所作的虚假行为也就没有了意义。反过来说也无法超过于单机操作系统能够管理的网络连通性，多机分布式场景下完全只能够依靠 Kubernetes 系统。

  

  当然，也并非所有的主流 CNI 都只在本机的操作系统内做文章，更加深入解决连通性的 Calico 组件有提供基于 BGP 协议的跨机连接方案，但也围绕着云上数据中心架构展开的。与此相对应的边缘环境中， 节点的 IP 地址是存在着局域性、变动性、不确定性的，可以风趣地说 Kubernetes  系统被节点欺骗了。

• 容器生命周期短暂且不确定，这个特性更像是此类问题的催化剂，使得边缘割裂场景下的网络连接更加难以使用固定的拓扑结构来进行规划管理。

系统设计思路

在本特性初阶段我们确定了此次项目实现的目标：是结合 EdgeMesh 已有的 P2P 功能来提供 CNI 特性， CNI 特性在目前阶段并不意味着开发出完全替代Flannel、Calico、Cilium 等已有架构的完全独立 CNI，而是作为多阶段逐步迭代实现的特性。

一方面从用户角度来说，如果直接替代云上已有的 CNI 架构，会带来额外的部署成本，也无法向用户保证新的架构有足够的价值可以完全覆盖老体系的场景和功能，以项目迭代开发的方式，优先实现一些能力，再慢慢优化、敏捷开发更能符合用户的利益。因而对于云上环境，我们倾向于直接兼容已有的 CNI 架构，使用它们提供的服务，但是补足他们不能够提供的 P2P 功能。

与此同时，现有的 CNI 方案并不能够为边缘复杂异构的环境提供统一的容器网络服务，所以相较于 Docker 或者是其他 CRI 提供的简单网络功能，我们更倾向于直接开发出自己的 CNI 来实现对边缘容器网络资源的管理。

而在上述的 CNI 需求之外，最重要的是如何与 EdgeMesh 的 P2P 服务结合起来；目前的开源社区中实现隧道的技术有：如 VPN，包含 IPSec、Wireguard等；如 P2P，包含 LibP2P 等，结合 EdgeMesh 应对的复杂异构多变边缘环境，我们选用了 LibP2P 技术进行开发。

在此之上需要判断哪些PodIP流量需要 P2P ,哪些流量仍旧使用原本的 CNI 网络服务；再来是将这两部分的功能解耦，以便后期的功能逐步迭代优化，主要的系统架构如下图所示：

上述系统设计将集群内的流量分为两类： 

• 同一网段流量： 指的是底层网络 NodeIP 可通信，Pod 容器流量通过 CNI 转换即可进行通讯。
• 跨网段流量:  指的是底层网络不可直接访问， Pod 容器流量通过 CNI 转换封装也无法到达目标节点。

针对于不同的流量我们提供不同的流量传输方式：

• 对于同一网段的流量：依旧使用主流 CNI 的方案，通过 CNI 转换地址的形式切换虚拟网络和真实网络，连通性依赖 Kubernetes 系统获取的 NodeIP。
• 对于跨网段的流量： 将这部分流量拦截到 EdgeMesh 当中，通过中继或者是穿透的形式转发到目标的节点，此时 EdgeMesh 充当具有 P2P 功能的 CNI 插件，来完成虚拟网络的切换。

这样的设计需要解决亮点重要的问题： 

• 云边集群容器网络资源统一控制管理

边缘节点以及云上节点 CNI 共同管理容器网络资源，使得容器可以分配到集群唯一的 IP地址，且不论云边都可以通过这个 IP 地址进行通信。 

• 云边以及边边跨网段容器网络通信能力

兼容原本 CNI 的通信方式让需要 P2P 的流量跨网段传输。系统设计的关键抉择在于，是否需要将 P2P 的功能放置到 CNI 执行的关键路径当中，或者是将 P2P 的功能与 CNI 架构解耦。

针对于第一个问题，核心关键是 IPAM 插件的设计和兼容，这方面我们倾向于集成开源社区成熟的方案 Siderpool ：

📌 ：https://github.com/spidernet-io/spiderpool Spiderpool 是一个kubernetes 的 underlay 和 RDMA 网络解决方案， 同时也是一款 CNCF Sanbox级别项目

这一方案也更加契合容器网络插件化设计的理念，用户可以依据业务的需求来更改系统组件的组合，在现阶段完全满足多 CNI 统一管理集群资源的设计。

针对第二个问题，核心在于为 CNI 创建的容器网络资源添加跨子网的连通性。方案设计上，如果将中继和穿透的功能放置到 CNI 执行的关键路径中，那就意味着需要在内核中实现中继和穿透的流程，否则将带来巨大的性能消耗。实际上目前 Calico 、 Flannel 、Cilium 等架构在云上使用隧道技术时候就是采用这个方法：在容器资源创建修改的时候，同步修改内核中的网络设备参数，然后对数据包进行封装或者是修改，比如 Vxlan 服务中将目标是其他节点容器的流量拦截，然后添加对协议参数。

这个方式在云上运用较为普遍，但是明显无法适应边缘的环境，原因在于：CNI 执行是无状态且一次性的，只有当容器网络资源创建、修改、删除的时候， CNI 调用链会被触发并执行对应的功能；这个方式的实质是通过静态配置的方式来提供通信服务，对于云上较为稳定的网络环境以及通信条件来说，确实是合适的选择，但对于边缘环境来说，网络资源并非一成不变；如果将隧道信息配置为静态形式，再通过 CNI 调用链触发管理，就无法应对部分容器动态变化之后隧道信息变迁的情况。

在上述考量的基础上，本特性将 分开 CNI 和 P2P 的功能，解耦彼此在系统运作上的依赖关系，这样也更加方便用户可以选择是否开启其中的一项功能。

边缘 CNI 功能

这部分设计为实现基础的 CNI 调用链功能，在边缘节点管理容器网络资源，同时通过 IPAM 组件 spiderpool 兼容云上其他的 CNI 架构，统一分配集群的容器网络资源，包括基础的 CNI 功能，其次是通过 SpiderPool 实现全局的容器 IP 地址唯一。

基于以上各组件设计,当集群内每一个容器都拥有了唯一的 IP 地址，我们接下来需要做的是为需要中继穿透的流量提供服务，设计方式为： 用户配置全局容器网段文件，分为云上 CIDR 和 边缘 CIDR ，每一段 CIDR 对应一个区域网络即 三层不可通的网络， EdgeMesh 通过配置文件插入路由表规则，将目标地址于本节点 CIDR 不相同的流量都拦截到本机的Tun 设备，再传输到 EdgeMesh 的 libP2P  host 通过中继或者穿透的方式传输到目标地址。

您可以通过以下配置的方式，在启动 EdgeMesh 时候启用 CNI 边缘 P2P 特性，配置过程中您可以依据对云边网段资源的划分需求来配置云边容器网络所处的区域：

# 启用 CNI 边缘特性
helm install edgemesh --namespace kubeedge \
--set 
agent.relayNodes[0].nodeName=k8s-master,agent.relayNodes[0].advertiseAddress="{1.1.1.1}" \
--set 
agent.cloudCIDR="{10.244.1.0/24,10.244.1.0/24}",agent.edgeCIDR="{10.244.5.0/24,10.244.6.0/24}"
https://raw.githubusercontent.com/kubeedge/edgemesh/main/build/helm/edgemesh.tgz

上述配置的参数中 cloudCIDR 是云上容器集群分配的地址， edgeCIDR 是边缘容器集群分配的地址；EdgeMesh 会对比部署节点分配到的容器网段 CIDR 与配置文件中是否属于不同网段，属于不同网段的地址会添加对应的 ip route 规则拦截到 Tun 设备。

• cloudCIDR 参数是云上分配的容器网段，类型为 []string ，形式为容器 IP 地址以及其子网掩码，表示一段虚拟网络区域，在区域内的容器应当网络二层可通，如果容器不能够通过二层设备访问，请划分为不同的容器网段。
• edgeCIDR 参数是边缘分配的容器网段，类型为 []string ，形式为容器IP地址以及其子网掩码，表示一段虚拟网络区域，在区域内的容器应当网络二层可通，如果容器不能够通过二层设备访问，请划分为不同的容器网段。

需要注意的是设置的地址必须为 CIDR 形式 ，同时需要您依据云边网络情况划分出对应的网段；另一方面本特性需要同时启动高可用特性，为跨网段的流量提供中继和穿透服务。

更多的安装配置信息请详见：

helm安装 :  https://edgemesh.netlify.app/zh/guide/#helm

项目功能特性介绍

依据系统的设计，边缘 CNI 特性提供以下具体的功能：

• 云边集群容器网络资源控制管理

📌 ：现版本推荐集群云上节点使用 calico/flannel/cilium 等 CNI 插件，同时边缘集群节点使用 EdgeMesh CNI 插件，整个集群配置 SpiderPool 作为统一的地址管理插件来提供服务。

针对于边缘网络复杂异构的情况，EdgeMesh 提供了边缘 CNI 插件来创建和管理边缘节点容器的地址资源，同时通过配合 IPAM 插件 spiderpool 协调云上节点的其他 CNI 插件来实现 整个集群的容器地址唯一，云边节点都可以通过唯一的地址进行通讯。

如下图所示，该项功能的主要特性在于屏蔽了云边复杂的网络集群拓扑，实现了云边集群统一的容器资源管理，使得云边的容器可以体验如同在一个局域网内的通信服务，而不必考虑边缘集群节点容器地址重复或者是云边集群底层地址不通的问题。

• 云边以及边边容器网络通信能力

针对于边缘环境中云边和边缘通信问题，EdgeMesh CNI 特性集成了 P2P 的功能，为跨网络集群的容器流量提供中继和穿透服务。该 P2P 特性现版本主要通过 TUN 设备在 IP 层拦截需要中继和穿透服务的流量实现，能够为应用网络通信提供底层连接的服务，而不受到 IP 层以上网络协议的影响。

系统功能运行如下图所示，在每个节点上的 EdgeMesh  会通过修改 IP Route 的形式拦截流量到 TUN 设备，再传输到 EdgeMesh 的 libP2P  host 通过中继或者穿透的方式传输到目标地址。这个过程中 EdgeMesh 并不会拦截所有的流量而是通过用户在启动时候设置的网络区域参数来区别哪些流量是跨网段，哪些流量是同局域网访问的，并不会干扰到正常同网段流量的通信。

后续计划以及未来设想

在项目开发的初期阶段，系统设计基础实现了最初的需求，但是在边缘容器网络环境当中，由于网路部署和设备架构的使用情况多样复杂，对于容器网络提出了三方面重点的需求：

• 可观测

具体指的是对于云边以及边边流量的去向，包含在节点内操作系统处理的过程以及节点外多节点之间转发传输的流程可观测性。这类需求对于运维人员以及应用开发人员有着非常重要的价值和意义，可以快速定位网络流量问题出现的位置和导致的原因，并快速得出性能优化的方案和解决问题的办法。

• 高性能

与纯云部署的容器集群相似，云边混杂集群同样也面临着性能堪忧的问题，在网络层面主要指的是节点内对网络数据包在操作系统处理路径上的优化，减少其处理的逻辑和相关资源的消耗。

• 强稳定

相较于纯云上集群的部署，云边混杂集群的状态往往难以稳定，需要服务能够应对环境变化同时在出现问题时候较快地将流量卸载到正常的服务当中。

附：KubeEdge社区贡献和技术交流地址

[1] 网站: https://kubeedge.io

[2] Github地址: https://github.com/kubeedge/kubeedge

[3] Slack地址: https://kubeedge.slack.com

[4] 每周社区例会: https://zoom.us/j/4167237304

[5] Twitter: https://twitter.com/KubeEdge

[6] 文档地址: https://docs.kubeedge.io/en/latest/

更多云原生技术动向

关注容器魔方

添加小助手k8s2222进入技术群