边缘计算场景下 Service Mesh 的延伸和扩展

在 KubeCon2021 上，华为云云原生技术开发工程师王杰章发表了《边缘计算场景下 Service Mesh 的延伸和扩展》主题演讲，分享了 KubeEdge EdgeMesh 的项目概况。

演讲主要包含 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 支持跨集群服务通信

最后，欢迎更多的云原生爱好者加入我们，一起去探索边缘计算的方向！

附：技术交流地址

网站: https://kubeedge.io

EdgeMesh Github 地址：https://github.com/kubeedge/edgemesh