Alibaba Cloud Service Mesh:サイドカープロキシの設定

構成リファレンス

この構成項目は、注入された Sidecar プロキシを持つ Pod 内の istio-init コンテナに必要な最小限および許容される最大 CPU およびメモリリソースを指定します。 istio-init コンテナは、Pod の起動時に実行される init コンテナであり、トラフィックインターセプトルーティングルールと Sidecar プロキシコンテナのその他の前提条件の構成を担当します。

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[リソース設定] をクリックします。

2. （オプション）手順 1 で [名前空間] または [ワークロード] を選択した場合は、この手順を実行します。次に、[リソース設定] セクションで、[istio-init コンテナのリソースを構成する] を選択します。

3. [リソース制限] セクションで、[CPU] を 1 コア、[メモリ] を 512 MiB に設定します。[必要なリソース] セクションで、[CPU] を 0.1 コア、[メモリ] を 128 MiB に設定します。次に、[設定の更新] をクリックします。

4. ワークロードを再デプロイすると、Sidecar プロキシの構成が有効になります。

5. 次のコマンドを実行して、istio-init コンテナのリソース構成を表示します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   期待される出力：

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
   ...
         name: istio-init
         resources:
           limits:
             cpu: '1'
             memory: 512Mi
           requests:
             cpu: 100m
             memory: 128Mi
   ...

   ポッド内の istio-init コンテナの リソース フィールドは、想定されるリソース値に設定されています。これは、[istio-init コンテナのリソースを設定] の構成が有効になっていることを示します。

構成リファレンス

この構成設定では、注入された Istio プロキシと istio-init コンテナに ACK 動的オーバーアロケートリソースの割り当てを指定します。詳細については、「動的リソースオーバーコミットメント」をご参照ください。

構成項目は、注入された Istio プロキシのリソースを構成するおよびistio-init コンテナのリソースを構成するの場合と同じ方法で構成されます。上記の構成が完了すると、ポッドに koordinator.sh/qosClass ラベルが付いている場合、通常の CPU とメモリ リソースではなく、動的にオーバーコミットできるリソースが、ポッド内の Sidecar プロキシと istio-init コンテナに割り当てられます。このラベルは、ACK リソースの動的オーバーコミットが有効になっていることを示します。

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[リソース設定] をクリックします。

2. [Sidecar プロキシ用に動的にオーバーコミットできる ACK リソースを設定する] を選択し、設定を構成して、[設定の更新] をクリックします。

   構成項目	子構成項目	説明
   注入された Sidecar プロキシのリソースを構成する（ACK 動的オーバーコミットリソース）	リソース制限	[CPU] を 2000 ミリコア、[メモリ] を 2048 MiB に設定します。
   	必要なリソース	[CPU] を 200 ミリコア、[メモリ] を 256 MiB に設定します。
   Istio-init コンテナリソース（ACK 動的オーバーセリングリソース）	リソース制限	[CPU] を 1000 ミリコア、[メモリ] を 1024 MiB に設定します。
   	必要なリソース	[CPU] を 100 ミリコア、[メモリ] を 128 MiB に設定します。

3. ワークロードを再デプロイすると、Sidecar プロキシ構成が有効になります。

4. 次のコマンドを実行して、istio-init コンテナのリソース構成を表示します。

   kubectl get pod -n <Namespace> <Pod name> -o yaml

   予想される出力:

   apiVersion: v1
   kind: Pod
   metadata:
   ...
     labels:
       koordinator.sh/qosClass: BE
   spec:
     containers:
       - args:
   ...
         name: istio-proxy
   ...
         resources:
           limits:
             kubernetes.io/batch-cpu: 2k
             kubernetes.io/batch-memory: 2Gi
           requests:
             kubernetes.io/batch-cpu: '200'
             kubernetes.io/batch-memory: 256Mi
   ...
     initContainers:
       - args:
   ...
         name: istio-init
         resources:
           limits:
             kubernetes.io/batch-cpu: 1k
             kubernetes.io/batch-memory: 1Gi
           requests:
             kubernetes.io/batch-cpu: '100'
             kubernetes.io/batch-memory: 128Mi
   ...

   ポッド内の istio-proxy コンテナ（Sidecar プロキシコンテナ）と istio-init コンテナの両方に、リソース フィールドが含まれており、リソース値が構成されています。これは、[Sidecar プロキシに対して動的にオーバーコミットできる ACK リソースの設定] が有効になっていることを示しています。

