当开放服务网格 OSM 遇到 Pipy

在《服务网格接口 SMI 规范解读》一文中，我们领略了 SMI 在服务网格功能层面的抽象，在实现最终用户的标准化的基础上，又可以实现服务网格技术提供商的创新。今天我们带来了 SMI 的实现开放服务网格（Open Service Mesh，简称 OSM）。

阅读本文您将收获：

• 了解 SMI 和 OSM 出现的背景

• 了解 OSM 如何在设计和实现中做到“开放”

• 了解 Flomeh 如何扩展 OSM 支持 Pipy Sidecar，实现 ARM Ready，将场景延伸至边缘

Flomesh OSM 源码 可以从这里访问。

背景

自从 Buoyant 的 Willian Morgan 在 2017 年的 What’s a service mesh? And why do I need one? 首次提出服务网格，至今已经有 5 年了。几年间 Istio 俨然有着成为服务网格事实标准的趋势，然而依然会有各式各样的服务网格产品层出不穷。

打开 CNCF 的服务网格全景图 可以发现已经有不少的服务网格产品。此外还有没列出的，比如 HashiCorp Consul Connect、OpenShift Service Mesh、Nginx Service Mesh、Kong Mesh、SOFAMesh 等等，以及一些云服务商的产品。

这些产品有些使用相同的数据平面，也有些不同，但控制平面各不相同。众多产品为大家提供了更多选择的同时，也由于各个产品间有着很强的隔离性，阻碍了生态系统的发展。这导致很难从一个实现切换到另一个，从控制面到数据面，以及为其开发的管理后台都有重新开发的成本。此外，还有用户使用习惯的改变，无法做到透明无感知。

针对这种诉求，按照“惯例”就是借助标准接口来进行抽象，提供实现的互通性。比如容器网络、运行时、存储有 CNI、CRI、CSI 接口，服务网格也有其抽象接口 Service Mesh Interface（简称 SMI，规范的详细截图见上一篇文章），以及其实现也就是今天的主角 Open Service Mesh（简称 OSM）。

开放服务网格 OSM

这里提出一个问题：开放服务网格是如何开放的？大家可以带着这个问题继续下面的内容，看完应该就能知道答案了。

”开放式“设计

OSM 的控制层面包含了五个核心组件：

• Proxy Control Plane：代理控制面在操作服务网格中起着关键作用，所有以 sidecar 方式运行的代理，都会与其建立连接，并不断地接受配置的更新。这个组件实现反向代理所需的接口。目前 OSM 使用 Envoy 作为其默认的代理实现，因此这个组件实现了 Envoy 的 xDS API。

• Certificate Manger：证书管理器组件为网格中的服务提供 TLS 证书，这些证书用于使用 mTLS 建立和加密服务之间的连接。

• Endpoints Providers：端点提供者是与计算平台（Kubernetes 集群、云主机、本地机器）交互的一系列组件的统称。端点提供者将服务名解析为 IP 地址。

• Mesh Specification：网格规范是现有SMI 规范组件的封装。该组件抽象了为 YAML 定义的特定存储。这个模块实际上是SMI Spec 的 Kubernetes informers的封装。

• Mesh Catalog：是 OSM 的核心组件，它将其他组件的输出组装成新的结构。新的结构可以转换为代理配置并通过代理控制面分发给所有的代理。

源码分析

上面几个抽象的组件，都有接口与其一一对应，

• Proxy Control Plane：Envoy AggregatedDiscoveryServiceServer
  

• Certificate Manger：certificate.Manager
  

• Endpoints Providers：endpoint.Provider
  

• Mesh Specification：smi.MeshSpec
  

• Mesh Catalog：catalog.MeshCataloger
  

OSM 默认使用 Envoy 作为 sidecar 代理，Proxy Control Plane 的实现是一个 xDS server，与代理间使用 xDS API 进行数据传输。

OSM 控制平面中有一个“消息总线”。集群中，任何资源（K8s 原生资源、OSM 定义资源、SMI 资源）的变更，都会以事件的方式发布到消息总线。

特定事件消息的订阅方在接收到事件后就会执行特定的逻辑，Proxy Control Plane 就是时间消息的订阅方。

网格目录接口

