トラフィックレーンは、リクエストヘッダーに基づいて、特定のサービスバージョンを通じてエンドツーエンドのトラフィックをルーティングします。複数のチームが同時に異なる機能を開発している場合、トラフィックレーンは各チームのリクエストフローをフルコールチェーン全体で分離し、バージョン間の相互汚染を防止します。パーソナライズドモードでは、一致しないリクエストは自動的にベースラインサービスにフォールバックされます。
本トピックでは、共通およびシナリオ固有の準備手順について説明します。ご利用のシナリオに該当する手順を完了後、対応するシナリオガイドに進んでください。
| ステップ | タスク | 適用範囲 |
|---|---|---|
| 1 | Istio ゲートウェイの作成 | すべてのシナリオ |
| 2 | サンプルサービスのデプロイ | シナリオ 1 およびシナリオ 2 |
| 3 | バゲージヘッダー伝搬の設定 | シナリオ 3 |
前提条件
開始前に、以下の要件を満たしていることを確認してください。
Enterprise Edition または Ultimate Edition の Service Mesh (ASM) インスタンス(バージョン 1.18.2.111 以降)。インスタンスを作成またはスペックアップするには、「ASM インスタンスの作成」または「ASM インスタンスのスペックアップ」をご参照ください。
ASM インスタンスに追加されたクラスターです。詳細については、「ASM インスタンスにクラスターを追加する」をご参照ください。
ingressgatewayという名前の ASM イングレスゲートウェイ。詳細については、「イングレスゲートウェイの作成」をご参照ください。
ステップ 1:Istio ゲートウェイの作成
istio-system 名前空間に ingressgateway という名前の Istio ゲートウェイを作成します。このゲートウェイはポート 80 で HTTP トラフィックをリッスンし、すべてのホストからのリクエストを受け入れます。詳細については、「Istio ゲートウェイの管理」をご参照ください。
次の 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: - '*'構成を適用します。
kubectl apply -f gateway.yamlゲートウェイが作成されたことを確認します。
kubectl get gateway ingressgateway -n istio-system期待される出力:
NAME AGE ingressgateway 10s
ステップ 2:サンプルサービスのデプロイ
自動サイドカープロキシ注入の有効化
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 オペレーターのデプロイ
ASM インスタンスに追加済みの Kubernetes クラスターに接続し、
opentelemetry-operator-system名前空間を作成します。kubectl create namespace opentelemetry-operator-systemHelm を使用して 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オペレーターが実行中であることを確認します。
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 defaultInstrumentation リソースを確認します。
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 |