構成リファレンス

この構成項目は、サイドカー プロキシ コンテナのワーカー スレッドの数を指定します。 負でない整数である必要があります。 0 に設定すると、ワーカー スレッドの数は、サイドカー プロキシに構成されている リクエストされた CPU リソース または CPU リソース制限 に基づいて自動的に決定されます。リソース制限は、リクエストされたリソースよりも優先されます。

構成例

1. [サイドカー プロキシ設定] ページで、構成レベルタブを選択し、[リソース設定] をクリックします。

2. (オプション) ステップ 1 で [名前空間] または [ワークロード] を選択した場合は、この手順を実行します。 [サイドカー プロキシ スレッドの数] を 3 に設定し、[設定の更新] をクリックします。

3. この構成は、サイドカー プロキシ コンテナが実行時に 3 つのワーカー スレッドを起動することを示しています。

4. ワークロードを再デプロイすると、サイドカー プロキシの構成が有効になります。

5. サイドカー プロキシ スレッドの数の構成を表示するには、次のコマンドを実行します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=warning'
           - '--proxyComponentLogLevel=misc:error'
           - '--log_output_level=default:info'
           - '--concurrency'
           - '3'
   ...
         name: istio-proxy
   ...

   concurrency パラメーター istio-proxy コンテナが 3 に設定されています。これは、[サイドカー プロキシ スレッドの数] の構成が有効になっていることを示します。

構成リファレンス

カンマ (,) で区切られた IP アドレス範囲のリストを構成します。各 IP アドレス範囲は CIDR 表記で指定されます。Sidecar プロキシが挿入されたワークロードが他のサービスにアクセスする場合、構成された範囲内の宛先 IP アドレスを持つリクエストのみが Sidecar プロキシコンテナによってインターセプトされます。これらの範囲外の リクエスト は Sidecar プロキシをバイパスし、宛先に直接送信されます。デフォルトの構成は * に設定されています。これは、Sidecar プロキシコンテナがワークロードからのすべてのアウトバウンドトラフィックをインターセプトすることを意味します。

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[ポートまたは IP アドレスによる Sidecar プロキシの有効化/無効化] を展開します。

2. (オプション) ステップ 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。[Sidecar プロキシにリダイレクトされる外部アクセスのアドレス] を選択します。

3. [Sidecar プロキシにリダイレクトされる外部アクセスのアドレス] を 192.168.0.0/16,10.1.0.0/24 に設定し、[設定の更新] をクリックします。

   この構成は、Sidecar プロキシコンテナが、宛先 IP アドレスが 192.168.0.0/16 および 10.1.0.0/24 CIDR ブロック内にあるリクエストをインターセプトすることを示します。

4. Sidecar プロキシの構成を有効にするには、ワークロードを再デプロイする必要があります。

5. 構成を表示するには、次のコマンドを実行します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '192.168.0.0/16,10.1.0.0/24'  // Sidecar プロキシにリダイレクトされるアドレス
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...

   istio-init コンテナのランタイムパラメータ -i は 192.168.0.0/16,10.1.0.0/24 に設定されています。これは、[Sidecar プロキシにリダイレクトされる外部アクセスのアドレス] の構成が有効になっていることを示します。

構成リファレンス

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[ポートまたは IP アドレスで Sidecar プロキシを有効化/無効化する] を展開します。

2. (オプション) ステップ 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。[Sidecar プロキシに外部アクセスがリダイレクトされないアドレス] を選択します。

3. [Sidecar プロキシに外部アクセスがリダイレクトされないアドレス] を 10.1.0.0/24 に設定し、[設定の更新] をクリックします。

   この構成は、宛先 IP アドレスが 10.1.0.0/24 CIDR ブロック内にあるリクエストを sidecar プロキシコンテナがインターセプトしないことを示します。

4. ワークロードを再デプロイする と、Sidecar プロキシの構成が有効になります。

