边缘服务网格 osm-edge 概览
本文篇幅稍长，阅读本文将了解以下内容：
什么是 osm-edge 及其产生背景
边缘计算与中心云计算的差异，以及带来的挑战
osm-edge 的设计及采用的技术
5 分钟快速体验边缘服务网格
关于 osm-edge
osm-edge 是针对边缘计算环境设计的服务网格，采用 osm 作为控制平面，采用 Pipy 作为数据平面，具有高性能、低资源、简单、易用、易扩展、广泛兼容（支持 x86/arm64/龙芯/RISC-V）的特点。
基于 osm 的控制平面，osm-edge 充分支持 SMI 规范；通过搭配使用支持 ingress、gateway API、跨集群服务发现的 fsm，"osm+fsm" 套件提供了完整的" k8s 集群内+多集群"的"东西+南北"流量管理和服务治理能力。
osm-edge 的开发和测试环境采用k3s、k8e 等流行的边缘计算 k8s 发行版，目标是 osm-edge 用户可以快速低成本的在 x86、arm、RISC-V、龙芯等硬件平台上部署低资源高性能的服务网格，以更好的支撑微服务架构在低能耗的边缘计算场景运行。
osm-edge 已经在 GitHub 上开源，仓库地址：https://github.com/flomesh-io/osm-edge，也可访问 osm-edge 文档中心 了解更多内容：https://osm-edge-docs.flomesh.io。
现邀请感兴趣的小伙伴参与内测，参与内测并提交测试结果的小伙伴将获得由 Flomesh 提供的小礼物。感兴趣的小伙伴可以微信联系 张晓辉（微信 duwasai，邮箱 tyrael@flomesh.io）。
产生的背景
在实际工作中，我们遇到多种行业的用户对服务网格提出了类似的需求。这些行业用户和场景包括：
能源和电力公司。他们希望在每个变电站或者加油站建立简易的机房，部署计算和存储能力，用于对该地点覆盖范围内设备产生的数据的处理。他们希望把传统数据中心的应用推向这些简易机房，并充分采用数据中心的应用管理和运维能力
车联网服务提供商。他们希望在非数据中心的环境建立自己的简易计算环境用于数据采集以及提供服务给车和车主。这些环境可能是公路近距离的位置，或者停车场，以及车流密集的地方
零售商。他们希望在每个商店建立最简的计算环境，除了支撑传统的进存销、收付款等能力，也希望引入新的数据采集、加工、传输能力
医疗机构。他们希望在每个医院，或者是简易的医疗点，提供网络能力，除了面向患者的提供数字化服务能力，也同时完成数据采集，以及和上级管理部门的数据联动
校园、医院等园区。这些园区具有人员相对固定且人流密集的特点。他们希望在更多的人群聚集点附近部署计算资源，用于交付数字化服务，以及采集和处理实时的数据
这些都是典型的边缘计算场景，他们具有相似的需求：
用户希望把传统数据中心的计算模式，尤其是微服务，以及相关的应用交付、管理运维能力带到边缘侧
在工作环境方面，用户需要面对电力供应、算力有限、不稳定的网络等因素。因此需要计算平台具有更强的鲁棒性，在极端的情况下可以快速部署或者完整恢复一个计算环境
通常需要部署的位置（我们称为 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 的支持跨容器集群的服务发现和路由策略管理跨集群流量调度和故障迁移
架构
从控制平面的视角，对于熟悉 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
我们已经向 osm 社区提交了 Sidecar driver 设计的 proposal，以增强 osm 在代理控制平面的开放性设计。有了 sidecar dirver 的引入，各家代理厂商可以提供针对不同代理的实现，使 osm 可以支持多重不同的数据平面代理。
快速体验
以下演示如何在 5 分钟之内，下载、安装、运行 osm-edge，并部署一个演示应用，并完成链路加密、访问控制、流量分割等 SMI 标准功能。该演示使用 x86 版本的 Ubuntu 21，运行 v1.23.8+k3s1 版本的 k3s。更多版本和平台的支持，请参考完整的新手上路文档。
先决条件
一个运行中的 Kubernetes 集群，可以通过下面的命令快速创建 k3s 单节点集群：
osm-edge 支持的最低 Kubernetes 版本为 1.19。
下载并安装 osm-edge 命令行工具
在 Kubernetes 上安装 osm-edge
此命令启用 Prometheus、Grafana 和 Jaeger 集成
部署演示应用
演示应用包括了如下服务：
bookbuyer是一个 HTTP 客户端，它发送请求给bookstore。这个流量是允许的。bookthief是一个 HTTP 客户端，很像bookbuyer，也会发送 HTTP 请求给bookstore。这个流量应该被阻止。bookstore是一个服务器，负责对 HTTP 请求给与响应。同时，该服务器也是一个客户端，发送请求给bookwarehouse服务。这个流量是被允许的。bookwarehouse是一个服务器，应该只对bookstore做出响应。bookbuyer和bookthief都应该被其阻止。mysql是一个 MySQL 数据库，只有bookwarehouse可以访问。
使用如下命令部署这些服务：
把每个服务的 GUI 端口对外暴露，这样用浏览器我们可以访问这些端口，观察演示的现象。
在一个浏览器中，打开下面的 URL：
注意：如果需要从宿主机访问，需要将 localhost 替换成虚拟机的 IP 地址；或者在宿主机上运行 port-forward-all.sh 脚本。
http://localhost:8080 - bookbuyer
http://localhost:8083 - bookthief
http://localhost:8084 - bookstore
访问控制
通过上面的命令安装 osm-edge，所有的服务都是没有访问控制的（宽松流量模式），或者说所有的访问都是允许的。通过在浏览器中观察每个服务的页面数量增长可以看到没有访问控制时候的情况：
在 bookbuyer、bookthief UI 中的计数分别对应了购买和盗窃的书籍数量，而在 bookstore-v1 中这些都应该在增加：
http://localhost:8080 - bookbuyer
http://localhost:8083 - bookthief
在 bookstore UI 中的对于书籍销售的计数也应该在增加：
http://localhost:8084 - bookstore
接下来演示通过禁用宽松流量策略模式，拒绝对 bookstore 服务的访问：
此时会发现计数将不再增加。
现在执行下面的命令，放行 bookbuyer 对 bookstore 的访问：
这里再去查看 bookbuyer 和 bookstore UI，会发现计数恢复增加，而 bookthief UI 的计数仍然停止。
通过访问控制，我们成功阻止 bookthief 从 bookstore 盗窃书籍，而正常的购买不受影响。
可观测性
Metrics
使用下面的命令开启命名空间下的 metrics 采集，否则前面创建的 Pod 产生的 metrics 并不会被采集：
在执行了端口转发脚本之后，在浏览器中打开 http://localhost:3000 可以访问已经安装的 Grafana，默认的用户名和密码分别为 admin、admin。
osm-edge 内置了多个 dashboard 提供控制平面和数据平面各项指标的可视化展示。比如下图中展示的是 bookthief 服务的 pod http://localhost:3000 访问其他 service 的指标：
下图展示的是 bookthief 以 deployment 为粒度，访问其他 service 的指标。与上个图的差别在于，假如 bookthief 有多个副本，这里会展示所有副本的汇总数据：
接下来展示的 osm-edge 组件、以及网格基础信息等的指标：
Tracing
在浏览器中输入 http://localhost:16686/search 可访问 Jaeger 的仪表板：
仪表板中可以查询服务相关的 tracing 信息：
展示服务拓扑图：
Logging
osm-edge 控制平面将诊断日志输出到了标准输出上，用于服务网格的管理，可以通过调整日志的级别来控制日志信息的输出。输出到标准输出上的日志，可以通过日志采集工具采集聚合并存储。
卸载服务网格
在完成 osm-edge 的快速体验后，如果要卸载全部与之相关的资源，就需要删除这些示例应用和相关的 SMI 资源，并且卸载掉 osm-edge 控制平面和集群范围内的 osm-edge 资源。
删除示例应用：
卸载控制平面：
总结
通过这篇文章我们介绍了边缘计算中不断出现的多样化的需求，以及对网络基础设施带来的挑战。osm-edge 将服务网格向边缘进一步延伸，使得原本在中心云计算中才能使用的服务网格在边缘场景中的应用变成可能。同时 osm-edge 实现了 SMI（服务网格接口规范），提供服务网格的通用功能。阅读本文之后，可能会发现边缘服务网格实际上不仅仅用于边缘计算，中心云计算大规模、高密度的部署同样适合。
在下一篇文章中，将通过数据平面的基准测试来为大家呈现 osm-edge 如何以高性能、低资源特性应对边缘计算的基础网络需求。
版权声明: 本文为 InfoQ 作者【Flomesh】的原创文章。
原文链接:【http://xie.infoq.cn/article/cc02688451576a3820e36b038】。文章转载请联系作者。
微信订阅号：flomesh 2022.04.07 加入
一站式云原生应用流量管理供应商 官网：https://flomesh.io
评论