Destination Rule

サービスレジストリからのサービスの名前。サービス名は、プラットフォームのサービスレジストリ（例えば、Kubernetes サービス、Consul サービスなど）と、ServiceEntries で宣言されたホストから検索されます。サービスレジストリに存在しないサービスに対して定義されたルールは無視されます。

Kubernetes ユーザー向けの注記: 短い名前（例えば、"reviews.default.svc.cluster.local" ではなく "reviews"）が使用されている場合、Istio はサービスではなくルールの名前空間に基づいて短い名前を解釈します。「default」名前空間内のホスト「reviews」を含むルールは、レビューサービスに関連付けられた実際の名前にかかわらず、「reviews.default.svc.cluster.local」として解釈されます。潜在的な設定ミスを避けるために、短い名前ではなく常に完全修飾ドメイン名を使用することを推奨します。

ホストフィールドは HTTP サービスと TCP サービスの両方に適用されることに注意してください。

適用するトラフィックポリシー（ロードバランシングポリシー、接続プールサイズ、外れ値検出）。

サービスの個々のバージョンを表す1つ以上の名前付きセット。トラフィックポリシーはサブセットレベルでオーバーライドできます。

このデスティネーションルールがエクスポートされる名前空間のリスト。サービスに適用されるデスティネーションルールの解決は、名前空間の階層のコンテキストで発生します。デスティネーションルールをエクスポートすると、他の名前空間のサービスの解決階層に含めることができます。この機能は、サービス所有者とメッシュ管理者が名前空間の境界を越えてデスティネーションルールの可視性を制御するためのメカニズムを提供します。

名前空間が指定されていない場合、デスティネーションルールはデフォルトですべての名前空間にエクスポートされます。

値 "。" は予約されており、デスティネーションルールが宣言されているのと同じ名前空間へのエクスポートを定義します。同様に、値 "*" は予約されており、すべての名前空間へのエクスポートを定義します。

このDestinationRule構成を適用する特定のポッド/VMのセットを選択するために使用される基準。指定した場合、DestinationRule構成は、同じ名前空間内のワークロードセレクターラベルに一致するワークロードインスタンスにのみ適用されます。ワークロードセレクターは、名前空間の境界を越えて適用されません。省略した場合、DestinationRuleはデフォルトの動作に戻ります。たとえば、特定のサイドカーがメッシュ外部のサービスに対してエグレスTLS設定を持つ必要がある場合、メッシュ内のすべてのサイドカーが構成を持つ必要はなく（これがデフォルトの動作です）、ワークロードセレクターを指定できます。

ロードバランサーアルゴリズムを制御する設定。

アップストリームサービスへの接続量を制御する設定

ロードバランシングプールから異常なホストを排除することを制御する設定

アップストリームサービスへの接続に関する TLS 関連の設定。

個々のポートに固有のトラフィックポリシー。ポートレベルの設定は、宛先レベルの設定をオーバーライドすることに注意してください。宛先レベルで指定されたトラフィック設定は、ポートレベルの設定によってオーバーライドされた場合、継承されません。つまり、ポートレベルのトラフィックポリシーで省略されたフィールドにはデフォルト値が適用されます。

DestinationRule で構成されたホストに対して、他のトランスポート層またはアプリケーション層を介して TCP をトンネリングするための構成。トンネル設定は、TCP ルートまたは TLS ルートに適用でき、HTTP ルートには適用できません。

アップストリームの PROXY プロトコル設定。

サブセットの名前。サービス名とサブセット名は、ルートルールでのトラフィック分割に使用できます。

ラベルは、サービスレジストリ内のサービスのエンドポイントにフィルターを適用します。使用例については、ルートルールを参照してください。

このサブセットに適用されるトラフィックポリシー。サブセットは、DestinationRule レベルで指定されたトラフィックポリシーを継承します。サブセットレベルで指定された設定は、DestinationRule レベルで指定された対応する設定をオーバーライドします。

