本文首发：容器魔方
KubeEdge 社区边缘网络方案致力于研究和解决边缘计算场景下跟网络连通、服务协同、流量治理等相关的一系列问题。其中，EdgeMesh 子项目当前实现了边缘计算场景下应用的跨云边、跨边边的网络通信，目前项目已逐渐从一个创新项目走向成熟，被多家厂商集成到自己的边缘计算解决方案中。本文带大家进一步了解 EdgeMesh 的进展以及未来的规划。
下图展示了一个目前比较通用的边云协同视频AI服务的大致架构，通过这个服务我们可以去做一些人脸识别、人流分析等任务，并将这些技术运用在安防、交通、电力等等实际的产业里。如下图所示，边缘会有一些端侧设备接入到EdgeCore中，比如摄像头或车载系统，在某些场景下边缘应用会采集视频流、图片、音频等等媒体资源，再到云上处理或训练，通过这种边云协同的方式来提高AI识别的精度。
但是在边缘计算场景下，会遇到一些困难和挑战使得没法顺利的完成这些功能。总结如下：
边云、边边网络割裂，微服务之间无法跨子网直接通信
边缘端网络质量不稳定，节点离线、网络抖动是常态
边缘场景下网络组网复杂、配置管理困难
边缘侧缺少服务发现、负载均衡与流量治理等能力
通过上述边缘计算场景网络通信面临的挑战分析，总结归纳后，我们将它们抽象成了一个分层的结构。
如上图所示，边缘网络通信痛点问题主要分为三个层次：
从物理链路层看
1.边缘网络拓扑构造复杂，网络质量不稳定
2.边云、边边物理网络割裂，多边服务协同困难
从虚拟网络层看
1.传统的虚拟网络技术，比如kube-proxy、cni等，无法解决跨网络数据的转发
2.数据处理链路较长，专线铺设造价昂贵
从物理链路层看
1.边缘网络拓扑构造复杂，网络质量不稳定
2.边云、边边物理网络割裂，多边服务协同困难
依据上面的痛点分析结果，我们归纳出了当前阶段主要关注的几个核心问题的范畴。如下所示，依旧是按照一个分层的结构去抽象问题。
边缘物理网络层
边缘物理网络层也是使用传统的计算机网络技术搭建的网络基础设施。在边缘场景里，物理网络一般都是基于区域隔离，大到跨省、跨市，小到跨园区。它们之间的网络往往是不互通的，必须经过因特网以及电信运营商的网络才能互通。对于物理网络这个层次，其实很难在这个层面进行改造，主要因为物理网络层几乎都是硬件的基础设施，确实不太好深入去改造，所以我们主要将焦点瞄准在上面几个层次。
边缘隧道网络层
边缘隧道网络层最核心的问题就是如何将下层割裂的物理网络进行连通，以此屏蔽边缘网络拓扑的复杂性。这层核心的能力是提供网络隧道技术、加密技术等，主要的业界实现有libp2p，ipsec等。像EdgeMesh其实就是用到了libp2p技术，尝试去建立每个对等点的连接（无论这些对等点是否处于同一个子网内），以此形成一个p2p的隧道网络。像阿里云开源的raven以及博云开源的fabedge就是用了ipsec技术来完成这件事情。像kilo这款cni插件，用了wireguard技术先实现了隧道网络，再实现了cni的功能。
边缘容器网络层
容器网络主要围绕cni技术展开，前文也提到过边缘场景下cni插件是不支持跨子网转发数据的，因为cni本身依赖三层网络能互通。所以边缘容器网络得依赖边缘隧道网络层的能力才能发挥原本cni容器网络配置、数据包封包和路由以及网络策略的能力。上层依赖下层提供的服务的形式类型于计算机网络协议栈的概念。EdgeMesh目前缺失边缘容器网络层的能力，因此EdgeMesh目前还不支持pod ip级别的数据转发，也还不支持网络策略，不过这块内容在EdgeMesh未来的路标内。
边缘虚拟网络层
能够通过K8s service去访问特定的服务是此层的核心功能，主要负责应用暴露服务的透明代理兼负载均衡器，比较常见的实现有k8s官方的kube-proxy，其他还有cilium等。Cilium的能力覆盖到了容器网络层和虚拟网络层，它使用了ebpf技术能在内核态去转发数据，性能很高，这也是EdgeMesh未来在性能转发方面的一个优化方向。
边缘服务网格层
这一层会提供比容器网络层更加丰富的网络策略管理能力，此外还有很多服务治理功能，比如服务发现、灰度发布、熔断、限流、分布式调用链等等。目前业界实现的istio、linkerd之类的产品，都做的非常强大，EdgeMesh对此层更倾向于集成已有的Service Mesh的成果。
可能有人会疑问的是，除了边缘隧道网络层以外的其他几层现在都有业界成熟的实现，那是不是只需要把边缘隧道网络层做出来，其他上面几层直接部署原生的组件即可？其实这是没问题的，但是可能场景覆盖得不够全面。比如在一些资源特别受限的场景下，边缘计算资源很难集成太多组件（比如kube-proxy、cni插件、coredns等），而且服务网格数据面使用sidecar模式会占用更多的资源。然而edgemesh仅需一个轻量的组件（内存占用<80MB）即可解决一切问题，也会采用节点级的模式代替sidecar模式进行服务治理。
EdgeMesh定位于解决边缘场景下云边、边边网络通信，下图是EdgeMesh的架构。
EdgeMesh具有以下几点优势：
跨子网通信
屏蔽复杂的边缘网络环境，提供容器间的跨子网边边和边云通信能力
高可靠性
通过NAT穿透技术建立点对点直连，转发效率高；在不支持打洞时通过中继转发流量，保障服务之间的正常通讯
云原生体验
为 KubeEdge 集群中的容器应用提供与云原生一致的服务发现与流量转发体验
轻量化
每个节点仅需部署一个极轻的代理组件，采用分层式设计架构，各模块能够与原生组件兼容并支持动态关闭
下图展示了EdgeMesh的基本工作流程：
下图展示了我们正在做的以及后续规格中要做的事项，红色边的区域代表目前基本已经完成的模块，后续也会持续的演进和优化。其他蓝色区域表示都是在未来规划内的模块，比如容器网络/网络策略、服务网格、动态路由。动态路由这一块内容，主要是想去探索一下在移动场景下的网络通信的优化。最后是消息系统，目前市面上有很多消息中间件，比如rabbitmq，kafka和redis等，可以为网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统，这在边缘网络通信场景下也是非常有价值的。
KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。
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/