5. 構成を表示するには、次のコマンドを実行します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - '192.168.0.1/32,10.1.0.0/24'  // デフォルトで構成されたホストのCIDRブロックとSidecarプロキシ設定で指定されたIPアドレス範囲
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...

   istio-init コンテナのランタイムパラメータ -x は 192.168.0.1/32,10.1.0.0/24 に設定されています。192.168.0.1/32 は、デフォルトで構成されたホストの CIDR ブロックです。10.1.0.0/24 は、Sidecar プロキシ構成で指定された IP アドレス範囲と同じです。これは、[Sidecar プロキシに外部アクセスがリダイレクトされないアドレス] の構成が有効になっていることを示します。

構成リファレンス

カンマ (,) で区切られたポート番号のリストを構成します。 サイドカープロキシコンテナは、宛先ポートがリストにあるインバウンドトラフィックをインターセプトします。 デフォルト値は [*] で、サイドカープロキシコンテナがワークロードのすべてのインバウンドトラフィックをインターセプトすることを示します。

構成例

1. [サイドカープロキシ設定] ページで、構成レベルタブを選択し、[ポートまたは IP アドレスによるサイドカープロキシの有効化/無効化] をクリックします。

2. (オプション) ステップ 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。 [ポートまたは IP アドレスによるサイドカープロキシの有効化/無効化] セクションで、[サイドカープロキシにリダイレクトされるインバウンドトラフィックのポート] を選択します。

3. [サイドカープロキシにリダイレクトされるインバウンドトラフィックのポート] を 80,443 に設定し、[設定の更新] をクリックします。

   この構成は、サイドカープロキシコンテナが対応するワークロードのポート 80 および 443 宛てのリクエストをインターセプトすることを示します。

4. ワークロードを再デプロイすると、サイドカープロキシの構成が有効になります。

5. 以下のコマンドを実行して、構成済みを表示します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   期待される出力:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '80,443'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   istio-init コンテナのランタイムパラメータ -b は 80,443 に設定されています。これは、サイドカープロキシ構成で設定されたインバウンドポートと同じです。 これは、[サイドカープロキシにリダイレクトされるインバウンドトラフィックのポート] の構成が有効になっていることを示します。

構成リファレンス

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[ポートまたは IP アドレスによる Sidecar プロキシの有効化/無効化] をクリックします。

2. (オプション) ステップ 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。 [Sidecar プロキシにリダイレクトされるアウトバウンドトラフィックのポート] を選択します。

3. [Sidecar プロキシにリダイレクトされるアウトバウンドトラフィックのポート] を 80,443 に設定し、[設定の更新] をクリックします。

   この構成は、Sidecar プロキシコンテナがポート 80 および 443 宛てのリクエストをインターセプトすることを示します。

4. ワークロードを再デプロイすると、Sidecar プロキシの構成が有効になります。

5. 構成を表示するには、次のコマンドを実行します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
           - '-q'
           - '80,443'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   istio-init コンテナのランタイムパラメータ -q は 80,443 に設定されています。これは、Sidecar プロキシ構成で設定されたアウトバウンドポートと同じです。これは、[Sidecar プロキシにリダイレクトされるアウトバウンドトラフィックのポート] の構成が有効になっていることを示します。

構成リファレンス

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[ポートまたは IP アドレスによる Sidecar プロキシの有効化/無効化] をクリックします。

2. (オプション) ステップ 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。[Sidecar プロキシにリダイレクトされない受信トラフィックのポート] を選択します。

3. [Sidecar プロキシにリダイレクトされない受信トラフィックのポート] を 8000 に設定し、[設定の更新] をクリックします。

   この構成は、Sidecar プロキシコンテナがワークロードのポート 8000 宛てのリクエストをインターセプトしなくなることを示します。

4. ワークロードを再デプロイすると、Sidecar プロキシの構成が有効になります。

5. 構成を表示するには、次のコマンドを実行します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020,8000'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   istio-init コンテナのランタイムパラメータ -d は 15090,15021,15081,9191,8000 に設定されています。15090、15021、15081、および 9191 は、Sidecar プロキシのアプリケーションポートです。デフォルトでは、Sidecar プロキシコンテナは、これらのポート宛ての受信トラフィックをインターセプトしません。ポート 8000 は、Sidecar プロキシ構成で設定された受信ポートと同じです。これは、[Sidecar プロキシにリダイレクトされない受信トラフィックのポート] の構成が有効になっていることを示します。

