🥇Istio 和 Linkerd 的 CPU 消耗基準

介紹

我們在 Shopify 開始將 Istio 部署為服務網格。原則上，一切都很好，除了一件事： 它是昂貴的.

在 Istio 1.1 中，代理程式每秒每 0,6 個請求消耗約 1000 個 vCPU（虛擬核心）。

對於服務網格中的第一個區域（連接的每一側都有 2 個代理），我們將為代理提供 1200 個核心，速率為每秒 40 萬個請求。根據 Google 的成本計算器，配置費用約為 XNUMX 美元/月/核心 n1-standard-64，也就是說，每秒 50 萬個請求，光是這個區域就會花費我們每月 1 萬多美元。

伊凡·西姆（伊凡·西姆) 視覺比較服務網格去年延遲並承諾記憶體和處理器相同，但沒有成功：

顯然，values-istio-test.yaml 會嚴重增加 CPU 請求。如果我的計算正確的話，控制面板大約需要 24 個 CPU 核心，每個代理需要 0,5 個 CPU。我沒有那麼多。當更多資源分配給我時，我會重複測試。

我想親眼看看 Istio 的效能與另一個開源服務網格有多相似：林克德.

服務網格安裝

首先我是安裝在叢集中的超級格魯:

$ supergloo init
installing supergloo version 0.3.12
using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources created
serviceaccount/supergloo created
serviceaccount/discovery created
serviceaccount/mesh-discovery created
clusterrole.rbac.authorization.k8s.io/discovery created
clusterrole.rbac.authorization.k8s.io/mesh-discovery created
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created
deployment.extensions/supergloo created
deployment.extensions/discovery created
deployment.extensions/mesh-discovery created
install successful!

我使用 SuperGloo 是因為它使引導服務網格變得更加容易。我不需要做太多事情。我們不在生產中使用 SuperGloo，但它非常適合此類任務。我必須為每個服務網格使用幾個命令。我使用兩個叢集進行隔離——Istio 和 Linkerd 各一個。

該實驗是在 Google Kubernetes Engine 上進行的。我用過 Kubernetes 1.12.7-gke.7 和一個節點池 n1-standard-4 具有自動節點縮放功能（最少 4 個，最多 16 個）。

然後我從命令列安裝了兩個服務網格。

第一個連結器：

$ supergloo install linkerd --name linkerd
+---------+--------------+---------+---------------------------+
| INSTALL |     TYPE     | STATUS  |          DETAILS          |
+---------+--------------+---------+---------------------------+
| linkerd | Linkerd Mesh | Pending | enabled: true             |
|         |              |         | version: stable-2.3.0     |
|         |              |         | namespace: linkerd        |
|         |              |         | mtls enabled: true        |
|         |              |         | auto inject enabled: true |
+---------+--------------+---------+---------------------------+

然後是 Istio：

$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true
+---------+------------+---------+---------------------------+
| INSTALL |    TYPE    | STATUS  |          DETAILS          |
+---------+------------+---------+---------------------------+
| istio   | Istio Mesh | Pending | enabled: true             |
|         |            |         | version: 1.0.6            |
|         |            |         | namespace: istio-system   |
|         |            |         | mtls enabled: true        |
|         |            |         | auto inject enabled: true |
|         |            |         | grafana enabled: true     |
|         |            |         | prometheus enabled: true  |
|         |            |         | jaeger enabled: true      |
+---------+------------+---------+---------------------------+

崩潰循環持續了幾分鐘，然後控制面板穩定下來。

（註：SuperGloo 目前僅支援 Istio 1.0.x。我用 Istio 1.1.3 重複了實驗，但沒有註意到任何明顯的差異。）

設定 Istio 自動部署

為了讓 Istio 安裝 sidecar Envoy，我們使用 sidecar 注入器 - MutatingAdmissionWebhook。我們在本文中不會討論它。我只想說，這是一個控制器，監控所有新pod的訪問，並動態添加一個sidecar和initContainer，它負責任務 iptables.

我們 Shopify 編寫了自己的存取控制器來實作 sidecar，但對於此基準測試，我使用了 Istio 隨附的控制器。當命名空間中有快捷方式時，控制器預設注入 sidecar istio-injection: enabled:

$ kubectl label namespace irs-client-dev istio-injection=enabled
namespace/irs-client-dev labeled

$ kubectl label namespace irs-server-dev istio-injection=enabled
namespace/irs-server-dev labeled

設定自動 Linkerd 部署