地域ロードバランサーの設定。これにより、メッシュ全体のオブジェクトは完全にオーバーライドされ、このオブジェクトと MeshConfig のオブジェクトの間でマージは実行されません。

サービスのウォームアップ期間を表します。設定した場合、サービスの新しく作成されたエンドポイントは、作成時間からこのウィンドウの期間、ウォームアップモードのままになり、Istio は比例的な量のトラフィックを送信するのではなく、そのエンドポイントへのトラフィック量を徐々に増やします。これは、妥当なレイテンシーで完全な本番負荷を処理するためにウォームアップ時間が必要なサービスで有効にする必要があります。これは、Kubernetes のスケールイベントのように、新しいエンドポイントがいくつか登場する場合に最も効果的です。新しいデプロイメントのようにすべてのエンドポイントが比較的新しい場合、すべてのエンドポイントが同じ量の要求を取得することになるため、これはあまり効果的ではありません。現在、これは ROUND_ROBIN および LEAST_REQUEST ロードバランサーでのみサポートされています。

HTTP および TCP アップストリーム接続の両方に共通の設定。

HTTP 接続プール設定。

ローカルオリジンのエラーを外部エラーと区別するかどうかを決定します。true に設定した場合、外れ値検出の計算に consecutive_local_origin_failure が考慮されます。これは、アップストリームサービスによって返されるステータスコードではなく、接続の失敗、接続中のタイムアウトなど、ローカルで確認されたエラーに基づいて外れ値検出ステータスを導出する場合に使用する必要があります。これは、アップストリームサービスが一部の要求に対して明示的に 5xx を返す場合に特に役立ちます。ホストの外れ値検出ステータスを決定する際に、それらのアップストリームサービスからの応答を無視したい場合があります。デフォルトは false です。

排除が発生するまでのローカルで発生した連続的な失敗の数。デフォルトは 5 です。パラメーターは、split_external_local_origin_errors が true に設定されている場合にのみ有効になります。

ホストが接続プールから排除されるまでのゲートウェイエラーの数。アップストリームホストが HTTP 経由でアクセスされる場合、502、503、または 504 の戻りコードはゲートウェイエラーと見なされます。アップストリームホストが不透明な TCP 接続経由でアクセスされる場合、接続タイムアウトと接続エラー/失敗イベントはゲートウェイエラーと見なされます。この機能は、デフォルトでは無効になっているか、値 0 に設定されている場合は無効になっています。

consecutive_gateway_errors と consecutive_5xx_errors は個別にまたは一緒に使用できることに注意してください。consecutive_gateway_errors によってカウントされるエラーは consecutive_5xx_errors にも含まれているため、consecutive_gateway_errors の値が consecutive_5xx_errors の値以上である場合、consecutive_gateway_errors は効果がありません。

ホストが接続プールから削除されるまでの5xxエラー数。アップストリームホストが不透明なTCP接続を介してアクセスされる場合、接続タイムアウト、接続エラー/失敗、およびリクエスト失敗イベントは5xxエラーとして扱われます。この機能はデフォルトで5に設定されていますが、値を0に設定することで無効にできます。

consecutive_gateway_errors と consecutive_5xx_errors は個別にまたは一緒に使用できることに注意してください。consecutive_gateway_errors によってカウントされるエラーは consecutive_5xx_errors にも含まれているため、consecutive_gateway_errors の値が consecutive_5xx_errors の値以上である場合、consecutive_gateway_errors は効果がありません。

削除スイープ分析の間隔。形式: 1h/1m/1s/1ms。1ms以上である必要があります。デフォルトは10秒です。

最小削除時間。ホストは、最小削除時間とホストが削除された回数の積に等しい期間、削除されたままになります。この手法により、システムは異常なアップストリームサーバーの削除期間を自動的に延長できます。形式: 1h/1m/1s/1ms。1ms以上である必要があります。デフォルトは30秒です。

