写点什么

当开放服务网格 OSM 遇到 Pipy

作者:Flomesh
  • 2022 年 5 月 19 日
  • 本文字数:2937 字

    阅读完需:约 10 分钟

当开放服务网格 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 的核心组件,它将其他组件的输出组装成新的结构。新的结构可以转换为代理配置并通过代理控制面分发给所有的代理。

源码分析

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



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.Providerendpoint.Endpoint 抽象资源的提供者,在目前 OSM 版本中提供获取 Kubernetes Endpoint 的实现。

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

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

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

  • policy.Controller:用于获取 OSM 的 EgressIngressBackend 资源。


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


  • 控制面:endpoint.Providerservice.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,敬请期待。

用户头像

Flomesh

关注

微信订阅号:flomesh 2022.04.07 加入

一站式云原生应用流量管理供应商 官网:https://flomesh.io

评论

发布
暂无评论
当开放服务网格 OSM 遇到 Pipy_Service Mesh 服务网格_Flomesh_InfoQ写作社区