LoadBalancer Service について

このページでは、Kubernetes LoadBalancer Service マニフェストを適用するときに、Google Kubernetes Engine（GKE）で Cloud de Confiance by S3NS ロードバランサを作成、管理する方法の一般的な概要を説明します。LoadBalancer のタイプ、構成パラメータについて説明し、ベスト プラクティスの推奨事項を示します。

このページを読む前に、GKE ネットワーキングのコンセプトを理解しておく必要があります。

概要

LoadBalancer Service を作成すると、GKE により、その特性が Service マニフェストのパラメータに依存する Cloud de Confiance パススルー ロードバランサが構成されます。

LoadBalancer Service をカスタマイズする

使用する LoadBalancer Service の構成を選択する場合は、次の点を考慮してください。

LoadBalancer Service ディシジョン ツリー。
図: LoadBalancer Service ディシジョン ツリー

ロードバランサのタイプ - 内部または外部

GKE で LoadBalancer Service を作成するときに、ロードバランサに内部アドレスと外部アドレスのどちらを割り振るかを指定します。

  • 外部 LoadBalancer Service は、外部パススルー ネットワーク ロードバランサを使用して実装されます。VPC ネットワークの外部にあるクライアントと、インターネットにアクセスできる Cloud de ConfianceVM は、外部 LoadBalancer Service にアクセスできます。

    外部 LoadBalancer Service を作成するには、次のいずれかの方法を使用します。

    • GKE 1.33.1-gke.1779000 以降を実行しているクラスタでは、マニフェストをクラスタに送信する前に、Service マニフェストに spec.loadBalancerClass: "networking.gke.io/l4-regional-external" を追加します。このフィールドを使用することをおすすめします。このフィールドを使用すると、GCE_VM_IP NEG バックエンドを使用して、常にバックエンド サービスベースの外部パススルー ネットワーク ロードバランサが作成されるためです。spec.loadBalancerClass フィールドは不変であり、Service の作成後に変更することはできません。

    • サポートされている GKE バージョンを実行しているクラスタでは、マニフェストをクラスタに送信する前に、Service マニフェストに cloud.google.com/l4-rbs: "enabled" アノテーションを追加できます。このアノテーションは、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサも作成します。マニフェストが GKE 1.32.2-gke.1652000 以降を実行しているクラスタに送信された場合、ロードバランサは GCE_VM_IP NEG バックエンドを使用します。それ以外の場合、ロードバランサはインスタンス グループ バックエンドを使用します。GKE は、Service マニフェストがクラスタに最初に適用されたときにのみ、このアノテーションを評価します。

  • 内部 LoadBalancer Service は、内部パススルー ネットワーク ロードバランサを使用して実装されます。同じ VPC ネットワークまたはクラスタの VPC ネットワークに接続されたネットワークにあるクライアントは、内部 LoadBalancer Service にアクセスできます。

    効果的な手法として、内部 LoadBalancer Service を作成する前に、GKE のサブセット化が有効になっていることを確認してください。クラスタで GKE 1.36 以降が実行されている場合、GKE サブセット化は自動的に有効になります。以前の GKE バージョンでは、GKE サブセット化を明示的に有効にする必要があります。

    内部 LoadBalancer Service を作成するには、次のいずれかの方法を使用します。

    • GKE 1.33.1-gke.1779000 以降を実行し、GKE サブセットが有効になっているクラスタでは、マニフェストをクラスタに送信する前に、Service マニフェストに spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" を追加します。このフィールドを使用することをおすすめします。このフィールドは、常に GCE_VM_IP NEG バックエンドを使用して内部パススルー ネットワーク ロードバランサを作成するためです。spec.loadBalancerClass フィールドは不変であり、Service の作成後に変更することはできません。

    • サポートされている GKE バージョンを実行しているクラスタでは、マニフェストをクラスタに送信する前に、networking.gke.io/load-balancer-type: "Internal" アノテーションを Service マニフェストに追加できます。これにより、内部パススルー ネットワーク ロードバランサも作成されます。GKE サブセット化が有効になっているクラスタにマニフェストが送信された場合、ロードバランサは GCE_VM_IP NEG バックエンドを使用します。それ以外の場合、ロードバランサはインスタンス グループのバックエンドを使用します。

spec.loadBalancerClass がなく、cloud.google.com/l4-rbs: "enabled" または networking.gke.io/load-balancer-type: "Internal" アノテーションがない LoadBalancer Service マニフェストは、ターゲット プールベースの外部パススルー ネットワーク ロードバランサを作成します。ターゲット プールベースの外部パススルー ネットワーク ロードバランサの使用はおすすめしません。

