关于 osm-edge

osm-edge 是面向云边一体的轻量化服务网格，采用 OSM（Open Service Mesh） 作为控制平面，采用 Pipy 作为数据平面，具有高性能、低资源、简单、易用、易扩展、广泛兼容（支持x86/arm64/龙芯/RISC-V）的特点。

基于 osm 的控制平面，osm-edge 充分支持 SMI（Service Mesh Interface） 规范；通过搭配使用支持 Ingress、Gateway API、跨集群服务发现的 fsm，“osm+fsm” 套件提供了完整的"k8s 集群内+多集群"的"东西+南北"流量管理和服务治理能力。

osm-edge 的开发和测试环境采用k3s等流行的边缘计算 k8s 发行版，目标是 osm-edge 用户可以快速低成本的在 x86、arm、RISC-V、龙芯等硬件平台上部署低资源高性能的服务网格，以更好的支撑微服务架构在低能耗的边缘计算场景运行。

产生的背景

在实际工作中，我们遇到多种行业的用户对服务网格提出了类似的需求。这些行业用户和场景包括：

  • 能源和电力公司。他们希望在每个变电站或者加油站建立简易的机房，部署计算和存储能力，用于对该地点覆盖范围内设备产生的数据的处理。他们希望把传统数据中心的应用推向这些简易机房，并充分采用数据中心的应用管理和运维能力
  • 车联网服务提供商。他们希望在非数据中心的环境建立自己的简易计算环境用于数据采集以及提供服务给车和车主。这些环境可能是公路近距离的位置，或者停车场，以及车流密集的地方
  • 零售商。他们希望在每个商店建立最简的计算环境，除了支撑传统的进存销、收付款等能力，也希望引入新的数据采集、加工、传输能力
  • 医疗机构。他们希望在每个医院，或者是简易的医疗点，提供网络能力，除了面向患者的提供数字化服务能力，也同时完成数据采集，以及和上级管理部门的数据联动
  • 校园、医院等园区。这些园区具有人员相对固定且人流密集的特点。他们希望在更多的人群聚集点附近部署计算资源，用于交付数字化服务，以及采集和处理实时的数据

这些都是典型的边缘计算场景，他们具有相似的需求：

  • 用户希望把传统数据中心的计算模式，尤其是微服务，以及相关的应用交付、管理运维能力带到边缘侧
  • 在工作环境方面，用户需要面对电力供应、算力有限、不稳定的网络等因素。因此需要计算平台具有更强的鲁棒性，在极端的情况下可以快速部署或者完整恢复一个计算环境
  • 通常需要部署的位置（我们称为 POP=Point of Presence）数量众多，而且在不断的发展和扩展。因此需要更加精细的控制计算成本，一个 POP 点的造价、维护价格、扩容价格都成为重要的成本考量因素
  • 普通的、或者低端的 PC 服务器更多的被用于这些场景用于替代云端标准的服务器；基于 ARM 等低功耗技术的算力同时进一步替代低端 PC 服务器。在这些不能媲美云端标准服务器的硬件平台上，用户仍然希望拥有足够的算力以应对功能和数据量的增长。计算向靠近数据产生的位置前移、边缘侧数据量和功能需求的增长、边缘侧计算资源的有限性，这互相矛盾的三者要求边缘侧计算平台拥有更好的计算能效比，也就是用尽可能少的电、尽可能少的服务器、运行更多的应用、支撑更大的数据量
  • POP 点的脆弱性和数量庞大的特点，要求应用更好的支持多集群、跨 POP 的故障迁移。比如某个 POP 点出现故障，那么临近的 POP 点可以快速的分担甚者临时接管这些计算任务

