すべてのプロダクト
Search

このプロダクト

    Alibaba Cloud Service Mesh:サイドカー推奨有効化後の構成プッシュ最適化

    ドキュメントセンター

    Alibaba Cloud Service Mesh:サイドカー推奨有効化後の構成プッシュ最適化

    最終更新日:Jan 13, 2025

    単一のネームスペースに多数のサービスをデプロイしている場合は、サイドカー推奨機能を使用して、サイドカー構成のサイズを最大限に縮小できます。このトピックでは、420 個の Pod を持つ大規模クラスターを使用して、サイドカー推奨が有効になった後の Service Mesh (ASM) の構成プッシュの最適化をテストおよび分析します。

    前提条件

    テストクラスターへのアプリケーションのデプロイ

    このテストでは、ns-in-mesh ネームスペースに複数の sleep アプリケーションと HTTPBin アプリケーションを作成して、クラスター内で呼び出し依存関係が少ない多数のサービスをシミュレートします。ネームスペースの作成方法の詳細については、「グローバルネームスペースの管理」をご参照ください。

    • HTTPBin アプリケーションが起動すると、HTTPBin アプリケーションはポート 8000 で HTTP サービスを公開します。これらの HTTP サービスは、クラスター内で呼び出される多数のサービスをシミュレートします。

    • 各 sleep アプリケーションには、curl コンテナが含まれています。sleep アプリケーションの構成ファイルの command フィールドを変更できます。このようにして、sleep アプリケーションがスリープ状態に入る前に、複数の HTTPBin コンテナによって提供されるサービスを呼び出すように sleep アプリケーションを構成できます。これらの sleep アプリケーションによって提供されるサービスは、クラスター内の他のサービスに依存するサービスをシミュレートします。

    1. クラスターに HTTPBin アプリケーションをデプロイします。

      1. 次のテンプレートに基づいて、httpbin-{i} という名前の YAML ファイルを作成します。

        説明

        httpbin-{i} の {i} を特定の番号に置き換えます。このようにして、異なる ID を持つ複数の HTTPBin アプリケーションを作成できます。このテンプレートを使用して、必要な数の HTTPBin アプリケーションを生成できます。生成できるアプリケーションの最大数は、クラスターのサイズによって異なります。この例では、このテンプレートを使用して 200 個の HTTPBin アプリケーションが生成され、クラスターに 400 個の Pod がデプロイされて HTTPBin アプリケーションを実行します。

        展開して HTTPBin アプリケーションの YAML テンプレートを表示する

        apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: httpbin-{i}
    service: httpbin-{i}
  name: httpbin-{i}
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin-0  // HTTPBin アプリケーションのセレクター
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: httpbin-{i}
  name: httpbin-{i}
spec:
  replicas: 2
  selector:
    matchLabels:
      app: httpbin-{i}
      version: v1
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: httpbin-{i}
        version: v1
    spec:
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80
      serviceAccountName: httpbin

      2. 次のコマンドを実行して、httpbin-{i} アプリケーションを作成します。

        kubectl apply -f httpbin-{i}.yaml

        予期される出力：

        deployment.apps/httpbin-{i} created

    2. クラスターに sleep アプリケーションをデプロイします。

      1. 次のテンプレートに基づいて、sleep-{i} という名前の YAML ファイルを作成します。

        説明

        sleep-{i} の {i} を特定の番号に置き換えます。このようにして、異なる ID を持つ複数の sleep アプリケーションを作成できます。このテンプレートでは、args フィールドに追加される curl httpbin-{i*10}:8000 コマンドパラメーターは、異なる HTTPBin アプリケーションへの呼び出し依存関係をシミュレートします。コマンドパラメーターで指定する HTTPBin アプリケーションの ID は、デプロイされている HTTPBin アプリケーションの最大 ID を超えてはなりません。超えると、有効な呼び出しを行うことができません。このテストでは、各 sleep アプリケーションは 10 個の HTTPBin アプリケーションに依存しています。したがって、20 個の sleep アプリケーションが作成され、20 個の Pod がデプロイされて sleep アプリケーションを実行します。

        展開して sleep アプリケーションの YAML テンプレートを表示する

        apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: sleep-{i}
    service: sleep-{i}
  name: sleep-{i}
