Google Cloud 内部プロキシ ネットワーク ロードバランサは、オープンソースの Envoy プロキシ ソフトウェアと Andromeda ネットワークの仮想化スタックを活用したプロキシベースのロードバランサです。
内部プロキシ ネットワーク ロードバランサはレイヤ 4 ロードバランサで、同じ VPC ネットワーク内のクライアントまたは VPC ネットワークに接続されているクライアントのみがアクセスできるリージョン内部 IP アドレスの背後で TCP サービス トラフィックを実行し、スケーリングできます。ロードバランサは、まず Envoy プロキシでクライアントとロードバランサ間の TCP 接続を終端します。プロキシは、Google Cloud、オンプレミス、またはその他のクラウド環境でホストされているバックエンドへの 2 番目の TCP 接続を開きます。その他のユースケースについては、プロキシ ネットワーク ロードバランサの概要をご覧ください。
運用モード
内部プロキシ ネットワーク ロードバランサは、次のモードで構成できます。
リージョン内部プロキシ ネットワーク ロードバランサこれは、オープンソースの Envoy プロキシをベースにマネージド サービスとして実装されるリージョン ロードバランサです。リージョン モードでは、すべてのクライアントとバックエンドが指定されたリージョンに配置されるため、リージョンのコンプライアンスが必要な場合に役立ちます。
クロスリージョン内部プロキシ ネットワーク ロードバランサこれは、オープンソースの Envoy プロキシでマネージド サービスとして実装されるマルチリージョン ロードバランサです。クロスリージョン モードを使用すると、グローバルに分散しているバックエンド サービスにトラフィックをロードバランスできます。たとえば、最も近いバックエンドにトラフィックを転送するトラフィック管理ができます。このロードバランサは高可用性も実現します。バックエンドを複数のリージョンに配置すると、単一リージョンにおける障害を回避できます。1 つのリージョンのバックエンドが停止した場合でも、トラフィックを別のリージョンにフェイルオーバーできます。
次の表に、リージョン モードとクロスリージョン モードの重要な違いを示します。
機能 リージョン内部プロキシ ネットワーク ロードバランサ クロスリージョン内部プロキシ ネットワーク ロードバランサ ロードバランサの仮想 IP アドレス（VIP） 特定の Google Cloud リージョンのサブネットから割り振られます。 特定の Google Cloud リージョンのサブネットから割り振られます。 複数のリージョンの VIP アドレスは、同じグローバル バックエンド サービスを共有できます。
クライアント アクセス デフォルトでは、グローバルにアクセス可能ではありません。
必要に応じて、グローバル アクセスを有効にすることができます。常にグローバルにアクセス可能任意の Google Cloud リージョンのクライアントがロードバランサにトラフィックを送信できます。 ロードバランスされたバックエンド リージョン バックエンド。
ロードバランサは、ロードバランサのプロキシと同じリージョンにあるバックエンドにのみトラフィックを送信できます。グローバル バックエンド。
ロードバランサは、任意のリージョンのバックエンドにトラフィックを送信できます。High availability and failover 同じリージョン内の正常なバックエンドへの自動フェイルオーバー。 同一または異なるリージョンの正常なバックエンドへの自動フェイルオーバー。
モードを特定する
Cloud コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
[ロードバランサ] タブに、ロードバランサのタイプ、プロトコル、リージョンが表示されます。リージョンが空の場合、ロードバランサはクロスリージョン モードになっています。次の表に、ロードバランサのモードを識別する方法を示します。
ロードバランサ モード ロードバランサの種類 アクセスタイプ リージョン リージョン内部プロキシ ネットワーク ロードバランサ ネットワーク（プロキシ） 内部 リージョンの指定 クロスリージョン内部プロキシ ネットワーク ロードバランサ ネットワーク（プロキシ） 内部
gcloud
ロードバランサのモードを確認するには、次のコマンドを実行します。
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
コマンド出力で、負荷分散スキーム、リージョン、ネットワーク ティアを確認します。次の表に、ロードバランサのモードを識別する方法を示します。
ロードバランサ モード ロード バランシング スキーム 転送ルール リージョン内部プロキシ ネットワーク ロードバランサ INTERNAL_MANAGED リージョン クロスリージョン内部プロキシ ネットワーク ロードバランサ INTERNAL_MANAGED グローバル
アーキテクチャ
次の図は、内部プロキシ ネットワーク ロードバランサに必要な Google Cloud リソースを示しています。
リージョン
この図は、プレミアム ティアにリージョン内部プロキシ ネットワーク ロードバランサをデプロイした場合のコンポーネントを示しています。
クロスリージョン
次の図は、同じ VPC ネットワーク内のプレミアム ティアにクロスリージョン内部プロキシ ネットワーク ロードバランサをデプロイした場合のコンポーネントを示しています。各グローバル転送ルールは、クライアントの接続に使用するリージョン IP アドレスを使用します。
プロキシ専用サブネット
前の図では、プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。Envoy ベースの内部プロキシ ネットワーク ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを作成する必要があります。
次の表に、内部プロキシ ネットワーク ロードバランサのプロキシ専用サブネットの要件を示します。
| ロードバランサ モード | プロキシ専用サブネットの --purpose フラグの値 |
|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ |
リージョン ロードバランサとクロスリージョン ロードバランサで同じサブネットを共有することはできません リージョンと VPC ネットワーク内のすべてのリージョン Envoy ベースのロードバランサは、同じプロキシ専用サブネットを共有します。 |
| クロスリージョン内部プロキシ ネットワーク ロードバランサ |
リージョン ロードバランサとクロスリージョン ロードバランサで同じサブネットを共有することはできません ロードバランサが構成される各リージョンで、クロスリージョンの Envoy ベースのロードバランサにはプロキシ専用サブネットが必要です。同じリージョンとネットワークにあるクロスリージョン ロードバランサ プロキシは、同じプロキシ専用サブネットを共有します。 |
さらに、
- プロキシ専用サブネットは Envoy プロキシにのみ使用され、バックエンドには使用されません。
- リージョンと VPC ネットワーク内のすべての内部プロキシ ネットワーク ロードバランサのバックエンド仮想マシン（VM）インスタンスまたはエンドポイントは、プロキシ専用サブネットからの接続を受信します。
- 内部プロキシ ネットワーク ロードバランサの IP アドレスは、プロキシ専用サブネットにはありません。ロードバランサの IP アドレスは内部マネージド転送ルールによって定義されます。
転送ルールと IP アドレス
転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシとバックエンド サービスからなるロード バランシング構成にトラフィックをルーティングします。
IP アドレスの指定。各転送ルールは、アプリケーションの DNS レコードで使用できる単一のリージョン IP アドレスを参照します。使用できる静的 IP アドレスを予約するか、Cloud Load Balancing から割り当てます。推奨されているのは静的 IP アドレスの予約です。静的アドレスを予約しない場合、転送ルールを削除して新しく作り直すたびに DNS レコードを編集して、新しく割り当てられたエフェメラル IP アドレスに直す必要があるからです。
クライアントは IP アドレスとポートを使用してロードバランサの Envoy プロキシに接続します。転送ルールの IP アドレスはロードバランサの IP アドレスです（仮想 IP アドレスまたは VIP と呼ぶこともあります）。ロードバランサに接続するクライアントは TCP を使用する必要があります。サポートされているプロトコルの一覧については、ロードバランサの機能の比較をご覧ください。
転送ルールに関連付けられた内部 IP アドレスは、バックエンドと同じネットワークとリージョンにあるサブネットから取得できます。
ポートの指定。内部プロキシ ネットワーク ロードバランサで使用する各転送ルールは、1～65535 の単一ポートを参照できます。複数のポートをサポートするには、複数の転送ルールを構成する必要があります。
次の表に、内部プロキシ ネットワーク ロードバランサの転送ルールの要件を示します。
| ロードバランサ モード | 転送ルール、IP アドレス、プロキシ専用サブネット --purpose |
クライアントからロードバランサのフロントエンドへのルーティング |
|---|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ |
ロード バランシング スキーム
プロキシ専用サブネット
IP アドレス
|
グローバル アクセスを有効にして、任意のリージョンのクライアントがロードバランサにアクセスできるようにします。 バックエンドもロードバランサと同じリージョンに存在する必要があります。 |
| クロスリージョン内部プロキシ ネットワーク ロードバランサ |
ロード バランシング スキーム
プロキシ専用サブネット
IP アドレス
|
グローバル アクセスはデフォルトで有効になっており、任意のリージョンのクライアントがロードバランサにアクセスできます。バックエンドは複数のリージョンに配置できます。 |
転送ルールと VPC ネットワーク
このセクションでは、外部アプリケーション ロードバランサで使用される転送ルールを VPC ネットワークに関連付ける方法について説明します。
| ロードバランサ モード | VPC ネットワークの関連付け |
|---|---|
| クロスリージョン内部プロキシ ネットワーク ロードバランサ リージョン内部プロキシ ネットワーク ロードバランサ |
リージョン内部 IPv4 アドレスは常に VPC ネットワーク内に存在します。転送ルールを作成するときに、内部 IP アドレスを取得するサブネットを指定する必要があります。このサブネットは、プロキシ専用サブネットが作成されたリージョンと VPC ネットワークに存在する必要があります。このため、暗黙的なネットワークの関連付けが存在します。 |
ターゲット プロキシ
内部プロキシ ネットワーク ロードバランサは、クライアントからの TCP 接続を終端してバックエンドへの新しい接続を作成します。デフォルトでは、元のクライアントの IP アドレスとポート情報は保持されません。PROXY プロトコルを使用してこの情報を保持できます。ターゲット プロキシは、受信リクエストを直接ロードバランサのバックエンド サービスにルーティングします。
次の表に、内部プロキシ ネットワーク ロードバランサに必要なターゲット プロキシ API を示します。
| ロードバランサ モード | ターゲット プロキシ |
|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ | リージョン regionTargetTcpProxies |
| クロスリージョン内部プロキシ ネットワーク ロードバランサ | グローバルtargetTcpProxies |
バックエンド サービス
バックエンド サービスによって、受信トラフィックが 1 つ以上の関連バックエンドに振り向けられます。バックエンドは、インスタンス グループまたはネットワーク エンドポイント グループのいずれかになります。バックエンドには、接続に基づいて完全性を定義するためのバランシング モード情報が含まれています（たとえば、グループ バックエンドのみの場合は使用率）。
各内部プロキシ ネットワーク ロードバランサには、単一のバックエンド サービス リソースが含まれます。
次の表に、内部プロキシ ネットワーク ロードバランサのバックエンド サービスの要件を示します。
| ロードバランサ モード | バックエンド サービスのタイプ |
|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ | リージョン regionBackendServices |
| クロスリージョン内部プロキシ ネットワーク ロードバランサ | グローバルbackendServices |
サポートされているバックエンド
バックエンド サービスは、次のタイプのバックエンドをサポートします。
| ロードバランサ モード | バックエンド サービスでサポートされるバックエンド | ||||||
|---|---|---|---|---|---|---|---|
| インスタンス グループ | ゾーン NEG | インターネット NEG | サーバーレス NEG | ハイブリッド NEG | Private Service Connect NEG | GKE | |
| リージョン内部プロキシ ネットワーク ロードバランサ |
GCE_VM_IP_PORT タイプのエンドポイント |
リージョン NEG のみ | Private Service Connect NEG を追加する | ||||
| クロスリージョン内部プロキシ ネットワーク ロードバランサ |
GCE_VM_IP_PORT タイプのエンドポイント |
Private Service Connect NEG を追加する | |||||
すべてのバックエンドは同じ種類（インスタンス グループまたは NEG）である必要があります。異なるタイプのインスタンス グループ バックエンドを同時に使用することも、異なるタイプの NEG バックエンドを同時に使用することもできますが、同じバックエンド サービスでインスタンス グループと NEG バックエンドを併用することはできません。
同じバックエンド サービス内でゾーン NEG とハイブリッド NEG を混在させることができます。
ユーザーへの中断を最小限に抑えるために、バックエンド サービスのコネクション ドレインを有効にできます。このような中断は、バックエンドの停止、手動による削除、オートスケーラーによる削除によって発生することがあります。コネクション ドレインを使用してサービスの中断を最小限に抑える方法については、コネクション ドレインの有効化のドキュメントをご覧ください。
バックエンドと VPC ネットワーク
インスタンス グループ、ゾーン NEG、ハイブリッド接続 NEG の場合、すべてのバックエンドはバックエンド サービスと同じプロジェクトとリージョンに配置する必要があります。ただし、ロードバランサは、バックエンド サービスと同じプロジェクトで別の VPC ネットワークを使用するバックエンドを参照できます（この機能はプレビュー版です）。 ロードバランサの VPC ネットワークとバックエンド VPC ネットワーク間の接続は、VPC ネットワーク ピアリング、Cloud VPN トンネル、Cloud Interconnect VLAN アタッチメント、または Network Connectivity Center フレームワークを使用して構成できます。
バックエンド ネットワークの定義
- ゾーン NEG とハイブリッド NEG の場合、NEG の作成時に VPC ネットワークを明示的に指定します。
- マネージド インスタンス グループの場合、VPC ネットワークはインスタンス テンプレートで定義されます。
- 非マネージド インスタンス グループの場合、インスタンス グループの VPC ネットワークは、インスタンス グループに追加された最初の VM の
nic0インターフェースの VPC ネットワークと一致するように設定されます。
バックエンド ネットワークの要件
バックエンド ネットワークは、次のいずれかのネットワーク要件を満たしている必要があります。
バックエンドの VPC ネットワークは、転送ルールの VPC ネットワークと完全に一致する必要があります。
バックエンドの VPC ネットワークは、VPC ネットワーク ピアリングを使用して転送ルールの VPC ネットワークに接続する必要があります。転送ルールの VPC ネットワークのプロキシ専用サブネットと、バックエンド インスタンスまたはエンドポイントで使用されるサブネットとの通信を許可するには、サブネット ルート交換を構成する必要があります。
- バックエンドの VPC ネットワークと転送ルールの VPC ネットワークは、同じ Network Connectivity Center ハブの VPC スポークである必要があります。インポート フィルタとエクスポート フィルタでは、転送ルールの VPC ネットワークのプロキシ専用サブネットと、バックエンド インスタンスまたはエンドポイントで使用されるサブネットとの通信を許可する必要があります。
他のすべてのバックエンド タイプの場合、すべてのバックエンドを同じ VPC ネットワークとリージョンに配置する必要があります。
バックエンドとネットワーク インターフェース
インスタンス グループのバックエンドを使用する場合、パケットは常に nic0 に配信されます。別の NIC にパケットを送信する場合は、NEG バックエンドを使用します。
ゾーン NEG バックエンドを使用する場合、パケットは NEG のエンドポイントで表されるネットワーク インターフェースに送信されます。NEG エンドポイントは、NEG に明示的に定義された VPC ネットワークと同じ VPC ネットワークに存在する必要があります。
バックエンドと通信するためのプロトコル
内部プロキシ ネットワーク ロードバランサのバックエンド サービスを構成するときに、バックエンド サービスがバックエンドとの通信に使用するプロトコルを設定します。ロードバランサは、指定したプロトコルのみを使用し、他のプロトコルとの接続をネゴシエートしません。内部プロキシ ネットワーク ロードバランサは、バックエンドとの通信用に TCP のみをサポートしています。
ヘルスチェック
各バックエンド サービスは、ロードバランサからの接続を受信するバックエンドの稼働状況を定期的に監視するヘルスチェックを指定します。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。ヘルスチェックでは、アプリケーション自体が動作するかどうかはチェックされません。
ヘルスチェック プロトコル
必須ではなく、常に可能というわけでもありませんが、バックエンド サービスのプロトコルに一致するプロトコルでヘルスチェックを使用することをおすすめします。たとえば、TCP ヘルスチェックはバックエンドへの TCP 接続を最も正確にテストします。サポートされているヘルスチェック プロトコルの一覧については、ロード バランシング機能をご覧ください。
次の表に、各モードの内部プロキシ ネットワーク ロードバランサでサポートされているヘルスチェックのスコープを示します。
| ロードバランサ モード | ヘルスチェックのタイプ |
|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ | リージョン regionHealthChecks |
| クロスリージョン内部プロキシ ネットワーク ロードバランサ | グローバル healthChecks |
ヘルスチェックの詳細については、以下をご覧ください。
ファイアウォール ルール
内部プロキシ ネットワーク ロードバランサには、次のファイアウォール ルールが必要です。
- Google ヘルスチェック プローブからのトラフィックを許可する上り（内向き）許可ルール。
35.191.0.0/16130.211.0.0/22
2600:2d00:1:b029::/64
- プロキシ専用サブネットからのトラフィックを許可するための上り（内向き）許可ルール
これらのファイアウォール ルールのポートは、次のように構成する必要があります。
各バックエンド サービスのヘルスチェックのための宛先ポートへのトラフィックを許可する。
インスタンス グループのバックエンドの場合: バックエンド サービスの名前付きポートと、各インスタンス グループの名前付きポートに関連付けられたポート番号とのマッピングによって、構成するポートを決定します。同じバックエンド サービスに割り当てられたインスタンス グループ間でポート番号が異なる可能性があります。
GCE_VM_IP_PORTNEG バックエンドの場合: エンドポイントのポート番号へのトラフィックを許可します。
これらのロードバランサのファイアウォール ルール要件には、いくつかの例外があります。
- ハイブリッド NEG では、Google のヘルスチェック プローブ範囲を許可リストに登録する必要はありません。ただし、1 つのバックエンド サービスでハイブリッド NEG とゾーン NEG の組み合わせを使用している場合は、ゾーン NEG の Google ヘルスチェック プローブ範囲を許可リストに登録する必要があります。
- リージョン インターネット NEG の場合、ヘルスチェックは省略可能です。リージョン インターネット NEG を使用するロードバランサからのトラフィックは、プロキシ専用サブネットから発信され、Cloud NAT を使用して手動で、または自動的に割り振られた NAT IP アドレスに NAT 変換されます。このトラフィックには、ヘルスチェック プローブと、ロードバランサからバックエンドへのユーザー リクエストの両方が含まれます。詳細については、リージョン NEG: 下り（外向き）に Cloud NAT を使用するをご覧ください。
クライアント アクセス
クライアントは、同じネットワークまたは、VPC ネットワーク ピアリングを使用して接続された VPC ネットワークに配置できます。
リージョン内部プロキシ ネットワーク ロードバランサの場合、クライアントは、デフォルトでロードバランサと同じリージョンに存在しなければなりません。グローバル アクセスを有効にして、任意のリージョンのクライアントがロードバランサにアクセスできるようにします。
クロスリージョン内部プロキシ ネットワーク ロードバランサの場合、グローバル アクセスはデフォルトで有効になっています。任意のリージョンのクライアントがロードバランサにアクセスできます。
次の表は、リージョン内部プロキシ ネットワーク ロードバランサのクライアント アクセスをまとめたものです。
| グローバル アクセスが無効な場合 | グローバル アクセスが有効な場合 |
|---|---|
| クライアントはロードバランサと同じリージョンになければなりません。また、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。 | クライアントはどのリージョンにでも配置できます。ただし、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。 |
| オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを介してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、ロードバランサと同じリージョンになければなりません。 | オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを使用してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、どのリージョンにでも配置できます。 |
共有 VPC アーキテクチャ
内部プロキシ ネットワーク ロードバランサは、共有 VPC を使用するネットワークをサポートしています。共有 VPC を使用すると、ネットワーク管理者とサービス デベロッパーの責任を明確に分離できます。開発チームはサービス プロジェクトでのサービスの構築に集中し、ネットワーク インフラストラクチャ チームはロード バランシングのプロビジョニングと管理を行うことができます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要のドキュメントをご覧ください。
| IP アドレス | 転送ルール | ターゲット プロキシ | バックエンド コンポーネント |
|---|---|---|---|
内部 IP アドレスは、バックエンドと同じプロジェクトで定義する必要があります。 共有 VPC ネットワークでロードバランサを使用できるようにするには、内部 IP アドレスは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要があります。さらに、ホスト プロジェクト内の目的の共有 VPC ネットワーク内のサブネットを参照する必要があります。アドレス自体は、参照先サブネットのプライマリ IP 範囲から取得します。 |
内部転送ルールは、バックエンドと同じプロジェクトで定義する必要があります。 共有 VPC ネットワークでロードバランサを使用できるようにするには、内部転送ルールは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要があります。さらに、関連付けられている内部 IP アドレスが参照する同じサブネット（共有 VPC ネットワーク内）を参照する必要があります。 |
ターゲット プロキシは、バックエンドと同じプロジェクトで定義する必要があります。 | 共有 VPC のシナリオでは、バックエンド VM は通常、サービス プロジェクトに配置されます。そのサービス プロジェクトでは、リージョン内部のバックエンド サービスとヘルスチェックを定義する必要があります。 |
トラフィック分散
内部プロキシ ネットワーク ロードバランサは、次のようにバックエンドにトラフィックを分散します。
- 1 つのクライアントから発信された接続は、そのゾーン内の正常なバックエンド（インスタンス グループまたは NEG）が使用可能であり、容量があれば（バランシング モードによって判別されます）、同じゾーンに送信されます。リージョン内部プロキシ ネットワーク ロードバランサの場合、バランシング モードは
CONNECTION（インスタンス グループまたは NEG バックエンド）またはUTILIZATION（インスタンス グループ バックエンドのみ）になります。 - セッション アフィニティを構成している場合は、クライアントからの接続は同じバックエンドに送信されます。
- バックエンドが選択されると、ロード バランシング ポリシーに従ってインスタンス（インスタンス グループ）またはエンドポイント（NEG）間でトラフィックが分散されます。サポートされているロード バランシング ポリシー アルゴリズムについては、リージョン バックエンド サービス API ドキュメントの
localityLbPolicy設定をご覧ください。
セッション アフィニティ
セッション アフィニティでは、バックエンドが良好な状態で容量があれば、同じクライアントからのすべてのリクエストを同じバックエンドに送信するように、ロードバランサのバックエンド サービスを構成できます。
内部ネットワーク ロードバランサはクライアント IP アフィニティを提供します。これにより、バックエンドに容量があり、正常な状態を維持している限り、同じクライアント IP アドレスからのすべてのリクエストが同じバックエンドに転送されます。
フェイルオーバー
バックエンドが異常な状態になると、トラフィックは正常なバックエンドに自動的にリダイレクトされます。
次の表に、内部プロキシ ネットワーク ロードバランサのフェイルオーバー動作を示します。
| ロードバランサ モード | フェイルオーバーの動作 | すべてのバックエンドが異常な場合の動作 |
|---|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ | ロードバランサは、ゾーンごとに緩やかなフェイルオーバー アルゴリズムを実装します。ロードバランサは、ゾーン内のすべてのバックエンドが異常になるのを待つのではなく、いずれかのゾーンで正常なバックエンドと異常なバックエンドの比率が一定のしきい値（70%、このしきい値は構成不可）より低くなったときに、別のゾーンへのトラフィックのリダイレクトを開始します。すべてのゾーンのすべてのバックエンドが異常な状態である場合、ロードバランサは直ちにクライアント接続を終端します。 Envoy プロキシは、構成されたトラフィック分散に基づいて、リージョン内の正常なバックエンドにトラフィックを送信します。 |
接続を終端する |
| クロスリージョン内部プロキシ ネットワーク ロードバランサ | 同じリージョンまたは他のリージョン内の正常なバックエンドへの自動フェイルオーバー。 トラフィックは、構成されたトラフィック分散に基づいて、複数のリージョンにまたがる正常なバックエンド間で分散されます。 |
接続を終端する |
GKE アプリケーションのロード バランシング
Google Kubernetes Engine でアプリケーションを構築する場合は、スタンドアロン ゾーン NEG を使用してトラフィックを直接コンテナにロード バランシングできます。スタンドアロン NEG では、ゾーン NEG を作成する Service オブジェクトを作成し、NEG をバックエンド サービスに関連付けます。これにより、ロードバランサが Pod に接続できるようになります。
関連する GKE のドキュメント:
割り当てと上限
割り当てと上限について詳しくは、ロード バランシングのリソースの割り当てをご覧ください。
制限事項
- 内部プロキシ ネットワーク ロードバランサは、IPv6 トラフィックをサポートしていません。
- 内部プロキシ ネットワーク ロードバランサは、ロードバランサのフロントエンドが 1 つのホストまたはサービス プロジェクトにあるため、バックエンド サービスとバックエンドが別のサービス プロジェクトにある共有 VPC デプロイ（クロス プロジェクト サービス参照とも呼ばれます）をサポートしていません。