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

パラメーターの説明

このパラメーターは、サイドカープロキシが注入された Pod 内で、istio-init コンテナが実行時に必要とする最小の CPU およびメモリリソースと、コンテナが要求できる最大の CPU およびメモリリソースを指定します。istio-init コンテナは、サイドカープロキシが注入された Pod が起動する際に実行される init コンテナであり、サイドカープロキシコンテナのトラフィックインターセプトルーティングルールを設定します。

設定例

1. Sidecar プロキシ設定 ページで、ターゲットのサイドカープロキシ構成レベルのタブをクリックし、その後 リソース設定 をクリックします。

2. (任意) リソース設定 セクションで、istio-init 初期化コンテナのリソース設定項目 を選択します。

   このステップは、名前空間 および ワークロード タブで必須です。グローバル タブでは、このステップをスキップできます。

3. リソース制限 では、[CPU] を 1 コアに、メモリ を 512 MiB に設定します。リソース要求 では、[CPU] を 0.1 コアに、メモリ を 128 MiB に設定します。次に、ページ下部にある 設定項目の更新 をクリックします。

4. ワークロードを再デプロイして、サイドカープロキシの設定を有効にします。

5. 設定した istio-init 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
   ...

   Pod 内の istio-init という名前の init コンテナの リソース フィールドがターゲットリソース値に設定されている場合、istio-init 初期化コンテナのリソース設定項目 構成が適用されています。

パラメーターの説明

このパラメーターは、注入された Istio プロキシと istio-init init コンテナに割り当てられる ACK 動的オーバーセルドリソースを指定します。動的オーバーセルドリソースの詳細については、「動的リソースオーバーコミットメントの有効化」をご参照ください。

このパラメーターは、注入された Istio プロキシのリソース設定およびistio-init init コンテナのリソース設定と同じ方法で設定されます。設定後、Pod が ACK 動的リソースオーバーセリングの label koordinator.sh/qosClass を持っている場合、Pod 内の Istio プロキシと istio-init init コンテナには、通常の Kubernetes CPU およびメモリリソースの代わりに ACK 動的オーバーセルドリソースが割り当てられます。

設定例

1. Sidecar プロキシ設定 ページで、ターゲットのサイドカープロキシ構成レベルのタブをクリックし、リソース設定 をクリックし、Sidecar の ACK 動的オーバーコミットリソースを設定 を選択し、関連するパラメーターを設定してから、ページ下部にある 設定項目の更新 をクリックします。

   パラメーター	サブパラメーター	説明
   Istio プロキシのリソース設定 (ACK 動的オーバーコミットリソース)	リソース制限	[CPU] を 2000 ミリコアに、メモリ を 2048 MiB に設定します。
   	リソース要求	[CPU] を 200 ミリコアに、メモリ を 256 MiB に設定します。
   istio-init 初期化コンテナリソース (ACK SLO リソース)	リソース制限	[CPU] を 1000 ミリコアに、メモリを 1024 MiB に設定します。
   	リソース要求	[CPU] を 100 ミリコアに、メモリ を 128 MiB に設定します。

2. ワークロードを再デプロイして、サイドカープロキシの設定を有効にします。

3. 次のコマンドを実行して、設定した istio-init 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
   ...

   Pod 内の istio-proxy コンテナ (Istio プロキシコンテナ) と istio-init init コンテナの両方に resources フィールドがターゲットリソース値に設定されていることは、Sidecar の ACK 動的オーバーコミットリソースを設定 構成が有効になったことを示します。

パラメーターの説明

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

設定例

1. Sidecar プロキシ設定 ページで、ターゲットのサイドカープロキシ構成レベルのタブをクリックし、次に リソース設定 をクリックします。

2. (オプション) リソース設定 セクションで、Istio プロキシのスレッド数 を選択します。

   このステップは、名前空間 タブと ワークロード タブで必須です。グローバル タブでは、このステップを省略できます。

3. Istio プロキシのスレッド数 を 3 に設定し、ページ下部にある 設定項目の更新 をクリックします。

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