HttpLoadBalancing の前提条件

バックエンド サービスベースの外部パススルー ネットワーク ロードバランサまたは内部パススルー ネットワーク ロードバランサを利用する LoadBalancer Service を作成するには、クラスタで 1.36 より前の GKE バージョンが実行されている場合は、HttpLoadBalancing アドオンが有効になっていることを確認します。HttpLoadBalancing アドオンはデフォルトで有効になっています。

GKE バージョン 1.36 以降の LoadBalancer Service は、HttpLoadBalancing アドオンに依存しません。

externalTrafficPolicy の効果

externalTrafficPolicy パラメータは以下を制御します。

  • ロードバランサからパケットを受信するノード
  • ロードバランサがパケットをノードに配信した後、クラスタ内のノード間でパケットがルーティングされるかどうか
  • 元のクライアント IP アドレスが保持されるか失われるか

externalTrafficPolicy は Local または Cluster のいずれかになります。

  • externalTrafficPolicy: Local を使用することで、準備完了状態でサービスを提供している Pod が少なくとも 1 つあるノードにのみパケットが配信され、元のクライアントの送信元 IP アドレスが保持されるようにします。このオプションは、クラスタ内のノードの総数が変動しても、サービスを提供している Pod があるノードの数が比較的一定であるワークロードに最適です。このオプションは、重み付きロード バランシングのサポートには必須です。
  • クラスタ内のノードの総数は比較的一定であるが、サービスを提供している Pod があるノードの数が変動するという場合は、externalTrafficPolicy: Cluster を使用します。このオプションでは、元のクライアントの送信元 IP アドレスは保持されません。また、パケットがロードバランサからノードに配信された後、別のノード上のサービスを提供している Pod にルーティングされる場合があるため、レイテンシが増加する可能性があります。このオプションは重み付きロード バランシングに対応していません。

externalTrafficPolicy がノード内のパケット ルーティングにどのように影響するかの詳細については、パケット処理をご覧ください。

重み付きロード バランシング

外部 LoadBalancer Service は重み付きロード バランシングに対応しています。これにより、サービス提供中の Pod、準備完了 Pod、終了していない Pod が多いノードは、Pod が少ないノードと比較して、新しい接続の割合を増やすことができます。重み付きロード バランシングによってロードバランサの構成がどのように変化するかについては、重み付きロード バランシングの効果をご覧ください。

重み付きロード バランシングによるトラフィック分散。
図: 重み付きロード バランシングのトラフィック分散

図に示すように、重み付けロード バランシングが有効になっている Service は、各ノードの準備完了 Pod の数に比例して新しい接続を分散します。

重み付きロード バランシングを使用するには、次のすべての要件を満たす必要があります。

  • GKE クラスタはバージョン 1.31.0-gke.1506000 以降を使用する必要があります。

  • バックエンド サービスベースの外部パススルー ネットワーク ロードバランサを作成する外部 LoadBalancer Service を作成する必要があります。次のいずれかの方法を使用できます。

    • GKE 1.33.1-gke.1779000 以降を実行するクラスタでは、マニフェストをクラスタに送信する前に、spec.loadBalancerClass: "networking.gke.io/l4-regional-external" を Service マニフェストに追加します。こちらをおすすめします。

    • サポートされている GKE バージョンを実行しているクラスタでは、マニフェストをクラスタに送信する前に、cloud.google.com/l4-rbs: "enabled" アノテーションを Service マニフェストに追加します。

  • 重み付きロード バランシング機能を有効にするには、Service マニフェストに networking.gke.io/weighted-load-balancing: pods-per-node アノテーションを含める必要があります。

  • LoadBalancer Service マニフェストでは externalTrafficPolicy: Local を使用する必要があります。GKE で externalTrafficPolicy: Cluster を使用できないわけではありませんが、externalTrafficPolicy: Cluster を使用すると、ロードバランサの後にパケットが別のノードに転送される可能性があるため、重み付きロード バランシングが実質的に無効になります。

重み付きロード バランシングを使用するには、重み付きロード バランシングを有効にするをご覧ください。

ゾーン アフィニティ

内部 LoadBalancer Service はゾーン アフィニティ（プレビュー版）に対応しています。これにより、クライアントと同じゾーン内のサービス提供中の Pod を持つノードに新しい接続を転送できます。ゾーンに正常な Pod がない場合、GKE はトラフィックを別のゾーンに転送します。トラフィックをゾーン内に維持することで、ゾーン間のトラフィックを最小限に抑え、コストを削減してレイテンシを短縮できます。GKE クラスタでゾーン アフィニティを有効にするには、GKE サブセット化が有効になっている必要があります。

