Istio 完敗？Linkerd 和 Istio 基準測試

圖片來源: Febin Raj

兩年前，Kinvolk(https://kinvolk.io/) 的優秀人士對 Linkerd 和 Istio 的性能進行了基準測試(https://kinvolk.io/blog/2019/05/performance-benchmark-analysis-of-istio-and-linkerd)，結果顯示，只有 Linkerd 消耗了更多的數據平面 CPU 之外，Linkerd 在其他方面表現都比 Istio 明顯更好。最近，我們使用這兩個項目的最新版本重複了這些實驗。我們的結果顯示，「Linkerd 不僅仍然比 Istio 快得多，而且現在消耗的數據平面內存和 CPU 也少了一個數量級」。這些結果甚至在吞吐量水平超過 Kinvolk 評估的 3 倍情況下仍可保持，你也可以自己進行測試。

「背景介紹」

2019 年，Kinvolk 發佈了Linkerd 與 Istio 的公開基準數據比較(https://linkerd.io/2019/05/18/linkerd-benchmarks/) ，該測試提供了一個開源服務網格基準測試工具(https://github.com/kinvolk/service-mesh-benchmark)，任何人都可以使用這個工具進行重複測試。這個測試工具之所以引人注目，是因爲它模仿了"現實生活"的場景：它通過一個簡單的微服務應用程序發送持續的流量，同時使用了 gRPC 和 HTTP 調用，並在內存和 CPU 消耗以及延遲的角度測量了使用服務網格的成本。最關鍵的是，延遲是從客戶的角度來測量的，產生面向用戶的數據，而不是內部代理時間。

Kinvolk 產生的第二件事是 Linkerd 和 Istio 在 2019 年左右的實際基準測試結果。這些數據顯示，Linkerd 的速度明顯更快，而且在所有考慮的因素中，Linkerd 的資源消耗也明顯更小，除了一個方面：Linkerd 的數據平面（即它的代理）在最高負載水平下比 Istio 消耗更多的 CPU。

在這兩個項目的多次版本更新發布兩年後的今天，我們決定重新進行這些測試實驗。

「實驗設置」

在這些實驗中，我們將 Kinvolk 基準測試工具應用於兩個項目的最新穩定版本：Linkerd 2.10.2（默認安裝）和 Istio 1.10.0（"最小" 配置）。我們使用 Lokomotive Kubernetes 發行版的 Kubernetes v1.19 集羣上運行了最新版本的基準測試工具。基準測試在 Equinix Metal(https://www.equinix.com/) 向 CNCF 項目提供的裸機硬件上運行。

首先是在 Equinix Metal 內找到一個測試環境，該環境可以在不同的運行中提供一致的結果。我們嘗試的許多環境在不同的運行之間產生了巨大的延遲變化，包括在沒有服務網格的情況。例如，在我們嘗試的一個環境中，對於無服務網格的情況，基準報告的最大延遲從 26ms 到 159ms 不等！

我們最終在 Equinix Metal dfw2 數據中心找到了一個集羣，它產生了一致的行爲，每次運行之間的差異很小。該集羣包含 6 個s3.xlarge.x86配置的工作節點（Intel Xeon 4214，具有 24 個物理內核 @2.2GHz 和 192GB 內存）組成，基準應用程序在其上運行，加上一個相同配置的負載生成器節點，以及一個 c2.medium.x86 配置的 K8S 主節點。

接下來，我們需要關注測試的相關參數。雖然最初的 Kinvolk 工作評估了每秒 500 個請求 (RPS) 和 600 RPS 的性能，但我們想嘗試一個更廣的範圍：我們評估了 20 RPS、200 RPS 和 2,000 RPS 的網格。在每個級別中，我們針對 Linkerd、Istio 和無服務網格的情況分別進行了 6 次獨立運行，每次持續 10 分鐘的負載。在兩次運行之間，所有的基準測試和網格資源都進行了重新安裝。對於每個級別，我們丟棄了具有最高延遲的單個運行結果，留下另外 5 個運行結果。查看我們的原始數據地址(https://docs.google.com/spreadsheets/d/1x0QXFAvL0nWOIGL5coaaW1xwsju5EmSjsqjw6bwHMlQ/)

請注意，Kinvolk 框架以一種非常特定的方式來測量服務網格的行爲：

• 它測量控制平面和數據平面最高點的內存使用情況。換句話說，在運行中的任何時候，控制平面（作爲一個整體，即任何子組件聚合在一起）的最高內存使用量被報告爲該運行的控制平面內存消耗。

• 同樣，任何單個數據平面代理的最高內存使用量報告爲運行中的數據平面消耗量。

• 它以類似的方式測量 CPU 使用率，使用 CPU 時間作爲測量標準。

• 它從客戶端（負載生成器）的角度來測量延遲，其中包括集羣網絡上的時間、應用程序中的時間、代理中的時間等等。延遲是以分佈的百分位數來提供報告的，例如 p50（中位數）、p99、p999（第 99.9%）等。

還要注意是，這個基準測試報告的數據是服務網格和線束及其環境的函數。換句話說，這些不是絕對的得分，而是相對的分數，只能與在相同環境和相同方式下測量的其他選擇進行評估。

「測試了哪些服務網格功能？」

儘管每個服務網格都提供了大量功能，但是我們這裏只測試了其中一部分功能：

• 兩個服務網格都啓用了 mTLS，並且所有應用程序 Pod 之間加密流量和驗證身份。

• 兩個服務網格都在跟蹤指標，包括 L7 指標，儘管這些指標在本次實驗中沒有被消耗。

• 兩個服務網格都默認在 INFO 級別記錄各種日誌，我們沒有配置日誌記錄。

• 兩種服務網格都能夠添加重試和超時，以及以各種方式進行轉移流量，但在本實驗中沒有明確使用這些功能。

• 沒有啓用分佈式追蹤、多集羣通信或其他mesh-y功能。

「結果」

我們的實驗結果如下圖所示，圖中的每個點都是五次運行的平均值，誤差線代表該平均值的一個標準差。柱狀圖本身代表 Linkerd（藍色）、Istio（橙色）和無服務網格的基線（黃色）。

「20RPS 的延遲」

從相對穩定的 20RPS 級別開始，我們已經看到了面向用戶的延遲有很大差異。Linkerd 的中位延遲爲 17ms，比 6ms 的基線高 11ms。相比之下，Istio 的中位延遲爲 26ms，幾乎是 Linkerd 延遲的兩倍。在最大延遲方面，Linkerd 最多在 17ms 的延遲基線上增加了 53ms，而 Istio 的最大延遲則增加了 188ms，是 Linkerd 延遲的三倍。

從百分位數來看，我們發現 Istio 的延遲分佈在第 99 個百分位數時急劇上升到了 200ms，而 Linkerd 則將較高的百分位數逐漸增加到 70 毫秒。

「200RPS 的延遲」

200RPS 這個延遲報告和上面的結果非常相似，中位數延遲的時間幾乎相同，Linkerd 的中位延遲時間爲 17ms，比基線中位延遲的 6ms 高出 11ms，而 Istio 的中位延遲時間爲 25ms，超過了 19ms。在最大值上，Istio 的 221ms 延遲比 23ms 的基線要高 200ms，而 Linkerd 最大延遲爲 92ms，高出約 70ms，比 Istio 少 2.5 倍。我們看到 Istio 的延遲在第 99 個百分位時候發生了同樣的跳躍，幾乎達到了 200ms 的延遲，而 Linkerd 在第 99.9 個百分位時達到了近 90 毫秒的水平。

「2,000RPS 的延遲」

在 2,000RPS 時，我們的評估結果超過了 Kinvolk 的三倍，我們再次看到了相同的情況：在中位數，Linkerd 在 6ms 的基線上多了額外的 9ms 延遲，而 Istio 則增加了 15ms。在最大值下，Linkerd 在 25ms 的基線之上增加了 47ms 的額外時間，而 Istio 增加了 5 倍的額外時延 ~ 253ms。一般來說，在報告的每個百分位數上，Istio 都比 Linkerd 多了大概 40％至 400％的延遲。

「資源消耗」

接下來我們來看看資源的使用情況。下圖顯示了每個服務網格的 CPU 和內存消耗。這些數據在所有吞吐量級別上是相當一致的，因此我們將重點關注最高負載的的 2,000RPS 情況。

從控制平面開始，我們看到 Istio 的控制平面平均使用爲 837mb，約爲 Linkerd 控制平面內存消耗 324mb 的 2.5 倍。Linkerd 的 CPU 使用率要小几個數量級，與 Istio 的 3.7s 相比，控制平面的 CPU 時間爲 71ms。

比控制平面更重要的是數據平面。畢竟，這是網格的一部分，必須隨應用程序擴展。在這裏，我們看到了另一個巨大的差異：Linkerd 代理消耗的最大內存平均爲 17.8mb，而 Istio 的 Envoy 代理消耗的最大內存爲 154.6mb（是 8 倍）。類似地，Linkerd 的最大代理 CPU 時間是 10 毫秒，而 Istio 的是 88 毫秒 - 幾乎相差一個數量級。

「總結與討論」

在這些基準測試中，我們看到 Linkerd 的性能明顯優於 Istio，同時在關鍵的數據平面層面保持的資源成本要小很多個數量級。在最高吞吐量下，我們看到 Linkerd 在數據平面上消耗了 1/9 的內存和 1/8 的 CPU，同時提供了 Istio 的 75％的中位延遲和不到 1/5 的額外最大延遲。

在這些實驗中，我們選擇使用了已經發布的 Kinvolk 的基礎框架。在未來的工作中我們可能會做一些變化例如：

• 衡量累積的而不是最大的資源消耗更能反映真實的成本。

• 根據消耗的內核而不是 CPU 時間來衡量，可能更類似於衡量內存的方式。

• 計算所有運行數據的延遲百分位數，而不是取單個運行的百分位數的平均值，在統計上會更準確。

此外，我們的實驗比 Kinvolk 的 2019 年實驗簡單得多，該實驗涉及 30 分鐘的持續流量、不同的集羣、不同的數據中心以及用於控制可變硬件或網絡的其他技術。在我們的案例中，我們明確使用一個變化較低的環境來運行測試。

「爲什麼 Linkerd 這麼快又輕呢？」

Linkerd 和 Istio 在性能和資源成本上的巨大差異主要歸結爲一件事：Linkerd 的基於 Rust 的“微代理” Linkerd2-proxy(https://linkerd.io/2020/12/03/why-linkerd-doesnt-use-envoy/)。這種微型代理爲 Linkerd 的整個數據平面提供了動力，而這個基準測試在很大程度上反映了其性能和資源消耗。

我們已經寫了很多關於 Linkerd2-proxy 的信息，以及我們在 2018 年採用 Rust 的動機。有趣的是，構建 Linkerd2-proxy 的主要原因不是性能，而是出於運維原因：運維像 Istio 這樣基於 Envoy 的服務網格，往往需要你成爲運維 Envoy 的專家，這是我們不願意強加給 Linkerd 的用戶的。

令人高興的是，選擇構建 Linkerd2-proxy 還可以顯着提高性能和效率，通過解決僅作爲一個 “服務網格 Sidecar 代理” 這一非常具體的問題，我們可以在數據平面層面上非常高效。通過在 Rust 中構建 Linkerd2-proxy，我們可以在該生態系統中獲得令人難以置信的技術投資：像 Tokio、Hyper 和 Tower 這樣的庫是世界上一些最好的系統思維和系統設計。

Linkerd2-proxy 不僅僅具有令人難以置信的快速、輕便和安全性，它還代表了整個 CNCF 領域中一些最前沿技術。

「如何重現這些結果」

如果您想自己複製這些實驗，可以按照基準測試說明進行操作(https://github.com/linkerd/linkerd2/wiki/Linkerd-Benchmark-Setup)。如果您嘗試這樣做，請參考上面有關實驗方法的評論。關鍵是你要找到一個能夠提供一致結果的環境，特別是對於像最大延之類的情況，這些場景對網絡流量、資源爭奪等非常敏感。另外需要記住，你產生的數據將是相對的，而不是絕對的。

原文鏈接：https://linkerd.io/2021/05/27/linkerd-vs-istio-benchmarks/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/7A7eXQONpiNdCrfwt1HfhQ