4. ワークロードを再デプロイして、サイドカープロキシの設定を有効にします。

5. 次のコマンドを実行して、設定した Istio-Proxy の同時実行数を表示します。

   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
   ...

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

パラメーターの説明

カンマ (,) で区切られた IP アドレス範囲のリストを指定する必要があります。各 IP アドレス範囲は CIDR 表記です。サイドカープロキシが注入されたワークロードが他のサービスにアクセスする場合、宛先 IP アドレスが設定されたアドレス範囲内にあるリクエストのみがサイドカープロキシコンテナによってインターセプトされます。その他のリクエストは、サイドカープロキシを経由せずに直接宛先に送信されます。デフォルトでは、このパラメーターは * に設定されており、サイドカープロキシコンテナがワークロードのすべてのアウトバウンドトラフィックをインターセプトすることを示します。

設定例

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

2. (オプション) ポートまたはアドレスによる Sidecar プロキシの有効化/無効化 セクションで、インターセプト対象の外部アクセスアドレス範囲 を選択します。

   このステップは、名前空間 タブと ワークロード タブで必須です。グローバル タブでは、このステップをスキップできます。

3. インターセプト対象の外部アクセスアドレス範囲 を 192.168.0.0/16,10.1.0.0/24 に設定し、ページの下部にある 設定項目の更新 をクリックします。

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

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'
           - '192.168.0.0/16,10.1.0.0/24'
           - '-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 が含まれます。これは、インターセプト対象の外部アクセスアドレス範囲 構成が有効になったことを示します。

パラメーターの説明

設定例

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

2. (オプション) ポートまたはアドレスによる Sidecar プロキシの有効化/無効化 セクションで、外部へのアクセスをブロックしないアドレス範囲 を選択します。

   このステップは、名前空間 タブと ワークロード タブでは必須です。グローバル タブでは、このステップをスキップできます。

3. 外部へのアクセスをブロックしないアドレス範囲 を 10.1.0.0/24 に設定し、ページの下部にある 設定項目の更新 をクリックします。

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

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,10.1.0.0/24'
           - '-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 は、サイドカープロキシに設定された IP アドレス範囲と一致します。これは、外部へのアクセスをブロックしないアドレス範囲 構成が有効になったことを示しています。

パラメーターの説明

カンマ (,) で区切られたポートのリストを指定する必要があります。リスト内のポート宛のトラフィックは、サイドカープロキシコンテナによってインターセプトされます。デフォルトでは、このパラメーターは * に設定されており、サイドカープロキシコンテナがワークロードのすべてのインバウンドトラフィックをインターセプトすることを示します。

設定例

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

2. (オプション) ポートまたはアドレスによる Sidecar プロキシの有効化/無効化 セクションで、ポートを設定して、イングレストラフィックが Sidecar プロキシを経由するようにします。 を選択します。

   このステップは、名前空間 タブおよび ワークロード タブでは必須です。グローバル タブではこのステップを省略できます。

3. ポートを設定して、イングレストラフィックが Sidecar プロキシを経由するようにします。 を 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 が含まれています。これは、ポートを設定して、イングレストラフィックが Sidecar プロキシを経由するようにします。 構成が有効になったことを示します。

パラメーターの説明

設定例

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

2. (オプション) ポートまたはアドレスによる Sidecar プロキシの有効化/無効化 セクションで、Sidecar プロキシ経由にするアウトバウンドポートの設定 を選択します。

   このステップは、名前空間 タブと ワークロード タブでは必須です。グローバル タブでは、このステップを省略できます。

3. Sidecar プロキシ経由にするアウトバウンドポートの設定 を 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'
           - '*'
           - '-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 プロキシ経由にするアウトバウンドポートの設定 構成が有効になったことを示しています。

パラメーターの説明

設定例

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

2. (任意) ポートまたはアドレスによる Sidecar プロキシの有効化/無効化 セクションで、インバウンドトラフィックを sidecar から除外する を選択します。

   このステップは、名前空間 タブと ワークロード タブでは必須です。グローバル タブでは、このステップをスキップできます。

