ゾーン ネットワーク エンドポイント グループの概要

ネットワーク エンドポイント グループ(NEG)は、バックエンド エンドポイントまたはサービスのグループを指定する構成オブジェクトです。ゾーン NEG は、1 つのサブネット内の Google Cloud リソースの IP アドレスまたは IP アドレス / ポートの組み合わせのコレクションに相当するゾーンのリソースです。

NEG は、VM 全体ではなく、ソフトウェア サービスを表す IP アドレスとポートの論理グループを作成できる点でも有益です。Apache MesosCloud Foundry などのその他のオーケストレーターによって管理されるマイクロサービス(Google Cloud VM で実行)の IP アドレスをエンドポイントにできます。

その他の NEG タイプの詳細については、以下をご覧ください。

ゾーン NEG には、NEG を構成するネットワーク エンドポイントのタイプに応じて 2 つのタイプがあります。2 種類のゾーン NEG はそれぞれ、異なるユースケースとロードバランサ タイプをサポートしています。

ネットワーク負荷分散では、ゾーン NEG をバックエンドとして使用することはできません。

GCE_VM_IP NEG

これらのゾーン NEG には、Compute Engine VM のプライマリ IP アドレスに解決される 1 つ以上の内部ネットワーク エンドポイントが含まれています。このタイプのゾーン NEG ではポートを指定できません

これらのエンドポイントは、内部 TCP / UDP ロードバランサのバックエンド サービスのバックエンドとしてのみ使用できます。

GCE_VM_IP NEG を使用して接続できるのは、NEG の VPC ネットワーク内の VM のプライマリ内部 IP アドレスに属するエンドポイントのみです。NEG が NIC と同じ VPC ネットワークを使用している限り、マルチ NIC VM の NIC のプライマリ内部 IP アドレスを NEG に追加できます。

GCE_VM_IP_PORT NEG

これらのゾーン NEG には、VM のプライマリ内部 IP アドレスまたはエイリアス IP 範囲の IP アドレスに解決される 1 つ以上の内部ネットワーク エンドポイントが含まれます。たとえば、GKE はこのタイプの NEG を使用します。エンドポイントは、ノードのエイリアス IP 範囲の IP アドレスとポート(Pod IP アドレスとコンテナポート)で構成されます。各ネットワーク エンドポイントは、IP アドレスとポートの組み合わせを使用して指定されます。

これらの NEG は、外部 HTTP(S)、内部 HTTP(S) 負荷分散、TCP プロキシ、SSL プロキシのロードバランサのバックエンド サービスのバックエンドとして使用できます。内部 TCP / UDP ロードバランサまたはネットワーク ロードバランサでは GCE_VM_IP_PORT エンドポイントを使用できません。ゾーン NEG バックエンドでは IP アドレスとポートを指定できるため、VM インスタンス内で実行中のアプリケーションやコンテナ間で細かくトラフィックを分散できます。

VM 内で実行するコンテナまたはアプリケーションに独自の GCE_VM_IP_PORT ネットワーク エンドポイントを作成するには、エイリアス IP アドレス機能を使用して、VM のプライマリ IP アドレスまたは VM に割り振られたセカンダリ IP アドレスを使用する必要があります。VM で実行中のコンテナまたはアプリケーションで実行されているソフトウェアは、ネットワーク エンドポイントで使用される IP アドレスにバインドするように構成する必要があります。

GCE_VM_IP_PORT NEG は特に GKE で活用できます。GKE でゾーン NEG を使用する方法については、コンテナ ネイティブの負荷分散を使用するをご覧ください。

エンドポイントの関係

NEG を作成するときは、ゾーン、ネットワーク、サブネットを選択します。すべてのエンドポイント IP アドレスは、ゾーン NEG と同じサブネット内に存在する必要があります。