ゾーン アフィニティによるロードバランサ構成の変更（トラフィックをゾーン内に維持できる場合など）の詳細については、ゾーン アフィニティの効果をご覧ください。ゾーン アフィニティと externalTrafficPolicy がノード VM のパケット ルーティングにどのように影響するかについては、ノードでの送信元ネットワーク アドレス変換とルーティングをご覧ください。

内部 LoadBalancer Service の特別な考慮事項

このセクションでは、内部 LoadBalancer Service に固有の GKE のサブセット化機能と、GKE のサブセット化が externalTrafficPolicy との相互作用によってロードバランスされたノードの最大数に影響する仕組みについて説明します。

GKE のサブセット化

バージョン 1.36 以降を実行する GKE クラスタでは、内部 LoadBalancer Service の GKE サブセット化がデフォルトで有効になっています。これらのバージョンでは、クラスタ構成または Terraform などの Infrastructure as Code（IaC）ツールでクラスタレベルの --enable-l4-ilb-subsetting フラグが false に設定されていても、GKE サブセット化は有効なままです。

このクラスタ全体の構成オプションは、ノード エンドポイントを GCE_VM_IP ネットワーク エンドポイント グループ（NEG）に効率的にグループ化することで、内部パススルー ネットワーク ロードバランサのスケーラビリティを向上させます。NEG はロードバランサのバックエンドとして使用されます。

次の図は、3 つのノードがあるゾーンクラスタ内の 2 つの Service を示しています。クラスタで GKE のサブセット化が有効になっています。各サービスには 2 つの Pod があります。GKE は、Service ごとに 1 つの GCE_VM_IP NEG を作成します。各 NEG 内のエンドポイントは、それぞれの Service に対してサービスを提供している Pod があるノードです。

ゾーンクラスタ上の 2 つの Service の GKE サブセット化。

1.36 より前のバージョンを実行しているクラスタでは、クラスタの作成時または既存のクラスタの更新時に、GKE のサブセット化を手動で有効にできます。GKE のサブセット化を有効にした後、無効にすることはできません。

GKE のサブセット化には、以下が必要です。

  • GKE バージョン 1.18.19-gke.1400 以降、および
  • クラスタのバージョンが 1.36 より前の場合は、HttpLoadBalancing アドオンを有効にする必要があります。このアドオンはデフォルトで有効になっています。これにより、クラスタは、バックエンド サービスを使用するロードバランサを管理できます。クラスタがバージョン 1.36 以降の場合、HttpLoadBalancing アドオンは GKE サブセット化の前提条件ではありません。

ノード数

GKE のサブセット化が無効になっているクラスタでは、（すべてのノードプール間で）合計 250 を超えるノードが含まれている場合、内部 LoadBalancer Service で問題が発生する可能性があります。これは、GKE によって作成された内部パススルー ネットワーク ロードバランサが、250 個以下のバックエンド ノード VM にしかパケットを分散できないためです。この制限には次の 2 つの理由があります。

  • GKE はロードバランサ バックエンドのサブセット化を使用しないため。
  • ロードバランサ バックエンドのサブセット化が無効になっている場合、内部パススルー ネットワーク ロードバランサではパケットの分散先が 250 個以下のバックエンドに制限されるため。

GKE のサブセット化を使用するクラスタは、ノード数が合計 250 を超えるクラスタの内部 LoadBalancer Service に対応しています。

GKE サブセット化でサポートされるノードの数は、内部 LoadBalancer Service の externalTrafficPolicy フィールドの値によって異なります。

  • externalTrafficPolicy: Local: 特定の Service でサービスを提供する Pod を持つノードを最大 250 個サポートします。

  • externalTrafficPolicy: Cluster: サービスを提供する Pod を持つノードの数に上限はありません。この動作は、GKE が Service ごとに GCE_VM_IP NEG で最大 25 個のノード エンドポイントを構成するためです。詳細については、GCE_VM_IP NEG バックエンドのノード メンバーシップをご覧ください。

トラフィック分散

デフォルトでは、内部 LoadBalancer Service と外部 LoadBalancer Service は、セッション アフィニティが NONE に設定されたパススルー ネットワーク ロードバランサを作成します。パススルー ネットワーク ロードバランサは、セッション アフィニティ、ヘルス情報、場合によっては重みなどの詳細を使用して、新しい接続に適格なノード バックエンドを特定して選択します。