3. インバウンドトラフィックを sidecar から除外する を 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,8000'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   istio-init コンテナの実行時パラメーターには、-d 15090,15021,15081,9191,8000 が含まれます。ポート 15090,15021,15081,9191 はサイドカープロキシのアプリケーションポートであり、デフォルトでインターセプトから除外されます。ポート 8000 は、サイドカープロキシ用に構成されたインバウンドポートと一致します。これは、インバウンドトラフィックを sidecar から除外する 構成が有効になったことを示します。

パラメーターの説明

カンマ (,) で区切られたポートのリストを指定する必要があります。これは、すべてのアウトバウンドトラフィックの宛先サービスポートを表します。宛先サービスポートがリスト内にあるリクエストは、宛先 IP アドレスがインターセプトされるアウトバウンドアドレス範囲内にあるか、宛先ポートがインターセプトされるアウトバウンドポートリスト内にあるかに関わらず、サイドカープロキシコンテナによってインターセプトされません。

設定例

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

2. (オプション) ポートまたはアドレスによる Sidecar プロキシの有効化/無効化 セクションで、アウトバウンドトラフィックを sidecar から除外するポートを設定します。 を選択します。

   名前空間 タブと ワークロード タブでは、このステップは必須です。グローバル タブでは、このステップをスキップできます。

3. アウトバウンドトラフィックを sidecar から除外するポートを設定します。 を 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 が含まれていることは、サイドカープロキシ用に構成されたアウトバウンドポートと一致します。これにより、アウトバウンドトラフィックを sidecar から除外するポートを設定します。 構成が有効になったことがわかります。

パラメーターの説明

サイドカープロキシコンテナの DNS プロキシ機能を有効または無効にできます。DNS プロキシ機能が有効になると、サイドカープロキシコンテナはワークロードの DNS リクエストをインターセプトして、Service Mesh のパフォーマンスと可用性を向上させます。ワークロードからのすべてのリクエストはサイドカープロキシコンテナにリダイレクトされます。サイドカープロキシコンテナは IP アドレスとローカルドメイン名のマッピングをローカルに保存するため、リモートの DNS サービスにリクエストを送信することなく、DNS 応答を直接ワークロードに返すことができます。DNS リクエストがサイドカープロキシコンテナで処理できない場合、サイドカーは DNS リクエストを直接転送します。詳細については、「ASM での DNS プロキシの使用」をご参照ください。

設定例

1. Sidecar プロキシ設定 ページで、対象のサイドカープロキシ構成レベルのタブをクリックし、DNS プロキシ機能 をクリックします。

2. (オプション) DNS プロキシ機能 セクションで、[DNS プロキシを有効にする] を選択し、右側のスイッチをオンにして、設定項目の更新 をクリックします。

   このステップは、名前空間 タブおよび ワークロード タブで必須です。グローバル タブでは、このステップは省略可能です。スイッチをオンにすると、サイドカープロキシの DNS プロキシ機能が有効になります。

3. ワークロードを再デプロイして、サイドカープロキシの設定を有効にします。

4. 次のコマンドを実行して、設定した DNS プロキシ機能を表示します。

   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-proxy コンテナの ISTIO_META_DNS_AUTO_ALLOCATE および ISTIO_META_DNS_CAPTURE 環境変数は true に設定されます。これは、DNS プロキシ機能構成が有効になったことを示します。

パラメーターの説明

このパラメーターは、サイドカープロキシコンテナに追加される追加の環境変数を指定します。次の 2 種類のサイドカープロキシ環境変数を設定できます。

設定例

1. Sidecar プロキシ設定 ページで、対象のサイドカープロキシ構成レベルのタブをクリックし、次に Sidecar プロキシの環境変数管理 をクリックします。

2. (オプション) Sidecar プロキシの環境変数管理 セクションで、Sidecar のグレースフル終了 (EXIT_ON_ZERO_ACTIVE_CONNECTIONS) (EXIT_ON_ZERO_ACTIVE_CONNECTIONS) を選択します。

   このステップは、名前空間 タブおよび ワークロード タブでは必須です。グローバル タブでは、このステップをスキップできます。