選択したネットワークが自動モードのネットワークである場合は、サブネットの指定を省略できます。ただし、サブネットのゾーン NEG への関連付けはそのまま保持されます。ゾーン NEG を作成する際に自動モードのネットワークを指定して、サブネットを指定しない場合、使用されるサブネットは、ゾーン NEG に選択したゾーンを含むリージョンに自動的に作成されます。

作成するゾーン NEG のタイプは、NEG の作成時に指定されます(GCE_VM_IP または GCE_VM_IP_PORT)。これにより、NEG がサポートするエンドポイントのタイプが決まります。

GCE_VM_IPGCE_VM_IP_PORT ゾーン NEG の場合:

  • 各 VM エンドポイントの名前を指定する必要があります。

  • 各エンドポイント VM は NEG と同じゾーンに配置する必要があります。

  • NEG 内のエンドポイントはすべて、一意の IP アドレスとポートの組み合わせが必要です。一意のエンドポイント IP アドレスとポートの組み合わせは、複数の NEG から参照できます。

  • 各エンドポイント VM は、NEG と同じ VPC ネットワーク内にネットワーク インターフェース(NIC)を持つ必要があります。エンドポイント IP アドレスは NEG と同じサブネットに関連付ける必要があります。

  • 各 NEG は、NEG あたりのエンドポイントの最大数までサポートします。エンドポイントは、多数の一意の VM 間で分散させることも、1 つの VM に配置することもできます。

GCE_VM_IP_PORT NEG では、エンドポイントを追加する際に IP アドレスとポート、IP アドレスのみ、またはいずれも指定しないように選択できます。

  • IP アドレスとポートを指定する場合は、IP アドレスには VM NIC のプライマリ内部 IP アドレスまたは NIC のエイリアス IP のいずれかになります。ポートは自由に選択できます。

  • IP アドレスだけを指定すると、VM NIC のプライマリ内部 IP アドレスまたは NIC のエイリアス IP のどちらかになります。使用されるポートは、NEG のデフォルト ポートです。

  • 両方を省略すると、Google Cloud は NIC のプライマリ内部 IP アドレスを選択し、NEG のデフォルト ポートを使用します。

ゾーン NEG による負荷分散

ゾーン NEG は、ロードバランサのバックエンド サービスのバックエンドとして使用できます。ゾーン NEG をバックエンド サービスのバックエンドとして使用する場合、そのバックエンド サービス内の他のバックエンドはすべて同じタイプのゾーン NEG(すべての GCE_VM_IP または GCE_VM_IP_PORT のいずれか)である必要があります。インスタンス グループとゾーン NEG を同じバックエンド サービスのバックエンドとして使用することはできません。

同じネットワーク エンドポイントを複数のゾーン NEG に追加できます。複数のバックエンド サービスのバックエンドとして、同じゾーン NEG を使用できます。

GCE_VM_IP_PORT ゾーン NEG は、バックエンド サービスのプロトコルに応じて、RATE 分散モードまたは CONNECTION 分散モードのいずれかになります。サポートされているロードバランサでは、ターゲット容量を定義する必要があります。

GCE_VM_IP ゾーン NEG では CONNECTION 分散モードを使用する必要があり、内部 TCP / UDP ロードバランサはターゲット容量の設定をサポートしていないため、ターゲット容量を定義できません。

ゾーン NEG バックエンドには、分散モード UTILIZATION を使用できません

内部 TCP / UDP 負荷分散

GCE_VM_IP エンドポイントを持つゾーン NEG は、内部 TCP / UDP ロードバランサでのみバックエンド サービスのバックエンドとして使用できます。

GCE_VM_IP エンドポイントを使用する NEG の主なユースケースは次のとおりです。

内部 TCP / UDP ロードバランサの VM 管理の簡素化

インスタンス グループと同様に、同じ NEG を複数の内部 TCP / UDP ロードバランサのバックエンドとして使用できます。インスタンス グループとは異なり、VM エンドポイントは複数の NEG のメンバーになり、それぞれの NEG を 1 つ以上の内部 TCP / UDP ロードバランサのバックエンドとして使用できます。