構成リファレンス

カンマ (,) で区切られたポートのリストを構成します。リスト内のポート宛ての送信トラフィックは、宛先サービスの IP アドレスが [サイドカープロキシに外部アクセスがリダイレクトされるアドレス] に含まれているかどうかに関係なく、また、宛先サービスのポートが [サイドカープロキシに送信トラフィックがリダイレクトされるポート] に含まれているかどうかに関係なく、サイドカープロキシによってインターセプトされません。

構成例

1. [サイドカープロキシ設定] ページで、構成レベルタブを選択し、[ポートまたは IP アドレスによるサイドカープロキシの有効化/無効化] をクリックします。

2. (オプション) ステップ 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。 [サイドカープロキシにリダイレクトされない送信トラフィックのポート] を選択します。

3. [サイドカープロキシにリダイレクトされない送信トラフィックのポート] を 8000 に設定し、[設定の更新] をクリックします。

   この構成は、サイドカープロキシコンテナがポート 8000 宛てのサービスリクエストをインターセプトしなくなることを示しています。

4. ワークロードを再デプロイすると、サイドカープロキシの構成が有効になります。

5. 構成を表示するには、次のコマンドを実行します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   期待される出力:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
           - '-o'
           - '8000'
   ...
         name: istio-init
   ...
                               

   istio-init コンテナのランタイムパラメータ -o は 8000 に設定されています。これは、構成項目 [サイドカープロキシにリダイレクトされないアウトバウンドトラフィックのポート] で設定されたポートと同じです。これは、構成項目が有効になっていることを示します。

構成リファレンス

DNS プロキシが有効になっている場合、Sidecar プロキシはワークロードの DNS リクエストをインターセプトして、ASM のパフォーマンスと可用性を向上させます。 ワークロードからのすべてのリクエストは Sidecar プロキシにリダイレクトされます。 Sidecar プロキシは IP アドレスとローカルドメイン名のマッピングを保存するため、DNS リクエストが解決できない場合を除き、ほとんどの場合、リモート DNS サービスをリクエストせずにワークロードに DNS 応答を返します。 詳細については、「ASM インスタンスで DNS プロキシ機能を使用する」をご参照ください。

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[DNS プロキシ] をクリックします。

2. (オプション) ステップ 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。 [DNS プロキシを有効にする] を選択し、スイッチをオンにして、[設定を更新] をクリックします。

3. ワークロードを再デプロイすると、Sidecar プロキシの構成が有効になります。

4. 次のコマンドを実行して、構成を表示します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力:

   apiVersion: v1
   kind: Pod
   spec:
     containers:
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=warning'
           - '--proxyComponentLogLevel=misc:error'
           - '--log_output_level=default:info'
           - '--concurrency'
           - '3'
         env:
   ...
           - name: ISTIO_META_DNS_AUTO_ALLOCATE
             value: 'true'
           - name: ISTIO_META_DNS_CAPTURE
             value: 'true'
   ...
         name: istio-proxy
                               

   ISTIO_META_DNS_AUTO_ALLOCATE および ISTIO_META_DNS_CAPTURE 環境変数の istio-proxy コンテナが true に設定されています。これは、[DNS プロキシ] の構成が有効になっていることを示します。

構成リファレンス

これらの構成項目は、Sidecar プロキシコンテナに追加の環境変数を追加するために使用されます。 Sidecar プロキシには、次の環境変数を構成できます。

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[Sidecar プロキシの環境変数を管理する] をクリックします。

2. （オプション）手順 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。 [Sidecar グレースフルシャットダウン] を選択します。

3. スイッチをオンにして、[設定の更新] をクリックします。

4. ワークロードを再デプロイする と、Sidecar プロキシの構成が有効になります。

5. 次のコマンドを実行して、構成を表示します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力：

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
         env:
           - name: EXIT_ON_ZERO_ACTIVE_CONNECTIONS
             value: 'true'
         name: istio-proxy
   ...

   EXIT_ON_ZERO_ACTIVE_CONNECTIONS 環境変数が、ポッド内の istio-proxy コンテナの環境変数に追加されます。 これは、Sidecar プロキシの環境変数を管理する の構成が有効になっていることを示します。

