このページでは、Kubernetes LoadBalancer Service マニフェストを適用するときに、Google Kubernetes Engine（GKE）で Google Cloud ロードバランサを作成、管理する方法の一般的な概要を説明します。LoadBalancer のタイプ、構成パラメータについて説明し、ベスト プラクティスの推奨事項を示します。
このページを読む前に、GKE ネットワーキングのコンセプトを理解しておく必要があります。
概要
LoadBalancer Service を作成すると、GKE により、その特性が Service マニフェストのパラメータに依存する Google Cloud パススルー ロードバランサが構成されます。
LoadBalancer Service をカスタマイズする
使用する LoadBalancer Service の構成を選択する場合は、次の点を考慮してください。
ロードバランサのタイプ - 内部または外部
GKE で LoadBalancer Service を作成するときに、ロードバランサに内部アドレスと外部アドレスのどちらを割り振るかを指定します。
外部 LoadBalancer Service は、外部パススルー ネットワーク ロードバランサを使用して実装されます。VPC ネットワークの外部にあるクライアントと、インターネットにアクセスできる Google CloudVM は、外部 LoadBalancer Service にアクセスできます。
LoadBalancer Service を作成してカスタム設定を指定しないと、デフォルトでこの構成になります。
外部 LoadBalancer Service を作成する際のベスト プラクティスとして、Service マニフェストに
cloud.google.com/l4-rbs: "enabled"アノテーションを含めます。このアノテーションを Service マニフェストに含めると、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサが作成されます。cloud.google.com/l4-rbs: "enabled"アノテーションを省略した LoadBalancer Service マニフェストによって、ターゲット プールベースの外部パススルー ネットワーク ロードバランサが作成されます。現在は、ターゲット プールベースの外部パススルー ネットワーク ロードバランサの使用は推奨されていません。内部 LoadBalancer Service は、内部パススルー ネットワーク ロードバランサを使用して実装されます。同じ VPC ネットワークまたはクラスタの VPC ネットワークに接続されたネットワークにあるクライアントは、内部 LoadBalancer Service にアクセスできます。
内部 LoadBalancer Service を作成するには:
ベスト プラクティスは、GKE のサブセット化が有効になっていることを確認し、GKE が
GCE_VM_IPネットワーク エンドポイント グループ（NEG）を使用してノードを効率的にグループ化できるようにすることです。GKE のサブセット化は必須ではありませんが、実行することを強くおすすめします。Service マニフェストに
networking.gke.io/load-balancer-type: "Internal"アノテーションを含めます。
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 の数に比例して新しい接続を分散します。これにより、Pod が多いノードが新しい接続の大部分を受け取るようにします。
重み付きロード バランシングを使用するには、次のすべての要件を満たす必要があります。
GKE クラスタはバージョン 1.31.0-gke.1506000 以降を使用する必要があります。
クラスタで
HttpLoadBalancingアドオンが有効になっている必要があります。このアドオンはデフォルトで有効になっています。これによりクラスタは、バックエンド サービスを使用するロードバランサを管理できます。GKE でバックエンド サービスベースの外部パススルー ネットワーク ロードバランサが作成されるよう、LoadBalancer Service マニフェストに
cloud.google.com/l4-rbs: "enabled"アノテーションを含める必要があります。ターゲット プールベースの外部パススルー ネットワーク ロードバランサは、重み付きロード バランシングに対応していません。重み付きロード バランシング機能を有効にするには、LoadBalancer Service マニフェストに
networking.gke.io/weighted-load-balancing: pods-per-nodeアノテーションを含める必要があります。LoadBalancer Service マニフェストでは
externalTrafficPolicy: Localを使用する必要があります。GKE でexternalTrafficPolicy: Clusterを使用できないわけではありませんが、externalTrafficPolicy: Clusterを使用すると、ロードバランサの後にパケットが別のノードに転送される可能性があるため、重み付きロード バランシングが実質的に無効になります。
重み付きロード バランシングを使用するには、重み付きロード バランシングを有効にするをご覧ください。
ゾーン アフィニティ
内部 LoadBalancer Service はゾーン アフィニティ（プレビュー版）をサポートしています。これにより、クライアントと同じゾーン内のサービス提供中の Pod を持つノードに新しい接続をルーティングできます。トラフィックをゾーン内に維持すると、ゾーン間のトラフィックを最小限に抑えることができ、コストとレイテンシを削減できます。
ゾーン アフィニティを使用するには、ゾーン アフィニティを使用するをご覧ください。トラフィックをゾーン内に維持できる場合など、ゾーン アフィニティによってロードバランサの構成がどのように変化するかについては、ゾーン アフィニティの効果をご覧ください。ゾーン アフィニティと externalTrafficPolicy がノード VM のパケット ルーティングにどのように影響するかについては、ノードでの送信元ネットワーク アドレス変換とルーティングをご覧ください。
内部 LoadBalancer Service の特別な考慮事項
このセクションでは、内部 LoadBalancer Service に固有の GKE のサブセット化オプションと、GKE のサブセット化が externalTrafficPolicy との相互作用によってロードバランスされたノードの最大数に影響する仕組みについて説明します。
GKE のサブセット化
GKE のサブセット化を有効にして、内部 LoadBalancer Service のスケーラビリティを向上させます。
GKE のサブセット化（レイヤ 4 内部ロードバランサの GKE サブセット化）は、クラスタ全体の構成オプションです。これは、ノード エンドポイントを GCE_VM_IP ネットワーク エンドポイント グループ（NEG）により効率的にグループ化することで、内部パススルー ネットワーク ロードバランサのスケーラビリティを向上させます。NEG はロードバランサのバックエンドとして使用されます。
次の図は、3 つのノードがあるゾーンクラスタ内の 2 つの Service を示しています。クラスタで GKE のサブセット化が有効になっています。各サービスには 2 つの Pod があります。GKE は、Service ごとに 1 つの GCE_VM_IP NEG を作成します。各 NEG 内のエンドポイントは、それぞれの Service に対してサービスを提供している Pod があるノードです。
GKE のサブセット化は、クラスタの作成時に有効にすることも、既存のクラスタの更新によって有効にすることもできます。いったん GKE のサブセット化を有効にすると、無効にすることはできません。GKE のサブセット化には、以下が必要です。
- GKE バージョン 1.18.19-gke.1400 以降、および
- クラスタで有効になっている
HttpLoadBalancingアドオン。このアドオンはデフォルトで有効になっています。これにより、クラスタは、バックエンド サービスを使用するロードバランサを管理できます。
ノード数
GKE のサブセット化が無効になっているクラスタでは、（すべてのノードプール間で）合計 250 を超えるノードが含まれている場合、内部 LoadBalancer Service で問題が発生する可能性があります。これは、GKE によって作成された内部パススルー ネットワーク ロードバランサが、250 個以下のバックエンド ノード VM にしかパケットを分散できないためです。この制限には次の 2 つの理由があります。
- GKE はロードバランサ バックエンドのサブセット化を使用しないため。
- ロードバランサ バックエンドのサブセット化が無効になっている場合、内部パススルー ネットワーク ロードバランサではパケットの分散先が 250 個以下のバックエンドに制限されるため。
GKE のサブセット化を使用するクラスタは、ノード数が合計 250 を超えるクラスタの内部 LoadBalancer Service に対応しています。
GKE のサブセット化が有効になっているクラスタ内で
externalTrafficPolicy: Localを使用する内部 LoadBalancer Service では、この Service をサポートするサービスを提供する Pod があるノードを最大 250 個までサポートします。GKE のサブセット化が有効になっているクラスタ内で
externalTrafficPolicy: Clusterを使用する内部 LoadBalancer Service では、GKE がGCE_VM_IPNEG 内で構成するノード エンドポイントが 25 個未満に制限されているため、サービスを提供する Pod があるノードの数には制限がありません。詳細については、GCE_VM_IPNEG バックエンドのノード メンバーシップをご覧ください。
トラフィック分散
デフォルトでは、内部 LoadBalancer Service と外部 LoadBalancer Service は、セッション アフィニティが NONE に設定されたパススルー ネットワーク ロードバランサを作成します。パススルー ネットワーク ロードバランサは、セッション アフィニティ、ヘルス情報、場合によっては重みなどの詳細を使用して、新しい接続に適格なノード バックエンドを特定して選択します。
新しい接続では、接続トラッキング テーブルのエントリが作成されます。このエントリは、接続の後続のパケットを、以前に選択された適格なノード バックエンドにすばやく転送するために使用されます。パススルー ネットワーク ロードバランサが適格なバックエンドを識別して選択し、接続トラッキングを使用する方法の詳細については、以下をご覧ください。
重み付きロード バランシングの効果
外部 LoadBalancer Service に重み付けされたロード バランシングを構成すると、GKE は対応する外部パススルー ネットワーク ロードバランサで重み付けされたロード バランシングを有効にします。GKE は、ロードバランサのヘルスチェックへの応答にレスポンス ヘッダーを含めるように kube-proxy または cilium-agent ソフトウェアを構成します。このレスポンス ヘッダーは、各ノード上の準備完了状態でサービスを提供している Pod の数に比例する重みを定義します。
ロードバランサは、次のように重み情報を使用します。
ロードバランサの適格なノード バックエンドのセットは、重みがゼロ以外の正常なすべてのノードで構成されます。
ロードバランサは、対象となるノード バックエンドの 1 つを選択するときに重みを考慮します。Service が
externalTrafficPolicy: Localを使用している場合（重み付きロード バランシングを有効にするために必要）、サービス提供中の Pod が多く、準備完了状態で終了していない Pod が多い適格なノード バックエンドは、Pod が少ない適格なノード バックエンドよりも選択される可能性が高くなります。
ゾーン アフィニティの効果
内部 LoadBalancer Service のゾーン アフィニティを構成すると、GKE は ZONAL_AFFINITY_SPILL_CROSS_ZONE オプションとゼロのスピルオーバー比率で対応する内部パススルー ネットワーク ロードバランサを構成します。
このゾーン アフィニティ構成では、次の条件がすべて満たされる場合、ロードバランサは適格なノード バックエンドの元のセットを、クライアントと同じゾーンにある適格なノード バックエンドのみに絞り込みます。
クライアントがゾーン アフィニティと互換性がある。
クライアントのゾーンに、適格で正常なノード バックエンドが少なくとも 1 つ存在する。
それ以外の場合、ロードバランサはゾーン アフィニティの最適化を適用せずに、適格なノード バックエンドの元のセットを引き続き使用します。
ゾーン アフィニティ構成がロードバランサの動作に与える影響の詳細については、ゾーン アフィニティのドキュメントをご覧ください。
ノードのグループ化
GKE のバージョン、Service マニフェストのアノテーション、内部 LoadBalancer Service の場合は GKE のサブセット化オプションによって、生成される Google Cloud ロードバランサとバックエンドのタイプが決まります。ロードバランサとバックエンドのタイプによって、ノードを GCE_VM_IP NEG、インスタンス グループ、ターゲット プールにグループ化する方法が決まります。どのような状況でも、 Google Cloudパススルー ロードバランサは、特定のノードや Pod の IP アドレスではなく、GKE ノードのネットワーク インターフェース（NIC）を識別します。
| GKE LoadBalancer Service | 生成される Google Cloud ロードバランサ | ノードをグループ化する方法 |
|---|---|---|
| GKE サブセットが有効になっているクラスタで作成された内部 LoadBalancer Service1 | バックエンド サービスが GCE_VM_IP ネットワーク エンドポイント グループ（NEG）バックエンドを使用する内部パススルー ネットワーク ロードバランサ |
ノード VM は、Service の Service の |
| GKE のサブセット化が無効になっているクラスタで作成された内部 LoadBalancer Service | バックエンド サービスがゾーンの非マネージド インスタンス グループ のバックエンドを使用する内部パススルー ネットワーク ロードバランサ | すべてのノード VM は、GKE が内部パススルー ネットワーク ロードバランサのバックエンド サービスのバックエンドとして使用する、ゾーンの非マネージド インスタンス グループに配置されます。 Service の ロード バランシング インスタンス グループの制限により、同じ非マネージド インスタンス グループがクラスタ内で作成された他のロードバランサのバックエンド サービスに使用されます。 |
GKE バージョン 1.32.2-gke.1652000 以降を実行しているクラスタに適用された cloud.google.com/l4-rbs: "enabled" アノテーション2を持つ外部 LoadBalancer Service4 |
バックエンド サービスが GCE_VM_IP ネットワーク エンドポイント グループ（NEG）バックエンドを使用するバックエンド サービスベースの外部パススルー ネットワーク ロードバランサ |
ノード VM は、Service の Service の |
1.32.2-gke.16520004 より前の GKE バージョンを実行しているクラスタに適用された cloud.google.com/l4-rbs: "enabled" アノテーション2を持つ外部 LoadBalancer Service |
バックエンド サービスがゾーンの非マネージド インスタンス グループ バックエンドを使用するバックエンド サービスベースの外部パススルー ネットワーク ロードバランサ | すべてのノード VM は、GKE が外部パススルー ネットワーク ロードバランサのバックエンド サービスのバックエンドとして使用する、ゾーンの非マネージド インスタンス グループに配置されます。 Service の ロード バランシング インスタンス グループの制限により、同じ非マネージド インスタンス グループがクラスタ内で作成された他のロードバランサのバックエンド サービスに使用されます。 |
cloud.google.com/l4-rbs: "enabled" アノテーション3を含まない外部 LoadBalancer Service |
ターゲット プールにクラスタのすべてのノードが含まれるターゲット プールベースの外部パススルー ネットワーク ロードバランサ | ターゲット プールは、インスタンス グループに依存しないレガシー API です。すべてのノードがターゲット プール内で直接メンバーシップを持ちます。 Service の |
1 GKE のサブセット化を有効にした後に作成された内部パススルー ネットワーク ロードバランサのみが GCE_VM_IP NEG を使用します。GKE のサブセット化を有効にする前に作成された内部 LoadBalancer Service は、引き続き非マネージド インスタンス グループのバックエンドを使用します。例と構成ガイダンスについては、内部 LoadBalancer Service の作成をご覧ください。
2 GKE は、既存の外部 LoadBalancer Service をターゲット プールベースの外部パススルー ネットワーク ロードバランサからバックエンド サービスベースの外部パススルー ネットワーク ロードバランサに自動的には移行しません。バックエンド サービスベースの外部パススルー ネットワーク ロードバランサを利用する外部 LoadBalancer Service を作成するには、作成時に Service マニフェストに cloud.google.com/l4-rbs: "enabled" アノテーションを含める必要があります。
3 バックエンド サービスベースの外部パススルー ネットワーク ロードバランサを利用する既存の外部 LoadBalancer Service から cloud.google.com/l4-rbs: "enabled" アノテーションを削除しても、GKE でターゲット プールベースの外部パススルー ネットワーク ロードバランサは作成されません。ターゲット プールベースの外部パススルー ネットワーク ロードバランサを利用する外部 LoadBalancer Service を作成するには、作成時に Service マニフェストから cloud.google.com/l4-rbs: "enabled" アノテーションを省く必要があります。
4 GKE は、インスタンス グループ バックエンドを使用するバックエンド サービスベースの外部パススルー ネットワーク ロードバランサを利用する既存の外部 LoadBalancer Service を、GCE_VM_IP NEG バックエンドを使用するバックエンド サービスベースの外部パススルー ネットワーク ロードバランサに自動的には移行しません。GCE_VM_IP NEG バックエンドを使用するバックエンド サービスベースの外部パススルー ネットワーク ロードバランサを利用する外部 LoadBalancer Service を作成するには、Service マニフェストに cloud.google.com/l4-rbs: "enabled" アノテーションを含め、GKE バージョン 1.32.2-gke.1652000 以降を実行しているクラスタにマニフェストを適用する必要があります。手動移行の手順については、GCE_VM_IP NEG バックエンドに移行するをご覧ください。
GCE_VM_IP NEG バックエンドのノード メンバーシップ
クラスタで GKE のサブセット化が有効になっている場合、または cloud.google.com/l4-rbs: "enabled" を使用する外部パススルー ネットワーク ロードバランサが GKE バージョン 1.32.2-gke.1652000 以降で作成されている場合、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 のサブセット化が無効に設定されている場合の内部 LoadBalancer Service 用に作成された内部パススルー ネットワーク ロードバランサ。
cloud.google.com/l4-rbs: "enabled"アノテーションを付加して外部 LoadBalancer Service 用に作成されたバックエンド サービスベースの外部パススルー ネットワーク ロードバランサ。- コンテナ ネイティブのロード バランシングを使用せず、GKE Ingress コントローラを使用して、外部 GKE Ingress リソース用に作成された外部アプリケーション ロードバランサ。
ノード VM は複数のロード バランシング インスタンス グループのメンバーになれないため、GKE は、次のいずれかが正の場合、GKE Ingress リソース用に作成された内部パススルー ネットワーク ロードバランサ、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサ、外部アプリケーション ロードバランサを作成および管理できません。
- GKE の外部で、少なくとも 1 つのバックエンド サービスベースのロードバランサを作成し、クラスタのマネージド インスタンス グループをロードバランサのバックエンド サービスのバックエンドとして使用しました。
- GKE の外部で、クラスタのノードの一部または全体を含むカスタム非マネージド インスタンス グループを作成し、作成したカスタム非マネージド インスタンス グループをロードバランサのバックエンド サービスに接続します。
この制限を回避するには、可能であれば NEG バックエンドを使用するように GKE に指示できます。
- GKE のサブセット化を有効にします。そのため、新しい内部 LoadBalancer Service は代わりに
GCE_VM_IPNEG を使用します。 - コンテナ ネイティブのロード バランシングを使用するように外部 GKE Ingress リソースを構成します。詳しくは、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[]で指定されたプロトコルとポート - ロードバランサの転送ルールで構成されたプロトコルとポート
- Service マニフェストの
ノードでの宛先ネットワーク アドレス変換
ノードはパケットを受信した後、追加のパケット処理を実行します。以前のデータプレーンを使用する 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 |
ロードバランスされたパケットのルーティングのベースライン動作は次のとおりです。
リージョン クラスタで、ロードバランスされたパケットを受信したノードがパケットを別のノードに転送する場合、ゾーン アフィニティには次の効果があります。
最後の手段として、クラスタ内のすべてのノードに Service 用のサービスを提供する、準備完了の、終了していない Pod がない場合、次のようになります。
|
レスポンス パケットは、Direct Server Return を使用して常にノードから送信されます。
|
Local |
ロード バランシングされたパケットのルーティングのベースライン動作は次のとおりです。ロード バランシングされたパケットを受信したノードには、通常、サービスを提供する準備完了済みで終了していない Pod があります（このような Pod がないと、ロードバランサのヘルスチェックに合格できないため）。ノードは、負荷分散されたパケットをローカル Pod に転送します。 リージョン クラスタでは、ゾーン アフィニティによってロード バランシングされたパケットのルーティングのベースライン動作が変更されることはありません。 最後の手段として、ロードバランスされたパケットを受信したノードに、サービスを提供する準備完了状態で終了していない Pod がない場合、次のようになります。
|
サービスを提供する Pod を含むノードは、常にロードバランスされたパケットを受信したノードであり、そのノードは Direct Server Return を使用してレスポンス パケットを送信します。 |
1 プロキシ終端エンドポイントは、次の構成で有効になっています。
- 以前のデータプレーンを使用する GKE クラスタ: GKE バージョン 1.26 以降
- GKE Dataplane V2 を使用する GKE クラスタ: GKE バージョン 1.26.4-gke.500 以降
料金と割り当て
ネットワーク料金は、ロードバランサによって処理されるパケットに適用されます。詳細については、Cloud Load Balancing と転送ルールの料金をご覧ください。 Google Cloud 料金計算ツールを使用して請求額を見積もることもできます。
作成できる転送ルールの数は、ロードバランサの割り当てによって制御されます。
- 内部パススルー ネットワーク ロードバランサは、次のものを使用します。プロジェクトごとのバックエンド サービスの割り当て、プロジェクトごとのヘルスチェックの割り当て、Virtual Private Cloud ネットワーク割り当てあたりの内部パススルー ネットワーク ロードバランサの転送ルール。
- バックエンド サービスベースの外部パススルー ネットワーク ロードバランサは、次のものを使用します。プロジェクトごとのバックエンド サービスの割り当て、プロジェクトごとのヘルスチェックの割り当て、プロジェクトごとの外部パススルー ネットワーク ロードバランサ転送ルールの割り当て。
- ターゲット プールベースの外部パススルー ネットワーク ロードバランサは、プロジェクトごとのターゲット プールの割り当て、プロジェクトごとのヘルスチェックの割り当て、プロジェクトごとの外部パススルー ネットワーク ロードバランサ転送ルールの割り当てを使用します。
次のステップ
- GKE LoadBalancer Service のパラメータについて学習する。
- Kubernetes Service について学習する。