自動 Envoy デプロイを使用した Compute Engine VM 設定のオプション
このガイドでは、自動化された Envoy のデプロイの追加オプションと必要なタスクについて説明します。
追加のインスタンス テンプレート作成オプション
Envoy プロキシの自動デプロイ用のインスタンス テンプレートを作成する場合、次のパラメータを使用して、デプロイの側面とプロキシの動作を定義できます。
| パラメータ | 値と説明 | 必須または省略可 |
|---|---|---|
--service-proxy |
enabledサービス プロキシとエージェントを VM にインストールして構成するかどうかを制御します。 |
サービス プロキシを自動的にデプロイして構成する場合は必須です。この設定を省略すると、サービス プロキシはインストールまたは構成されません。 |
--service-proxy:serving-ports |
セミコロンで区切ったポートのリスト。 アプリケーションまたはワークロードがサービスを提供するポート。サービス プロキシは、受信トラフィックをインターセプトして、localhost の指定ポートに転送します。 |
省略可 このフラグを省略すると、サービス プロキシはワークロードからの送信トラフィックのみを処理します。受信トラフィックは、サービス プロキシによって処理されません。 |
--service-proxy:proxy-port |
単一のポート。 サービス プロキシがリッスンするポート。VM によってインターセプトされたトラフィックは、このポートにリダイレクトされ、サービス プロキシによって処理されます。 |
省略可。 このフラグを省略すると、値はデフォルトで 15001 になります。 |
--service-proxy:network |
有効な VPC ネットワークの名前。 サービス プロキシのコントロール プレーンがサービス プロキシの動的構成を生成するために使用する Google Cloud VPC ネットワーク。 |
VM が複数のネットワーク上にある場合は必須。それ以外の場合は省略可能です。 このフラグを省略すると、VM インスタンス テンプレートの作成時に --network パラメータを使用して指定した値が使用されます。 |
--service-proxy:tracing |
ON または OFF サービス プロキシが分散トレース情報を生成できるようにします。 ON に設定すると、サービス プロキシのコントロール プレーンは、リクエストの ID ベースのトレースを有効にする構成を生成します。詳細については、Envoy プロキシの generate_request_id ドキュメントをご覧ください。 |
省略可。 このフラグを省略すると、トレースは無効になります。 |
--service-proxy:access-log |
コントロール プレーンからサービス プロキシに送信されるアクセスログのファイルパス。このファイルには、すべての受信リクエストと送信リクエストが記録されます。 詳細については、Envoy プロキシのファイル アクセスログのドキュメントをご覧ください。 |
省略可。デフォルト値はありません。ファイルパスを指定しないと、ログは作成されません。 |
--service-proxy:intercept-all-outbound-traffic（プレビュー） |
サービス プロキシによるすべての送信トラフィックのインターセプトを有効にしてから、外部ホストにリダイレクトできます。このオプションでは gcloud beta を使用します。 |
省略可。 |
--service-proxy:exclude-outbound-ip-ranges（プレビュー） |
セミコロン（;）で区切られた IP アドレスまたは CIDR 範囲のリスト。リダイレクトの除外対象を引用符で囲んで指定します。intercept-all-outbound-traffic フラグが設定されている場合にのみ適用されます。このオプションでは gcloud beta を使用します。例: exclude-outbound-ip-ranges="8.8.8.8;129.168.10.0/24" |
省略可。 |
--service-proxy:exclude-outbound-port-ranges（プレビュー） |
セミコロン（;）で区切られたポートまたはポート範囲のリスト。リダイレクトの除外対象を引用符（"）で囲んで指定します。intercept-all-outbound-traffic フラグが設定されている場合にのみ適用されます。このオプションでは gcloud beta を使用します。例: exclude-outbound-port-ranges="81;8080-8090" |
省略可。 |
--service-proxy:scope（プレビュー） |
scope オプションは、Gateway リソースの論理構成境界を定義します。VM が起動すると、サービス プロキシは Cloud Service Mesh と通信し、このスコープ名を持つゲートウェイのルートに対応するルーティング情報を取得します。scope を指定した場合、ネットワークの値は無視されます。scope と mesh の値を同時に指定することはできません。このオプションでは gcloud beta を使用します。 |
省略可。 |
--service-proxy:mesh（プレビュー） |
mesh オプションは、Mesh リソースの論理構成境界を定義します。VM が起動すると、サービス プロキシは Cloud Service Mesh と通信し、このメッシュ名を使用して Mesh のルートに対応するルーティング情報を取得します。mesh を指定した場合、ネットワークの値は無視されます。scope と mesh の値を同時に指定することはできません。このオプションでは gcloud beta を使用します。 |
省略可。 |
--service-proxy:project-number（プレビュー） |
project-number オプションは、Mesh リソースと Gateway リソースが作成されるプロジェクトを指定します。指定しない場合、インスタンスが存在しているプロジェクトが使用されます。これは、新しいサービス ルーティング API にのみ適用されます。 |
省略可。 |
--service-proxy-labels |
key=value 形式の Key-Value ペア。サービス プロキシに適用できるラベル。これらは Envoy プロキシのブートストラップ メタデータに反映されます。ラベルには、プロキシ メタデータとして設定する任意の key=value ペアを指定できます（たとえば、構成フィルタリングで使用します）。これらのフラグは、app=review や version=canary など、アプリケーションとバージョンのラベルに使用します。併用も可能です。 |
省略可。 |
たとえば、次の gcloud コマンドは、proxy-it という名前のインスタンス テンプレートを作成します。このテンプレートから作成されたインスタンスには、Envoy プロキシとサービス プロキシ エージェントがインストールされています。
gcloud compute instance-templates create proxy-it \
--service-proxy enabled
次の例では、インスタンス テンプレートは proxy-it と呼ばれ、Envoy プロキシとサービス プロキシ エージェントがインストールされ、サービスポートとプロキシポートが設定され、トレースが有効になり、ラベルが定義されます。
gcloud compute instance-templates create proxy-it \ --service-proxy enabled,serving-ports=8080,proxy-port=15001,tracing=ON \ --service-proxy-labels version=canary
次の図は、サービスポートを 8080 として指定した場合のトラフィック フローを示しています。ポート 8080 への受信 TCP 接続は、iptables によってインターセプトされ、Envoy プロキシにリダイレクトされ、その後 TCP ポート 8080 でリッスンする VM 上のアプリケーションに渡されます。さらに:
- Cloud Service Mesh で構成されたサービスの VIP へのすべてのアウトバウンド接続は、iptables によってインターセプトされます。これにより、netfilter が構成されます。netfilter により、ネットワーク スタックを通過する対応のトラフィックがインターセプトされ、Envoy プロキシにリダイレクトされます。トラフィックは、Cloud Service Mesh の構成方法に基づいてロード バランシングされます。
- 他のすべてのインバウンド接続は、iptables によってインターセプトされず、VM 上のサービスに直接渡されます。
- 外部エンドポイントへのすべての接続は、インターセプトされずに外部 IP アドレスに直接渡されます。
- すべての UDP トラフィックは iptables によってインターセプトされることなく直接宛先に渡されます。
これを次の図に示します。
この図のトラフィック フローは次のようになります。
- 宛先ポートが
80の受信トラフィック。インターセプトされず、ポートでリッスンしているサービスに直接ルーティングされます。 - 宛先ポートが
8080の受信トラフィック。インターセプトされ、Envoy リスナーポートにリダイレクトされます。 - Envoy は（2）から localhost ポート
8080でリッスンするサービス 2 にトラフィックを転送します。 - Cloud Service Mesh 転送ルールの VIP とポートを宛先とする送信トラフィック。インターセプトされ、Envoy リスナーポートにリダイレクトされます。
- Envoy は、（4）から宛先である Cloud Service Mesh バックエンド サービスのバックエンドのエンドポイントにトラフィックを転送します。
- Cloud Service Mesh 以外の VIP とポートを宛先とする送信トラフィック。インターセプトされず、外部サービスに直接ルーティングされます。
ラベルの使用
Cloud Service Mesh メタデータ フィルタリングで使用するラベルを指定する場合、または Envoy プロキシのアクセス ロギングを有効にする場合は、--service-proxy-labels パラメータまたは --service-proxy access-log パラメータを使用します。
次に例を示します。
gcloud compute instance-templates create td-vm-template-auto \ --service-proxy enabled,access-log=/var/log/envoy/access.log,network=default \ --service-proxy-labels myapp=review,version=canary
Envoy プロキシは、VM 上のサービスのヘルスチェック ポートをインターセプトできます。これにより、アプリケーションと Envoy プロキシでヘルスチェック プローブが報告されます。Envoy プロキシが正しく実行されていないと、トラフィックが VM に転送されません。次に例を示します。
gcloud compute instance-templates create td-vm-template-auto \ --service-proxy=enabled,serving-ports="80;8080"
マネージド インスタンス グループの更新プロセスの使用
Envoy プロキシの構成に自動プロセスを使用した場合、マネージド インスタンス グループの更新プロセスを使用してマネージド インスタンス グループを更新できます。このプロセスは次の目的で使用します。
- サービス プロキシ コンポーネントを既存のマネージド インスタンス グループに追加し、Cloud Service Mesh ネットワークに登録する。
- VM のサービス プロキシ コンポーネントを更新する。
ローリング アップデートを実行する前に、次の作業を行います。
- バックエンド サービスのコネクション ドレインを 30 秒以上の値に設定します。
- アップデータを呼び出すときは、
--min-readyパラメータを 3 分以上の値に設定します。--min-readyパラメータを使用すると、VM が更新されてから次の VM の更新に進むまで、マネージド インスタンス グループが待機状態になります。これを行わないと、新しく作成された VM は Envoy とサービス プロキシ エージェントを完全に起動する時間がなく、更新の進行が早すぎることになります。
マネージド インスタンス グループでローリング アップデートを実行するには、次の手順に従います。
- 上記のように、サービス プロキシ情報を含む新しいインスタンス テンプレートを作成します。サービス プロキシ情報が含まれていて、プロキシ ソフトウェアを最新の安定したバージョンに更新する場合は、元のバージョンのインスタンス テンプレートを使用できます。
- マネージド インスタンス グループのローリング アップデートを実行します。
REPLACEは、Updater で実行する必要がある最小アクションとして設定していることを確認します。このインスタンス グループは、プロキシ ソフトウェアの最新バージョンをインストールし、インスタンス テンプレートで指定されたとおりに構成しています。
更新プロセスを使用して、マネージド インスタンス グループからサービス プロキシ コンポーネントを削除することもできます。
--service-proxyフラグを指定せずに、新しいインスタンス テンプレートを作成します。マネージド インスタンス グループの更新プロセスを使用して、ローリング アップデートを実行します。
これにより、VM から Envoy プロキシが削除されます。このマネージド インスタンス グループ以外にバックエンド サービスに接続している MIG がない場合、Cloud Service Mesh の設定時に作成した Cloud Service Mesh の構成を削除することもできます。