為了設定 Linkerd sidecar 嵌入，我們使用註釋（我透過手動添加它們 kubectl edit):

metadata:
  annotations:
    linkerd.io/inject: enabled

$ k edit ns irs-server-dev 
namespace/irs-server-dev edited

$ k get ns irs-server-dev -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    linkerd.io/inject: enabled
  name: irs-server-dev
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Istio 容錯模擬器

我們建立了一個名為 Istio 的容錯模擬器來試驗 Shopify 特有的流量。我們需要一個工具來建立自訂拓撲，該拓撲將代表我們服務圖的特定部分，並動態配置以對特定工作負載進行建模。

Shopify 的基礎架構在閃購期間負載很重。同時，Shopify 建議賣家更頻繁地舉行此類促銷活動。大客戶有時會對計劃中的閃購發出警告。其他人會在白天或晚上的任何時間為我們出乎意料地進行這些活動。

我們希望我們的彈性模擬器能夠對工作流程進行建模，以配合過去壓垮 Shopify 基礎架構的拓撲和工作負載。使用服務網格的主要目的是我們需要網路層級的可靠性和容錯能力，並且服務網格有效地應對先前中斷服務的負載對我們來說很重要。

容錯模擬器的核心是工作節點，它充當服務網格節點。工作節點可以在啟動時靜態配置，也可以透過 REST API 動態配置。我們使用工作節點的動態配置以回歸測試的形式建立工作流程。

以下是此類過程的範例：

我們啟動 10 台伺服器 bar 返回響應的服務 200/OK 100 毫秒後。
我們啟動 10 個客戶端 - 每個客戶端每秒發送 100 個請求 bar.
每 10 秒我們刪除 1 台伺服器並監控錯誤 5xx 在客戶端上。

在工作流程結束時，我們檢查日誌和指標並檢查測試是否通過。透過這種方式，我們了解服務網格的效能並執行回歸測試來測試我們對容錯的假設。

（注意：我們正在考慮開源 Istio 容錯模擬器，但尚未準備好這樣做。）

用於服務網格基準測試的 Istio 容錯模擬器

我們設定了模擬器的幾個工作節點：

irs-client-loadgen：3 個副本，每秒發送 100 個請求 irs-client.
irs-client：3個副本收到請求，等待100ms並將請求轉發到 irs-server.
irs-server：回傳 3 個副本 200/OK 100 毫秒後。

透過此配置，我們可以測量 9 個端點之間的穩定流量。邊車在 irs-client-loadgen и irs-server 每秒接收 100 個請求，並且 irs-client — 200（傳入與傳出）。

我們透過以下方式追蹤資源使用情況 DataDog因為我們沒有 Prometheus 群集。

Результаты

控制面板

首先，我們檢查了 CPU 消耗。

Linkerd 控制面板 ~22 毫核

Istio 控制面板：~750 毫核

Istio 控制面板大約使用 CPU 資源增加 35 倍比林克德。當然，一切都是預設安裝的，istio-telemetry在這裡消耗了大量的處理器資源（可以透過停用某些功能來停用）。如果我們刪除這個元件，我們仍然會得到超過 100 毫核，即 4倍以上比林克德。

邊車代理

然後我們測試了代理的使用。與請求數量應該存在線性關係，但對於每個 sidecar 來說，都有一些影響曲線的開銷。

Linkerd：irs-client 約 100 毫核，irs-client-loadgen 約 50 毫核

結果看起來合乎邏輯，因為客戶端代理接收的流量是 loadgen 代理的兩倍：對於 loadgen 的每個傳出請求，客戶端都有一個傳入和一個傳出。

Istio/Envoy：irs-client 約 155 毫核，irs-client-loadgen 約 75 毫核

我們在 Istio sidecar 中看到了類似的結果。

但總的來說，Istio/Envoy 代理消耗 CPU 資源增加約 50%比林克德。

我們在伺服器端看到同樣的方案：

Linkerd：irs-server 約 50 毫核

Istio/Envoy：irs-server 約 80 毫核

在伺服器端，sidecar Istio/Envoy 消耗 CPU 資源增加約 60%比林克德。

結論

在我們的模擬工作負載中，Istio Envoy 代理程式消耗的 CPU 比 Linkerd 多 50% 以上。 Linkerd 控制面板消耗的資源比 Istio 少得多，尤其是核心元件。

我們還在思考如何降低這些成本。如果您有想法，請分享！

來源： www.habr.com

Istio 和 Linkerd 的 CPU 消耗基準

介紹