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

Posted 2022-02-23 边缘计算社区

在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

戳阅读原文，观看演讲视频！