次の方法で共有

Istio サービス メッシュ アドオンのパフォーマンスとスケーリング

  • [アーティクル]

Istio ベースのサービス メッシュ アドオンは、論理的にコントロール プレーン (istiod) とデータ プレーンに分かれています。 データ プレーンは、ワークロード ポッド内の Envoy サイドカー プロキシで構成されます。 Istiod は、これらの Envoy プロキシを管理および構成します。 この記事では、リソース消費、サイドカー容量、待機時間のオーバヘッドなどのリビジョン asm-1-19 のコントロール プレーンとデータ プレーンの両方のパフォーマンスについて説明します。 さらに、高負荷時のリソースへの潜在的な負担に対応するための提案も用意されています。 この記事では、コントロール プレーンとゲートウェイのスケーリングをカスタマイズする方法についても取り上げます。

コントロール プレーンのパフォーマンス

Istiod の CPU とメモリ要件は、デプロイと構成の変更の速度、接続されているプロキシの数に関連付けられます。 テストされたシナリオは次のとおりです。

  • ポッド チャーン: ポッド チャーンが istiod に与える影響を調べます。 変数を減らすため、すべてのサイドカーに 1 つのサービスのみを使用します。
  • 複数のサービス: Istiod で管理できる最大サイドカー (サイドカー容量) に対する複数のサービスの影響を調べます。ここでは、各サービスには N 個のサイドカーがあり、合計で最大になります。

仕様のテスト

  • 既定の設定を使用した 1 つの istiod インスタンス
  • 無効になった水平ポッドの自動スケーリング
  • 次の 2 つのネットワーク プラグインでテスト済み: Azure Container Networking Interface (CNI) Overlay および Cilium を使用した Azure CNI Overlay (大規模クラスター用の推奨ネットワーク プラグイン)
  • ノード SKU: Standard D16 v3 (16 vCPU、64 GB メモリ)
  • Kubernetes バージョン: 1.28.5
  • Istio バージョン: asm-1-19

ポッド チャーン

ClusterLoader2 フレームワークは、サイドカー チャーンがある場合に Istiod で管理できるサイドカーの最大数を決定するために使用されました。 チャーン使用率は、テスト中にサイドカーがダウン/アップした割合として定義されます。 たとえば、10,000 個のサイドカーに 50% のチャーンがあった場合、5,000 個のサイドカーがチャーン ダウンし、その後 5,000 個のサイドカーがチャーン アップしたことになります。 テストされたチャーン使用率は、デプロイ ロールアウト時の一般的なチャーン使用率から決定しました (maxUnavailable)。 チャーン レートは、チャーン プロセスを完了するのにかかった実際の時間に対して、チャーンされたサイドカーの総数 (アップとダウン) を決定することで計算されました。

サイドカー容量と Istiod CPU とメモリ

Azure CNI オーバーレイ

チャーン (%) チャーン レート (サイドカー/秒) サイドカー容量 Istiod メモリ (GB) Istiod CPU
0 -- 25000 32.1 15
25 31.2 15000 22.2 15
50 31.2 15000 25.4 15

Cilium を使用した Azure CNI オーバーレイ

チャーン (%) チャーン レート (サイドカー/秒) サイドカー容量 Istiod メモリ (GB) Istiod CPU
0 -- 30000 41.2 15
25 41.7 25000 36.1 16
50 37.9 25000 42.7 16

複数のサービス

ClusterLoader2 フレームワークは、1,000 このサービスを管理できるサイドカー istiod の最大数を決定するために使用されました。 結果は、ポッド チャーン シナリオの 0% チャーン テスト (1 つのサービス) と比較することができます。 各サービスには、全体の最大サイドカー数に寄与している N 個のサイドカーがあります。 API サーバーのリソース使用状況を観察し、アドオンによる重大なストレスがあるかどうかを確認しました。

サイドカー容量

Azure CNI オーバーレイ Cilium を使用した Azure CNI オーバーレイ
20000 20000

CPU とメモリ

リソース Azure CNI オーバーレイ Cilium を使用した Azure CNI オーバーレイ
API サーバー メモリ (GB) 38.9 9.7
API サーバー CPU 6.1 4.7
Istiod メモリ (GB) 40.4 42.6
Istiod CPU 15 16

データ プレーンのパフォーマンス

要求のサイズ、プロキシ ワーカーのスレッド数、クライアントの接続数など、さまざまな要素がサイドカーのパフォーマンスに影響を与えます。 さらに、メッシュを流れる要求はすべてクライアント側のプロキシを経由し、次にサーバー側のプロキシを経由します。 そのため、データ プレーンのパフォーマンスを確認するために、待ち時間とリソース消費量が測定されます。