構成リファレンス

Sidecar Graceful Startup は、Sidecar プロキシのライフサイクルを管理するために使用されます。デフォルトでは、有効になっています。これは、Sidecar プロキシが挿入されたポッドの場合、アプリケーションコンテナの前に Sidecar プロキシを起動する必要があることを示します。目的は、Sidecar プロキシが起動されていない場合に、アプリケーションコンテナ宛てのトラフィックが失われないようにすることです。

この構成項目が無効になっている場合、Sidecar プロキシ コンテナとポッド内のアプリケーション コンテナは同時に起動されます。クラスターに多数のポッドがデプロイされている場合、API サーバーの負荷が高いため、Sidecar プロキシ コンテナの起動が遅くなる可能性があります。デプロイメントを高速化するには、この構成項目を無効にすることができます。

構成例

次の例では、[サイドカーのグレースフルスタートアップ] を [グローバル] タブで無効にする方法について説明します。

1. [サイドカープロキシ設定] ページで、[グローバル] タブを選択し、[ライフサイクル管理] をクリックします。

2. [サイドカーのグレースフルスタートアップ] の横にあるスイッチをオフにし、[設定の更新] をクリックします。

3. ワークロードを再デプロイすると、Sidecar プロキシ構成が有効になります。

4. 以下のコマンドを実行して構成を表示します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - command:
   ...
         name: sleep
   ...
         env:
           - name: PROXY_CONFIG
             value: >-
               {..."holdApplicationUntilProxyStarts":false,...}
   ...
         name: istio-proxy
   ...

   [サイドカーのグレースフルスタートアップ] が無効になっている場合、アプリケーションコンテナが起動する前に istio-proxy コンテナを起動する必要はなく、デフォルトの ライフサイクル フィールドは宣言されません。

構成リファレンス

[Sidecar プロキシ ドレイン期間（ポッド終了時）] は、Sidecar プロキシのライフサイクルを管理するためのものです。

ポッドの終了が開始されると、サービスはポッドへのトラフィックのルーティングを停止します。 Sidecar プロキシコンテナは、終了シグナルを受信した後も一定期間既存の受信トラフィックを処理し続けますが、新しい受信トラフィックは受け入れません。この期間は [Sidecar プロキシ ドレイン期間（ポッド終了時）] と呼ばれます。デフォルト値は 5s です。この構成項目は、10s などの秒単位の値に設定する必要があります。

停止されるサービスによって提供される一部の API の応答時間が Sidecar プロキシ ドレイン期間（ポッド終了時）を超えると、処理されていない場合でも、既存のすべての送受信接続が終了します。その結果、一部のリクエストが失われます。この場合は、送受信トラフィックの処理が完了できるように、より大きな値に設定します。

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[ライフサイクル管理] をクリックします。

2. （オプション）手順 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。 [Sidecar プロキシ ドレイン期間（ポッド終了時）] を選択します。

3. 10s に設定し、[設定の更新] をクリックします。

4. ワークロードを再デプロイすると、Sidecar プロキシ構成が有効になります。

5. 構成を表示するには、次のコマンドを実行します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力：

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
         env:
           - name: TERMINATION_DRAIN_DURATION_SECONDS
             value: '10'
   ...
           - name: PROXY_CONFIG
             value: >-
               {..."terminationDrainDuration":"10s"}
   ...
         name: istio-proxy
   ...

   ポッド内の istio-proxy コンテナは、値が 10 の TERMINATION_DRAIN_DURATION_SECONDS という名前の環境変数と、PROXY_CONFIG 内の terminationDrainDuration が 10s で構成されています。これは、[Sidecar プロキシ ドレイン期間（ポッド終了時）] の構成が有効になっていることを示しています。

構成リファレンス

Sidecar プロキシコンテナのライフサイクルフックをカスタマイズするには、コンテナライフサイクルフックフィールド（lifecycle）を JSON 形式で入力します。このフィールドは、Sidecar プロキシコンテナに構成されているデフォルトのコンテナライフサイクルフックフィールドを置き換えます。詳細については、「コンテナライフサイクルフック」をご参照ください。

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[ライフサイクル管理] をクリックします。

2. （オプション）手順 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。[Sidecar プロキシのライフサイクル] を選択します。

