边缘计算场景下Service Mesh的延伸和扩展
在KubeCon2021上，华为云云原生技术开发工程师王杰章发表了《边缘计算场景下Service Mesh的延伸和扩展》主题演讲，分享了KubeEdge EdgeMesh的项目概况。
王杰章 @Poorunga
KubeEdge Member&EdgeMesh Maintainer
云原生、边缘计算技术爱好者
演讲主要包含4个部分的内容：
1）边缘计算场景下的网络挑战
2）EdgeMesh项目概况、架构、核心能力
3）EdgeMesh性能测试
4）EdgeMesh RoadMap
以下为演讲全文
首先，来了解下云原生容器网络，云原生容器网络总共经历了3个阶段：
第一阶段：Docker 容器网络，在Docker出现之后，也有自己的4种容器网络模型，比如Host模式、Content模式，None模式以及 Bridge模式。但原生Docker容器无法解决容器之间的跨级通信问题，后来Docker推出CNM以及对应的实现libnetwork解决了这个问题。
第二阶段：容器网络接口(CNI), 后来由于各种原因Kubernetes主推的CNI热度反超了CNM，CNI是一个接口更简单、而且兼容性更高的容器网络接口规范。
第三阶段: 服务网格 + CNI, 随着服务网络的发展，它与CNI进行了配合，一些服务网格的插件，会在每个pod启动时往pod里注入Sidecar代理，来提供4层或7层的流量治理功能。
Kubernetes服务发现
Kubernetes服务发展其实与容器网络是依赖的关系，首先用户会通过deployment创建一组应用的后端实例对其进行管理。但pod的生命周期是非常短暂的，可能会随着pod更新升级或迁移等，它的Pod IP都会发生变化，这个现象称之为Pod IP的漂移。
为了解决这个问题, Kubernetes社区提出了service的概念，每个service都会对应到一组后端的一个应用实例上，通过提供恒定不变的Cluster IP来解决Pod IP漂移的问题，同时也提供了proxy组件，基于控制面提供的一些信息维护Cluster IP到Pod IP的转换规则。当client需要访问该服务时，一般只需要访问这个不变的Cluster IP即可。这个流量会经过本机的网络栈，被替换成了mysql后端实例的Pod IP，通过容器网络请求发送。
边缘场景中的关键挑战
1）边缘计算细分领域众多，互操作性差
2）边云通信网络质量低，时延高，且边缘经常位于私有网络，难以实现双向通信
3）边缘资源受限，需要轻量化的组件管理运行边缘应用
4）边缘离线时，需要具备业务自治和本地故障恢复等能力
5）边缘节点高度分散，如何高效管理，降低运维成本
6）如何对异构资源进行标准化管理和灵活配置
以上这些关键挑战，边缘计算平台KubeEdge均可以实现，也解决了基本上所有的问题。但除了这些问题外，还有一些其他问题,举个例子：比如边缘有一个视频流应用，需要与云上的AI应用进行交互。首先边缘的网络是无法直接与云上网络互相连通的，所以无法从边缘对云上进行访问。不过这个问题其实可以通过给云上的AI应用配置一个公共IP来解决，但如果云上的每一个应用都配置一个公网IP，那IP将无法收敛。而且云上的应用想要主动访问边缘的应用，其实也是做不到的，因为边缘上的应用一般都处于私网里，它一般不会有公共IP，所以就无法做到正确路由和双向通信。
总的来说，有以下几个问题：
1）边云网络割裂，微服务之间无法跨子网直接通信
2）边缘侧缺少服务发现能力
3）边缘环境下组网配置管理复杂
基于以上的问题，EdgeMesh应运而生。
EdgeMesh项目概况、架构、核心能力
云原生边缘计算平台——KubeEdge
KubeEdge是Kubernetes在边缘场景下的延伸。目标是将Kubernetes对容器编排的能力延伸到边缘上，KubeEdge主要包含两个组件，云端的CloudCore和边缘节点上EdgeCore，同时还有一个Device模块，用于管理海量的边缘设备。
EdgeMesh在KubeEdge架构中所处的位置: EdgeMesh打通了所有边缘应用之间的网络通信，无论应用处于同个组件或不同组件。此外，EdgeMesh还能完成云上应用与边缘应用之间的通信。
EdgeMesh设计原则
轻量化: 每个节点仅需部署一个极轻的代理组件，边缘侧无需依赖 CoreDNS、Kube-Proxy 和 CNI 插件等原生组件
云原生体验: 为 KubeEdge 集群中的容器应用提供与云原生一致的服务发现与流量转发体验
跨子网通信: 屏蔽复杂的边缘网络环境，提供容器间的跨子网边边和边云通信能力
高可靠性: 通过打洞建立点对点直连，转发效率极高；在不支持打洞时通过中继转发流量，保障服务之间的正常通讯
分层式架构: 采用分层式设计架构，各模块能够与原生组件兼容并支持动态关闭
什么是EdgeMesh？
定义
EdgeMesh 作为 KubeEdge 集群的数据面组件，为应用程序提供了简单的服务发现与流量代理功能，从而屏蔽了边缘场景下复杂的网络结构
优势
EdgeMesh 满足边缘场景下的新需求（如边缘资源有限、边云网络不稳定、网络结构复杂等），即实现了高可用性、高可靠性和极致轻量化：
1、高可用性
1）利用 P2P打洞的技术，来打通边缘节点间的网络
2）将边缘节点间的通信分为局域网内和跨局域网
局域网内的通信：直接通信
跨局域网的通信：打洞成功时 Agent 之间建立直连通道，否则通过 Server 中继转发
2、高可靠性 （离线场景）
1）控制面元数据通过 KubeEdge 边云通道下发
2）EdgeMesh 内部实现轻量级的 DNS 服务器，域名请求在节点内闭环
3、极致轻量化：每个节点有且仅有一个 Agent，节省边缘资源
4、用户价值
1）使用户具备了跨越不同局域网边到边/边到云/云到边的应用跨子网互访能力
2）相对于在边缘部署 kube-proxy + cni + nodelocaldns 这一套组件，用户只需要在节点部署一个 Agent 就能完成目标，All in One 部署
目前实现的关键功能：
EdgeMesh架构
EdgeMesh-Agent
Proxier: 负责配置内核的 iptables 规则，将请求拦截到 EdgeMesh 进程内
DNS: 内置的 DNS 解析器，将节点内的域名请求解析成一个服务的集群 IP
Traffic: 基于 Go-Chassis 框架的流量转发模块，负责转发应用间的流量
Controller: 通过 KubeEdge 的边缘侧 Local APIServer 能力获取 Services、Endpoints、Pods 等元数据
Tunnel-Agent: 利用中继和打洞技术来提供跨子网通讯的能力
EdgeMesh-Server
Tunnel-Server: 与 EdgeMesh-Agent 建立连接，协助打洞以及为 EdgeMesh-Agent 提供中继能力
EdgeMesh工作原理
EdgeMesh性能测试
在等吞吐量、等测试应用规模的情况下，单个数据面组件edgemesh-agent的内存消耗大约是istio-proxy的30%，edgemesh-agent的CPU消耗大约是istio-proxy的10%
控制面组件edgemesh-server的内存消耗大约是istiod的4.5%，edgemesh-server的CPU消耗大约是istiod的0.15%
EdgeMesh是节点模式的代理，数据面总资源消耗是集群节点数的倍数；
Istio是sidecar模式的代理，数据面总资源消耗是集群应用数的倍数
在相同的网络环境下，当吞吐量在20RPS(request per second)、100RPS的并发请求下，EdgeMesh的转发性能优于Istio（转发速率提高10倍左右）；
此情况下的EdgeMesh端到端时延与基准组的测试结果几乎相同
EdgeMesh端到端时延的方差随着并发量的增加而增大，当在并发请求超过500RPS时EdgeMesh的端到端时延波动明显（正在优化中）
Benchmark测试工具：
https://github.com/Poorunga/service-mesh-benchmark
EdgeMesh RoadMap
2021.06：EdgeMesh项目开源
2021.09：EdgeMesh支持微服务跨局域网边云/边边通信
2021.12：EdgeMesh支持一键化部署
2022.03：EdgeMesh支持Pod IP的流量跨边云转发
2022.06：EdgeMesh对接标准的Istio进行服务治理控制
2022.09：EdgeMesh支持跨集群服务通信
最后，欢迎更多的云原生爱好者加入我们，一起去探索边缘计算的方向！
附：技术交流地址
End
网站: https://kubeedge.io
EdgeMesh Github地址：https://github.com/kubeedge/edgemesh
戳阅读原文，观看演讲视频！