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

ネットワーク エンドポイント グループ(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 コントローラでレイヤ 7 ロードバランサの作成が容易になります。たとえば、仮想 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

次のステップ