3. [Sidecar プロキシのライフサイクル] の下の編集ボックスで、次の YAML ファイルを構成し、[設定の更新] をクリックします。

   この YAML ファイルは、postStart および preStop フックパラメータを構成します。

   • postStart: Sidecar プロキシコンテナの起動後、 pilot-agent が pilot-agent と Envoy プロキシの完全な起動を待機し始めることを示します。

   • preStop: Sidecar プロキシコンテナが停止する前に 13 秒間スリープすることを示します。

   {
     "postStart": {
       "exec": {
         "command": [
           "pilot-agent",
           "wait"
         ]
       }
     },
     "preStop": {
       "exec": {
         "command": [
           "/bin/sh",
           "-c",
           "sleep 13"
         ]
       }
     }
   }

4. ワークロードを再デプロイすると、Sidecar プロキシ構成が有効になります。

5. 構成を表示するには、次のコマンドを実行します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
   ...
           lifecycle:
           postStart:
             exec:
               command:
               - pilot-agent
               - wait
           preStop:
             exec:
               command:
               - /bin/sh
               - -c
               - sleep 13
         name: istio-proxy
   ...

   ポッド内の istio-proxy コンテナのライフサイクルフックフィールド（lifecycle）が、想定される構成に変更されています。これは、[Sidecar プロキシのライフサイクル] の構成が有効になっていることを示します。

構成リファレンス

この構成項目は、Sidecar プロキシコンテナのアウトバウンドトラフィックポリシーを構成するために使用されます。外部サービスとは、ASM のサービスレジストリで定義されていないサービスを指します。デフォルトでは、ASM によって管理される Kubernetes クラスタ内のサービスは登録済みサービスです。サービスエントリ（ServiceEntry）リソースを宣言することで、サービスを ASM に手動で登録できます。

構成例

1. [グローバル] タブの [Sidecar プロキシ設定] ページで、[アウトバウンドトラフィックポリシー] をクリックし、[REGISTRY_ONLY] を選択して、[設定の更新] をクリックします。

2. ワークロードを再デプロイすると、Sidecar プロキシ構成が有効になります。

3. 次の内容を含む sleep.yaml ファイルを作成します。

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: curlimages/curl
           command: ["/bin/sleep", "3650d"]
           imagePullPolicy: IfNotPresent
           volumeMounts:
           - mountPath: /etc/sleep/tls
             name: secret-volume
         volumes:
         - name: secret-volume
           secret:
             secretName: sleep-secret
             optional: true
   ---

4. 次のコマンドを実行して、sleep アプリケーションをデプロイします。

   kubectl apply -f sleep.yaml -n default