Fortio は、負荷を生成するために使用されました。 テストは、アドオンを使用して変更した Istio ベンチマーク リポジトリで実施されました。

仕様のテスト

  • 2 つのネットワーク プラグインでテスト済み: Azure CNI Overlay および Cilium を使用した Azure CNI Overlay (大規模クラスター用の推奨ネットワーク プラグイン)
  • ノード SKU: Standard D16 v5 (16 vCPU、64 GB メモリ)
  • Kubernetes バージョン: 1.28.5
  • 2 つのプロキシ ワーカー
  • .1 KB のペイロード
  • さまざまなクライアント接続で 1,000 QPS (Queries per second)
  • http/1.1 プロトコルと相互トランスポート層セキュリティ (TLS) が有効
  • 26 データ ポイントが収集済み

CPU とメモリ

すべてのネットワーク プラグイン シナリオにおいて、16 件のクライアント接続、1,000 QPS の場合のクライアント プロキシとサーバー プロキシの両方のメモリと CPU の使用量は、およそ 0.4 vCPU と 72 MB です。

Latency

サイドカー Envoy プロキシは、クライアントに応答した後に生のテレメトリ データを収集します。これは、要求の合計処理時間に直接影響を与えることはありません。 しかし、このプロセスは次の要求の処理開始を遅らせ、キューの待ち時間の一因となり、平均待ち時間やテール レイテンシに影響を与えます。 トラフィック パターンによって、実際のテール レイテンシは異なります。

次の結果はサイドカー プロキシをデータ パスに追加した場合の影響を評価したもので、P90 と P99 の待ち時間を示しています。

  • サイドカー トラフィック パス: client --> client-sidecar --> server-sidecar --> server
  • ベースライン トラフィック パス: client --> server

Istio アドオンと AKS バージョン間のデータ プレーン待ち時間のパフォーマンスの比較については、こちらを参照してください。

Azure CNI オーバーレイ Cilium を使用した Azure CNI オーバーレイ
Azure CNI オーバーレイの P99 待ち時間を比較した図。 Azure CNI オーバーレイと Cilium を使用した P99 待ち時間を比較した図。
Azure CNI オーバーレイの P90 待ち時間を比較した図。 Azure CNI オーバーレイと Cilium の P90 待ち時間を比較した図。

スケーリング

水平ポッドの自動スケーリングのカスタマイズ

水平ポッド自動スケーリング (HPA) は、istiod およびイングレス ゲートウェイのポッドに対して有効になっています。 istiod とゲートウェイのデフォルトの構成は次のとおりです。

  • 最小レプリカ数: 2
  • 最大レプリカ数: 5
  • CPU 使用率: 80%

Note

PodDisruptionBudget との競合を防ぐために、このアドオンでは、minReplicas を初期既定値である 2 より下には設定できません。

istiod とイングレス ゲートウェイの HPA リソースは次のとおりです。

NAMESPACE           NAME                                         REFERENCE
aks-istio-ingress   aks-istio-ingressgateway-external-asm-1-19   Deployment/aks-istio-ingressgateway-external-asm-1-19

aks-istio-ingress   aks-istio-ingressgateway-internal-asm-1-19   Deployment/aks-istio-ingressgateway-internal-asm-1-19

aks-istio-system    istiod-asm-1-19                              Deployment/istiod-asm-1-19

HPA の構成は、パッチおよび直接編集によって変更できます。 例:

kubectl patch hpa aks-istio-ingressgateway-external-asm-1-19 -n aks-istio-ingress --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'

Note

カナリア アップグレード中に両方のリビジョンに HPA 設定を適用する方法の詳細については、Istio アドオンのアップグレードに関するドキュメントを参照してください。

サービス エントリ

Istio の ServiceEntry カスタム リソース定義では、Istio の内部サービス レジストリに他のサービスを追加することができます。 ServiceEntry では、既にメッシュ内にあるサービスが指定されたサービスをルーティングまたはアクセスできるようになります。 ただし、resolution フィールドを DNS に設定した複数の ServiceEntries を構成すると、ドメイン ネーム システム (DNS) サーバーに高負荷がかかる可能性があります。 次の提案は、負荷を軽減するのに役立ちます。

  • プロキシ DNS 検索を完全に回避するには、resolution: NONE に切り替えます。 ほとんどのユース ケースに適しています。
  • 解決されるドメインを制御する場合は、TTL (Time To Live) を増やします。
  • exportTo を使用して ServiceEntry スコープを制限します。