新しい接続により、接続トラッキング テーブルのエントリが作成されます。このエントリは、この接続の後続のパケットを以前に選択された適格なノード バックエンドにすばやく転送するために使用されます。パススルー ネットワーク ロードバランサが適格なバックエンドを特定して選択し、接続トラッキングを使用する方法については、以下をご覧ください。

重み付きロード バランシングの効果

外部 LoadBalancer Service に重み付きロード バランシングを構成すると、GKE は対応する外部パススルー ネットワーク ロードバランサで重み付きロード バランシングを有効にします。GKE は、ロードバランサのヘルスチェックへの応答にレスポンス ヘッダーを含めるように kube-proxy ソフトウェアまたは cilium-agent ソフトウェアを構成します。このレスポンス ヘッダーは、各ノード上のサービス提供中の Pod、準備完了 Pod、終了していない Pod の数に比例する重みを定義します。

ロードバランサは、次のように重み情報を使用します。

  • ロードバランサの適格なノード バックエンドのセットは、重みがゼロ以外の正常なすべてのノードで構成されます。

  • ロードバランサは、適格なノード バックエンドのいずれかを選択するときに重みを考慮します。Service が externalTrafficPolicy: Local を使用している場合（重み付きロード バランシングを有効にするために必要）、サービス提供中の Pod、準備完了 Pod、終了していない Pod が多い適格なノード バックエンドは、Pod が少ない適格なノード バックエンドよりも選択される可能性が高くなります。

ゾーン アフィニティの効果

内部 LoadBalancer Service のゾーン アフィニティを構成すると、GKE により ZONAL_AFFINITY_SPILL_CROSS_ZONE オプションとゼロのスピルオーバー比率で対応する内部パススルー ネットワーク ロードバランサが構成されます。

このゾーン アフィニティ構成では、次の条件がすべて満たされる場合、ロードバランサにより適格なノード バックエンドの元のセットが、クライアントと同じゾーンにある適格なノード バックエンドのみに絞り込まれます。

  • クライアントがゾーン アフィニティと互換性がある。

  • クライアントのゾーンに、適格で正常なノード バックエンドが少なくとも 1 つ存在する。

それ以外の場合、ロードバランサではゾーン アフィニティの最適化が適用されずに、適格なノード バックエンドの元のセットが引き続き使用されます。

ゾーン アフィニティ構成がロードバランサの動作に与える影響の詳細については、ゾーン アフィニティのドキュメントをご覧ください。

ノードのグループ化

GKE のバージョン、Service マニフェストのアノテーション、内部 LoadBalancer Service の場合は GKE のサブセット化オプションによって、生成される Cloud de Confiance ロードバランサとバックエンドのタイプが決まります。

次の表に、さまざまな LoadBalancer Service 構成のノード グループ化方法の概要を示します。

サービスとクラスタの詳細 生成される Cloud de Confiance ロードバランサ ノードをグループ化する方法
内部 LoadBalancer Service
GKE サブセット化が有効になっているクラスタの GKE バージョン 1.33.1-gke.1779000 以降。1spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" を使用してクラスタに送信された Service マニフェスト。 バックエンド サービスが GCE_VM_IP ネットワーク エンドポイント グループ（NEG）バックエンドを使用する内部パススルー ネットワーク ロードバランサ

ノード VM は、Service の externalTrafficPolicy とクラスタ内のノードの数に基づいて、サービスごとに GCE_VM_IP ゾーン NEG にグループ化されます。

Service の externalTrafficPolicy は、ロードバランサのヘルスチェックに合格するノードとパケット処理も制御します。
GKE サブセット化が有効になっているクラスタ内のサポートされているすべての GKE バージョン。1networking.gke.io/load-balancer-type: "Internal" アノテーションを使用してクラスタに送信された Service マニフェスト。
GKE のサブセット化が無効になっているクラスタの 1.36 より前の GKE バージョン。1networking.gke.io/load-balancer-type: "Internal" アノテーションを使用してクラスタに送信された Service マニフェスト。 バックエンド サービスがゾーンの 非マネージド インスタンス グループ のバックエンドを使用する内部パススルー ネットワーク ロードバランサ

すべてのノード VM は、GKE が内部パススルー ネットワーク ロードバランサのバックエンド サービスのバックエンドとして使用する、ゾーンの非マネージド インスタンス グループに配置されます。

Service の externalTrafficPolicy は、ロードバランサのヘルスチェックに合格するノードとパケット処理を制御します。