アップストリームサービスのロードバランシングプールで削除できるホストの最大パーセント。デフォルトは10%です。

関連するロードバランシングプールに少なくともmin_health_percentのホストが正常モードである限り、外れ値検出が有効になります。ロードバランシングプール内の正常なホストの割合がこのしきい値を下回ると、外れ値検出が無効になり、プロキシはプール内のすべてのホスト（正常および異常）で負荷分散を行います。このしきい値は0％に設定することで無効にできます。デフォルトは0％です。これは、サービスあたりのポッド数が少ないk8s環境では通常適用できないためです。

このポートへの接続をTLSを使用して保護する必要があるかどうかを示します。このフィールドの値によって、TLSがどのように適用されるかが決まります。

modeがMUTUALの場合は必須。使用するクライアント側のTLS証明書を保持するファイルへのパス。modeがISTIO_MUTUALの場合は空にする必要があります。

modeがMUTUALの場合は必須。クライアントの秘密鍵を保持するファイルへのパス。modeがISTIO_MUTUALの場合は空にする必要があります。

オプション：提示されたサーバー証明書の検証に使用する認証局証明書を含むファイルへのパス。省略した場合、プロキシはOSのCA証明書を使用してサーバーの証明書を検証します。modeがISTIO_MUTUALの場合は空にする必要があります。

CA証明書を含む、クライアントのTLS証明書を保持するシークレットの名前。このシークレットは、証明書を使用するプロキシの名前空間に存在する必要があります。Opaqueシークレットには、次のキーと値が含まれている必要があります。key: <秘密鍵>、cert: <クライアント証明書>、cacert: <CA証明書>、crl: <証明書失効リスト>ここで、CA証明書はサーバー証明書を検証するために使用されます。相互TLSの場合、cacert: <CA証明書>は同じシークレットまたは<secret>-cacertという名前の別のシークレットで提供できます。CA証明書の追加のca.crtキーと証明書失効リスト（CRL）のca.crlキーを持つクライアント証明書のTLSシークレットもサポートされています。クライアント証明書とCA証明書またはcredentialNameのいずれか一方のみを指定できます。

注意: このフィールドは、DestinationRuleにworkloadSelectorが指定されている場合にのみサイドカーに適用されます。それ以外の場合、フィールドはゲートウェイにのみ適用され、サイドカーは引き続き証明書パスを使用します。

証明書のサブジェクトIDを検証するための代替名のリスト。指定した場合、プロキシはサーバー証明書のサブジェクト代替名が指定された値の1つと一致することを検証します。指定した場合、このリストはServiceEntryのsubject_alt_namesの値をオーバーライドします。未指定の場合、新しいアップストリーム接続に対して提示されたアップストリーム証明書の自動検証は、ダウンストリームのHTTPホスト/認証ヘッダーに基づいて行われます。

TLSハンドシェイク中にサーバーに提示するSNI文字列。指定しない場合、SNIはSIMPLEおよびMUTUAL TLSモードのダウンストリームHTTPホスト/認証ヘッダーに基づいて自動的に設定されます。

insecureSkipVerifyは、プロキシがホストに対応するサーバー証明書のCA署名とSANの検証をスキップするかどうかを指定します。このフィールドのデフォルト値はfalseです。

オプション：提示されたサーバー証明書の検証に使用する証明書失効リスト（CRL）を含むファイルへのパス。CRLは、スケジュールされた有効期限日より前にCA（認証局）によって失効された証明書のリストです。指定した場合、プロキシは、提示された証明書が失効された証明書リストの一部であるかどうかを検証します。省略した場合、プロキシはcrlに対して証明書を検証しません。

オプション：distribute、failover、またはfailoverPriorityのいずれか1つのみを設定できます。異なるゾーンおよび地理的な場所間の負荷分散ウェイトを明示的に指定します。ロケーションに基づいた負荷分散を参照してください。空の場合、ロケーションウェイトは、その中のエンドポイント数に応じて設定されます。