spec:
  ports:
  - name: http
    port: 80
    targetPort: 0  // sleep アプリケーションの targetPort
  selector:
    app: sleep-{i}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: sleep-{i}
  name: sleep-{i}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep-{i}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: sleep-{i}
    spec:
      containers:
      - args:
        - curl httpbin-{i*10}:8000; curl httpbin-{i*10+1}:8000; curl httpbin-{i*10+2}:8000; curl httpbin-{i*10+3}:8000;
          curl httpbin-{i*10+4}:8000; curl httpbin-{i*10+5}:8000; curl httpbin-{i*10+6}:8000; curl httpbin-{i*10+7}:8000;
          curl httpbin-{i*10+8}:8000; curl httpbin-{i*10+9}:8000; sleep 3650d // sleep アプリケーションの curl コマンド
        command:
        - /bin/sh
        - -c
        image: curlimages/curl
        imagePullPolicy: IfNotPresent
        name: sleep
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      serviceAccountName: sleep
      terminationGracePeriodSeconds: 0
      volumes:
      - name: secret-volume
        secret:
          optional: true
          secretName: sleep-secret

      2. 次のコマンドを実行して、sleep-{i} アプリケーションを作成します。

        kubectl apply -f sleep-{i}.yaml

        予期される出力：

        deployment.apps/sleep-{i} created

    サイドカー推奨を有効にする前のコントロールプレーンの構成プッシュのテスト

    テスト 1：サイドカー推奨を有効にする前の各サイドカーの構成サイズをテストする

    1. 次のコマンドを実行して、httpbin-0 アプリケーションを実行する Pod の名前を取得します。

      kubectl get pod -n ns-in-mesh | grep httpbin-0

      予期される出力：

      NAME                         READY   STATUS    RESTARTS   AGE
httpbin-0-756995d867-jljgp   2/2     Running   0          9m15s
httpbin-0-756995d867-whstr   2/2     Running   0          9m15s

    2. 次のコマンドを実行して、httpbin-0 アプリケーションを実行する Pod 内のサイドカーの構成をローカルファイルにダンプします。

      kubectl exec -it httpbin-0-756995d867-jljgp -c istio-proxy -n ns-in-mesh -- curl -s localhost:15000/config_dump > config_dump.json

    3. 次のコマンドを実行して、構成ファイルのサイズを表示します。

      du -sh config_dump.json

      予期される出力：

      1.2M    config_dump.json

      上記の出力は、クラスターに 420 個の Pod がデプロイされている場合、サイドカーの構成サイズが約 1.2 MB であることを示しています。クラスター内の各 Pod にサイドカーが作成されると、これらのサイドカーの構成はかなりのサイズに達し、コントロールプレーンの構成プッシュの負荷が増加します。

    シナリオ 2：サイドカー推奨を有効にする前のコントロールプレーンの構成プッシュ効率をテストする

    ASM コンソールで httpbin-0 アプリケーションの仮想サービスを作成します。これにより、コントロールプレーンがデータプレーンのサイドカーに構成をプッシュします。コントロールプレーンのログを表示して、1 回の構成プッシュにおけるコントロールプレーンの効率を確認できます。コントロールプレーンログ収集を有効にする方法の詳細については、「1.17.2.35 より前のバージョンの ASM インスタンスでコントロールプレーンログ収集とログベースのアラーティングを有効にする」をご参照ください。

    1. 次のコンテンツを含む YAML ファイルを使用して、Service Mesh インスタンスで httpbin-0 アプリケーションの仮想サービスを作成して、リクエストのタイムアウトを処理します。仮想サービスの作成方法の詳細については、「仮想サービスの管理」をご参照ください。

      apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-0-timeout
  namespace: default