ロード バランシング インスタンス グループの制限により、同じ非マネージド インスタンス グループがクラスタ内で作成された他のロードバランサのバックエンド サービスに使用されます。
外部 LoadBalancer Service
GKE バージョン 1.33.1-gke.1779000 以降。spec.loadBalancerClass: "networking.gke.io/l4-regional-external" を使用してクラスタに送信された Service マニフェスト。 GCE_VM_IP ネットワーク エンドポイント グループ（NEG）バックエンドを使用するバックエンド サービスベースの外部パススルー ネットワーク ロードバランサ

ノード VM は、Service の externalTrafficPolicy とクラスタ内のノードの数に基づいて、サービスごとに GCE_VM_IP ゾーン NEG にグループ化されます。

Service の externalTrafficPolicy は、ロードバランサのヘルスチェックに合格するノードとパケット処理も制御します。
GKE バージョン 1.32.2-gke.1652000 以降。cloud.google.com/l4-rbs: "enabled" アノテーション2 を使用してクラスタに送信された Service マニフェスト。
GKE バージョン 1.32.2-gke.16520003 より前。cloud.google.com/l4-rbs: "enabled" アノテーション2 を使用してクラスタに送信された Service マニフェスト。 ゾーンの 非マネージド インスタンス グループ バックエンドを使用するバックエンド サービスベースの外部パススルー ネットワーク ロードバランサ

すべてのノード VM は、GKE が外部パススルー ネットワーク ロードバランサのバックエンド サービスのバックエンドとして使用する、ゾーンの非マネージド インスタンス グループに配置されます。

Service の externalTrafficPolicy は、ロードバランサのヘルスチェックに合格するノードとパケット処理を制御します。

ロード バランシング インスタンス グループの制限により、同じ非マネージド インスタンス グループがクラスタ内で作成された他のロードバランサのバックエンド サービスに使用されます。
サポートされているすべての GKE バージョン。次のすべてを含まない Service マニフェストがクラスタに送信されました。
  • spec.loadBalancerClass
  • networking.gke.io/load-balancer-type アノテーション
  • cloud.google.com/l4-rbs アノテーション
 ターゲット プールにクラスタのすべてのノードが含まれるターゲット プールベースの外部パススルー ネットワーク ロードバランサ

ターゲット プールは、NEG やインスタンス グループに依存しないレガシー API です。すべてのノードがターゲット プール内で直接メンバーシップを持ちます。

Service の externalTrafficPolicy は、ロードバランサのヘルスチェックに合格するノードとパケット処理を制御します。

1GKE バージョン 1.36 以降では、GKE サブセット化が自動的に有効になります。GKE のサブセット化を有効にすると、無効にすることはできません。

2 cloud.google.com/l4-rbs: "enabled" アノテーションは、Service マニフェストがクラスタに送信された場合にのみ適用されます。このアノテーションを既存の Service マニフェストに追加しても、ターゲット プールベースの外部パススルー ネットワーク ロードバランサはバックエンド サービスベースの外部パススルー ネットワーク ロードバランサに変換されません。

3GKE は、インスタンス グループ バックエンドを使用するバックエンド サービスベースの外部パススルー ネットワーク ロードバランサを、GCE_VM_IP NEG バックエンドを使用するバックエンド サービスベースの外部パススルー ネットワーク ロードバランサに自動的には更新しません。手動移行の手順については、 GCE_VM_IP NEG バックエンドに移行するをご覧ください。

GCE_VM_IP NEG バックエンドのノード メンバーシップ

GKE が GCE_VM_IP NEG バックエンドを使用して内部パススルー ネットワーク ロードバランサまたはバックエンド サービスベースの外部パススルー ネットワーク ロードバランサを作成すると、次のように NEG が作成および管理されます。

  • GKE は、LoadBalancer Service ごとに各ゾーンに一意の GCE_VM_IP NEG を作成します。インスタンス グループとは異なり、ノードはロード バランシングされた複数の GCE_VM_IP NEG のメンバーになることができます。

  • Service の externalTrafficPolicy とクラスタ内のノード数によって、Service の GCE_VM_IP NEG にエンドポイントとして追加されるノードが決定されます。

次の表にまとめられているように、クラスタのコントロール プレーンは Service の externalTrafficPolicy の値とクラスタ内のノード数に従って、GCE_VM_IP NEG のノード エンドポイントを管理します。

内部パススルー ネットワーク ロードバランサのノード