オプション：distribute、failover、またはfailoverPriorityのいずれか1つのみを設定できます。ローカルリージョンのエンドポイントが異常になった場合にトラフィックが着陸するリージョンを明示的に指定します。異常なエンドポイントを検出するには、OutlierDetectionと組み合わせて使用する必要があります。注：OutlierDetectionが指定されていない場合、これは有効になりません。

failoverPriorityは、優先度ベースの負荷分散を行うためにエンドポイントをソートするために使用されるラベルの順序付きリストです。これは、さまざまなエンドポイントグループ間のトラフィックフェイルオーバーをサポートするためのものです。次の2種類のラベルを指定できます。

• ラベルキーのみを指定[key1, key2, key3]すると、istioはクライアントのラベル値をエンドポイントと比較します。合計N個のラベルキー[key1, key2, key3, ...keyN]が指定されていると仮定します

  1. クライアントプロキシとすべてのN個のラベルが一致するエンドポイントには、優先度P(0)、つまり最高の優先度が与えられます。
  2. クライアントプロキシと最初のN-1個のラベルが一致するエンドポイントには、優先度P(1)、つまり2番目に高い優先度が与えられます。
  3. このロジックの拡張として、クライアントプロキシと最初のラベルのみが一致するエンドポイントには、優先度P(N-1)、つまり2番目に低い優先度が与えられます。
  4. その他すべてのエンドポイントには、優先度P(N)、つまり最低の優先度が与えられます。

• キーと値を持つラベル[key1=value1, key2=value2, key3=value3]を指定すると、istioはラベルをエンドポイントと比較します。合計N個のラベル[key1=value1, key2=value2, key3=value3, ...keyN=valueN]が指定されていると仮定します

  1. すべてのN個のラベルが一致するエンドポイントには、優先度P(0)、つまり最高の優先度が与えられます。
  2. 最初のN-1個のラベルが一致するエンドポイントには、優先度P(1)、つまり2番目に高い優先度が与えられます。
  3. このロジックの拡張として、最初のラベルのみが一致するエンドポイントには、優先度P(N-1)、つまり2番目に低い優先度が与えられます。
  4. その他すべてのエンドポイントには、優先度P(N)、つまり最低の優先度が与えられます。

注：ラベルが一致すると見なされるためには、前のラベルが一致する必要があります。つまり、n番目のラベルは、最初のn-1個のラベルが一致する場合にのみ一致すると見なされます。

クライアントとサーバーの両方のワークロードで指定された任意のラベルを指定できます。特別な意味を持つ次のラベルもサポートされています

• topology.istio.io/networkは、エンドポイントのネットワークメタデータと一致するために使用されます。これは、ポッド/名前空間ラベルtopology.istio.io/network、サイドカー環境ISTIO_META_NETWORK、またはMeshNetworksによって指定できます。
• topology.istio.io/clusterは、エンドポイントのクラスターIDと一致するために使用されます。これは、ポッドラベルtopology.istio.io/clusterまたはポッド環境ISTIO_META_CLUSTER_IDによって指定できます。
• topology.kubernetes.io/regionは、エンドポイントのリージョンメタデータと一致するために使用されます。これは、Kubernetesノードラベルtopology.kubernetes.io/regionまたは非推奨のラベルfailure-domain.beta.kubernetes.io/regionにマップされます。
• topology.kubernetes.io/zoneは、エンドポイントのゾーンメタデータと一致するために使用されます。これは、Kubernetesノードラベルtopology.kubernetes.io/zoneまたは非推奨のラベルfailure-domain.beta.kubernetes.io/zoneにマップされます。
• topology.istio.io/subzoneは、エンドポイントのサブゾーンメタデータと一致するために使用されます。これは、Istioノードラベルtopology.istio.io/subzoneにマップされます。
• kubernetes.io/hostnameは、エンドポイントの現在のノードと一致するために使用されます。これは、Kubernetesノードラベルkubernetes.io/hostnameにマップされます。