「GCE_VM_IP」ゾーン NEG が重複している内部 TCP / UDP ロードバランサ
ゾーン NEG が重複している内部 TCP / UDP ロードバランサ

GKE のサブセット化

GKE は、GCP_VM_IP ゾーン NEG とサブセット化を使用して、次のように内部 TCP / UDP ロードバランサのスケーラビリティを改善します。

サブセット化しない場合、GKE はゾーンごとに、そのゾーンに含まれるすべてのノードプールからのクラスタのノードで構成される 1 つの非マネージド インスタンス グループを作成します。これらのゾーン インスタンス グループは、1 つ以上の内部 LoadBalancer Service(および NEG 自体を使用しない外部 Ingress)のバックエンドとして使用されます。

サブセット化した場合、GKE は内部 LoadBalancer Service ごとに GCE_VM_IP ゾーン NEG を作成します。同じエンドポイントを複数のゾーン NEG のメンバーにすることもできます。インスタンス グループとは異なり、Google Cloud は同じエンドポイントを含む複数のゾーン NEG に負荷分散できます。

サブセット化すると、250 を超えるノードを持つクラスタの内部 LoadBalancer Service に効率的にトラフィックを分散できます。たとえば、300 ノードの GKE クラスタには、NEG に 25 のノードを持つ内部 LoadBalancer Service がある場合があります。その Service にサービスを提供する Pod が 25 あるからです。この Service のインスタンス グループのバックエンドに 300 ノードすべてを追加する必要はありません。

NEG、転送ルール、バックエンド サービス、その他の Google Cloud ネットワーク リソースの割り当ては引き続き適用されます。

HTTP(S)、内部 HTTP(S)、TCP プロキシ、SSL プロキシの負荷分散

GCE_VM_IP_PORT エンドポイントを使用したゾーン NEG は、外部 HTTP(S)、内部 HTTP(S)、TCP プロキシ、SSL プロキシの負荷分散のバックエンド サービスのバックエンドとして使用できます。

GCE_VM_IP_PORT NEG ゾーン NEG の主なユースケースは、コンテナネイティブの負荷分散です。これにより、VM で実行されているコンテナ(GKE クラスタの Pod IP アドレスなど)にトラフィックを直接分散できます。

次の例は、VM のコンテナ内で実行されるマイクロサービス間で、ロードバランサがトラフィックを分散する方法を示しています。VM は、サブネットのエイリアス IP 範囲を使用するように構成され、コンテナによって使用されるアドレスです。

コンテナを使用したゾーン ネットワーク エンドポイント グループの負荷分散(クリックして拡大)
コンテナを使用したゾーン ネットワーク エンドポイント グループの負荷分散(クリックして拡大)

次の図は、ゾーン NEG がバックエンドである場合の、HTTP(S) ロードバランサ、TCP / SSL プロキシ ロードバランサ、内部 HTTP(S) ロードバランサの構成要素を示しています。

  • 各プレミアム ティア HTTP(S)、SSL プロキシ、および TCP プロキシのロードバランサには、適切なターゲット プロキシ オブジェクトにトラフィックを転送する独自のグローバル外部転送ルールがあります。

  • 各スタンダード ティア HTTP(S)、SSL プロキシ、および TCP プロキシのロードバランサには、適切なターゲット プロキシ オブジェクトにトラフィックを転送する独自のリージョン外部転送ルールがあります。

  • 各内部 HTTP(S) ロードバランサには、適切なターゲット プロキシ オブジェクトにトラフィックを転送する独自のリージョンの内部マネージド転送ルールがあります。

  • ターゲット HTTP(S) プロキシの場合、使用されるバックエンド サービスは、URL マップでリクエストのホスト名とパスを確認して決定されます。外部 HTTP(S) ロードバランサと内部 HTTP(S) ロードバランサには、URL マップから参照される複数のバックエンド サービスを設定できます。

  • ターゲット TCP またはターゲット SSL プロキシには、バックエンド サービスを 1 つのみ定義できます。

  • バックエンド サービスによってバックエンド ゾーン NEG にトラフィックが転送されます。リクエストごとに、ロードバランサはゾーン NEG の 1 つからネットワーク エンドポイントを選択し、トラフィックを送信します。

