另眼旁觀 Linkerd 2.12 的釋出：服務網格标準的曙光？

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的設計。

圖檔來自 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）。

簡化設計，降低學習和維護的成本；降低資源需求，降低使用成本；提供最小功能集，“夠用就好”，減少備援功能帶來的成本提升。

• 開放的控制平面設計，通過擴充支援更多的服務發現。
• 可程式設計的sidecar 代理 Pipy，功能擴充更容易；除了作為服務網格代理，還可以獨立使用。
• 基于 SMI 的實作。SMI 與 Gateway API 都是同樣的流量辨別與政策分離的設計，簡單的對比可以看這篇。

總結