このページでは、Kubernetes LoadBalancer Service マニフェストを適用するときに、Google Kubernetes Engine（GKE）で Google Cloud ロードバランサを作成、管理する方法の一般的な概要を説明します。LoadBalancer のタイプ、構成パラメータについて説明し、ベスト プラクティスの推奨事項を示します。
このページを読む前に、GKE ネットワーキングのコンセプトを理解しておく必要があります。
概要
LoadBalancer サービスを作成すると、GKE により、その特性がサービス マニフェストのパラメータに依存する Google Cloud のパススルー ロードバランサが構成されます。
ネットワークの LoadBalancer Service をカスタマイズする
使用する LoadBalancer Service の構成を選択する場合は、次の点を考慮してください。
ロードバランサのタイプ - 内部または外部
GKE で LoadBalancer Service を作成するときに、ロードバランサに内部アドレスと外部アドレスのどちらを割り振るかを指定します。
外部 LoadBalancer Service は、外部パススルー ネットワーク ロードバランサを使用して実装されます。VPC ネットワークの外部にあるクライアントと、インターネットにアクセスできる Google Cloud VM は、外部 LoadBalancer Service にアクセスできます。
LoadBalancer サービスを作成してカスタム設定を指定しないと、デフォルトでこの構成になります。
ベスト プラクティスとして、外部 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を使用すると、少なくとも 1 つのサービスを提供していて、準備が完了しており、終了していない Pod が配置されているノードにのみパケットが配信され、元のクライアントの送信元 IP アドレスが保持されます。このオプションは、クラスタ内のノードの総数が変動しても、サービス提供 Pod を持つノードの数が比較的一定のワークロードに最適です。このオプションは、重み付けされたロード バランシングをサポートするために必要です。
- クラスタ内のノードの総数は比較的一定であるが、サービスを提供する Pod があるノードの数は変化する場合は、
externalTrafficPolicy: Clusterを使用します。このオプションでは、元のクライアントの送信元 IP アドレスは保持されません。また、パケットがロードバランサからノードに配信された後、別のノードのサービング Pod にルーティングされる可能性があるため、レイテンシが増加する可能性があります。このオプションは重み付きロード バランシングと互換性がありません。
externalTrafficPolicy がノード内のパケット ルーティングに与える影響の詳細については、パケット処理をご覧ください。
重み付き負荷分散
外部 LoadBalancer 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 の特別な考慮事項
このセクションでは、内部 LoadBalancer Service に固有の GKE サブセット化オプションと、GKE サブセット化が externalTrafficPolicy と連携してロードバランスされたノードの最大数に影響する仕組みについて説明します。
GKE のサブセット化
GKE のサブセット化を有効にして、内部 LoadBalancer Service のスケーラビリティを向上させます。
GKE のサブセット化（レイヤ 4 内部ロードバランサの GKE サブセット化）は、クラスタ全体の構成オプションです。ノード エンドポイントを GCE_VM_IP ネットワーク エンドポイント グループ（NEG）に効率的にグループ化することで、内部パススルー ネットワーク ロードバランサのスケーラビリティを向上させます。NEG は、ロードバランサのバックエンドとして使用されます。
次の図は、3 つのノードを持つゾーンクラスタ内の 2 つの Service を示しています。クラスタで GKE のサブセット化が有効になっています。各 Service には 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 バックエンドのノード メンバーシップをご覧ください。
セッション アフィニティとトラフィック分散
セッション アフィニティを使用すると、ロードバランサがクライアントからのリクエストをバックエンドに割り当てる方法を制御し、クライアントからの後続のリクエストがすべて同じバックエンドにルーティングされるようにできます。
セッション アフィニティが CLIENT_IP に設定された内部パススルー ネットワーク ロードバランサを使用すると、バックエンドへのトラフィックの分散が不均一になることがあります。これは、ロードバランサが特定のクライアント IP アドレスから常に同じバックエンドにトラフィックを送信するためです。トラフィック量が多いクライアントが少数の場合、一部のバックエンドが過負荷になり、他のバックエンドが十分に使用されない可能性があります。
詳細については、セッション アフィニティのオプションをご覧ください。
ノードのグループ化
Service マニフェストのアノテーションと、内部 LoadBalancer Service では、GKE サブセット化のステータスによって、生成される Google Cloud ロードバランサとバックエンドのタイプが決定されます。Google Cloud パススルー ロードバランサのバックエンドは、特定のノードや Pod の IP アドレスではなく、GKE ノードのネットワーク インターフェース（NIC）を識別します。ロードバランサとバックエンドのタイプによって、ノードを GCE_VM_IP NEG、インスタンス グループ、ターゲット プールにグループ化する方法が決定されます。
| GKE LoadBalancer Service | 生成される Google Cloud ロードバランサ | ノードをグループ化する方法 |
|---|---|---|
| GKE サブセットが有効になっているクラスタで作成された内部 LoadBalancer Service1 | バックエンド サービスが GCE_VM_IP ネットワーク エンドポイント グループ（NEG）バックエンドを使用する内部パススルー ネットワーク ロードバランサ |
ノード VM は、Service の Service の |
| GKE サブセットが無効のクラスタで作成された内部 LoadBalancer Service | バックエンド サービスがゾーンの非マネージド インスタンス グループ のバックエンドを使用する内部パススルー ネットワーク ロードバランサ | すべてのノード VM は、GKE が内部パススルー ネットワーク ロードバランサのバックエンド サービスのバックエンドとして使用する、ゾーンのアンマネージド インスタンス グループに配置されます。 Service の ロード バランシング インスタンス グループの制限により、同じアンマネージド インスタンス グループがクラスタ内で作成された他のロードバランサのバックエンド サービスに使用されます。 |
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 の作成をご覧ください。
2GKE は、既存の外部 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" アノテーションを省略する必要があります。
GCE_VM_IP NEG バックエンドのノード メンバーシップ
クラスタで GKE のサブセット化を有効にすると、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 内部 LoadBalancer Service 用のサービスを提供する Pod を持つノードは 250 個までです。クラスタに 250 を超えるノードを含めることができますが、内部パススルー ネットワーク ロードバランサのバックエンドのサブセット化が無効の場合、内部パススルー ネットワーク ロードバランサは 250 個のバックエンド VM にのみ分散します。GKE サブセットを有効にしても、GKE は内部パススルー ネットワーク ロードバランサのバックエンド サブセットを使用して内部パススルー ネットワーク ロードバランサを構成しません。この制限の詳細については、内部バックエンド サービスあたりの VM インスタンスの最大数をご覧ください。
単一のロード バランシング インスタンス グループの制限
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（以前の Dataplane）または cilium-agent（GKE Dataplane V2）ソフトウェアが応答します。LoadBalancer Service のロードバランサのヘルスチェックに Pod が応答することはできません。
Service の externalTrafficPolicy は、ロードバランサのヘルスチェックに合格するノードを決定します。
externalTrafficPolicy |
ヘルスチェックに合格するノード | 使用するポート |
|---|---|---|
Cluster |
サービスを提供する Pod のないノードを含む、クラスタ内のすべてのノードがヘルスチェックに合格します。ノードに 1 つ以上のサービスを提供する Pod が存在する場合、その Pod の状態に関係なく、ノードはロードバランサのヘルスチェックに合格します。 | ロードバランサのヘルスチェック ポートは TCP ポート 10256 である必要があります。カスタマイズはできません。 |
Local |
ロードバランサのヘルスチェックでは、他の Pod の状態に関係なく、準備が完了しており終了していないサービスを提供する Pod がノードに 1 つ以上存在する場合、ノードは正常と見なされます。サービスを提供する Pod がないノード、サービスを提供する Pod がすべて readiness プローブに失敗したノード、サービスを提供する Pod がすべて終了しているノードは、ロードバランサのヘルスチェックに失敗します。 状態の移行中は、ノードはロードバランサのヘルスチェックの異常しきい値に達するまで、ロードバランサのヘルスチェックに合格します。移行状態は、ノード上のサービスを提供する Pod のすべてが readiness プローブに失敗し始めたとき、またはノード上のサービスを提供する Pod のすべてが終了したときに発生します。この状況でのパケットの処理方法は、GKE のバージョンによって異なります。詳細については、次のセクションのパケット処理をご覧ください。 |
カスタム ヘルスチェック ポートを指定しない限り、ヘルスチェック ポートは TCP ポート 10256 です。 |
重み付けロード バランシングが有効になっている場合、kube-proxy または cilium-agent ソフトウェアは、ロードバランサのヘルスチェックへの回答にレスポンス ヘッダーを含めます。このレスポンス ヘッダーは、ノード上のサービング Pod、準備完了 Pod、終了していない Pod の数に比例する重みを定義します。ロードバランサは、この重みに基づいて新しい接続をサービング Pod に転送します。
パケット処理
以下の各セクションでは、ロードバランサとクラスタノードが連携して LoadBalancer Service で受信したパケットを転送する方法について説明します。
パススルー ロード バランシング
パススルー ネットワーク ロードバランサは、GKE クラスタのノードの nic0 インターフェースにパケットを転送します。ノードで受信するロードバランスされた各パケットには次の特性があります。
- パケットの宛先 IP アドレスがロードバランサの転送ルールの IP アドレスと一致する。
- パケットのプロトコルと宛先ポートは次のいずれかと一致します。
- Service マニフェストの
spec.ports[]で指定されたプロトコルとポート - ロードバランサの転送ルールで構成されたプロトコルとポート
- Service マニフェストの
ノードでの宛先ネットワーク アドレス変換
ノードはパケットを受信した後、追加のパケット処理を実行します。以前のデータプレーンを使用する GKE クラスタでは、ノードは iptables を使用してロードバランスされたパケットを処理します。GKE Dataplane V2 が有効になっている GKE クラスタでは、ノードは代わりに eBPFを使用します。ノードレベルのパケット処理には、常に次のアクションが含まれます。
- ノードは、パケットに対して宛先ネットワーク アドレス変換（DNAT）を実行し、宛先 IP アドレスをサービスを提供する Pod の IP アドレスに設定します。
- ノードは、パケットの宛先ポートを、対応する Service の
spec.ports[]のtargetPortに変更します。
ノードでの送信元ネットワーク アドレス変換
externalTrafficPolicy は、ノードレベルのパケット処理が、送信元ネットワーク アドレス変換（SNAT）と、パケットがノードから Pod へたどるパスを実行するかどうかも決定します。
externalTrafficPolicy |
ノードの SNAT の動作 | 転送の動作 |
|---|---|---|
Cluster |
ノードは、ロード バランシングされたパケットの送信元 IP アドレスを、ロードバランサから受信したノードの IP アドレスと一致するように変更します。 | ノードは、任意のサービスを提供する Pod にパケットを転送します。サービスを提供する Pod は同じノード上に存在する場合もあれば、そうでない場合もあります。 ロードバランサからパケットを受信したノードに、準備が完了しサービスを提供している Pod がない場合、ノードは、準備が完了しサービスを提供している Pod を含む別のノードにパケットを転送します。Pod からのレスポンス パケットはノードから、ロードバランサからリクエスト パケットを受信したノードに転送されます。その最初のノードが、Direct Server Return を使用して元のクライアントにレスポンス パケットを送信します。 |
Local |
ノードは、負荷分散されたパケットの送信元 IP アドレスを変更しません。 | ほとんどの場合、ノードはロードバランサからパケットを受信したノードで実行されているサービスを提供する Pod にパケットを転送します。このノードが Direct Server Return を使用して元のクライアントにレスポンス パケットを送信します。これが、このタイプのトラフィック ポリシーの主な目的です。 状況によっては、Service に対して準備完了状態でサービスを提供している Pod がノードにない場合でも、ノードがロードバランサからパケットを受信する場合があります。この状況は、ロードバランサのヘルスチェックがまだ失敗しきい値に達していないものの、以前に準備が完了しサービスを提供していた Pod の準備ができていないか、終了しようとしている場合に発生します（ローリング アップデートを行う場合など）。この状況でパケットがどのように処理されるかは、GKE のバージョン、クラスタで GKE Dataplane V2 を使用するかどうか、
|
料金と割り当て
ネットワーク料金は、ロードバランサによって処理されるパケットに適用されます。詳細については、Cloud Load Balancing と転送ルールの料金をご覧ください。Google Cloud の料金計算ツールを使用して請求額を見積もることもできます。
作成できる転送ルールの数は、ロードバランサの割り当てによって制御されます。
- 内部パススルー ネットワーク ロードバランサは、次のものを使用します。 プロジェクトごとのバックエンド サービスの割り当て、プロジェクトごとのヘルスチェックの割り当て、Virtual Private Cloud ネットワーク割り当てあたりの内部パススルー ネットワーク ロードバランサの転送ルール。
- バックエンド サービスベースの外部パススルー ネットワーク ロードバランサは、次のものを使用します。プロジェクトごとのバックエンド サービスの割り当て、プロジェクトごとのヘルスチェックの割り当て、プロジェクトごとの外部パススルー ネットワーク ロードバランサ転送ルールの割り当て。
- ターゲット プールベースの外部パススルー ネットワーク ロードバランサは、プロジェクトごとのターゲット プールの割り当て、プロジェクトごとのヘルスチェックの割り当て、プロジェクトごとの外部パススルー ネットワーク ロードバランサ転送ルールの割り当てを使用します。
次のステップ
- GKE LoadBalancer Service パラメータについて学習する。
- Kubernetes Services について学習する。