来源：容器魔方

EdgeMesh项目解决了边缘计算场景下复杂网络的通信问题，中心化的edgemesh-server作为一个中继组件，协助其他节点进行网络穿透和流量中转。之前的edgemesh-server本身不具备高可用特性，会遇到性能瓶颈与单点故障问题，目前EdgeMesh v1.12版本的高可用架构不仅优化了上述问题，也带来了更加稳定的系统运行时，还覆盖了多种边缘网络的痛点场景，如分布式动态中继连接场景和私有局域网的网络自治场景等。此外，EdgeMesh 在v1.12中还带来了基于PSK密码的安全连接、对接HTTPS的边缘Kube API Endpoint等特性和能力，整体提升了EdgeMesh的性能、稳定性与安全性。

作为开源之夏课题【EdgeMesh：高可用架构的设计与实现 】的实践者，这是我第一次接触开源社区相关的项目，非常有幸能深入地参与到KubeEdge开源项目的开发之中，也非常开心能够参与EdgeMesh高可用特性的方案设计与代码开发。我将通过高可用特性应用场景、高可用特性使用手册、课题总结、未来展望等四个部分的内容来向大家介绍新版本EdgeMesh的高可用架构以及我个人在KubeEdge社区的成长经历。

高可用架构的主要目的是为了保障系统的稳定性以及提升系统的整体性能，此次EdgeMesh的高可用特性在原有功能的基础上还覆盖了多种边缘网络的痛点场景。以下为EdgeMesh高可用特性在边缘计算场景下的具体应用场景，用户可以依据这些用例来理解本特性能提供的服务。

1.1 单点故障以及高负载场景

如图所示，当单个节点承担中继功能时，所有其他的节点都需要连接该节点才能够获取网络连接的服务。在这样的场景当中，单个节点的负载就会相应地增加，过高的通信负载或者是密集的连接数量，在诸多情况下是限制服务性能的主要原因，同时如果该节点出现故障则会导致中继连接断开，使得中继连接功能暂时性停滞。

为了能够优化这部分的问题，覆盖高负载访问场景，EdgeMesh 新版本考量使用分布式网络连接的思想，通过给予每一个节点能够提供中继功能的结构，使每一个节点都具有为其他节点提供中继的能力。

针对这部分场景需求，用户可以在集群初始化时指定多个特定的节点作为默认的中继节点，依据自身情况调节集群内负载的分配，EdgeMesh将会在提供中继服务的时候，优先尝试连接这些节点；如果不做设置，EdgeMesh也会寻找合适的节点执行中继功能，分散减轻单个节点的中继访问负担。

1.2 分布式动态中继连接场景

如图所示，位于上海的边缘应用A和B通过中继互相通信，需要把流量转发到处于北京数据中心里的relay节点，数据传输在远距离的两地之间绕了一圈，导致服务时延较长，用户体验较差。非常遗憾的是，边缘计算场景下集群规模经常横跨多地或者是多区域部署，如果中继节点距离请求服务的节点非常遥远，就会造成极大的延迟，影响用户的体验。这个情况尤其是在中继连接对象与自己不在相邻地理位置下的时候，体现得尤为明显。

为了能够优化这部分的体验，覆盖远距离服务场景，EdgeMesh新版本考量就近中继的原则，用户可以根据集群节点的地理位置分布情况，支持选择一个地理位置适中的relay节点。当应用需要中继连接服务的时候，edgemesh-agent就会动态优先选择就近的relay节点作为中继来提供网络连接服务，以此缩短中继服务的时延。

1.3 私有局域网网络自治场景

如图所示，在老版本的EdgeMesh的代码实现中，edgemesh-agent必须保持与云上中继服务edgemesh-server的连接，当局域网内的节点离线后，导致edgemesh-agent断开与中继节点的连接，断连节点上的服务就彻底失去流量代理的能力了，这在部分私有局域网网络内或者是网络情况波动较大的环境当中会给用户造成较大的困扰。

为了能够优化这部分的问题，提高网络应用连接的稳定性，EdgeMesh 新版本考量了分布式管理及网络自治的想法，让EdgeMesh能够通过mDNS机制保障私有局域网网络内或者是离线局域网内节点之间的相互发现和转发流量，维持应用服务的正常运转。

针对这部分场景需求，用户并不需要再单独设置任何的参数来启用此功能，该功能一般面对两种情形进行服务维持：

a. 在刚部署EdgeMesh的时候，部分节点就已经在私有局域网下，那这个局域网内的节点依旧可以通过EdgeMesh来相互之间访问和转发流量。

b. 在集群正常运转过程当中，部分节点离线后，这部分节点依旧可以通过EdgeMesh来维持相互之间的网络连接和流量转发。

2.1 基本原理介绍

在EdgeMesh v1.12版本中，社区将edgemesh-server的能力合并到了edgemesh-agent的EdgeTunnel模块当中，使得具备中继能力的edgemesh-agent能够自动成为中继服务器，为其他节点提供内网穿透和中继转发的功能，新老系统架构对比如下：

EdgeMesh高可用特性的主要实现原理是：当集群内有节点具备中继能力时，其上的edgemesh-agent会承担起中继节点的角色，来为其他节点提供内网穿透和流量中继转发的服务。在集群初始化或者是有节点新加入集群时，EdgeMesh系统会基于mDNS机制发现局域网内的节点并作记录，同时DHT机制会发现跨局域网的其他节点并对其发起连接建立请求，这样当集群内跨局域网的两节点需要连接的时候，中继节点就可以为它们提供流量中继和协助内网穿透的服务。

