另眼旁观 Linkerd 2.12 的发布:服务网格标准的曙光?

另眼旁观 Linkerd 2.12 的发布:服务网格标准的曙光?

另眼旁观 Linkerd 2.12 的发布:服务网格标准的曙光?_第1张图片

8 月 24 日,发明服务网格的公司 Buoyant 发布了 Linkerd 2.12,这是时隔近一年的版本发布。不知道大家的对新版本期待如何,在我来看新版本中的功能对于一年的时间来说确实不算多,但是我想说的是 Linkerd 还是那个 Linkerd,还是秉持着一贯的 “Keep it simple” 的设计理念。

新版本的内容不一一介绍,其中最主要的功能:per-route 策略,相比上个版本基于端口的策略,扩展到了 per-route。

而我想说的特别之处也就是在 per-route策略上。

per-route 和策略有何特别之处?

《SMI 与 Gateway API 的 GAMMA 倡议意味着什么?》 层有过猜想:未来服务网格的标准有可能全部或者部分以 Kubernetes 原生 API 的方式存在。

“网关 API,之于集群是入口/出口网关,之于 Pod 是 inbound/outbound sidecar。”

现在来看,Linkerd 先迈出了这一步。

per-route

路由(routing)是通过网络将流量从源地址传输到目的地的操作。不同的流量有不同的操作(路由),流量路由的前提是流量的识别,通俗来讲就是请求的匹配。对服务网格中常见的 TCP 流量,有源地址、源端口、目的地址、目的端口等标识;对于 HTTP 流量,标识则更多:路径、报头、参数等等。

Linkerd 通过一个 CRD ServiceProfile 提供了 per-route 的 指标、重试和超时设置,该 CRD 中可以配置匹配规则来进行流量的识别。在新的 per-route 策略中,则又引入了新的流量识别机制 HTTPRoute 。这个 HTTPRoute 实际上是来自 Kubernetes Gateway API,以镜像的方式维护在 policy.linkerd.io/v1alpha1 包中。

至于为何要自己维护 HTTPRoute,在 Buoyant 的另一篇博客《Linkerd and the Gateway API》 中也给出了答案:目前的 Gateway API 虽易展现出成为标准的设计,但还不足以满足目前的需求。

为何无法满足目前的需求,让我们继续来看策略。

策略

2.12 带来的 per-route 策略是授权策略(Authorization Policy),通过 AuthorizationPolicy 及其他几个 CRD 来进行配置,与 HTTPRoute 一起维护在 policy.linkerd.io/v1alpha1 包中。从包名来看,policy.linkerd.io/v1alpha1 是考虑到了 Kubernetes Gateway API Policy Attachment的设计。

另眼旁观 Linkerd 2.12 的发布:服务网格标准的曙光?_第2张图片
图片来自 Kubernetes Gateway API 文档

在服务网格的功能中有很多的策略:路由、认证/授权、超时、重试、熔断、限流、故障注入等等。而目前 Policy Attachment 还只是提供了概念设计,对这些策略没有任何具体的定义。因此 Linkerd 将其维护在 policy.linkerd.io/v1alpha1 包中,并乐观地相信有一天其可以被 Kubernetes 原生的 CRD 替代,且切换的成本微不足道。

在此我也猜想,原本 ServiceProfile 中的策略也会被废弃,并转移到新的包中。因为 ServiceProfile 的设计本就不够优雅,将流量的标识与策略耦合(估计这也是 Linkerd 的 Keep it simple 执念,尽量少定义 CRD)。

无独有偶

架构设计总是伴随着取舍,在结构化和可扩展性间进行着平衡。Linkerd 秉持 Keep it simple 的设计理念,尽量避免定义过多的 CRD,降低复杂度。不只是这次的 HTTPRoute,其流量拆分上使用了Service Mesh Interface(SMI)TrafficSplit API(Linkerd 支持 v1alpha2,最新为 v1alpha4)。

简化设计,降低学习和维护的成本;降低资源需求,降低使用成本;提供最小功能集,“够用就好”,减少冗余功能带来的成本提升。

服务网格面世 5 年来,用户逐渐意识到“轻、快、易用”对于服务网格的重要性。这条路上 Linkerd 并不是孤独的,国产的服务网格产品 Flomesh 开源的 osm-edge 也是同样的简化设计,轻量级高性能的 sidecar 代理,此外还有着:

  • 开放的控制平面设计,通过扩展支持更多的服务发现。
  • 可编程的sidecar 代理 Pipy,功能扩展更容易;除了作为服务网格代理,还可以独立使用。
  • 基于 SMI 的实现。SMI 与 Gateway API 都是同样的流量标识与策略分离的设计,简单的对比可以看这篇

总结

这篇文章是 Linkerd 2.12 发表之际的一些启发和感想,版本发布只是表面,更要探寻表面之外的深意。利用周末的时间来挖掘一下,写下这篇。

写作的同时,有一个词浮出脑海:返璞归真。下一篇,目前只想到了标题《服务网格:少即是多,Less is more》。

文章统一发布在公众号云原生指北

你可能感兴趣的:(云计算)