コントロールプレーンが大量の無関係な構成を非効率的にプッシュしている場合は、適応型 xds 最適化機能を使用してプッシュ効率を向上させることができます。この機能は、サービス間の呼び出し関係を分析して、最適化された Sidecar リソースを自動的に生成します。その後、必要な構成のみを対象のサービスにプッシュし、ネットワーク通信を削減してサービスメッシュのパフォーマンスと応答性を向上させます。
-
適応型 xds 最適化を有効にするには、ASM インスタンスのバージョンが 1.15.3.63 以降である必要があります。インスタンスのアップグレード方法の詳細については、「ASMインスタンスのアップグレード」をご参照ください。
-
適応型 xds 最適化機能は、HTTP プロトコルを使用するサービスのみをサポートします。
背景情報
デフォルトでは、サービスメッシュはサービス間の呼び出し依存関係を判断できません。そのため、Sidecar 構成にはデータプレーン内のすべてのサービスに関する情報が保存されます。コントロールプレーンまたはデータプレーンへの変更 (コントロールプレーンでの新しい仮想サービスルールの作成など) が発生するたびに、コントロールプレーンはデータプレーン内のすべての Sidecar に新しい構成をプッシュします。
この問題に対処するため、適応型 xds 最適化機能を有効にすると、構成プッシュを最適化する Sidecar リソースが自動的に作成されます。この機能を有効にすると、istio-axds-egressgateway という名前の Egress ゲートウェイがクラスターにデプロイされます。すべての初期 HTTP トラフィックはこの Egress ゲートウェイに転送され、アクセスログに基づいてサービス依存関係が自動的に分析されます。このプロセスは完全に自動化されています。Sidecar リソースによる最適化効果の詳細については、「Sidecarリソースによる構成プッシュの最適化」をご参照ください。
前提条件
-
Helm がインストールされていること。
ステップ 1：適応型 xds 最適化の有効化
ASM コンソール にログインします。左側のナビゲーションウィンドウで、 を選択します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
-
Adaptive xds optimization ページで、Enable adaptive xds optimization スイッチをオンにします。Confirm ダイアログボックスで、OK をクリックします。
OK をクリックすると、Enable adaptive xds optimization スイッチの下に Updating ステータスが表示されます。更新が完了すると、Enable adaptive xds optimization スイッチがオンになり、その下に適応型最適化が可能な名前空間のリストが表示されます。
ステップ 2：名前空間の最適化の有効化
名前空間で適応型 xds 最適化を有効にすると、この機能は Sidecar リソースを使用して、その名前空間内のすべてのサービスを自動的に最適化します。または、サービスのannotationsにasm.alibabacloud.com/asm-adaptive-xds: trueを追加することで、特定のサービスでこの機能を有効にすることもできます。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
-
Adaptive xds optimization ページの Select namespaces to be optimized リストで、対象サービスの名前空間の横にあるスイッチをオンにします。この例では、default 名前空間を使用します。Confirm ダイアログボックスで、OK をクリックします。
ASM インスタンスの詳細ページで、左側のナビゲーションウィンドウの を選択します。
-
Sidecar Traffic Configuration ページで、Sidecar リソースの詳細を確認します。
名前が axds で始まる、自動的に作成された Sidecar リソースが表示されます。各 Sidecar リソースは、前提条件でデプロイした Bookinfo アプリケーションのサービスに対応しています。ページには、axds-details (スコープ
app:details)、axds-productpage (スコープapp:productpage)、axds-ratings (スコープapp:ratings)、axds-reviews (スコープapp:reviews) の 4 つの Sidecar リソースが表示されます。すべてのリソースの Source は System で、Namespace はdefaultです。
ステップ 3：最適化のトリガー
-
ブラウザーのアドレスバーに
http://{Ingress ゲートウェイの IP アドレス}/productpageと入力して、Bookinfo アプリケーションにアクセスします。{Ingress ゲートウェイの IP アドレス}は、前のステップで取得した IP アドレスに置き換えてください。 -
適応型最適化された Sidecar リソースを確認します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
-
Sidecar Traffic Configuration ページで、axds-productpage リソースを見つけ、Actions 列の View YAML をクリックします。以下は例です。
apiVersion: networking.istio.io/v1beta1 kind: Sidecar metadata: annotations: adapted-svc: productpage.default.svc.cluster.local creationTimestamp: '2024-01-05T07:52:56Z' generation: 4 labels: asm-adaptive-xds-system: 'true' asm-system: 'true' provider: asm name: axds-productpage namespace: default resourceVersion: '23688435' uid: 753e3603-6bee-4dd1-b1fc-2e735a88**** spec: egress: - hosts: - arms-prom/* - default/details.default.svc.cluster.local - default/kubernetes.default.svc.cluster.local - default/reviews.default.svc.cluster.local - istio-system/* - kube-system/* workloadSelector: labels: app: productpageBookinfo アプリケーションにアクセスすると、
productpageサービスを最適化するために生成された Sidecar リソースaxds-productpageが、productpageサービスが依存するdetailsサービスとreviewsサービスを自動的に追加するため、手動設定は不要であることがわかります。
適応型 xds 最適化：パフォーマンスの比較
以下のテストでは、asm-perf 名前空間におけるコントロールプレーンとデータプレーンのパフォーマンスを、適応型 xds 最適化を無効にした場合と有効にした場合の 2 つのシナリオで比較します。
-
ワークロードのスケールアウト：
httpbinDeployment を 2 レプリカから 400 レプリカにスケールアウトします。 -
テストトラフィックの開始：
sleepアプリケーションから異なるhttpbinアプリケーションにランダムなリクエストを送信し、新しい適応型構成プッシュをトリガーします。 -
ワークロードの再起動：
httpbinアプリケーションの再デプロイをトリガーして、ワークロードのスケーリングと更新のシナリオをシミュレートします。
ステップ 1：環境の準備
-
サンプルスクリプトリポジトリをクローンします。
git clone https://github.com/AliyunContainerService/asm-labs.git && \ cd asm-labs/asm-perf/adaptivexds -
テスト環境をセットアップします。
bash run.sh -sこのコマンドは、クラスターに次のリソースを作成します。
-
asm-perf名前空間。 -
監視用の
prometheusおよびgrafanaワークロード。 -
1 つの
sleepアプリケーションと、構成プッシュを受信する 2 レプリカのhttpbinアプリケーション。
次のコマンドを実行して、監視ダッシュボードへのポートフォワーディングを行います。その後、
localhost:3000にアクセスしてダッシュボードを表示できます。kubectl port-forward svc/grafana -n asm-perf 3000 -
ステップ 2：パフォーマンスの比較
-
ワークロードをスケールアウトします。
bash run.sh -suしばらく待ってから、ダッシュボードを確認します。以下のような結果になります。
適応型 xds 最適化を無効にした場合
sleep アプリケーションの CPU 使用率
sleep アプリケーションのメモリ使用量
sleep アプリケーションのネットワーク帯域幅
コントロールプレーンのトラフィック
-
ASM インスタンスの Base Information ページで、Istio Pilot負荷バランス に関連付けられた CLB ID を記録します。
-
Classic Load Balancer (CLB) コンソールにログインします。対応する CLB の モニタリング アイコンをクリックし、 を選択して、[Listener Traffic] グラフを表示します。
メッシュ内のサービスが変更されると、コントロールプレーンが新しい構成をプッシュするため、パフォーマンスのオーバーヘッドが発生します。
適応型 xds 最適化を有効にした場合
sleep アプリケーションの CPU 使用率
sleep アプリケーションのメモリ使用量
sleep アプリケーションのネットワーク帯域幅
コントロールプレーンのトラフィック
メッシュ内のサービスが変更されると、コントロールプレーンが新しい構成をプッシュするため、パフォーマンスのオーバーヘッドが発生します。ただし、適応型 xds 最適化を無効にした場合と比較して、パフォーマンスへの影響は低くなります。
Sidecar リソースの構成
-
sleepアプリケーションのアクティブな Sidecar リソース構成を表示します。kubectl get sidecar axds-sleep -n asm-perf -o yaml期待される出力：
apiVersion: networking.istio.io/v1 kind: Sidecar metadata: annotations: adapted-svc: sleep.asm-perf.svc.cluster.local creationTimestamp: "2024-04-03T03:09:42Z" generation: 2 labels: asm-adaptive-xds-system: "true" asm-system: "true" provider: asm name: axds-sleep namespace: asm-perf resourceVersion: "14844729886" uid: 31dfc081-b0ec-403f-b420-91f3c3e5f8fb spec: egress: - hosts: - arms-prom/* - asm-perf/grafana.asm-perf.svc.cluster.local - default/kubernetes.default.svc.cluster.local - istio-system/* - kube-system/* workloadSelector: labels: app: sleepspec.egress.hostsフィールドには複数のサービスがリストされています。これは、リストされているこれらのサービスへの変更のみが、sleepアプリケーションへの構成の再プッシュをトリガーすることを意味します。Sidecar リソースのパフォーマンスへの影響の詳細については、「Sidecarリソースによる構成プッシュの最適化」をご参照ください。
-
-
テストトラフィックを開始します。
sleepアプリケーションから異なるhttpbinアプリケーションに合計 100 件のランダムなリクエストを送信します。bash run.sh -tリクエストが完了したら、再度ダッシュボードを確認します。
適応型 xds 最適化を無効にした場合
sleep アプリケーションの CPU 使用率
sleep アプリケーションのメモリ使用量
sleep アプリケーションのネットワーク帯域幅
コントロールプレーンのトラフィック
適応型 xds 最適化を無効にした場合、各ワークロードはすでに完全な構成を保持しているため、
sleepアプリケーションからトラフィックを開始しても構成配信には影響しません。適応型 xds 最適化を有効にした場合
sleep アプリケーションの CPU 使用率
sleep アプリケーションのメモリ使用量
sleep アプリケーションのネットワーク帯域幅
コントロールプレーンのトラフィック
sleepアプリケーションからトラフィックを開始すると、コントロールプレーンからの構成プッシュがトリガーされます。Sidecar リソースの構成
-
sleepアプリケーションのアクティブな Sidecar リソース構成を表示します。kubectl get sidecar axds-sleep -n asm-perf -o yaml期待される出力：
spec.egress.hostsフィールドには複数のサービスがリストされています。これは、リストされているこれらのサービスへの変更のみが、sleepアプリケーションへの構成の再プッシュをトリガーすることを意味します。Sidecar リソースのパフォーマンスへの影響の詳細については、「Sidecarリソースによる構成プッシュの最適化」をご参照ください。
-
-
ワークロードを再起動します。
bash run.sh -rすべてのワークロードが再起動したら、コントロールプレーンのトラフィックの変化を確認します。
適応型 xds 最適化を無効にした場合
コントロールプレーンのトラフィック
メッシュ内のサービスが変更されると、コントロールプレーンが新しい構成をプッシュするため、パフォーマンスのオーバーヘッドが発生します。
適応型 xds 最適化を有効にした場合
コントロールプレーンのトラフィック
ワークロードを再起動する際、適応型 xds 最適化を無効にした場合と比較して、構成プッシュの量が大幅に削減されます。
-
テスト環境を復元します。
bash run.sh -sdhttpbinアプリケーションの Pod が 400 から 2 にスケールダウンし、環境が初期状態に復元されるまでに約 2 分かかります。
関連操作
適応型 xds 最適化の無効化
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
-
Adaptive xds optimization ページで、Enable adaptive xds optimization スイッチをオフにします。Confirm ダイアログボックスで、OK をクリックします。
OK をクリックすると、Enable adaptive xds optimization スイッチの下に Updating が表示されます。更新が完了すると、Enable adaptive xds optimization スイッチがオフになります。
-
インスタンスの詳細ページで、左側メニューから を選択します。
適応型 xds 最適化機能によって作成された Sidecar リソースが削除されています。
Egress ゲートウェイ構成の変更
適応型 xds 最適化を有効にすると、istio-axds-egressgateway という名前の Egress ゲートウェイが Container Service for Kubernetes (ACK) クラスターにデプロイされます。このゲートウェイは、ACK コンソールのターゲットクラスターの ページで確認できます。すべての初期 HTTP トラフィックはこの Egress ゲートウェイに転送され、アクセスログからサービス依存関係が自動的に分析されます。必要に応じて、Egress ゲートウェイ構成を変更して、さまざまなトラフィック負荷に対応できます。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
-
[Adaptive xds optimization] ページで、[Egress Gateway Configuration] タブをクリックします。必要に応じて Egress ゲートウェイ構成を変更し、Update Settings をクリックします。
Update Settings をクリックすると、サービスメッシュは一時的に更新状態になります。更新が完了すると、Egress ゲートウェイは指定された構成で更新されます。
説明ASM では、Egress ゲートウェイのリソース設定、ゲートウェイレプリカ数、HPA 自動スケーリングステータス、HPA メトリック監視しきい値、HPA レプリカの最大数と最小数を変更できます。