在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)

為少 發表於 2021-07-22

在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)

Intenseye,我們 follow(跟隨) trends(趨勢) & hype(最被炒作) 的技術,並在使用時應用最佳實踐。 我們在用 ScalaGoPython 等編寫的 Kubernetes 上執行了數百個 pod,其中大多數使用 gRPC

在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)

gRPC 是一種現代開源高效能遠端過程呼叫 (RPC) 框架,它使用 HTTP/2 進行傳輸。HTTP/2 支援通過單個 TCP 連線發出多個請求以減少往返次數。這就是問題出現的地方;負載均衡。建立連線後,所有請求都將固定到單個目標 Pod。 因此,我們不會有平衡的負載。 我們需要一個 L7 感知負載均衡器,而不是 L4。稍後您可以從這裡閱讀問題的詳細資訊。

在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)

我們正在為另一個問題尋求解決方案;微服務之間的安全傳輸。我們有數十個元件,總共執行數百個 Pod。 在它們之間一一配置 TLS 令人生畏,而且會很耗時。

在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)

我們還需要一個監控系統和來自所有這些元件和微服務的流量指標(traffic metrics)。
我們想觀察成功/失敗(success/failure)率、PodRPS、誰與誰交談的頻率等。

我們有這三個問題的單一解決方案:Service Mesh

什麼是 Service Mesh?

服務網格是一種工具,通過在平臺層而不是應用程式層插入這些功能,為應用程式新增可觀察性(observability)、安全性(security)和可靠性(reliability)功能。(servicemesh.es)

服務網格通常作為與應用程式程式碼一起部署的一組可擴充套件的網路代理來實現;一種稱為邊車的模式。這些代理處理微服務之間的通訊,並允許控制流量並獲得整個系統的洞察力。Service Mesh 提供了很棒的功能,例如流量指標(traffic metrics)、熔斷(circuit breaking)、mTLS、流量拆分(traffic split)、重試和超時(retry & timeout)、A/B 路由(routing)等。

在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)
source: servicemesh.es

我們開始挖掘服務網格的細節並評估對我們很重要的功能,我們如何從中受益等。由於服務網格會影響延遲和資源消耗,因此也必須衡量這些缺點。由於我們有 500 多個 Pod,因此資源成本將是 500 x sidecar。另外,我們在與時間賽跑,所以延遲應該是最小的。

經過一些研究和 PoC,我們決定在 IstioConsulLinkerd2 之間使用 Linkerd2。 我必須說,servicemesh.es 幫助我們獲得了有關服務網格的知識並比較了它們之間的功能。

在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)

除了我們正在尋求的功能之外,與 IstioConsul 相比,我們選擇 Linkerd23 個原因。(L7 LBmTLStraffic metrics 等):

  • 輕量級(低 CPU 和記憶體消耗)
  • 低延遲
  • 延遲感知 LB

Istio 有很多不錯的功能(感謝 Envoy 代理),但我們並不需要所有這些功能。與 Linkerd2 相比,它的 sidecar 代理 CPU 和記憶體消耗也很高。Consul 使用相同的 sidecar 代理,因此我們也將其刪除。這裡詳細解釋了為什麼 Linkerd2 使用它自己的代理而不是 Envoy。另外,Linkerd2 非常好用。Istio 的文件實在太多了。

Linkerd和“Cardi B”押韻。
“d”要分開發音,如“Linker-DEE”。()

解決方案

問題 1:gRPC 負載平衡

在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)

without mesh / with mesh

正如您在圖中所見,有些 pods 像替罪羊,有些像樹懶。網格後,一切都很好。

在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)

問題 2:mTLS

在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)

感謝 Linkerd2 的 mTLS 功能,我們像 Thanos(滅霸) 一樣,像彈指一樣保護了微服務之間的內部通訊。 Linkerd224 小時自動輪換一次證照。您也可以使用 cert-manager 來輪換頒發者證照和私鑰。

問題 3:流量監控

在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)

Linkerd2PrometheusGrafana 捆綁在一起,但您可以自帶例項並通過官方文件對其進行配置。 我們遵循文件並開始使用我們現有的例項。現在我們從每個網格化的 pod 中獲得了很好的指標,並且我們對叢集有了更好的可觀察性。

結論

感謝 Linkerd2,我們解決了我們的問題,從此過上了幸福的生活。 文件非常清晰,入門頁面很容易理解(+ 他們有演示應用程式。)當然,並非一切都是光明的。 我們在網格劃分 pod 時或網格後遇到的問題很少,但我們也解決了這些問題。 甚至我們在 GitHub 上開啟了一個問題並得到了幫助。

在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.1)

所以這篇文章是我們服務網格之旅的第一部分,它是關於“什麼是服務網格以及我們為什麼選擇 Linkerd2?” 在第二部分,我們將討論我們面臨的問題以及我們如何解決這些問題。

References

我是為少。
微信:uuhells123。
公眾號:黑客下午茶。