spec:
  hosts:
    - httpbin-0.default.svc.cluster.local
  http:
    - route:
        - destination:
            host: httpbin-0.default.svc.cluster.local
      timeout: 5s

    2. 新しく生成されたコントロールプレーンログを表示します。

      バージョン 1.17.2.35 以降の ASM インスタンスの場合

      1. ASM コンソール にログインします。左側のナビゲーションペインで、[service Mesh] > [メッシュ管理] を選択します。

      2. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、[可観測性管理センター] > [ログセンター] を選択します。

      3. [ログセンター] ページで、[コントロールプレーンログ] タブをクリックしてログを表示します。

      バージョン 1.17.2.35 より前の ASM インスタンスの場合

      1. ASM コンソール にログインします。

      2. 左側のナビゲーションペインで、[service Mesh] > [メッシュ管理] を選択します。

      3. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。

      4. ASM インスタンスの詳細ページで、[ASM インスタンス] > [基本情報] を選択します。

      5. 表示されるページで、ログの表示[コントロールプレーンログ収集] の右側にある をクリックします。

      ログのサンプル：

      021-12-01T10:20:09.708673Z info  ads CDS: PUSH for node:httpbin-27-7dd8578b46-nkmvg.default resources:227 size:169.3kB // コントロールプレーンログの例
2021-12-01T10:20:09.710469Z info  ads CDS: PUSH for node:httpbin-184-65d97797db-njst5.default resources:227 size:169.3kB
2021-12-01T10:20:09.713567Z info  ads CDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:227 size:169.3kB
2021-12-01T10:20:09.714514Z info  ads LDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:16 size:70.7kB
2021-12-01T10:20:09.792732Z info  ads LDS: PUSH for node:httpbin-27-7dd8578b46-nkmvg.default resources:16 size:70.7kB
2021-12-01T10:20:09.792982Z info  ads LDS: PUSH for node:httpbin-184-65d97797db-njst5.default resources:16 size:70.7kB
2021-12-01T10:20:09.796430Z info  ads RDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:8 size:137.4kB
...
2021-12-01T10:20:13.405850Z info  ads RDS: PUSH for node:httpbin-156-68b85b4f79-2znmp.default resources:8 size:137.4kB
2021-12-01T10:20:13.406154Z info  ads RDS: PUSH for node:httpbin-121-7c4cff97b9-sn5g4.default resources:8 size:137.4kB
2021-12-01T10:20:13.406420Z info  ads CDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:227 size:169.3kB
2021-12-01T10:20:13.407230Z info  ads LDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:16 size:70.7kB
2021-12-01T10:20:13.410147Z info  ads RDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:8 size:137.4kB
2021-12-01T10:20:13.494840Z info  ads RDS: PUSH for node:httpbin-57-69b756f779-db7vv.default resources:8 size:137.4kB

      上記のコンテンツは、仮想サービスが追加された後、コントロールプレーンがデータプレーンのすべてのサイドカーに構成の変更をプッシュすることを示しています。420 個の Pod がデプロイされているクラスターでは、多数のプッシュログが生成されます。各サイドカーにプッシュされるデータ量は大きくなります。Service Mesh インスタンスに仮想サービスを適用するために、コントロールプレーンがデータプレーンに構成をプッシュするのに約 4 秒かかります。コントロールプレーンの構成プッシュ効率は低くなります。

    サイドカー推奨を有効にした後のコントロールプレーンの構成プッシュのテスト

    サイドカー推奨機能を使用して、アクセスログ分析に基づいてテストクラスター内の各ワークロードにサイドカーを推奨します。これは、コントロールプレーンの構成プッシュ効率を向上させるのに役立ちます。詳細については、「アクセスログ分析に基づいて自動的に推奨されるサイドカーを使用する」をご参照ください。

    テスト 1：サイドカー推奨を有効にした後の各サイドカーの構成サイズをテストする

    1. 次のコマンドを実行して、httpbin-0 アプリケーションを実行する Pod 内のサイドカーの構成をローカルファイルにダンプします。

      kubectl exec -it httpbin-0-756995d867-jljgp -c istio-proxy -n ns-in-mesh -- curl -s localhost:15000/config_dump > config_dump.json

    2. 次のコマンドを実行して、構成ファイルのサイズを表示します。

      du -sh config_dump.json

      予期される出力：

      105k    config_dump.json

      上記の出力は、420 個の Pod がデプロイされているクラスターでサイドカー推奨を有効にすると、サイドカーの構成サイズが 10 倍以上削減されることを示しています。コントロールプレーンからデータプレーンのサイドカーへの構成のプッシュ効率が大幅に向上します。

    シナリオ 2：サイドカー推奨を有効にした後のコントロールプレーンの構成プッシュ効率をテストする

    ASM コンソールで httpbin-0 アプリケーションの仮想サービスを再度作成します。これにより、コントロールプレーンがデータプレーンのサイドカーに構成をプッシュします。

    1. Service Mesh インスタンスで以前に作成した仮想サービスを削除します。次のコンテンツを含む YAML ファイルを使用して、Service Mesh インスタンスで httpbin-0 アプリケーションの仮想サービスを作成して、リクエストのタイムアウトを処理します。仮想サービスの作成方法の詳細については、「仮想サービスの管理」をご参照ください。

      apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-0-timeout
  namespace: default
