インターネット ネットワーク エンドポイント グループを使用した Cloud Service Mesh
Cloud Service Mesh は、INTERNET_FQDN_PORT タイプのインターネット ネットワーク エンドポイント グループ（NEG）を使用するように構成できます。外部サービスは、NEG 内の完全修飾ドメイン名（FQDN）とポート番号で表されます。NEG に含めることができる FQDN:Port ペアは 1 つだけです。バックエンド サービスには、このタイプの NEG を 1 つだけ含めることができます。FQDN は、基盤となる Virtual Private Cloud（VPC）ネットワークの名前解決順序で解決されます。
FQDN バックエンドを使用して Cloud Service Mesh サービス メッシュを拡張する
Cloud Service Mesh サービス メッシュでは、名前付きのオンプレミス サービス、マルチクラウド サービス、インターネット サービスなど、ハイブリッド接続を使用して到達可能なプライベート サービスにトラフィックをルーティングできます。リモート サービスは FQDN で参照されます。
公共のインターネット経由で到達可能なサービスにトラフィックをルーティングすることもできます。
Google Cloud のリソースとアーキテクチャ
このセクションでは、インターネット NEG を使用して Cloud Service Mesh を構成するためのリソースとアーキテクチャについて説明します。
INTERNET_FQDN_PORT ネットワーク エンドポイント グループ
FQDN で参照される外部サービスにトラフィックをルーティングするには、INTERNET_FQDN_PORT タイプのグローバル インターネット NEG を使用します。NEG には、サービスの FQDN とポート番号が含まれます。Cloud Service Mesh は、xDS 構成を使用して FQDN を Envoy プロキシにプログラムします。
Cloud Service Mesh 自体がリモート エンドポイントの名前解決と到達性を保証するものではありません。FQDN は、Envoy プロキシが接続している VPC ネットワークの名前解決順序で解決する必要があります。また、解決されたエンドポイントは Envoy プロキシから到達可能である必要があります。
ヘルスチェック
INTERNET_FQDN_PORT タイプのネットワーク エンドポイントのヘルスチェックは、Cloud Load Balancing と Cloud Service Mesh で使用される他のタイプのネットワーク エンドポイントのヘルスチェックと動作が異なります。他のネットワーク エンドポイント タイプでは Google Cloud の一元化されたヘルスチェック システムを使用していますが、マルチクラウド環境（INTERNET_FQDN_PORT と NON_GCP_PRIVATE_IP_PORT）のエンドポイントに使用される NEG は Envoy の分散ヘルスチェックを使用します。
Envoy は、ヘルスチェック用に次のプロトコルをサポートしています。
- HTTP
- HTTPS
- HTTP/2
- TCP
Compute Engine API を使用してヘルスチェックを構成します。
DNS に関する考慮事項
DNS については、次の 2 つの点を考慮してください。
- 外部サービスのリソース レコードをホストする DNS サーバー。
- 接続管理に DNS を使用するように Envoy プロキシを構成するモード。
Cloud DNS サーバー
Cloud DNS の限定公開マネージド ゾーンを作成すると、Google Cloud プロジェクトで DNS レコードをホストできます。転送ゾーンなど、Cloud DNS の他の機能を使用して、オンプレミスの DNS サーバーからレコードを取得することもできます。
Envoy DNS モード
Envoy DNS モードはサービス ディスカバリとも呼ばれ、Envoy プロキシが送信接続の管理に DNS レコードを使用する方法を指定します。Cloud Service Mesh は、厳格な DNS モードを使用するように Envoy を構成します。Strict DNS モードでは、解決されたすべてのエンドポイントに対して負荷分散が行われます。ヘルスチェックのステータスに従って、正常でないエンドポイントや DNS で解決されなくなったエンドポイントに対しては接続のドレインを行います。このモードは変更できません。
サービス ディスカバリの詳細については、Envoy のドキュメントをご覧ください。
接続性とルーティング
トラフィックをプライベート サービスにルーティングする場合、基盤となるネットワーク接続は次の要件を満たしている必要があります。
- オンプレミスのデータセンターまたはサードパーティのパブリック クラウドと VPC ネットワーク間のハイブリッド接続は、Cloud VPN または Cloud Interconnect で確立されている。
- Envoy からプライベート サービス エンドポイント（必要であれば、オンプレミス DNS サーバー）への双方向のネットワーク到達性が確立されように、VPC ファイアウォール ルールとルートが正しく構成されている。
- リージョンの高可用性フェイルオーバーを成功させるには、グローバル動的ルーティングが有効になっていること。詳細については、動的ルーティング モードをご覧ください。
インターネットから到達可能な外部サービスにルーティングする場合は、次の要件を満たす必要があります。
- VPC ネットワーク内のクライアント仮想マシン（VM）インスタンスに、外部 IP アドレスまたは Cloud NAT が設定されていること。
- インターネットへの下り（外向き）トラフィックに、デフォルト ルートが存在すること。
上述のどちらの場合も、トラフィックは VPC ネットワークのルーティングを使用します。
セキュリティ
FQDN バックエンドは、Cloud Service Mesh のセキュリティ機能および API と互換性があります。外部サービスへの送信接続では、クライアント TLS ポリシーを使用して SNI ヘッダーに FQDN を構成できます。
制限事項と考慮事項
INTERNET_IP_PORTタイプのインターネット NEG は、Cloud Service Mesh ではサポートされていません。- FQDN バックエンドには Envoy バージョン 1.15.0 以降が必要です。
- Google Cloud CLI または REST API を使用して、Cloud Service Mesh を構成します。Google Cloud コンソールを使用したエンドツーエンドの構成はサポートされていません。
- FQDN バックエンドは Envoy でのみサポートされています。プロキシレス gRPC はサポートされていません。
INTERNET_FQDN_PORTタイプの NEG を Cloud Service Mesh で使用すると、リモート エンドポイントのヘルスチェックは Envoy の分散ヘルスチェック メカニズムを使用して行われます。新しいリモート エンドポイントが追加されるたびに、すべての Envoy プロキシが個別にヘルスチェックを開始します。同様に、新しい Envoy プロキシをメッシュに追加すると、すべてのリモート エンドポイントのチェックを開始します。このため、デプロイメント内の Envoy プロキシとリモート エンドポイントの数によっては、ヘルスチェック メッシュによって大量のネットワーク トラフィックが発生し、リモート エンドポイントの負荷が過剰になる可能性があります。ヘルスチェックを構成しないことも可能です。
FQDN バックエンドのヘルスチェック ステータスは Google Cloud コンソールに表示されません。
UDP、SSL、gRPC プロトコルを使用したヘルスチェックはサポートされていません。
次のヘルスチェック オプションはサポートされていません。
- HTTP / HTTP2 / HTTPS ヘルスチェック
--proxy-header--response
- TCP ヘルスチェック
--proxy-header--request--response
- HTTP / HTTP2 / HTTPS ヘルスチェック
次のステップ
- インターネット NEG を使用して Cloud Service Mesh を設定するには、外部バックエンドの設定をご覧ください。
- ハイブリッド接続 NEG については、ハイブリッド接続 NEG を使用した Cloud Service Mesh をご覧ください。