Mesh Catalog 的接口 catalog.MeshCataloger，定义了一些用于生成结构化数据的方法。这些结构化的数据，是在 K8s 原生资源、SMI 自定义资源的基础上的封装。作为底层资源和代理控制面的中间层，对上隔离了底层资源的实现，对下统一了资源的对外暴露形式。

接口的实现 catalog.MeshCatalog，也是通过几个接口获取底层的资源：

• endpoint.Provider：endpoint.Endpoint 抽象资源的提供者，在目前 OSM 版本中提供获取 Kubernetes Endpoint 的实现。

• service.Provider：service.MeshService 抽象资源的提供者，目前同样是提供获取 Kubernetes Service 的实现。

• smi.MeshSpec：顾名思义针对是 SMI 自定义资源，直接使用 SMI 的定义，并没有重新抽象封装。

• k8s.Controller：用于获取 Kubernetes 原生资源，比如 ServiceAcount、Namespace、Pods 等。

• policy.Controller：用于获取 OSM 的 Egress 和 IngressBackend 资源。

看到这里，大家可能已经看出 OSM 如何通过“开放式”的设计为各家厂商预留了扩展点：

• 控制面：endpoint.Provider 和 service.Provider 提供了对服务发现的扩展

• 数据面：Proxy Control Plane 提供了对 sidecar proxy 的扩展，使用其他的 proxy 作为 sidecar

Flomesh OSM

Pipy 是面向云、边缘和 IoT 的开源的可编程代理。Pipy 的灵活多变使其可以用于很多场景，且轻量级、ARM Ready 的特点也非常适合边缘计算场景。

对 OSM 的数据面扩展支持 Pipy 后，OSM 开箱即用的支持了 x86 和 ARM 生态，不仅适用于云端，功能也延伸到了边缘计算的场景。同时，可编程的特性也使数据面功能的扩展非常容易。

设计

既然了解了如何在数据面对 OSM 进行扩展，在设计上就一目了然了。

基于 OSM 最新的 v1.1.0，我们为 Pipy 实现了新的 Proxy Control Plane（其功能可以参考 Pipy Repo 的介绍），将 Mesh Catalog 的数据转换成 Pipy 的配置。对应源码 pkg/pipy 目录中的内容，而 pkg/envoy 是 Envoy 的 Proxy Control Plane。

数据面的功能实现，则按照 Pipy 的方式通过 PipyJS 提供，main.js。

目前，Pipy sidecar 的功能已经实现原数据面的大部分功能，除了下面的几个测试用例：

• HTTP/2 相关：在本月底将要发布的 Pipy 0.4.0 版本中将会提供 HTTP/2 的支持，届时会重新测试相关的用例

• WASM 相关：有一个测试用例是通过 WASM 脚本来扩展分析流量自定义指标，Pipy 支持原生（PipyJS）的方式对功能进行扩展。

ARM Ready

ARM 架构在价格和能耗方面相比 x86 有着很大的优势，越来越多的云端和边缘设备开始采用 ARM 架构的硬件，尤其是边缘场景设备对能耗格外看重。另一方面，边缘设备的可用资源相对较少，对软件资源占用限制较大。

Pipy 有着轻量级和支持 ARM 的优势，使得 Flomesh OSM 得以进一步向边缘场景延伸，为边缘设备提供服务网格的各项功能。

原生 OSM 没有为运行和测试提供相应的镜像，部署上也不支持 ARM；同时 Envoy 的开销对边缘场景也略显昂贵。除了引入 Pipy 替代 Envoy 外，我们还对 OSM 的组件进行了调整，比如构建 ARM 架构镜像，调整部署配置增加 ARM 的支持。

详细内容可以参考 如何在 ARM64 上运行 OSM。

总结

SMI 和 OSM 的出现，为原本互相隔离的生态带来了标准化的可能。在提供标准化的同时，又为技术提供商预留了扩展点。不过目前 OSM 对于 sidecar 的注入还未提供扩展点，我们也在与上游社区探讨此事。

Flomesh OSM 目前还在持续更新中，在 Pipy 0.4.0 发布完成对 HTTP/2 的支持后，将完成所有用例的测试。同时从编译构建、部署、文档层面进一步完善。在所有工作完成后，会将所有内容都贡献到上游社区。

后续，我们会提供更多文章介绍如何使用 OSM，敬请期待。