3. Sidecar のグレースフル終了 (EXIT_ON_ZERO_ACTIVE_CONNECTIONS) (EXIT_ON_ZERO_ACTIVE_CONNECTIONS) の右にあるスイッチをオンにして、構成の更新 をクリックします。

4. ワークロードを再デプロイして、サイドカープロキシの設定を有効にします。

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 環境変数が、Pod 内の istio-proxy コンテナのサイドカーの環境変数に追加されます。これは、Sidecar プロキシの環境変数管理 構成が有効になったことを示します。

パラメーターの説明

HoldApplicationUntilProxyStarts は、サイドカープロキシのライフサイクル管理パラメーターです。HoldApplicationUntilProxyStarts はデフォルトで有効になっており、サイドカープロキシが注入された Pod では、Pod 内のアプリケーションコンテナが起動する前にサイドカープロキシコンテナが正常に起動する必要があります。これにより、サイドカープロキシの起動が完了していないためにアプリケーションコンテナへのトラフィックが失われるのを防ぎます。

このパラメーターを無効にすると、Pod 内のサイドカープロキシコンテナとアプリケーションコンテナが同時に起動します。クラスターに多数の Pod がデプロイされている場合、APIServer の負荷が高いためにサイドカープロキシコンテナの起動が遅くなることがあります。HoldApplicationUntilProxyStarts を無効にすることで、デプロイメントを高速化できます。

設定例

次の例では、グローバル タブで HoldApplicationUntilProxyStarts を無効にする方法を説明します。

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

2. サイドカーのグレースフル起動 (HoldApplicationUntilProxyStarts) (HoldApplicationUntilProxyStarts) の右にあるスイッチをオフにし、設定項目の更新 をクリックします。

   この設定は、HoldApplicationUntilProxyStarts 機能が無効になることを示します。

3. ワークロードを再デプロイして、サイドカープロキシの設定を有効にします。

4. 次のコマンドを実行して、HoldApplicationUntilProxyStarts の設定を表示します。

   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
   ...

   holdApplicationUntilProxyStarts 機能が無効になると、istio-proxy コンテナはアプリケーションコンテナの前に強制的に宣言されなくなり、デフォルトの lifecycle フィールドも宣言されなくなります。この場合、Service Mesh は、アプリケーションコンテナが起動する前にサイドカープロキシコンテナが正常に起動することを保証しなくなります。

パラメーターの説明

サイドカープロキシの終了ドレイン期間は、サイドカープロキシのライフサイクル管理パラメーターです。サイドカープロキシが Pod に注入されると、アプリケーション Pod のトラフィックはサイドカープロキシコンテナによってインターセプトされます。

Pod が停止を開始すると、対応するサービスは Pod へのトラフィック転送を停止します。サイドカープロキシコンテナが終了シグナルを受信すると、一定期間待機します。この期間中、コンテナは新しいインバウンドトラフィックの受け入れを停止しますが、既存のインバウンドトラフィックの処理は続行します。アウトバウンドトラフィックは影響を受けず、通常通り送信できます。この期間をサイドカープロキシの終了ドレイン期間と呼びます。サイドカープロキシコンテナのデフォルトの終了ドレイン期間は 5s です。s 単位で期間を設定できます (例：10s)。

停止したサービスが提供するインターフェイス呼び出しに時間がかかり、サイドカープロキシコンテナの終了ドレイン期間を超えると、既存のインバウンドおよびアウトバウンド接続は完全に処理されていなくても終了し、一部のリクエストが失われる可能性があります。この場合、このパラメーターを使用してサイドカープロキシの終了ドレイン期間を延長し、インバウンドおよびアウトバウンドトラフィックが完全に処理されるようにすることができます。

サイドカープロキシの終了ドレイン期間は、10s のように s 単位で秒数を指定する必要があります。

設定例

