すべてのプロダクト
Search
ドキュメントセンター

Alibaba Cloud Service Mesh:パーソナライズドモードでのトラフィックレーンの準備

最終更新日:Mar 12, 2026

トラフィックレーンは、リクエストヘッダーに基づいて、特定のサービスバージョンを通じてエンドツーエンドのトラフィックをルーティングします。複数のチームが同時に異なる機能を開発している場合、トラフィックレーンは各チームのリクエストフローをフルコールチェーン全体で分離し、バージョン間の相互汚染を防止します。パーソナライズドモードでは、一致しないリクエストは自動的にベースラインサービスにフォールバックされます。

本トピックでは、共通およびシナリオ固有の準備手順について説明します。ご利用のシナリオに該当する手順を完了後、対応するシナリオガイドに進んでください。

ステップタスク適用範囲
1Istio ゲートウェイの作成すべてのシナリオ
2サンプルサービスのデプロイシナリオ 1 およびシナリオ 2
3バゲージヘッダー伝搬の設定シナリオ 3

前提条件

開始前に、以下の要件を満たしていることを確認してください。

ステップ 1:Istio ゲートウェイの作成

istio-system 名前空間に ingressgateway という名前の Istio ゲートウェイを作成します。このゲートウェイはポート 80 で HTTP トラフィックをリッスンし、すべてのホストからのリクエストを受け入れます。詳細については、「Istio ゲートウェイの管理」をご参照ください。

  1. 次の YAML を gateway.yaml というファイル名で保存します。

    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
      name: ingressgateway
      namespace: istio-system
    spec:
      selector:
        istio: ingressgateway
      servers:
        - port:
            number: 80
            name: http
            protocol: HTTP
          hosts:
            - '*'
  2. 構成を適用します。

    kubectl apply -f gateway.yaml
  3. ゲートウェイが作成されたことを確認します。

    kubectl get gateway ingressgateway -n istio-system

    期待される出力:

    NAME              AGE
    ingressgateway    10s

ステップ 2:サンプルサービスのデプロイ

説明

このステップはシナリオ 1およびシナリオ 2にのみ適用されます。シナリオ 3 を使用する場合は、ステップ 3に進んでください。

自動サイドカープロキシ注入の有効化

default 名前空間に対して自動サイドカープロキシ注入を有効化します。詳細については、「自動サイドカープロキシ注入の有効化」をご参照ください。

注入ポリシーの詳細については、「サイドカープロキシ注入ポリシーの設定」をご参照ください。

サービスのデプロイ

ご利用の Container Service for Kubernetes (ACK) クラスターに、サンプルサービスの 3 つのバージョンをデプロイします。

kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-tracing-v1.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-tracing-v2.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-tracing-v3.yaml

すべての Pod が実行中であることを確認します。

kubectl get pods -n default

すべての Pod は Running ステータスで、2/2 のコンテナが準備完了状態(アプリケーションコンテナとサイドカープロキシ)である必要があります。

説明

シナリオ 1 およびシナリオ 2 のサンプルサービスは Golang で記述されています。一方、シナリオ 3 ではバゲージヘッダー伝搬メカニズムが言語固有の要件を持つため、Java ベースのサービスを使用します。詳細については、「自動インストルメンテーションの注入」をご参照ください。

ステップ 3:バゲージヘッダー伝搬の設定

説明

このステップはシナリオ 3にのみ適用されます。

このステップでは、OpenTelemetry オペレーターの自動インストルメンテーション機能を使用して、アプリケーションコードを変更することなく、サービス Pod 間で透過的なバゲージヘッダー伝搬を有効化します。