以下のトポロジ構成は、次の優先度レベルを示しています

failoverPriority:
- "topology.istio.io/network"
- "topology.kubernetes.io/region"
- "topology.kubernetes.io/zone"
- "topology.istio.io/subzone"

1. エンドポイントが、クライアントプロキシと同じ[network, region, zone, subzone]ラベルと一致する場合は、最高の優先度を持ちます。
2. エンドポイントが、クライアントプロキシと同じ[network, region, zone]ラベルを持ち、異なる[subzone]ラベルを持つ場合は、2番目に高い優先度を持ちます。
3. エンドポイントが、クライアントプロキシと同じ[network, region]ラベルを持ち、異なる[zone]ラベルを持つ場合は、3番目に高い優先度を持ちます。
4. エンドポイントが、クライアントプロキシと同じ[network]を持ち、異なる[region]ラベルを持つ場合は、4番目に高い優先度を持ちます。
5. その他すべてのエンドポイントは、同じ最低の優先度を持ちます。

サービスに関連付けられたエンドポイントが複数のクラスターに存在する場合、以下の例は次を表します

1. clusterAにあり、version=v1ラベルを持つエンドポイントには、P(0)優先度が与えられます。
2. clusterAにはないが、version=v1ラベルを持つエンドポイントには、P(1)優先度が与えられます。
3. その他すべてのエンドポイントには、P(2)優先度が与えられます。

failoverPriority:
- "version=v1"
- "topology.istio.io/cluster=clusterA"

オプション：distribute、failover、またはfailoverPriorityのいずれか1つのみを設定できます。また、OutlierDetectionと組み合わせて異常なエンドポイントを検出するために使用する必要があります。そうしないと、効果がありません。

ロケーション負荷分散を有効にします。これはDestinationRuleレベルであり、メッシュ全体のすべての設定を上書きします。たとえば、trueは、メッシュ全体の設定に関係なく、このDestinationRuleのロケーション負荷分散をオンにすることを意味します。

このポリシーが適用される宛先サービスのポート番号を指定します。

ロードバランサーアルゴリズムを制御する設定。

アップストリームサービスへの接続量を制御する設定

ロードバランシングプールから異常なホストを排除することを制御する設定

アップストリームサービスへの接続に関する TLS 関連の設定。

ダウンストリーム接続のトンネリングに使用するプロトコルを指定します。サポートされているプロトコルは次のとおりです。CONNECT - HTTP CONNECTを使用します。POST - HTTP POSTを使用します。指定されていない場合、デフォルトではCONNECTが使用されます。アップストリームリクエストのHTTPバージョンは、プロキシに対して定義されたサービスプロトコルによって決定されます。

ダウンストリーム接続がトンネリングされるホストを指定します。ターゲットホストは、FQDNまたはIPアドレスである必要があります。

ダウンストリーム接続がトンネリングされるポートを指定します。

使用するPROXYプロトコルのバージョン。詳細については、https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt を参照してください。デフォルトはV1です。

ハッシュリングに使用する仮想ノードの最小数。デフォルトは1024です。リングサイズが大きいほど、負荷分散が細かくなります。負荷分散プール内のホストの数がリングサイズよりも大きい場合、各ホストに単一の仮想ノードが割り当てられます。

Maglevハッシュのテーブルサイズ。これは、バックエンドホストが変更されたときの混乱を制御するのに役立ちます。テーブルサイズを大きくすると、混乱の量が減ります。テーブルサイズは、5000011未満の素数である必要があります。指定しない場合、デフォルトは65537です。

Cookieの名前。

Cookieに設定するパス。

Cookieの有効期間。指定した場合、Cookieが存在しない場合は、TTL付きのCookieが生成されます。TTLが存在し、ゼロの場合、生成されたCookieはセッションCookieになります。