1. Sidecar プロキシ設定 ページで、対象のサイドカープロキシ構成レベルのタブをクリックし、次に ライフサイクル管理 をクリックします。

2. (任意) ライフサイクル管理 セクションで、Sidecar プロキシの終了待機時間 を選択します。

   このステップは、名前空間 タブおよび ワークロード タブでは必須です。グローバル タブではこのステップをスキップできます。

3. Sidecar プロキシの終了待機時間 を 10s に設定し、設定項目の更新 をクリックします。

   この設定は、サイドカープロキシが終了時に既存の接続を処理するために 10 秒間待機することを示します。

4. ワークロードを再デプロイして、サイドカープロキシの設定を有効にします。

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
   ...

   Pod 内の istio-proxy コンテナでは、環境変数 TERMINATION_DRAIN_DURATION_SECONDS が 10 に設定され、環境変数 PROXY_CONFIG には terminationDrainDuration が 10s として記録されます。これは、Sidecar プロキシの終了待機時間 構成が有効になったことを示します。

パラメーターの説明

サイドカープロキシのライフサイクルパラメーターを使用すると、サイドカープロキシコンテナのコンテナライフサイクルフックを完全にカスタマイズできます。このパラメーターには、JSON 形式で宣言されたコンテナライフサイクルフックフィールド (lifecycle) を入力する必要があります。このフィールドは、サイドカープロキシコンテナのデフォルトのコンテナライフサイクルフックフィールドを置き換えます。詳細については、「コンテナライフサイクルフック」をご参照ください。

設定例

1. Sidecar プロキシ設定 ページで、対象のサイドカープロキシ構成レベルのタブをクリックし、次に ライフサイクル管理 をクリックします。

2. (オプション) ライフサイクル管理 セクションで、サイドカープロキシのライフサイクル を選択します。

   このステップは、名前空間 タブと ワークロード タブでは必須です。グローバル タブでは、このステップを省略できます。

3. サイドカープロキシのライフサイクル で、次の YAML コンテンツを入力し、設定項目の更新 をクリックします。

   この YAML コンテンツは、postStart および preStop フックパラメーターを設定します。

   • postStart：サイドカーコンテナが起動した後、pilot-agent が起動するのを待ちます。

   • preStop：サイドカーコンテナが停止する前に 13 秒間スリープします。

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

4. ワークロードを再デプロイして、サイドカープロキシの設定を有効にします。

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
   ...

   Pod 内の istio-proxy コンテナのコンテナライフサイクルフックフィールド (lifecycle) がターゲット構成に変更されます。これは、サイドカープロキシのライフサイクル 構成が有効になったことを示します。

パラメーターの説明

このパラメーターは、サイドカープロキシコンテナの外部サービスへのアクセスポリシーを指定します。外部サービスとは、メッシュ外にあり、Service Mesh に登録されていないサービスのことです。デフォルトでは、Service Mesh が管理する Kubernetes クラスター内のすべてのサービスは登録済みサービスです。ServiceEntry リソースを宣言することで、手動でサービスを Service Mesh に登録できます。登録されていないサービスは外部サービスと見なされます。

設定例

1. グローバル タブ、Sidecar プロキシ設定 ページで、外部サービスアクセスポリシー をクリックし、外部サービスへのアクセスポリシー OutboundTrafficPolicy の右側で [REGISTRY_ONLY] を選択し、設定項目の更新 をクリックします。

   この設定により、メッシュ内のサービスが外部サービスにアクセスすることが制限されます。

2. ワークロードを再デプロイして、サイドカープロキシの設定を有効にします。

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 {sleep-pod-name} -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

   502 応答は、サイドカープロキシが注入された sleep アプリケーションが外部サービス www.aliyun.com にアクセスできないことを示します。これは、外部サービスアクセスポリシー 構成が有効になったことを示します。

パラメーターの説明