3a. OpenTelemetry オペレーターのデプロイ

  1. ASM インスタンスに追加済みの Kubernetes クラスターに接続し、opentelemetry-operator-system 名前空間を作成します。

    kubectl create namespace opentelemetry-operator-system
  2. Helm を使用して OpenTelemetry Operator をインストールします。Helm がインストールされていない場合は、「Helm をインストールする」をご参照ください。

    helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
    helm install  \
        --namespace=opentelemetry-operator-system \
        --version=0.46.0 \
        --set admissionWebhooks.certManager.enabled=false \
        --set admissionWebhooks.certManager.autoGenerateCert=true \
        --set manager.image.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/opentelemetry-operator" \
        --set manager.image.tag="0.92.1" \
        --set kubeRBACProxy.image.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/kube-rbac-proxy" \
        --set kubeRBACProxy.image.tag="v0.13.1" \
        --set manager.collectorImage.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/opentelemetry-collector" \
        --set manager.collectorImage.tag="0.97.0" \
        --set manager.opampBridgeImage.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/operator-opamp-bridge" \
        --set manager.opampBridgeImage.tag="0.97.0" \
        --set manager.targetAllocatorImage.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/target-allocator" \
        --set manager.targetAllocatorImage.tag="0.97.0" \
        --set manager.autoInstrumentationImage.java.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/autoinstrumentation-java" \
        --set manager.autoInstrumentationImage.java.tag="1.32.1" \
        --set manager.autoInstrumentationImage.nodejs.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/autoinstrumentation-nodejs" \
        --set manager.autoInstrumentationImage.nodejs.tag="0.49.1" \
        --set manager.autoInstrumentationImage.python.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/autoinstrumentation-python" \
        --set manager.autoInstrumentationImage.python.tag="0.44b0" \
        --set manager.autoInstrumentationImage.dotnet.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/autoinstrumentation-dotnet" \
        --set manager.autoInstrumentationImage.dotnet.tag="1.2.0" \
        --set manager.autoInstrumentationImage.go.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/opentelemetry-go-instrumentation" \
        --set manager.autoInstrumentationImage.go.tag="v0.10.1.alpha-2-aliyun" \
        opentelemetry-operator open-telemetry/opentelemetry-operator
  3. オペレーターが実行中であることを確認します。

    kubectl get pod -n opentelemetry-operator-system

    期待される出力:

    NAME                                      READY   STATUS    RESTARTS   AGE
    opentelemetry-operator-854fb558b5-pvllj   2/2     Running   0          1m

    両方のコンテナ(2/2)が Running ステータスである必要があります。

3b. 自動インストルメンテーションの設定

Instrumentation リソースは、OpenTelemetry オペレーターに対して、サービス Pod にどのようにインストルメンテーションを注入するかを指示します。propagators: [baggage] 設定により、W3C バゲージヘッダー伝搬が有効化され、これによってトラフィックレーンはサービス間でルーティングコンテキストを渡すことができます。

ご利用の環境に合った構成を選択してください。

オプション A:OpenTelemetry Collector がデプロイされていない場合

トレースやメトリックの収集を行わず、トラフィックレーン用のバゲージヘッダー伝搬のみが必要な場合は、この構成を使用します。always_off サンプラーによりトレース収集が無効化され、OTEL_METRICS_EXPORTER: none によりメトリックエクスポートが無効化されるため、テレメトリデータは生成されません。

次の YAML を instrumentation.yaml というファイル名で保存します。

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: demo-instrumentation
spec:
  env:
  - name: OTEL_METRICS_EXPORTER
    value: none
  propagators:
  - baggage
  sampler:
    argument: "1"
    type: always_off

オプション B:OpenTelemetry Collector がデプロイされている場合

クラスター内に OpenTelemetry Collector がデプロイされており、トレースとバゲージヘッダーの両方を収集したい場合は、この構成を使用します。parentbased_traceidratio サンプラーに引数 "1" を指定することで、トレースの 100% がサンプリングされます。

次の YAML を instrumentation.yaml というファイル名で保存します。

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: demo-instrumentation
spec:
  propagators:
    - baggage
  sampler:
    type: parentbased_traceidratio
    argument: "1"
重要

OpenTelemetry Collector がデプロイされていない場合、メトリック収集およびトレーシング分析を有効化することはできません。ASM トレースデータを OpenTelemetry 向けマネージドサービスに収集する方法については、「ASM トレースデータを OpenTelemetry 向けマネージドサービスに収集する」をご参照ください。

Instrumentation リソースを default 名前空間に適用します。

kubectl apply -f instrumentation.yaml -n default

Instrumentation リソースを確認します。

kubectl describe instrumentation demo-instrumentation -n default

出力には、設定されたプロパゲーターおよびサンプラーの設定が表示される必要があります。

説明

個々の Pod に対して自動インストルメンテーションを有効化するために必要なアノテーション手順は、シナリオ 3で説明されています。OpenTelemetry Collector のデプロイは本トピックの範囲外です。ASM トレースデータを収集するには、「ASM トレースデータを OpenTelemetry 向けマネージドサービスに収集する」をご参照ください。

次のステップ

ご利用のユースケースに合ったシナリオに進んでください。

シナリオ使用タイミング必要なステップ
シナリオ 1: Baggage ヘッダーがアプリケーションによって伝播されないサービスがバゲージヘッダーを伝搬しない場合ステップ 1、ステップ 2
シナリオ 2:アプリケーションによる Baggage ヘッダーの伝播サービスは既にアプリケーション コード内でバゲージ ヘッダーを伝搬していますステップ 1、ステップ 2
シナリオ 3:透過的なバゲージヘッダー伝搬アプリケーション コードを変更することなく自動バゲージ伝搬ステップ 1、ステップ 3