EdgeMesh高可用特性的核心功能如上图所示，集群当中A节点与B节点通过R1中继节点连接来提供服务，当R1节点无法提供中继服务的时候，A、B节点可以通过高可用特性自动切换到中继节点R2并重新建立连接。在这个过程当中用户几乎感受不到网络连接的变化。

接下来我将简单介绍不同情况下使用EdgeMesh高可用特性的方式。

2.2 部署时启用高可用特性

您可以通过以下配置方法，在安装EdgeMesh时启用高可用特性，配置过程当中您可以依据集群连接的需求配置中继节点的地址：

# 启用高可用特性

helm install edgemesh --namespace kubeedge \

--set agent.relayNodes[0].nodeName=k8s-master,agent.relayNodes[0].advertiseAddress="{1.1.1.1}" \

https://raw.githubusercontent.com/kubeedge/edgemesh/main/build/helm/edgemesh.tgz

·relayNodes 参数是中继节点表，类型为 []relayNode，您可以通过配置它来指定集群中应该承担中继节点角色的edgemesh-agent。

·relayNode.nodeName 参数使用节点名的方式来指定relay节点，这必须与K8s的节点名相同，您可以通过 kubectl get nodes 查看您的k8s节点名。

·relayNode.advertiseAddress 参数用于指定relay节点的地址，其应当与节点在K8s集群当中的节点地址一致, 如果您购买了公有云的公网IP并挂载到此relay节点上，则 relayNode.advertiseAddress 参数最好应该填写该公网IP地址。

需要注意的是：设置中继节点的数量由 relayNodes[num] 中索引值 num 来规定，num 取值从 0 开始，relayNodes[0] 表示中继节点1。

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

helm安装：

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

手动安装：

https://edgemesh.netlify.app/zh/guide/

2.3 运行时添加新中继节点

如果您在使用EdgeMesh高可用特性时，想要在集群当中添加新的中继节点，可以通过修改 edgemesh-agent-cfg 当中的 relayNodes 参数来达到目的，以下为具体修改配置的方式：

之后您可以使用 kubeadm join 或者 keadm join 添加加新的中继节点R2，接着通过以下操作查看添加的中继节点是否正常运行：

2.4 运行时转化节点成中继

如果您在集群运行过程当中，想要将一些已有节点转化为中继节点，只需要修改 edgemesh-agent-cfg 当中的 relayNodes 参数即可, 以下为具体修改配置的方式：

修改完此配置后，需要重启R2节点（转化节点）上的edgemesh-agent。在这个过程当中，假设新设置的节点有中继能力，那么在重新Tunnel模块运行时会执行以下逻辑：

1.edgemesh-agent会读取configmap里的中继节点表relayNodes，检查自己是否被用户设置为中继节点。如果在relayNodes中读取到R2存在，则表明R2被设置为默认初始的中继节点。

2. R2节点上的edgemesh-agent会尝试成为relay ，启动对应的中继功能。

3. 如果发现该节点没有中继能力（一般挂载了公网IP的节点会具备中继能力），那么该节点还是不能承担起中继节点的角色，造成这个结果的原因可能是该节点的advertiseAddress并不能让所有节点访问。

以上就是EdgeMesh高可用架构的原理以及应用场景的介绍了，此次课题结项完成了开源之夏的所有产出要求，也同时作为KubeEdge v1.12新版本的一个重要特性发布，非常高兴能够为开源社区及KubeEdge的开发和完善做出贡献。

于我个人而言，当初是在测试5G边缘架构时认识到了KubeEdge, 并为其设计以及功能设想所折服，这与我理想的边缘网络智能架构有诸多的相似之处，也成为我参与开源之夏的契机。

在项目开发当中，从功能设计、实现方案到代码编写，各类问题层出不穷，主要是校内知识和研发方式与开源社区及工业环境脱节导致的问题，不过这些困难都在老师社区的帮助和自身努力之下逐一解决了，也是在这个过程当中领我体会到了开源工作中各社区之间相互借鉴推进，各个开发者之间相互帮助交流的强大，也更加理解到优秀的社区环境以及高效的社区例会机制能够快速同步各处开发进度，修正不合理的开发方向和想法，集思广益的同时步步为营，这样让我更加向往社区的工作了。

就EdgeMesh发展设想而言，此次开发已经实现了当初设想的目的，但在参与社区例会，了解整个开源项目的发展之中，许多的想法和创新也随之涌现，是否能够引入ebpf、Webassembly等新兴技术来优化甚至是革新EdgeMesh提供的网络服务；是否可以将人工智能引入到边缘集群的管理和自治当中，让人工智能作为基础建设的一部分，这些设想都让人热血沸腾，忍不住想要参与到社区的开发和研究当中。

就我个人而言，未来也会更多地参与到社区的开发和研究当中，一方面我原本所期盼的将科研成果转化为产业价值的目标，已通过开源之夏初见眉目；另一方面，诸多的设想和创新还未能够与大家交流，还未能够得到实践和测试；这些都不断鼓励着我更加深入到社区项目的研发当中。

 最后非常感谢王杰章老师的悉心教导，可以说老师的耐心沟通和鼓励指导是项目能够成功推进的重要动力；同时还要感谢开源之夏能够给予我们机会参与到实际的开发当中，走出了高校学术的楼阁，尽管此次开源之夏已经结束，但我们的开源之旅却正要开始。

本文作者：

南开大学 达益鑫 2374087322@qq.com  

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

KubeEdge网站 : https://kubeedge.io

GitHub地址 : https://github.com/kubeedge/kubeedge

Slack地址 :https://kubeedge.slack.com

邮件列表 : https://groups.google.com/forum/#!forum/kubeedge

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

Twitter : https://twitter.com/KubeEdge

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