導入
私たちは Istio をサービス メッシュとしてデプロイし始めました。 原則として、次の点を除いてすべて問題ありません。 高い.
В Istio の場合は次のようになります。
Istio 1.1 では、プロキシは 0,6 秒あたり 1000 リクエストあたり約 XNUMX vCPU (仮想コア) を消費します。
サービス メッシュの最初のリージョン (接続の両側に 2 つのプロキシ) では、1200 秒あたり 40 万リクエストの速度で、プロキシ専用に XNUMX コアが存在します。 Google のコスト計算ツールによると、構成にかかる費用はコアあたり月額約 XNUMX ドルとなります。 n1-standard-64つまり、このリージョンだけで、50 秒あたり 1 万件のリクエストに対して月額 XNUMX 万ドル以上の費用がかかります。
イワン・シム () サービス メッシュは昨年遅延し、メモリとプロセッサについても同様のことを約束しましたが、うまくいきませんでした。
どうやら、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 は実稼働環境では使用しませんが、このようなタスクには最適です。 各サービス メッシュに対して文字通りいくつかのコマンドを使用する必要がありました。 分離には XNUMX つのクラスター (Istio と Linkerd にそれぞれ XNUMX つずつ) を使用しました。
実験は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にサイドカーEnvoyをインストールさせるには、サイドカーインジェクターを使用します- MutatingAdmissionWebhook。 この記事ではそれについては説明しません。 これはすべての新しいポッドのアクセスを監視し、タスクを担当するサイドカーと initContainer を動的に追加するコントローラーであることだけは言っておきます。 iptables.
Shopify ではサイドカーを実装するために独自のアクセス コントローラーを作成しましたが、このベンチマークでは Istio に付属のコントローラーを使用しました。 名前空間にショートカットがある場合、コントローラーはデフォルトでサイドカーを挿入します。 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 labeledLinkerd の自動展開のセットアップ
Linkerd サイドカーの埋め込みを設定するには、アノテーションを使用します (アノテーションは、次の方法で手動で追加しました) 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: ActiveIstio フォールト トレランス シミュレーター
Shopify に固有のトラフィックを実験するために、Istio と呼ばれるフォールト トレランス シミュレーターを構築しました。 サービス グラフの特定の部分を表すカスタム トポロジを作成し、特定のワークロードをモデル化するように動的に構成するツールが必要でした。
Shopify のインフラストラクチャは、フラッシュ セール中に大きな負荷がかかります。 同時に、Shopify 。 大口顧客は、フラッシュセールの計画について警告することがあります。 昼夜を問わず、私たちのために予期せずにそれらを行う人もいます。
私たちは、過去に Shopify のインフラストラクチャを圧倒していたトポロジやワークロードに適合するワークフローをモデル化する復元力シミュレーターを望んでいました。 サービス メッシュを使用する主な目的は、ネットワーク レベルでの信頼性とフォールト トレランスが必要なことであり、サービス メッシュが以前にサービスを中断させた負荷に効果的に対処することが重要です。
フォールト トレランス シミュレーターの中心となるのは、サービス メッシュ ノードとして機能するワーカー ノードです。 ワーカー ノードは、起動時に静的に構成することも、REST API を介して動的に構成することもできます。 ワーカー ノードの動的構成を使用して、回帰テストの形式でワークフローを作成します。
そのようなプロセスの例を次に示します。
- として 10 台のサーバーを起動します
bar応答を返すサービス200/OK100ミリ秒後。 - 10 個のクライアントを起動し、それぞれが 100 秒あたり XNUMX リクエストを送信します。
bar. - 10 秒ごとに 1 台のサーバーを削除し、エラーを監視します
5xxクライアント上で。
ワークフローの最後に、ログとメトリクスを調べて、テストが成功したかどうかを確認します。 このようにして、サービス メッシュのパフォーマンスについて学習し、回帰テストを実行してフォールト トレランスに関する想定をテストします。
(注: Istio フォールト トレランス シミュレーターのオープンソース化を検討していますが、まだその準備ができていません。)
サービス メッシュ ベンチマーク用の Istio フォールト トレランス シミュレーター
シミュレータのいくつかの動作ノードをセットアップします。
irs-client-loadgen: 3 秒あたり 100 リクエストを送信する XNUMX つのレプリカirs-client.irs-client: リクエストを受信する 3 つのレプリカは、100 ミリ秒待ってからリクエストを転送します。irs-server.irs-server: 戻ってくるレプリカ 3 個200/OK100ミリ秒後。
この構成により、9 つのエンドポイント間の安定したトラフィック フローを測定できます。 サイドカー irs-client-loadgen и irs-server 100 秒あたり XNUMX リクエストを受信し、 irs-client — 200 (受信および送信)。
私たちはリソースの使用状況を次の方法で追跡します。 Prometheus クラスターがないからです。
結果
制御盤
まず、CPU 消費量を調べました。
Linkerd コントロール パネル ~22 ミリコア
Istio コントロール パネル: ~750 ミリコア
Istio コントロール パネルは約 35 倍の CPU リソースリンカードよりも。 もちろん、すべてがデフォルトでインストールされており、ここでは istio-telemetry が多くのプロセッサ リソースを消費します (一部の機能を無効にすることで無効にできます)。 このコンポーネントを削除しても、依然として 100 ミリコアを超えます。 4倍リンカードよりも。
サイドカープロキシ
次に、プロキシの使用をテストしました。 リクエストの数には線形関係があるはずですが、各サイドカーには曲線に影響を与えるオーバーヘッドが存在します。
Linkerd: irs-client の場合は最大 100 ミリコア、irs-client-loadgen の場合は最大 50 ミリコア
クライアント プロキシは、loadgen プロキシの XNUMX 倍のトラフィックを受信するため、結果は論理的であるように見えます。loadgen からの送信リクエストごとに、クライアントは XNUMX つの受信リクエストと XNUMX つの送信リクエストを受け取ります。
Istio/Envoy: irs-client の場合は最大 155 ミリコア、irs-client-loadgen の場合は最大 75 ミリコア
Istio サイドカーでも同様の結果が見られます。
ただし、一般的に、Istio/Envoy プロキシは消費します。 CPU リソースが約 50% 増加リンカードよりも。
サーバー側でも同じスキームが見られます。
Linkerd: irs-server の場合は ~50 ミリコア
Istio/Envoy: irs-server の場合は最大 80 ミリコア
サーバー側では、サイドカー Istio/Envoy が消費します CPU リソースが約 60% 増加リンカードよりも。
まとめ
Istio Envoy プロキシは、シミュレートされたワークロードで Linkerd よりも 50% 以上多くの CPU を消費します。 Linkerd コントロール パネルは、特にコア コンポーネントで消費するリソースが Istio よりもはるかに少なくなります。
これらのコストを削減する方法については現在も検討中です。 アイデアがある場合は、共有してください。
出所： habr.com