5. 次のコマンドを実行して、sleep アプリケーションを使用して外部サービスにアクセスします。

   kubectl exec -it {Name of the pod for the sleep service} -c sleep -- curl www.aliyun.com -v

   予想される出力：

   *   Trying *********...
   * Connected to www.aliyun.com (********) port 80 (#0)
   > GET / HTTP/1.1
   > Host: www.aliyun.com
   > User-Agent: curl/7.87.0-DEV
   > Accept: */*
   >
   * Mark bundle as not supporting multiuse
   < HTTP/1.1 502 Bad Gateway
   < date: Mon,********* 03:25:00 GMT
   < server: envoy
   < content-length: 0
   <
   * Connection #0 to host www.aliyun.com left intact

   HTTP ステータスコード 502 が返されます。これは、Sidecar プロキシが挿入された sleep アプリケーションが外部サービス www.aliyun.com にアクセスできないことを示しています。これは、[アウトバウンドトラフィックポリシー] の構成が有効になっていることを示しています。

構成リファレンス

この構成項目は、サイドカープロキシのインバウンドトラフィックインターセプト戦略を設定します。 デフォルトでは、サイドカープロキシコンテナは iptables リダイレクトポリシーを使用して、アプリケーションワークロード宛てのインバウンドトラフィックをインターセプトします。 リダイレクトを介してインターセプトした後、アプリケーションはリクエストの送信元 IP として サイドカープロキシコンテナの IP のみを確認し、元のクライアント送信元 IP を識別できません。

インバウンドトラフィックインターセプト戦略を透過プロキシモード（TPROXY）に変更することにより、ASM はサイドカープロキシコンテナが iptables の透過プロキシモードを使用してインバウンドトラフィックをインターセプトできるようにします。 この構成の後、アプリケーションは元のクライアント送信元 IP を確認できるようになります。 詳細については、「クライアントが ASM のサービスにアクセスする際にクライアントの送信元 IP アドレスを保持する」をご参照ください。

構成例

1. [サイドカープロキシ設定] ページで、構成レベルタブを選択し、[サイドカートラフィックインターセプトモード] をクリックします。

2. （オプション）手順 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。 [サイドカートラフィックインターセプトモード] を選択します。

3. [サイドカートラフィックインターセプトモード] の右側で、[TPROXY] を選択し、[設定の更新] をクリックします。

4. ワークロードを再デプロイすると、サイドカープロキシの構成が有効になります。

5. サイドカートラフィックインターセプトモードの構成を表示するには、次のコマンドを実行します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   期待される出力：

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
           - name: PROXY_CONFIG
             value: >-
               {..."interceptionMode":"TPROXY",...}
           - name: ISTIO_META_POD_PORTS
             value: |-
               [
               ]
   ...
         name: istio-proxy
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - TPROXY
   ...
         name: istio-init
   ...

   "interceptionMode":"TPROXY" は、ポッド内の istio-proxy コンテナの環境変数に記録されます。 istio-init コンテナも TPROXY 設定を使用して初期化コマンドを実行します。 これは、[サイドカートラフィックインターセプトモード] の構成が有効になっていることを示します。

構成リファレンス

この構成項目は、Sidecar プロキシコンテナのログレベルを設定するために使用されます。 デフォルトでは、Sidecar プロキシのログレベルは info です。 ログレベルは、info、debug、trace、warning、error、critical、off の 7 つのレベルのいずれかに設定できます。

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[監視統計] をクリックします。

2. (オプション) ステップ 1 で [ワークロード] または [名前空間] を選択した場合は、この手順を実行します。 [ログレベル] を選択します。

3. [ログレベル] ドロップダウンリストから [error] を選択し、[設定の更新] をクリックします。

   この構成は、Sidecar プロキシが error レベル以上のログを表示することを示します。

4. ワークロードを再デプロイすると、Sidecar プロキシの構成が有効になります。

5. 構成を表示するには、次のコマンドを実行します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=error'
   ...
         name: istio-proxy
   ...

   istio-proxy コンテナのランタイムパラメータ --proxyLogLevel が error に設定されています。これは、[ログレベル] の構成が有効になっていることを示します。

構成項目の説明

この構成項目は、Sidecar プロキシによって報告されるカスタム Envoy 統計メトリクスを定義します。Sidecar プロキシの技術実装である Envoy は、広範囲のメトリクスを収集および報告できます。ただし、ASM はデフォルトでこれらのメトリクスのサブセットのみを有効にして、Sidecar プロキシのパフォーマンスオーバーヘッドを最小限に抑えます。

この構成項目を使用して、プレフィックス、サフィックス、または正規表現を照合することにより、Sidecar プロキシが収集および公開する必要がある追加のメトリクスを指定できます。

構成例

1. [Sidecar プロキシ設定] ページで、構成レベルタブを選択し、[モニタリング統計] をクリックします。

2. [proxyStatsMatcher] と [正規表現一致] を選択し、正規表現一致を .*outlier_detection.* に設定します。

   この構成は、Sidecar プロキシがサーキットブレーカーメトリクスの統計を収集することを示します。

3. 詳細については、「ワークロードを再デプロイする」をご参照ください。Sidecar プロキシの構成を有効にするには、ワークロードを再デプロイする必要があります。

4. 次のコマンドを実行して、proxyStatsMatcher の構成を表示します。

   kubectl  get pod -n <Namespace> <Pod name>  -o yaml

   予想される出力：

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
    ...
           - name: PROXY_CONFIG
             value: >-
               {..."proxyStatsMatcher":{"inclusionRegexps":[".*outlier_detection.*"]},...}
   ...

   カスタムメトリクスは、ポッド内の istio-proxy コンテナの環境変数で更新されます。これは、[proxyStatsMatcher] の構成が有効になっていることを示します。