externalTrafficPolicy クラスタ内のノード数 エンドポイントのメンバーシップ
Cluster 1～25 ノード GKE は、ノードに Service 用のサービスを提供する Pod が含まれていない場合でも、クラスタ内のすべてのノードを Service の NEG 用のエンドポイントとして使用します。
Cluster 25 ノード超 GKE は、ノードに Service 用のサービスを提供する Pod が含まれていない場合でも、最大 25 ノードのランダムなサブセットを Service の NEG のエンドポイントとして使用します。
Local 任意の数のノード1 GKE は、Service のサービスを提供する Pod を少なくとも 1 つ持つノードを Service の NEG のエンドポイントとして使用するだけです。

1 サービスを提供する Pod を持つノードは 250 個までです。クラスタに 250 個を超えるノードを配置できますが、内部パススルー ネットワーク ロードバランサのバックエンドのサブセット化が無効の場合、内部パススルー ネットワーク ロードバランサは 250 個のバックエンド VM にのみ負荷を分散します。GKE のサブセット化を有効にしても、GKE は内部パススルー ネットワーク ロードバランサ バックエンドのサブセット化を使用して内部パススルー ネットワーク ロードバランサを構成しません。この制限の詳細については、内部バックエンド サービスあたりの VM インスタンスの最大数をご覧ください。

外部パススルー ネットワーク ロードバランサのノード

externalTrafficPolicy クラスタ内のノード数 エンドポイントのメンバーシップ
Cluster 1～250 ノード GKE は、ノードに Service 用のサービスを提供する Pod が含まれていない場合でも、クラスタ内のすべてのノードを Service の NEG 用のエンドポイントとして使用します。
Cluster 250 ノード超 GKE は、ノードに Service 用のサービスを提供する Pod が含まれていない場合でも、最大 250 ノードのランダムなサブセットを Service の NEG のエンドポイントとして使用します。
Local 任意の数のノード1 GKE は、Service のサービスを提供する Pod を少なくとも 1 つ持つノードを Service の NEG のエンドポイントとして使用するだけです。

1 サービスを提供する Pod を持つノードは 3,000 個までです。クラスタには 3,000 を超えるノードを含めることができますが、GCE_VM_IP NEG バックエンドを使用するバックエンド サービスベースの外部パススルー ネットワーク ロードバランサを作成する場合、GKE は最大 3,000 個までのエンドポイントの作成をサポートします。

単一のロード バランシング インスタンス グループの制限

Compute Engine API では、VM が複数のロード バランシング インスタンス グループのメンバーになることはできません。GKE ノードにはこの制約が適用されます。

非マネージド インスタンス グループのバックエンドを使用する場合、GKE は、クラスタが使用する各ゾーンのすべてのノードプールからすべてのノードを含む非マネージド インスタンス グループを作成または更新します。これらの非マネージド インスタンス グループは、GKE によって作成された次のロードバランサのバックエンドです。

  • マニフェストに networking.gke.io/load-balancer-type: "Internal" アノテーションが含まれ、GKE バージョン 1.36 より前の GKE サブセット化が無効になっているクラスタに送信された内部 LoadBalancer Service 用に作成された内部パススルー ネットワーク ロードバランサ。
  • マニフェストに cloud.google.com/l4-rbs: "enabled" アノテーションが含まれ、1.32.2-gke.1652000 より前の GKE バージョンを実行しているクラスタに送信された外部 LoadBalancer Service 用に作成されたバックエンド サービスベースの外部パススルー ネットワーク ロードバランサ。
  • コンテナ ネイティブのロード バランシングを使用せず、GKE Ingress コントローラを使用して、外部 GKE Ingress 用に作成された外部アプリケーション ロードバランサ。

ノード VM は複数のロード バランシング インスタンス グループのメンバーになれないため、GKE は、次のいずれかが正の場合、GKE Ingress リソース用に作成された内部パススルー ネットワーク ロードバランサ、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサ、外部アプリケーション ロードバランサを作成および管理できません。

  • GKE の外部で、少なくとも 1 つのバックエンド サービスベースのロードバランサを作成し、クラスタのマネージド インスタンス グループをロードバランサのバックエンド サービスのバックエンドとして使用しました。
  • GKE の外部で、クラスタのノードの一部または全体を含むカスタム非マネージド インスタンス グループを作成し、作成したカスタム非マネージド インスタンス グループをロードバランサのバックエンド サービスに接続します。

この制限を回避するには、NEG バックエンドを使用するように GKE に指示します。

ロードバランサのヘルスチェック

すべての GKE LoadBalancer Service で、ロードバランサのヘルスチェックが実装されます。ロードバランサのヘルスチェック システムはクラスタの外部で動作し、Pod の readiness プローブ、liveness プローブ、起動プローブとは異なります。