spec:
  hosts:
    - httpbin-0.default.svc.cluster.local
  http:
    - route:
        - destination:
            host: httpbin-0.default.svc.cluster.local
      timeout: 5s

    2. 新しく生成されたコントロールプレーンログを表示します。

      バージョン 1.17.2.35 以降の ASM インスタンスの場合

      1. ASM コンソール にログインします。左側のナビゲーションペインで、[service Mesh] > [メッシュ管理] を選択します。

      2. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、[可観測性管理センター] > [ログセンター] を選択します。

      3. [ログセンター] ページで、[コントロールプレーンログ] タブをクリックしてログを表示します。

      バージョン 1.17.2.35 より前の ASM インスタンスの場合

      1. ASM コンソール にログインします。

      2. 左側のナビゲーションペインで、[service Mesh] > [メッシュ管理] を選択します。

      3. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。

      4. ASM インスタンスの詳細ページで、[ASM インスタンス] > [基本情報] を選択します。

      5. 表示されるページで、[ログの表示][コントロールプレーンログ収集] の右側をクリックします。

      ログのサンプル：

      2021-12-01T12:12:43.498048Z info  ads Push debounce stable[750] 1: 100.03379ms since last change, 100.033692ms since last push, full=true // コントロールプレーンログの例
2021-12-01T12:12:43.504270Z info  ads XDS: Pushing:2021-12-01T12:12:43Z/493 Services:230 ConnectedEndpoints:421  Version:2021-12-01T12:12:43Z/493
2021-12-01T12:12:43.507451Z info  ads CDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:14 size:7.8kB
2021-12-01T12:12:43.507739Z info  ads LDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:3 size:15.5kB
2021-12-01T12:12:43.508029Z info  ads RDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:1 size:6.3kB

      上記のコンテンツは、サイドカー推奨が有効になった後、データプレーンの各ワークロードは、ワークロードが依存関係を持たないサービスに関連する変更を受信しないことを示しています。httpbin-0 アプリケーションの仮想サービスを作成した後、コントロールプレーンは sleep-0 アプリケーションを実行する Pod 内のサイドカーにのみ構成の変更をプッシュします。これは、sleep-0 アプリケーションのみが httpbin-0 アプリケーションとの依存関係を持っているためです。構成のプッシュは約 0.01 秒で完了します。最適化前の時間と比較すると、構成プッシュ効率は約 400 倍向上します。さらに、プッシュされるデータ量は約 10 倍削減されます。これは、サイドカー推奨機能が、コントロールプレーンがデータプレーンに構成をプッシュする効率を大幅に向上させることができることを示しています。

    テストサマリー

    このテストでは、複数の sleep アプリケーションと HTTPBin アプリケーションを使用して、クラスター内で呼び出し依存関係が少ない多数のサービスをシミュレートします。合計 200 個の HTTPBin アプリケーション、HTTPBin アプリケーションを実行する 400 個の Pod、20 個の sleep アプリケーション、および sleep アプリケーションを実行する 20 個の Pod がデプロイされます。次の表に、サイドカー推奨を有効にする前後の比較を示します。

    項目

    サイドカー推奨を有効にする前

    サイドカー推奨を有効にした後

    サイドカー構成サイズ

    1.2 MB

    105 KB

    無関係なサービスに関する情報がプッシュされるかどうか

    はい

    いいえ

    コントロールプレーンが構成をプッシュするのにかかる時間

    約 4 秒

    約 0.01 秒