相比于云端数据中心的计算场景，边缘计算三个核心和主要的差异和难点在于：

  • 边缘计算要求支持异构的硬件架构。我们看到非 x86 的算力正在边缘被广泛的使用，他们通常具有低功耗、低成本的优势
  • 边缘计算 POP 点是脆弱的。这种脆弱性体现在他们可能没有极高可靠度的供电，或者是供电的功率不像数据中心一样大；他们的运行环境可能更差，而不是数据中心的恒温通风环境；他们的网络可能是窄带和不稳定的
  • 边缘计算是天然的分布式计算。几乎所有的边缘计算场景，都有多个 POP 点，而且 POP 点的数量在持续增加。POP 点之间可以互相灾备，发生故障时可以向临近 POP 点迁移，是边缘计算的基础能力

k8s 向边缘侧的演进，在一定程度上解决了边缘计算的难点，尤其是对抗脆弱性；而服务网格向边缘侧发展，则侧重边缘计算中网络问题，对抗网络的脆弱性，以及对分布式提供基础网络支持，如故障迁移。在实践中，容器平台作为今天事实上准标准的应用交付手段，正在快速的向边缘侧演进，出现了大批针对边缘特征的发行版，典型的如 k3s；但是服务网格作为容器平台的重要网络扩展，并没有很快的跟上这个趋势。事实上，目前用户很难发现针对边缘计算场景的服务网格，因此我们启动了 osm-edge 开源项目，几个重要的考量和目标是：

  • 支持和兼容 SMI 规范，这样可以满足用户对服务网格管理标准化的需求
  • 对于 ARM 生态的充分支持。ARM 作为边缘计算的“一等公民”甚至首选计算平台，服务网格应该也充分适配、满足这种趋势。事实上，osm-edge 是遵循 “ARM First” 的策略，也就是所有的功能都是优先在 ARM 平台完成开发、测试，并具备交付能力
  • 高性能且低资源。服务网格作为基础设施，在边缘侧应该使用更少的资源（CPU/MEM）同时交付更高的性能（TPS/Latency)

采用的技术

从设计视角，osm-edge 主要包括如下几个大的功能领域；同时从实现角度，我们选择了对应的组件和技术：

  • 兼容 SMI 规范且轻量易用的控制平面。这个环节我们选择了 osm，选择的理由是包括支持 SMI 规范、轻量化、易用。该组件主要功能包括：
    • 兼容和支持 SMI 规范
    • 单一 k8s 集群内的东西流量的配置
    • 流量拦截和 sidecar 的注入
    • 证书管理
  • 轻量化、高性能、低资源的 sidecar 代理。这个环节我们选择了 pipy，该组件主要的功能包括：
    • 支持 SMI 规范所需要的各种网络功能，如代理、路由、负载均衡、多路复用、故障迁移
    • 支持微服务所需要的各种功能，如服务发现、流量标签/灰度发布、熔断、降级、限流、限速
    • 支持应用网络所需要的各种功能，如链路加解密、内容加验签
    • 对 MQTT 的良好支持，MQTT 作为边缘计算的重要协议之一，服务网格在边缘计算场景下，应该像支持 HTTP 一样的支持 MQTT
    • 对多路复用的支持，在某些场景下，POP 点和云端连接的网络可能是窄带和不稳定的，多路复用网络技术可以很好的支持数据的快速、稳定传输
  • 南北流量管理和跨集群能力。这个环境我们选择了集成 fsm，该组件可以使用 osm 标准客户端部署，完成的功能主要包括：
    • Ingress/Egress 和 Gateway API 的支持
    • 跨容器集群的服务发现和路由策略管理
    • 跨集群流量调度和故障迁移

架构

diagram

从控制平面的视角，对于熟悉 osm 架构的用户，osm-edge 在 osm 基础上扩展、替换、增加了如下组件

  • sidecar driver。该组件实现了sidecar和控制平面接口标准化，用户可以选择不同的 sidecar proxy 实现。该组件默认采用 pipy proxy
  • pipy sidecar。该组件替换了标准 osm 的 envoy proxy；同时作为兼容，用户可以通过 sidecar driver 配置使用 envoy 或者其他的 sidecar proxy
  • ingress。该组件来源于 fsm，提供了标准的 ingress 和 Gateway API