ロードバランサのヘルスチェック パケットには、各ノードで実行されている kube-proxy（以前のデータプレーン）または cilium-agent（GKE Dataplane V2）ソフトウェアが応答します。LoadBalancer Service のロードバランサのヘルスチェックに Pod が応答することはできません。

Service の externalTrafficPolicy は、ロードバランサのヘルスチェックに合格するノードを決定します。ロードバランサがヘルスチェック情報を使用する方法の詳細については、トラフィック分散をご覧ください。

externalTrafficPolicy ヘルスチェックに合格するノード 使用するポート
Cluster サービスを提供する Pod がないノードを含め、クラスタ内のすべてのノードがヘルスチェックに合格します。ノードにサービスを提供する Pod が 1 つ以上存在する場合、そのノードは Pod の状態に関係なくロードバランサのヘルスチェックに合格します。 ロードバランサのヘルスチェック ポートは TCP ポート 10256 であることが必要です。カスタマイズはできません。
Local

ロードバランサのヘルスチェックでは、ノードに準備完了状態でサービスを提供している Pod が 1 つ以上存在する場合は、他の Pod の状態に関係なく、そのノードを正常とみなします。サービスを提供する Pod がないノード、サービスを提供する Pod がすべて readiness プローブに失敗したノード、サービスを提供する Pod がすべて終了しているノードは、ロードバランサのヘルスチェックに失敗します。

状態の移行中は、ノードはロードバランサのヘルスチェックの異常しきい値に達するまで、ロードバランサのヘルスチェックに合格します。移行状態は、ノード上のサービスを提供する Pod のすべてが readiness プローブに失敗し始めたとき、またはノード上のサービスを提供する Pod のすべてが終了したときに発生します。この状況でのパケットの処理方法は、GKE のバージョンによって異なります。詳細については、次のセクションのパケット処理をご覧ください。

 カスタム ヘルスチェック ポートを指定しない限り、Kubernetes コントロール プレーンがノードポートの範囲からヘルスチェック ポートを割り当てます。

重み付きロード バランシングが有効になっている場合、ロードバランサはヘルス情報と重み情報の両方を使用して、適格なノード バックエンドのセットを特定します。詳細については、重み付きロード バランシングの効果をご覧ください。

ゾーン アフィニティが有効になっている場合、ロードバランサにより適格なノード バックエンドのセットが絞り込まれる場合があります。詳細については、ゾーン アフィニティの効果をご覧ください。

パケット処理

以下の各セクションでは、ロードバランサとクラスタノードが連携して LoadBalancer Service で受信したパケットを転送する方法について説明します。

パススルー ロード バランシング

パススルー ネットワーク ロードバランサは、GKE クラスタのノードの nic0 インターフェースにパケットを転送します。ノードが受信するロードバランスされた各パケットには次の特性があります。

  • パケットの宛先 IP アドレスはロードバランサの転送ルールの IP アドレスと一致します。
  • パケットのプロトコルと宛先ポートは以下の両方と一致します。
    • Service マニフェストの spec.ports[] で指定されたプロトコルとポート
    • ロードバランサの転送ルールで構成されたプロトコルとポート

ノードでの宛先ネットワーク アドレス変換

ノードはパケットを受信した後、追加のパケット処理を実行します。以前のデータプレーンを使用する GKE クラスタでは、ノードは iptables を使用してロードバランスされたパケットを処理します。GKE Dataplane V2 が有効になっている GKE クラスタでは、ノードは代わりに eBPF を使用します。ノードレベルのパケット処理には、常に次のアクションが含まれます。

  • ノードは、パケットに対して宛先ネットワーク アドレス変換（DNAT）を実行し、サービスを提供する Pod の IP アドレスに宛先 IP アドレスを設定します。
  • ノードは、パケットの宛先ポートを、対応する Service の spec.ports[] の targetPort に変更します。

ノードでの送信元ネットワーク アドレス変換とルーティング

次の表に、externalTrafficPolicy と、ロードバランスされたパケットを受信したノードが、そのパケットを Pod に送信する前に送信元ネットワーク アドレス変換（SNAT）を実行するかどうかとの関係を示します。

externalTrafficPolicy SNAT の動作
Cluster

以前のデータプレーンを使用する GKE クラスタでは、ロードバランスされたパケットを受信した各ノードは、そのノードがパケットをローカル Pod や別のノードの Pod に転送するかどうかにかかわらず、常にパケットの送信元 IP アドレスをノードの IP アドレスと一致するように変更します。

