Anthos Service Mesh と Traffic Director は Cloud Service Mesh になりました。詳細については、Cloud Service Mesh の概要をご覧ください。

高度な構成の設定

このドキュメントでは、Cloud Service Mesh を構成する際に役立つ事項について説明します。

Cloud Service Mesh 用の単一の Compute Engine VM の構成

この手順は、サイドカープロキシのデプロイとトラフィックインターセプトを実装して、VM に Cloud Service Mesh サービスへのアクセス権を付与する方法の例として使用します。

この手順を使用するには、Docker がインストールされている必要があります。Docker Engine のインストール手順については、Docker の手順をご覧ください。

このプロセスに従って単一の VM に Cloud Service Mesh を構成する場合は、一部の設定タスクで Linux ホストにアクセスする必要があります。Virtual Private Cloud のネットワーク上で実行されているローカルマシンまたは VM をホストに設定できます。

まず、構成ファイルとサンプルスクリプトをダウンロードして準備します。

セットアッププロセスで使用している Linux ホストにログインします。
必要なファイルのアーカイブを Linux ホストにダウンロードして、アーカイブを展開します。
```
wget https://storage.googleapis.com/traffic-director/traffic-director-xdsv3.tar.gz
tar -xzvf traffic-director-xdsv3.tar.gz; cd traffic-director-xdsv3
```
アーカイブには次のファイルが含まれています。
- sidecar.env - 環境変数を含む構成ファイル。
- iptables.sh - netfilter ルールを設定するためのスクリプト。
- bootstrap_template.yaml - Envoy 用のブートストラップテンプレートファイル。
- run.sh – sidecar.env 構成ファイルを使用して iptables をインターセプト用に設定し、Envoy サイドカープロキシを実行する最上位スクリプト。
サイドカープロキシを実行する各ホストで、Envoy プロキシのプロセスを実行するシステムユーザーを作成します。これは Envoy プロキシユーザーです。Envoy プロキシユーザーのログインは無効になっています。
```
sudo adduser --system --disabled-login envoy
```
sidecar.env ファイルを編集して構成を変更します。各変数の詳細な説明については、構成ファイルのインラインコメントをご覧ください。
1. sidecar.env ファイルで、ENVOY_USER 変数を Envoy プロキシユーザーとして選択したユーザー名に設定します。

次に、Cloud Service Mesh を使用してアプリケーションを実行している各 VM ホストに対して、次の手順を行います。

Cloud Service Mesh を使用するように構成するアプリケーションを実行している各 VM ホストに、変更済みの sidecar.env ファイルを格納する traffic-director-xdsv3 ディレクトリ全体をコピーします。
run.sh スクリプトをシステムの起動スクリプトに追加します。これにより、VM が再起動するたびにスクリプトが実行されます。
各 VM ホストで、run.sh スクリプトを実行します。
```
cd traffic-director-xdsv3
sudo ./run.sh start
```
Envoy プロキシが正常に起動したことを確認します。
```
sudo ./run.sh status
```
次の出力が表示されます。
```
OK: Envoy seems to be running.
OK: Traffic interception seems to be enabled.
```
トラフィックインターセプトの方向を確認するには、次のコマンドを使用します。
```
sudo iptables -S -t nat | grep ISTIO_REDIRECT
```
想定される出力は次のとおりです。
```
-N ISTIO_REDIRECT
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001`
```

ルーティングルールマップ

ルーティングルールマップでルーティングを構成する方法は 2 つあります。

サービスの実際の宛先 VIP に基づいてルーティングを有効にできます。サービスの VIP を転送ルールの IPAddress パラメータとして構成した場合、そのアドレスが宛先として指定され、ポートに関連付けられたトラフィックのみが、URL マップに指定されたホストパラメータとパスパラメータに基づいて一致し、ルーティングされます。

また、転送ルールのアドレスを 0.0.0.0 に設定することもできます。これにより、リクエストの宛先 IP アドレスに関係なく、宛先ポートに基づいてのみトラフィックを照合するようにプロキシが構成されます。その後、URL マップで指定されたホストパラメータとパスパラメータに基づいて、トラフィックがルーティングされます。

これらの 2 つの方法では、ホストルールで構成されている通り、ホスト名は、宛先 VIP とポートペア、または宛先ポート（VIP が 0.0.0.0 の場合）に関連付けられており、サービスメッシュ構成内で一意である必要があります。つまり、同じホスト名を使用する 2 つの異なるサービスを、異なるバックエンドのセットで使用することはできません。

選択した方法に関係なく、サービスのホスト名 / FQDN によって解決される VIP へのトラフィックと、サービスがリッスンするポートがインターセプトされ、サイドカープロキシにリダイレクトされる必要があります。ホストの完全な構成の詳細については、Cloud Service Mesh 用の単一の Compute Engine VM の構成をご覧ください。

VPC ネットワーク内の転送ルールには、VPC ネットワークごとに IP アドレスとポートの組み合わせが必要です（0.0.0.0 アドレスを含む）。同じ IP アドレスとポートで、特定の VPC ネットワーク内に複数の転送ルールを作成すると、最初の転送ルールだけが有効になります。他の要素は無視されます。

トラフィックの損失を防ぐために、以下の高度なトラフィックインターセプトの構成セクションの説明に従ってください。

高度なトラフィックインターセプトの構成

VM で Cloud Service Mesh によって構成されたサービスにアクセスする必要があるアプリケーションを実行する場合、サイドカープロキシをインストールして VM にトラフィックインターセプトを構成し、サイドカープロキシがそれらのサービスのバックエンドへのトラフィックルーティングを管理できるようにする必要があります。

デプロイの要件によりすべての送信 VM トラフィックをインターセプトできない場合は、残りのトラフィックがホストのネットワーク構成で定義された通常のルートに従う状態のまま、特定のトラフィックをサイドカープロキシにリダイレクトできます。

これを行うには、VM を使用した Cloud Service Mesh の設定と Envoy の手動デプロイの手順で Compute Engine VM ホストの設定を次のように変更します。

Cloud Service Mesh で制御されるサービスで解決する IP アドレスの範囲を決定します。これらの IP アドレス宛てのトラフィックはインターセプトされ、サイドカープロキシにリダイレクトされます。範囲はデプロイに固有のものです。
sidecar.env ファイルで、SERVICE_CIDR の値をこの範囲に設定します。これらの IP アドレスへのトラフィックは、netfilter によってサイドカープロキシにリダイレクトされ、Cloud Service Mesh が指定した構成に従って負荷分散されます。
サイドカープロキシは、トラフィックインターセプトから除外されている専用ユーザーとして厳格に実行する必要はありません。ただし、そのような運用については引き続き推奨します。
メインの手順で run.sh スクリプトを実行すると、この特定の範囲のインターセプトとリダイレクトのみが iptables に構成されます。
次のコマンドを実行して、netfilter が正しく構成されていることを確認します。${SERVICE_CIDR} は、インターセプトする IP アドレス範囲として構成した値に置き換えます。
```
sudo iptables -L -t nat | grep -E "(ISTIO_REDIRECT).+${SERVICE_CIDR})"
```