宛先ホストへのHTTP1 /TCP接続の最大数。デフォルトは2^32-1です。

TCP接続タイムアウト。形式：1h/1m/1s/1ms。1ms以上である必要があります。デフォルトは10秒です。

設定されている場合、ソケットでSO_KEEPALIVEを設定してTCP Keepalivesを有効にします。

接続の最大期間。期間は、接続が確立されてからの期間として定義されます。設定しない場合、最大期間はありません。max_connection_durationに達すると、接続は閉じられます。期間は1ms以上である必要があります。

TCP接続のアイドルタイムアウト。アイドルタイムアウトは、アップストリームまたはダウンストリーム接続のいずれでもバイトが送受信されない期間として定義されます。設定しない場合、デフォルトのアイドルタイムアウトは1時間です。0秒に設定すると、タイムアウトは無効になります。重み付き宛先を使用する場合、idleTimeoutはリスナーのプロパティであり、クラスターのプロパティではないため、idleTimeoutはクラスターごとに個別に構成されません。その場合、最初の重み付きルートの宛先ルールで指定されたidleTimeoutがリスナーで構成されます。これは、すべての重み付きルートにも適用されます。

準備完了の接続プール接続を待機している間にキューに入れられるリクエストの最大数。デフォルトは2^32-1です。HTTP2の新しい接続が作成される条件については、https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking を参照してください。これはHTTP/1.1とHTTP2の両方に適用できることに注意してください。

宛先へのアクティブなリクエストの最大数。デフォルトは2^32-1です。これはHTTP/1.1とHTTP2の両方に適用できることに注意してください。

バックエンドへの接続ごとの最大リクエスト数。このパラメーターを1に設定すると、キープアライブが無効になります。デフォルトは0で、「無制限」、最大2^29を意味します。

特定の時間にクラスター内のすべてのホストに対して未処理にできる再試行の最大数。デフォルトは2^32-1です。

アップストリーム接続プール接続のアイドルタイムアウト。アイドルタイムアウトは、アクティブなリクエストがない期間として定義されます。設定しない場合、デフォルトは1時間です。アイドルタイムアウトに達すると、接続は閉じられます。接続がHTTP/2接続の場合、接続を閉じる前にドレインシーケンスが発生します。リクエストベースのタイムアウトは、HTTP/2 PINGが接続を維持しないことを意味します。HTTP1.1とHTTP2接続の両方に適用されます。

関連付けられた宛先に対してhttp1.1接続をhttp2にアップグレードする必要があるかどうかを指定します。

trueに設定すると、バックエンドへの接続を開始する際にクライアントプロトコルが保持されます。これがtrueに設定されている場合、h2_upgrade_policyは無効になる、つまり、クライアント接続はhttp2にアップグレードされないことに注意してください。

1つのHTTP/2接続上のピアに許可される同時ストリームの最大数。デフォルトは2^31-1です。

応答なしで送信するキープアライブプローブの最大数。接続が切断されたと判断する前に送信します。デフォルトは、OSレベルの構成を使用することです（オーバーライドされない限り、Linuxのデフォルトは9です）。

キープアライブプローブの送信を開始する前に、接続がアイドル状態である必要がある時間。デフォルトは、OSレベルの構成を使用することです（オーバーライドされない限り、Linuxのデフォルトは7200秒（つまり2時間）です）。

キープアライブプローブ間の時間間隔。デフォルトは、OSレベルの構成を使用することです（オーバーライドされない限り、Linuxのデフォルトは75秒です）。

発信元のロカリティ。 ‘/’で区切られます。例：’region/zone/sub_zone’。

トラフィック分散の重みに対するアップストリームロカリティのマップ。すべての重みの合計は100である必要があります。存在しないロカリティはトラフィックを受信しません。

発信元のリージョン。

「from」リージョンのエンドポイントが異常になった場合に、トラフィックがフェイルオーバーされる宛先リージョン。

uint32値。