GKE Dataplane V2 を使用する GKE クラスタでは、ロードバランスされたパケットを受信した各ノードは、受信ノードがパケットを別のノードの Pod に転送する場合にのみ、パケットの送信元 IP アドレスをそのノードの IP アドレスと一致するように変更します。ロード バランシングされたパケットを受信したノードが、そのパケットをローカル Pod に転送する場合、そのノードはこれらのパケットの送信元 IP アドレスを変更しません。
Local

ロード バランシングされたパケットを受信した各ノードは、そのパケットをローカル Pod にのみ転送します。ノードは、これらのパケットの送信元 IP アドレスを変更しません。

次の表は、externalTrafficPolicy がロードバランスされたパケットとレスポンス パケットのノードによる転送の仕方を制御する方法を示しています。

externalTrafficPolicy ロードバランスされたパケットのルーティング レスポンス パケットのルーティング
Cluster

ロードバランスされたパケットのルーティングのベースライン動作は次のとおりです。

  • ロードバランスされたパケットを受信したノードにサービスを提供している準備完了状態の Pod がない場合、そのノードはサービスを提供している準備完了状態の Pod を持つ別のノードにパケットを転送します。
  • ロードバランスされたパケットを受信したノードにサービスを提供している準備完了状態の Pod がある場合、そのノードはパケットを次のいずれかに転送する可能性があります。
    • ローカル Pod。
    • サービスを提供している準備完了状態の Pod を持つ別のノード。

リージョン クラスタで、ロードバランスされたパケットを受信したノードがパケットを別のノードに転送する場合、ゾーン アフィニティには次の影響があります。

  • ゾーン アフィニティが有効になっていない場合、別のノードはどのゾーンに存在してもかまいません。
  • ゾーン アフィニティが有効になっている場合、ロードバランスされたパケットを受信したノードは、同じゾーン内の別のノードにパケットを転送しようとします。それが不可能な場合、別のノードはどのゾーンに存在してもかまいません。

最後の手段として、クラスタ内のすべてのノードにサービス提供中の Pod、準備完了 Pod、終了していない Pod がない場合、次のようになります。

  • プロキシ終了エンドポイントが有効になっている場合1、ロードバランスされたパケットを受信したノードは、可能な場合は、サービスを提供しているが終了中の Pod にパケットを転送します。
  • プロキシ終了エンドポイントが無効になっている場合、またはクラスタ全体に Pod がない場合、ロードバランスされたパケットを受信したノードは TCP リセットにより接続を閉じます。

レスポンス パケットは、常に Direct Server Return を使用してノードから送信されます。

  • サービスを提供中の Pod を含むノードが、対応するロード バランシングされたパケットを受信したノードでない場合、サービスを提供するノードはレスポンス パケットを受信ノードに送り返します。その後、受信ノードは Direct Server Return を使用してレスポンス パケットを送信します。
  • サービスを提供中の Pod を含むノードが、ロードバランスされたパケットを受信したノードである場合、そのノードは Direct Server Return を使用してレスポンス パケットを送信します。
Local

ロード バランシングされたパケットのルーティングのベースライン動作は次のとおりです。ロード バランシングされたパケットを受信したノードには、通常、サービス提供中の準備完了状態で終了していない Pod があります（このような Pod がないと、ロードバランサのヘルスチェックに合格できないため）。ノードは、ロードバランスされたパケットをローカル Pod に転送します。

リージョン クラスタでは、ゾーン アフィニティによってロード バランシングされたパケットのルーティングのベースライン動作が変更されることはありません。

最後の手段として、ロードバランスされたパケットを受信したノードに、サービス提供中の Pod、準備完了 Pod、終了していない Pod がない場合、次のようになります。

  • プロキシ終了エンドポイントが有効になっている場合1、ロードバランスされたパケットを受信したノードは、可能な限り、ローカルのサービス提供中であるが終了中の Pod にパケットを転送します。
  • プロキシ終了エンドポイントが無効になっている場合、またはロードバランスされたパケットを受信したノードにサービスを提供中の Pod がない場合、そのノードは TCP リセットにより接続を閉じます。

サービス提供中の Pod を含むノードは、常にロードバランスされたパケットを受信したノードであり、そのノードは Direct Server Return を使用してレスポンス パケットを送信します。

1 プロキシ終了エンドポイントは、次の構成で有効になっています。

  • 以前のデータプレーンを使用する GKE クラスタ: GKE バージョン 1.26 以降
  • GKE Dataplane V2 を使用する GKE クラスタ: GKE バージョン 1.26.4-gke.500 以降

割り当て

作成できる転送ルールの数は、ロードバランサの割り当てによって制御されます。

次のステップ