このパラメーターは、サイドカープロキシのインバウンドトラフィックに対するインターセプトポリシーを指定します。デフォルトでは、サイドカープロキシコンテナは iptables の REDIRECT ポリシーを使用して、アプリケーションワークロードに送信されるインバウンドトラフィックをインターセプトします。リダイレクトによってインバウンドトラフィックがインターセプトされた後、アプリケーションはリクエストのソース IP アドレスとしてサイドカープロキシコンテナの IP アドレスしか見ることができず、クライアントの元の IP アドレスを見ることはできません。

インバウンドトラフィックのインターセプトポリシーを透過型プロキシ (TPROXY) ポリシーに変更すると、Service Mesh はサイドカープロキシコンテナが iptables の透過型プロキシモードでインバウンドトラフィックをインターセプトできるようにします。このパラメーターを設定すると、アプリケーションはクライアントの元の IP アドレスを見ることができます。詳細については、「Service Mesh でクライアントのソース IP を取得する」をご参照ください。

設定例

1. Sidecar プロキシ設定 ページで、対象のサイドカープロキシ構成レベルのタブをクリックし、次に Sidecar のインバウンドトラフィックインターセプトポリシー をクリックします。

2. (オプション) Sidecar のインバウンドトラフィックインターセプトポリシー セクションで、Sidecar のインバウンドトラフィックインターセプトポリシー を選択します。

   このステップは、名前空間 タブと ワークロード タブでは必須です。グローバル タブでは、このステップをスキップできます。

3. Sidecar のインバウンドトラフィックインターセプトポリシー の右側で、透過型プロキシポリシー を選択し、設定項目の更新 をクリックします。

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
   ...

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

パラメーターの説明

このパラメーターは、サイドカープロキシコンテナのログレベルを指定します。デフォルトでは、サイドカープロキシは info ログレベルを使用します。サイドカープロキシからより多くの、またはより少ないログ情報を取得するために、サイドカープロキシのログレベルを info、debug、trace、warning、error、critical、off の 7 つのレベルのいずれかに変更できます。

設定例

1. Sidecar プロキシ設定 ページで、対象のサイドカープロキシ構成レベルのタブをクリックし、モニタリング統計 をクリックします。

2. (オプション) モニタリング統計 セクションで、ログレベル を選択します。

   このステップは、名前空間 タブと ワークロード タブでは必須です。グローバル タブでは、このステップをスキップできます。

3. ログレベル の右側で、[error] を選択し、設定項目の更新 をクリックします。

   この設定は、サイドカープロキシが error レベルでログを出力し、error レベル以上のログのみが出力されることを示します。

4. ワークロードを再デプロイして、サイドカープロキシの設定を有効にします。

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 に設定されています。これは、ログレベル 構成が有効になったことを示しています。

パラメーターの説明

このパラメーターは、サイドカープロキシによって報告されるカスタム Envoy 統計を定義します。Envoy はサイドカープロキシの技術的実装であり、一連のメトリックを収集して報告できます。しかし、Service Mesh は、サイドカープロキシのパフォーマンスオーバーヘッドを削減するために、デフォルトで一部のメトリックの収集と公開のみを有効にします。このパラメーターを使用して、プレフィックスマッチング、サフィックスマッチング、または正規表現マッチングによって、サイドカープロキシが収集および報告する必要がある追加のメトリックを指定できます。

設定例

1. Sidecar プロキシ設定 ページで、対象のサイドカープロキシ構成レベルのタブをクリックし、モニタリング統計 をクリックします。

2. モニタリング統計 セクションで、[proxyStatsMatcher] を選択し、正規表現マッチング を選択して .*outlier_detection.* に設定します。

   この設定により、サイドカープロキシのサーキットブレーカーメトリクスの収集が追加されます。

3. ワークロードを再デプロイして、サイドカープロキシの設定を有効にします。

4. 次のコマンドを実行して、設定したサイドカープロキシのカスタム統計を表示します。

   kubectl get pod -n <namespace> <pod-name> -o yaml

   期待される出力：

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

   Pod 内の istio-proxy コンテナのサイドカー環境変数内のカスタム統計が更新されています。これは、proxyStatsMatcher の設定が有効になっていることを示します。