負荷分散のゾーン ネットワーク エンドポイント グループ(クリックして拡大)
負荷分散のゾーン ネットワーク エンドポイント グループ(クリックして拡大)

ユースケース: コンテナネイティブの負荷分散

コンテナネイティブの負荷分散により、ロードバランサは Pod を直接ターゲットにして、VM レベルではなく Pod レベルで負荷分散の決定を行うことができます。コンテナ ネイティブの負荷分散を構成するには、GKE Ingress が管理する NEG を使用する方法と、スタンドアロン NEG を使用する方法があります。

Kubernetes Ingress と NEG(推奨)

NEG を Ingress と一緒に使用すると、Ingress コントローラで L7 ロードバランサの作成が容易になります。たとえば、仮想 IP アドレス、転送ルール、ヘルスチェック、ファイアウォール ルールなどを簡単に作成できます。構成方法については、Ingress によるコンテナ ネイティブの負荷分散をご覧ください。

Ingress は、NEG の管理を簡素化する多くの機能を備えているため、コンテナ ネイティブの負荷分散を使用する場合におすすめします。Ingress によって管理される NEG がユースケースに対応していない場合は、スタンドアロン NEG を使用できます。

Ingress を使用してロードバランサを設定する方法については、Ingress によるコンテナ ネイティブの負荷分散をご覧ください。

スタンドアロン NEG

GKE Ingress 以外でプロビジョニングされたロードバランサを使用してデプロイされた NEG は、スタンドアロン NEG とみなされます。スタンドアロン ゾーン NEG は NEG コントローラを介してデプロイ、管理されますが、転送ルール、ヘルスチェック、その他の負荷分散コンポーネントは手動でデプロイします。

GKE でスタンドアロン ゾーン NEG を使用する例については、以下をご覧ください。

制限事項

  • ゾーン NEG はレガシー ネットワークでは使用できません。
  • NEG をバックエンドとして使用するバックエンド サービスの場合は、バックエンドとしてインスタンス グループを使用できません。

GCE_VM_IP ゾーン NEG の制限事項:

  • GCE_VM_IP エンドポイントを持つゾーン NEG は、内部 TCP / UDP ロードバランサでのみサポートされます。
  • default-port プロパティGCE_VM_IP ゾーン NEG ではサポートされていません。
  • Cloud Console を使用して GCE_VM_IP NEG を作成または管理することはできません。gcloud または REST API を使用してください。

割り当て

  • プロジェクトごとの NEG、バックエンド サービスごとの NEG、NEG ごとのエンドポイントなどの NEG 割り当てについては、負荷分散の割り当てページをご覧ください。

トラブルシューティング

トラフィックがエンドポイントに到達しない

サービスが構成されると、通常、新しいエンドポイントはゾーン NEG に接続後にヘルスチェックに応答できれば到達可能になります。

トラフィックがエンドポイントに到達できず、HTTP(S) で 502 エラーコードが生成されるか、TCP / SSL ロードバランサで接続が拒否される場合は、次の点を確認してください。

  • ファイアウォール ルールで、エンドポイントへの TCP トラフィックの受信を、130.211.0.0/2235.191.0.0/16 の範囲で許可します。
  • エンドポイントが正常であることを確認するには、以下のように gcloud を使用するか、showHealth パラメータ セットを SHOW に設定してバックエンド サービス リソースの getHealth API またはゾーン NEG の listEndpoints API を呼び出します。次の gcloud コマンドによって、ネットワーク エンドポイント別に正常性の情報が表示されます。
gcloud compute network-endpoint-groups list-network-endpoints NAME \
    --zone=ZONE

次のステップ