Envoy を使用して高度なトラフィック管理を構成する
構成はプレビュー版をご利用のお客様に対してサポートされていますが、新規の Cloud Service Mesh ユーザーにはおすすめしません。詳細については、Cloud Service Mesh サービス ルーティングの概要をご覧ください。
このドキュメントでは、Envoy を使用する Cloud Service Mesh のデプロイ用に高度なトラフィック管理を構成する方法について説明します。
始める前に
高度なトラフィック管理を構成する前に、Envoy を使用して Cloud Service Mesh の設定を準備するの手順に沿って、Cloud Service Mesh と仮想マシン(VM)ホストまたは必要な Google Kubernetes Engine(GKE)クラスタを構成します。必要な Google Cloud リソースを作成します。
高度なトラフィック管理機能の可用性は、選択したリクエスト プロトコルによって異なります。このプロトコルは、ターゲット HTTP または HTTPS プロキシ、ターゲット gRPC プロキシ、またはターゲット TCP プロキシ リソースを使用してルーティングを構成するときに構成されます。
- ターゲット HTTP プロキシとターゲット HTTPS プロキシでは、このドキュメントで説明するすべての機能を使用できます。
- ターゲット gRPC プロキシでは、一部の機能を使用できます。
- ターゲット TCP プロキシでは、高度なトラフィック管理機能は使用できません。
詳細については、Cloud Service Mesh の機能と高度なトラフィック管理をご覧ください。 エンドツーエンドの設定ガイドについては、プロキシレス gRPC サービスを使用して高度なトラフィック管理を構成するをご覧ください。
トラフィック分割を設定する
ここでは、次のことを想定しています。
- Cloud Service Mesh のデプロイに
review-url-map
という URL マップがあります。 - URL マップは、デフォルトのバックエンド サービスとして機能する
review1
という 1 つのバックエンド サービスにすべてのトラフィックを送信します。 - トラフィックの 5% を新しいバージョンのサービスにルーティングする予定です。このサービスは、バックエンド サービス
review2
に関連付けられたネットワーク エンドポイント グループ(NEG)のバックエンド VM またはエンドポイントで実行されます。 - ホストルールやパスマッチャーは使用しません。
URL マップでまだ参照されていない新しいサービスにトラフィックを分割する場合は、まず新しいサービスを weightedBackendServices
に追加し、それに 0
の重みを設定します。次に、そのサービスに割り当てられた重みを徐々に増やしていきます。
トラフィック分割を設定する手順は次のとおりです。
コンソール
Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。
[ルーティング ルール マップ] をクリックします。
[
ルーティング ルール マップを作成] をクリックします。[ルーティング ルール マップを作成] ページで、名前を入力します。
[プロトコル] メニューで [HTTP] を選択します。
既存の転送ルールを選択します。
[ルーティング ルール] で [詳細なホスト、パス、ルートのルール] を選択します。
[ホストとパスのマッチャー] で、[
Add hosts and path matcher] をクリックします。これにより、トラフィックを分割するように構成できる新しいパスマッチャーが追加されます。[パスマッチャー] フィールドに次の設定を追加します。
- defaultService: global/backendServices/review1 name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: '' routeAction: weightedBackendServices: - backendService: global/backendServices/review1 weight: 95 - backendService: global/backendServices/review2 weight: 5
[完了] をクリックします。
[保存] をクリックします。
新しいバージョンに問題がないことを確認したら、2 つのサービスの重みを徐々に調整し、最終的にはすべてのトラフィックを review2
に送信できます。
gcloud
gcloud export
コマンドを使用して、URL マップの構成を取得します。gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yaml
review-url-map-config.yaml
ファイルに次のセクションを追加します。hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/review1 name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: '' routeAction: weightedBackendServices: - backendService: global/backendServices/review1 weight: 95 - backendService: global/backendServices/review2 weight: 5
URL マップを更新します。
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
新しいバージョンに問題がないことを確認したら、2 つのサービスの重みを徐々に調整し、最終的にはすべてのトラフィックを review2
に送信できます。
部分的なリリースを設定する
カナリア処理と呼ばれる部分的デプロイ プロセスを使用して、新しいソフトウェア バージョンをごく少数のサーバーにリリースしてから、新しいバージョンを本番環境サーバーの残高にリリースします。
部分的なリリースの場合、weightedBackendServices
が使用されます。部分的なリリースを有効にするには、バックエンド サービスをテストまたはカナリア サービスとして指定し、重み付けをします(2 または 5 など)。これらのサーバーにのみ新しいソフトウェア バージョンをデプロイします。新しいバージョンに問題がないことを確認したら、残りのサービスにデプロイします。
- 部分的なリリースを有効にするには、次の YAML コードサンプルを使用します。
pathMatchers: - defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_PARTIAL_URL weight: 2 - backendService: BACKEND_SERVICE_URL weight: 98
DEFAULT_SERVICE_URL
は、サービスのデフォルトの URL です。BACKEND_SERVICE_PARTIAL_URL
は、トラフィックの 2% を受信するバックエンド サービスの URL です。BACKEND_SERVICE_URL
は、トラフィックの 98% を受信するバックエンド サービスの URL です。
Blue/Green デプロイを設定する
Blue/Green デプロイは、本番環境トラフィックをサービスの新しいリリースまたは以前のリリースのロールバックに切り替えるのに必要な時間を短縮するリリースモデルです。これらのデプロイでは、本番環境で使用可能な両方のバージョンのサービスを維持し、トラフィックを一方から他方に移行します。
Blue/Green デプロイでは、weightedBackendServices
を使用します。以下の YAML の例では、SERVICE_BLUE_URL
へのバックエンドは現在の本番環境リリースに完全にデプロイされ、SERVICE_GREEN_URL
のバックエンドは新しいリリースに完全にデプロイされます。この例の構成では、GREEN
デプロイが本番環境のトラフィックの 100% を受信します。問題が見つかった場合は、2 つのデプロイの重みを逆にすることで、不具合のある GREEN
リリースを元に戻し、正常な BLUE
リリースを復元できます。両方のバージョンでトラフィックを受信できる体制が整っているため、いずれの場合でもトラフィックを迅速に移行できます。
- Blue/Green デプロイを有効にするには、次の YAML コードサンプルを使用します。
pathMatchers: - defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_BLUE_URL weight: 0 - backendService: BACKEND_SERVICE_GREEN_URL weight: 100
DEFAULT_SERVICE_URL
は、サービスのデフォルトの URL です。BACKEND_SERVICE_BLUE_URL
は、トラフィックを受信しないバックエンド サービスの URL です。BACKEND_SERVICE_GREEN_URL
は、トラフィックをすべて受信するバックエンド サービスの URL です。
トラフィックのミラーリングを設定する
トラフィックのミラーリングは、新しいサービスのデバッグやテストのために 2 つの異なるバックエンド サービスにトラフィックを転送する場合に使用します。
次の例では、すべてのリクエストが SERVICE_URL
と MIRROR_SERVICE_URL
に送信されます。クライアントには SERVICE_URL
からのレスポンスのみが返されます。MIRROR_SERVICE_URL
はクライアントに影響しません。
トラフィック分割を設定する手順は次のとおりです。
コンソール
Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。
[ルーティング ルール マップ] をクリックします。
[
ルーティング ルール マップを作成] をクリックします。[ルーティング ルール マップを作成] ページで、名前を入力します。
[プロトコル] リストで [HTTP] を選択します。
既存の転送ルールを選択します。
[ルーティング ルール] で [詳細なホスト、パス、ルートのルール] を選択します。
[ホストとパスのマッチャー] で、[
Add hosts and path matcher] をクリックします。これにより、トラフィックを分割するように構成できる新しいパスマッチャーが追加されます。[パスマッチャー] フィールドに次の設定を追加します。
- defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_URL weight: 100 requestMirrorPolicy: backendService: BACKEND_SERVICE_MIRROR_URL
DEFAULT_SERVICE_URL
は、サービスのデフォルトの URL です。BACKEND_SERVICE_URL
は、ミラーリングされるバックエンドの URL です。BACKEND_SERVICE_MIRROR_URL
は、ミラーリングするバックエンド サービスの URL です。
[完了] をクリックします。
[保存] をクリックします。
gcloud
gcloud export
コマンドを使用して、URL マップの構成を取得します。gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yaml
review-url-map-config.yaml
ファイルに次のセクションを追加します。hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_URL weight: 100 requestMirrorPolicy: backendService: BACKEND_SERVICE_MIRROR_URL
DEFAULT_SERVICE_URL
は、サービスのデフォルトの URL です。BACKEND_SERVICE_URL
は、ミラーリングされるバックエンドの URL です。BACKEND_SERVICE_MIRROR_URL
は、ミラーリングするバックエンド サービスの URL です。
URL マップを更新します。
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
サーキット ブレーカーを設定する
クライアント リクエストでバックエンドが過負荷にならないように、サーキット ブレーカーで障害しきい値を設定できます。リクエストが設定した上限に達すると、クライアントは新しい接続の許可や追加のリクエストの送信を停止し、バックエンドの復旧のための時間を確保します。
バックエンドで過負荷を発生させずにエラーをクライアントに返すことで、カスケード障害を回避できます。これにより、自動スケーリングによって容量を増やしてトラフィックの急増に対応するなど、過負荷状態を管理する時間を確保しつつ、一部のトラフィックを処理できます。
次の例では、サーキット ブレーカーを次のように設定します。
- 接続あたりの最大リクエスト数: 100
- 最大接続数: 1,000
- 最大保留リクエスト数: 200
- 最大リクエスト数: 1,000
- 最大再試行回数: 3
サーキット ブレーカーを設定するには、次の手順に従います。
コンソール
Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。
更新するバックエンド サービスの名前をクリックします。
[
編集] をクリックします。[詳細構成] をクリックします。
[サーキット ブレーカー] で [有効にする] チェックボックスをオンにします。
[
編集] をクリックします。- [接続あたりの最大リクエスト数] に「
100
」と入力します。 - [最大接続数] に「
1000
」と入力します。 - [保留中のリクエストの最大数] に「
200
」と入力します。 - [最大リクエスト数] に「
1000
」と入力します。 - [最大再試行回数] に「
3
」と入力します。
- [接続あたりの最大リクエスト数] に「
[保存] をクリックし、もう一度 [保存] をクリックします。
gcloud
gcloud export
コマンドを実行して、バックエンド サービスの構成をエクスポートします。BACKEND_SERVICE_NAME
は、バックエンド サービスの名前に置き換えます。gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
BACKEND_SERVICE_NAME
.yaml ファイルを次のように更新します。affinityCookieTtlSec: 0 backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group:https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME maxUtilization: 0.8 circuitBreakers: maxConnections: 1000 maxPendingRequests: 200 maxRequests: 1000 maxRequestsPerConnection: 100 maxRetries: 3 connectionDraining: drainingTimeoutSec: 300 healthChecks: - https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME loadBalancingScheme: INTERNAL_SELF_MANAGED localityLbPolicy: ROUND_ROBIN name: BACKEND_SERVICE_NAME port: 80 portName: http protocol: HTTP sessionAffinity: NONE timeoutSec: 30
バックエンド サービス構成ファイルを更新します。
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
HTTP_COOKIE
に基づいてセッション アフィニティを設定する
高度なトラフィック管理では、設定した Cookie に基づいてセッション アフィニティを構成できます。
HTTP_COOKIE
を使用してセッション アフィニティを構成する手順は次のとおりです。
コンソール
Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。
更新するバックエンド サービスの名前をクリックします。
[
編集] をクリックします。[詳細構成] をクリックします。
[セッション アフィニティ] で [HTTP Cookie] を選択します。
[地域による負荷分散ポリシー] で [リングハッシュ] を選択します。
- [HTTP Cookie 名] フィールドに「
http_cookie
」と入力します。 - [HTTP Cookie パス] フィールドに「
/cookie_path
」と入力します。 - [HTTP Cookie TTL] フィールドに「
100
」と入力します。 - [最小リングサイズ] フィールドに「
10000
」と入力します。
- [HTTP Cookie 名] フィールドに「
[保存] をクリックします。
gcloud
gcloud export
コマンドを実行して、バックエンド サービスの構成をエクスポートします。BACKEND_SERVICE_NAME
は、バックエンド サービスの名前に置き換えます。gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
次のように
YAML
ファイルを更新します。sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 30 minimumRingSize: 10000
バックエンド サービス構成ファイルをインポートします。
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
外れ値検出を設定する
外れ値検出によって、負荷分散プールから正常でないホストのエビクションが制御されます。Cloud Service Mesh は、NEG 内の正常でないバックエンド VM やエンドポイントをエビクションさせるための基準と、バックエンドやエンドポイントが再びトラフィックを受信するのに十分な健全性を持つと判断された場合の基準を指定する一連のポリシーを使用してこれを実行します。
次の例のバックエンド サービスには、バックエンドとして 1 つのインスタンス グループがあります。外れ値検出の設定で、外れ値検出分析が 1 秒に 1 回実行されることが指定されています。エンドポイントから 5 つの連続した 5xx
エラーが返された場合、最初の 30 秒間は負荷分散の候補から除外されます。同じエンドポイントの実際の除外時間は、除外される回数 × 30 秒に相当します。
バックエンド サービス リソースに外れ値検出を設定するには、次の手順を行います。
コンソール
Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。
サービスの名前をクリックします。
[
編集] をクリックします。[詳細構成] をクリックします。
[外れ値検出] チェックボックスをオンにします。
[
編集] をクリックします。- [連続するエラー] を
5
に設定します。 - [間隔] を
1000
ミリ秒に設定します。 - [ベースの排出時間] を
30000
ミリ秒に設定します。
- [連続するエラー] を
[保存] をクリックし、もう一度 [保存] をクリックします。
gcloud
gcloud export
コマンドを実行して、バックエンド サービスの構成をエクスポートします。BACKEND_SERVICE_NAME
は、バックエンド サービスの名前に置き換えます。gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
BACKEND_SERVICE_NAME
をバックエンド サービスの名前に置き換えて、以下のようにYAML
ファイルを更新します。name: BACKEND_SERVICE_NAME loadBalancingScheme: INTERNAL_SELF_MANAGED backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: $INSTANCE_GROUP_URL healthChecks: - $HEALTH_CHECK_URL port: 80 portName: http protocol: HTTP outlierDetection: consecutiveErrors: 5, interval: seconds: 1, nanos: 0 baseEjectionTime: seconds: 30, nanos: 0
バックエンド サービス構成ファイルをインポートします。
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
地域による負荷分散ポリシーを設定する
地域によるロード バランシング ポリシーを使用して、Cloud Service Mesh で提供される局所性の重み付けと優先度に基づいてロード バランシング アルゴリズムを選択します。たとえば、正常なエンドポイント間で重み付けされたラウンドロビンを実行します。また、一貫したハッシュを実行することもできます。
次の例のバックエンド サービスには、バックエンドとして 1 つのインスタンス グループがあります。地域による負荷分散ポリシーは RING_HASH
に設定されています。
地域によるロードバランシング ポリシーを設定する手順は次のとおりです。
コンソール
Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。
サービスの名前をクリックします。
[
編集] をクリックします。[詳細構成] をクリックします。
[トラフィック ポリシー] の [地域による負荷分散] メニューで、[リングハッシュ] を選択します。
[保存] をクリックします。
gcloud
gcloud export
コマンドを実行して、バックエンド サービスの構成をエクスポートします。BACKEND_SERVICE_NAME
は、バックエンド サービスの名前に置き換えます。gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
BACKEND_SERVICE_NAME
.yaml ファイルを次のように更新します。name: shopping-cart-service loadBalancingScheme: INTERNAL_SELF_MANAGED backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: $INSTANCE_GROUP_URL healthChecks: - $HEALTH_CHECK_URL port: 80 portName: http protocol: HTTP localityLbPolicy: RING_HASH
バックエンド サービス構成ファイルをインポートします。
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
地域による負荷分散ポリシーの仕組みについては、backendService リソースのドキュメントをご覧ください。
URL リダイレクトの設定
ここでは、次のことを想定しています。
- Cloud Service Mesh のデプロイに
review-url-map
という URL マップがあります。 - URL マップは、デフォルトのバックエンド サービスとして機能する
review1
という 1 つのバックエンド サービスにすべてのトラフィックを送信します。 - ホスト間でトラフィックをリダイレクトします。
URL リダイレクトを設定する手順は次のとおりです。
コンソール
Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。
[ルーティング ルール マップ] をクリックします。
[
ルーティング ルール マップを作成] をクリックします。[ルーティング ルール マップを作成] ページで、名前を入力します。
[プロトコル] メニューで [HTTP] を選択します。
既存の転送ルールを選択します。
[ルーティング ルール] で [詳細なホスト、パス、ルートのルール] を選択します。
[ホストとパスのマッチャー] で、[
Add hosts and path matcher] をクリックします。これにより、トラフィックをリダイレクトする新しいパスマッチャーが追加されます。[パスマッチャー] フィールドに次の設定を追加します。
- defaultService: global/backendServices/review1 name: matcher1 routeRules: - matchRules: - prefixMatch: '' urlRedirect: hostRedirect: '[REDIRECT_HOST]' pathRedirect: '[REDIRECT_URL]' redirectResponseCode: 'FOUND', stripQuery: True
[完了] をクリックします。
[保存] をクリックします。
gcloud
gcloud export
コマンドを使用して、URL マップの構成を取得します。gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yaml
review-url-map-config.yaml
ファイルに次のセクションを追加します。hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/review1 name: matcher1 routeRules: - matchRules: - prefixMatch: '' urlRedirect: hostRedirect: '[REDIRECT_HOST]' pathRedirect: '[REDIRECT_URL]' redirectResponseCode: 'FOUND', stripQuery: True
URL マップを更新します。
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
URL 書き換えにによってトラフィック ステアリングを設定する
トラフィック ステアリングを使用すると、ヘッダー値などのリクエスト属性に基づいて、複数のバックエンド サービスにトラフィックを転送できます。さらに、リクエストがバックエンド サービスに転送される前に、リクエストの URL の書き換えなどのアクションを構成できます。
次の例では、/mobile/
で始まるリクエストパスとリクエストの User-Agent
に Android
が含まれている場合、リクエストは SERVICE_ANDROID_URL
に転送されます。リクエストをバックエンド サービスに送信する前に、URL のプレフィックスを REWRITE_PATH_ANDROID
(/android/
など)に変更できます。ただし、パスの先頭に /mobile/
があり、User-Agent
に iPhone
が含まれている場合、トラフィックは SERVICE_IPHONE_URL
に転送され、URL プレフィックスが REWRITE_PATH_IPHONE
に変更されます。先頭に /mobile/
があり、User-Agent
に Android または iPhone 以外の値が設定されている他のリクエストはすべて SERVICE_GENERIC_DEVICE_URL
に送信されます。
pathMatchers: - defaultService: [DEFAULT_SERVICE_URL] name: matcher1 routeRules: - matchRules: - prefixMatch: /mobile/ headerMatches: - headerName: User-Agent regexMatch: .*Android.* service: $[SERVICE_ANDROID_URL] routeAction: urlRewrite: pathPrefixRewrite: [REWRITE_PATH_ANDROID] - matchRules: - prefixMatch: /mobile/ headerMatches: - headerName: User-Agent regexMatch: .*iPhone.* service: [SERVICE_IPHONE_URL] routeAction: urlRewrite: pathPrefixRewrite: [REWRITE_PATH_IPHONE] - matchRules: - prefixMatch: /mobile/ service: [SERVICE_GENERIC_DEVICE_URL]
フォールト インジェクションを設定する
フォールト インジェクションを使用すると、特定のルートに固定遅延または強制停止(中断)の一方または両方を挿入して、アプリケーションの耐障害性をテストできます。
次の例では、すべてのリクエストが SERVICE_URL
に送信され、リクエストの 100% に 10 秒の固定遅延が追加されます。リクエストを送信するクライアントで、すべてのレスポンスが 10 秒遅延することを確認できます。また、リクエストの 50% に Service Unavailable
503 レスポンスを含む停止障害が適用されます。クライアントで、リクエストの 50% が 503 レスポンスを受信することを確認できます。これらのリクエストはバックエンド サービスに到達しません。
pathMatchers: - defaultService: [DEFAULT_SERVICE_URL] name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: [SERVICE_URL] weight: 100 faultInjectionPolicy: delay: fixedDelay: seconds: 10 nanos: 0 percentage: 100 abort: httpStatus: 503 percentage: 50
MetadataFilters
の一致に基づいて構成フィルタリングを設定する
MetadataFilters
は転送ルールと HttpRouteRuleMatch
で有効になっています。この機能を使用して、特定の転送ルールまたはルートルールを制御し、ノード メタデータがメタデータ フィルタの設定と一致するプロキシにのみ転送ルールまたはルートルールが転送されるようにします。MetadataFilters
を指定しない場合、ルールはすべての Envoy プロキシに送信されます。
この機能を使用すると、構成の段階的なデプロイを簡単に行うことができます。たとえば、forwarding-rule1
という名前の転送ルールを作成し、ノード メタデータに app: review
と version: canary
が含まれている Envoy にのみ push されるようにします。
転送ルールに MetadataFilters
を追加する手順は次のとおりです。
gcloud
gcloud export
コマンドを使用して、転送ルールの構成を取得します。gcloud compute forwarding-rules export forwarding-rule1 \ --destination=forwarding-rule1-config.yaml \ --global
転送ルールを削除します。
gcloud compute forwarding-rules delete forwarding-rule1 \ --global
forwarding-rule1-config.yaml
ファイルを更新します。次の例では、
MATCH_ALL
メタデータ フィルタを作成します。metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'canary'
次の例では、
MATCH_ANY
メタデータ フィルタを作成します。metadataFilters: - filterMatchCriteria: 'MATCH_ANY' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'production'
forwarding-rule1-config.yaml
ファイルから出力専用フィールドをすべて削除します。詳細については、gcloud compute forwarding-rules import
のドキュメントをご覧ください。gcloud import
コマンドを実行してforwarding-rule1-config.yaml
ファイルを更新します。gcloud compute forwarding-rules import forwarding-rule1 \ --source=forwarding-rule1-config.yaml \ --global
Envoy を起動する前に、以下の手順で Envoy にノードのメタデータを追加します。文字列値のみがサポートされています。
a. VM ベースのデプロイの場合は、
bootstrap_template.yaml
のmetadata
セクションに以下を追加します。app: 'review' version: 'canary'
b. Google Kubernetes Engine または Kubernetes ベースのデプロイの場合は、
trafficdirector_istio_sidecar.yaml
のenv
セクションに次の行を追加します。- name: ISTIO_META_app value: 'review' - name: ISTIO_META_version value: 'canary'
メタデータのフィルタリングの例
複数のプロジェクトが同じ共有 VPC ネットワークにあり、各サービス プロジェクトの Cloud Service Mesh リソースを同じプロジェクト内のプロキシに表示できるようにすることが必要な場合の手順は、次のとおりです。
共有 VPC の設定は次のとおりです。
- ホスト プロジェクトの名前:
vpc-host-project
- サービス プロジェクト:
project1
、project2
project1
とproject2
で xDS 準拠のプロキシを実行するバックエンド インスタンスまたはエンドポイントを持つバックエンド サービス
project1
を分離するように Cloud Service Mesh を構成する手順は次のとおりです。
gcloud
次のメタデータ フィルタを使用して、すべての転送ルールを
project1
に作成します。metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels - name: 'project_name' value: 'project1' - name: 'version' value: 'production'
project1
でインスタンスまたはエンドポイントにデプロイされたプロキシを構成する場合は、ブートストラップ ファイルのノード メタデータ セクションに次のメタデータを追加します。project_name: 'project1' version: 'production'
project2
にデプロイされているプロキシに、最初の手順で作成した転送ルールが受信されていないことを確認します。これを行うには、project2
でプロキシを実行しているシステムからproject1
のサービスにアクセスします。Cloud Service Mesh 構成が正しく機能していることを確認する方法については、構成の検証をご覧ください。
すべてのプロキシで使用可能にする前に、プロキシのサブセットで新しい構成をテストするには、次の手順を行います。
gcloud
次のノード メタデータを使用して、テストに使用するプロキシを起動します。テストに使用しないプロキシには、このノード メタデータを挿入しないでください。
version: 'test'
テストする新しい転送ルールごとに、次のメタデータ フィルタを挿入します。
metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'version' value: 'test'
テストプロキシにトラフィックを送信して新しい構成をテストし、必要な変更を行います。新しい構成が正しく機能している場合は、テスト対象のプロキシのみが新しい構成を受け取ります。残りのプロキシは新しい構成を受信できず、使用できません。
新しい構成が正しく機能していることを確認したら、構成に関連付けられたメタデータ フィルタを削除します。これにより、すべてのプロキシが新しい構成を受信できます。
トラブルシューティング
構成したルートルールとトラフィック ポリシーに従ってトラフィックがルーティングされない場合は、次の方法でトラブルシューティングを行ってください。
症状:
- ルールの上位にあるサービスへのトラフィックが増加した。
- 特定のルートルールに対する
4xx
と5xx
の HTTP レスポンスが予期せず増加した。
解決策: ルートルールは優先度順に解釈されるため、各ルールに割り当てられた優先度を確認してください。
ルートルールを定義する際は、優先度の高い(つまり、優先度の番号が小さい)ルールが、後続のルートルールでルーティングされるトラフィックを誤ってルーティングしないようにします。次に例を示します。
最初のルートルール
- ルートルール マッチの pathPrefix =
/shopping/
- リダイレクト アクション: バックエンド サービス
service-1
にトラフィックを送信 - ルールの優先度:
4
- ルートルール マッチの pathPrefix =
2 つ目のルートルール
- ルートルール マッチの regexMatch =
/shopping/cart/ordering/.*
- リダイレクト アクション: バックエンド サービス
service-2
にトラフィックを送信 - ルールの優先度:
8
- ルートルール マッチの regexMatch =
この場合、パス /shopping/cart/ordering/cart.html
のリクエストは service-1
にルーティングされます。2 番目のルールが一致する場合でも、最初のルールが優先されるため無視されます。
サービス間のトラフィックをブロックする
GKE 上でデプロイされているサービス A とサービス B 間のトラフィックをブロックする場合、サービス セキュリティを設定し、認可ポリシーを使用してサービス間のトラフィックをブロックします。詳しい手順については、Cloud Service Mesh サービス セキュリティと、Envoy とプロキシレス gRPC を使用した設定手順をご覧ください。
次のステップ
- Cloud Service Mesh の構成の問題を解決するには、Envoy を使用するデプロイのトラブルシューティングをご覧ください。