深度解析 KubeEdge EdgeMesh 高可用架构
本文分享自华为云社区《KubeEdge EdgeMesh 高可用架构详解|KubeEdge云原生边缘计算社区》，作者：南开大学 达益鑫。
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 时启用高可用特性，配置过程当中您可以依据集群连接的需求配置中继节点的地址：
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 模块运行时会执行以下逻辑：
edgemesh-agent 会读取 configmap 里的中继节点表 relayNodes，检查自己是否被用户设置为中继节点。如果在 relayNodes 中读取到 R2 存在，则表明 R2 被设置为默认初始的中继节点。
R2 节点上的 edgemesh-agent 会尝试成为 relay ，启动对应的中继功能。
如果发现该节点没有中继能力（一般挂载了公网 IP 的节点会具备中继能力），那么该节点还是不能承担起中继节点的角色，造成这个结果的原因可能是该节点的 advertiseAddress 并不能让所有节点访问。
三、课题总结
以上就是 EdgeMesh 高可用架构的原理以及应用场景的介绍了，此次课题结项完成了开源之夏的所有产出要求，也同时作为 KubeEdge v1.12 新版本的一个重要特性发布，非常高兴能够为开源社区及 KubeEdge 的开发和完善做出贡献。
于我个人而言，当初是在测试 5G 边缘架构时认识到了 KubeEdge, 并为其设计以及功能设想所折服，这与我理想的边缘网络智能架构有诸多的相似之处，也成为我参与开源之夏的契机。
在项目开发当中，从功能设计、实现方案到代码编写，各类问题层出不穷，主要是校内知识和研发方式与开源社区及工业环境脱节导致的问题，不过这些困难都在老师社区的帮助和自身努力之下逐一解决了，也是在这个过程当中领我体会到了开源工作中各社区之间相互借鉴推进，各个开发者之间相互帮助交流的强大，也更加理解到优秀的社区环境以及高效的社区例会机制能够快速同步各处开发进度，修正不合理的开发方向和想法，集思广益的同时步步为营，这样让我更加向往社区的工作了。
四、未来展望
就 EdgeMesh 发展设想而言，此次开发已经实现了当初设想的目的，但在参与社区例会，了解整个开源项目的发展之中，许多的想法和创新也随之涌现，是否能够引入 ebpf、Webassembly 等新兴技术来优化甚至是革新 EdgeMesh 提供的网络服务；是否可以将人工智能引入到边缘集群的管理和自治当中，让人工智能作为基础建设的一部分，这些设想都让人热血沸腾，忍不住想要参与到社区的开发和研究当中。
就我个人而言，未来也会更多地参与到社区的开发和研究当中，一方面我原本所期盼的将科研成果转化为产业价值的目标，已通过开源之夏初见眉目；另一方面，诸多的设想和创新还未能够与大家交流，还未能够得到实践和测试；这些都不断鼓励着我更加深入到社区项目的研发当中。
最后非常感谢王杰章老师的悉心教导，可以说老师的耐心沟通和鼓励指导是项目能够成功推进的重要动力；同时还要感谢开源之夏能够给予我们机会参与到实际的开发当中，走出了高校学术的楼阁，尽管此次开源之夏已经结束，但我们的开源之旅却正要开始。
本文作者：南开大学 达益鑫
附：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/
版权声明: 本文为 InfoQ 作者【华为云开发者联盟】的原创文章。
原文链接:【http://xie.infoq.cn/article/098341b1b1d57126837048224】。文章转载请联系作者。
提供全面深入的云计算技术干货 2020-07-14 加入
华为云开发者社区，提供全面深入的云计算前景分析、丰富的技术干货、程序样例，分享华为云前沿资讯动态，方便开发者快速成长与发展，欢迎提问、互动，多方位了解云计算！ 传送门：https://bbs.huaweicloud.com/
评论