このページでは、Kubernetes LoadBalancer Service マニフェストを適用するときに、Google Kubernetes Engine（GKE）で Google Cloud ロードバランサを作成、管理する方法の一般的な概要を説明します。さまざまなタイプのロードバランサと、externalTrafficPolicy や L4 内部ロードバランサの GKE サブセット化などの設定により、ロードバランサの構成方法をどのように決定するかを説明します。
このページを読む前に、GKE ネットワーキングのコンセプトを理解しておく必要があります。
概要
LoadBalancer Service を作成すると、GKE により特性が Service マニフェストのパラメータに依存する Google Cloud のパススルー ロードバランサが構成されます。
LoadBalancer Service を選択する
使用する LoadBalancer Service の構成を選択する場合は、次の点を考慮してください。
- LoadBalancer の IP アドレスのタイプ。ロードバランサには、内部 IP アドレスまたは外部 IP アドレスを設定できます。
- LoadBalancer がサポートするノードの数とタイプ。
ネットワーク アーキテクチャの要件を決定したら、次のディシジョン ツリーを使用して、ネットワーク構成に対して選択する LoadBalancer Service を決定します。
外部ロード バランシングと内部ロード バランシング
GKE で LoadBalancer Service を作成するときに、ロードバランサに内部アドレスと外部アドレスのどちらを割り振るかを指定します。
クライアントが同じ VPC ネットワークまたはクラスタの VPC ネットワークに接続されているネットワーク内にある場合は、内部 LoadBalancer Service を使用します。内部 LoadBalancer Service は、内部パススルー ネットワーク ロードバランサを使用して実装されます。同じ VPC ネットワークまたはクラスタの VPC ネットワークに接続されたネットワークにあるクライアントは、ロードバランサの IP アドレスを使用して Service にアクセスできます。
内部 LoadBalancer Service を作成するには、Service マニフェストの
metadata.annotations[]に次のいずれかのアノテーションを含めます。networking.gke.io/load-balancer-type: "Internal"（GKE 1.17 以降）cloud.google.com/load-balancer-type: "Internal"（1.17 より前のバージョン）
クライアントが VPC ネットワークの外部に配置されている場合は、外部 LoadBalancer Service を使用します。インターネットにアクセスできる Google Cloud VM など、インターネット上でアクセス可能な次のタイプの外部パススルー ネットワーク ロードバランサのいずれかを使用できます。
- （推奨）マニフェストの
metadata.annotations[]にcloud.google.com/l4-rbs: "enabled"を追加して、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサを作成します。 cloud.google.com/l4-rbs: "enabled"アノテーションを省略して、ターゲット プールベースの外部パススルー ネットワーク ロードバランサを作成します。
- （推奨）マニフェストの
externalTrafficPolicy の効果
externalTrafficPolicy を Local または Cluster に設定して、準備ができているサービング Pod があるノードにパケットを転送する方法を定義できます。externalTrafficPolicy を定義する際は、次のシナリオを考慮してください。
externalTrafficPolicy: Localは、元のクライアント IP アドレスを保持する場合、またはクラスタ内のサービスを提供する Pod が配置されていないノードの数が変更されたときの中断を最小限に抑える場合に使用します。クラスタでサービスを提供する Pod がないノードの総数は変わらないものの、サービスを提供する Pod があるノードの数は変化する場合は、
externalTrafficPolicy: Clusterを使用します。このオプションでは、元のクライアント IP アドレスは保持されません。
externalTrafficPolicy がノード内のパケット ルーティングに与える影響の詳細については、パケット処理をご覧ください。
GKE のサブセット化
L4 内部ロードバランサのクラスタ全体の構成オプションに対する GKE のサブセット化（GKE のサブセット化）は、ロードバランサ バックエンドのノード エンドポイントをより効率的にグループ化することで、内部パススルー ネットワーク ロードバランサのスケーラビリティを改善します。
次の図は、3 つのノードと GKE のサブセット化が有効になっているゾーンクラスタ内の 2 つの Service を示しています。各サービスには 2 つの Pod があります。GKE は、Service ごとに 1 つの GCE_VM_IP ネットワーク エンドポイント グループ（NEG）を作成します。各 NEG 内のエンドポイントは、それぞれの Service のサービスを提供する Pod が配置されているノードです。
GKE のサブセット化は、クラスタの作成時に有効に設定できます。または、既存のクラスタを編集することで有効にすることもできます。有効にすると、GKE のサブセット化は無効にできなくなります。詳細については、GKE のサブセット化をご覧ください。
GKE のサブセット化には、以下の対象が必要です。
- GKE バージョン 1.18.19-gke.1400 以降、および
- クラスタで有効になっている
HttpLoadBalancingアドオン。このアドオンはデフォルトで有効になっています。これにより、クラスタは、バックエンド サービスを使用するロードバランサを管理できます。
GKE のサブセット化を有効にする際のノード数に関する考慮事項
内部 LoadBalancer Service を作成する必要がある場合は、GKE のサブセット化を有効にすることをおすすめします。GKE のサブセット化を使用すると、クラスタ内でより多くのノードをサポートできます。
クラスタで GKE のサブセット化が無効になっている場合は、（すべてのノードプール間で）合計 250 個を超えるノードを作成しないでください。クラスタ内に合計 250 個を超えるノードを作成すると、内部 LoadBalancer Service でトラフィックが不均一に分散される、または接続が完全に失われる可能性があります。
クラスタで GKE のサブセット化が有効になっている場合は、少なくとも 1 つのサービスを提供する Pod を持つ一意のノードの数が 250 ノードを超えない限り、
externalTrafficPolicy: LocalまたはexternalTrafficPolicy: Clusterのいずれかを使用できます。サービスを提供する Pod がないノードは関係ありません。少なくとも 1 つのサービスを提供する Pod がある 250 を超えるノードが必要な場合は、externalTrafficPolicy: Clusterを使用する必要があります。
GKE によって作成された内部パススルー ネットワーク ロードバランサは、250 個以下のバックエンド ノード VM にのみパケットを分散できます。この制限が存在するのは、GKE ではロードバランサのバックエンド サブセット化を使用せず、ロードバランサのバックエンドのサブセット化が無効になっている場合、内部パススルー ネットワーク ロードバランサではパケットの分散が 250 個以下のバックエンドに制限されているためです。
ノードのグループ化
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 には、ロードバランサのヘルスチェックが必要です。ロードバランサのヘルスチェックはクラスタの外部で実装され、readiness プローブや liveness プローブとは異なります。
Service の externalTrafficPolicy は、ロードバランサのヘルスチェックの動作を定義します。いずれの場合も、ロードバランサのヘルスチェック プローバーは、各ノードで実行されている kube-proxy ソフトウェアにパケットを送信します。ロードバランサのヘルスチェックは、kube-proxy が収集した情報（Pod が存在するかどうか、実行中である、readiness プローブに合格したなど）のプロキシです。LoadBalancer Service のヘルスチェックは、サービスを提供する Pod に転送できません。ロードバランサのヘルスチェックは、新しい TCP 接続をノードに転送するように設計されています。
次の表に、ヘルスチェックの動作を示します。
externalTrafficPolicy |
ヘルスチェックに合格するノード | 使用するポート |
|---|---|---|
Cluster |
ノードにサービスを提供する Pod がない場合でも、クラスタのすべてのノードはヘルスチェックに合格します。ノードに 1 つ以上のサービスを提供する Pod が存在する場合、サービスを提供する Pod の終了や readiness プローブの失敗があっても、対象のノードはロードバランサのヘルスチェックに合格します。 | ロードバランサのヘルスチェック ポートは TCP ポート 10256 であることが必要です。カスタマイズはできません。 |
Local |
準備が完了しており終了していない、サービスを提供する Pod が少なくとも 1 つあるノードのみが、ロードバランサのヘルスチェックに合格します。サービスを提供する Pod がないノード、サービスを提供する Pod がすべて readiness プローブに失敗したノード、サービスを提供する Pod がすべて終了しているノードは、ロードバランサのヘルスチェックに失敗します。 状態の移行中は、ノードはロードバランサの異常しきい値に達するまで、ロードバランサのヘルスチェックに合格します。移行状態は、ノード上のサービスを提供する Pod のすべてが readiness プローブに失敗し始めたとき、またはノード上のサービスを提供する Pod のすべてが終了したときに発生します。この状況でのパケットの処理方法は、GKE のバージョンによって異なります。詳細については、次のセクションのパケット処理をご覧ください。 |
カスタム ヘルスチェック ポートを指定しない限り、ヘルスチェック ポートは TCP ポート 10256 です。 |
パケット処理
以下の各セクションでは、ロードバランサとクラスタノードが連携して LoadBalancer Service で受信したパケットを転送する方法について説明します。
パススルー ロード バランシング
Google Cloud パススルー ロードバランサは、GKE クラスタのノードの nic0 インターフェースにパケットを転送します。ノードが受信するロードバランスされた各パケットには次の特性があります。
- パケットの宛先 IP アドレスがロードバランサの転送ルールの IP アドレスと一致する。
- パケットのプロトコルと宛先ポートは以下の両方と一致します。
- Service マニフェストの
spec.ports[]で指定されたプロトコルとポート - ロードバランサの転送ルールで構成されたプロトコルとポート
- Service マニフェストの
ノードでの宛先ネットワーク アドレス変換
ノードはパケットを受信した後、追加のパケット処理を実行します。GKE Dataplane V2 が有効になっていない GKE クラスタでは、ノードは iptables を使用してロードバランスされたパケットを処理します。GKE Dataplane V2 が有効になっている GKE クラスタでは、ノードは代わりに eBPF を使用します。ノードレベルのパケット処理には、常に次のアクションが含まれます。
- ノードは、パケットに対して宛先ネットワーク アドレス変換（DNAT）を実行し、サービスを提供する Pod の IP アドレスに宛先 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 ネットワーク割り当てあたりの内部パススルー ネットワーク ロードバランサの転送ルール。
- バックエンド サービスベースの外部パススルー ネットワーク ロードバランサは、次のものを使用します。プロジェクトごとのバックエンド サービスの割り当て、プロジェクトごとのヘルスチェックの割り当て、プロジェクトごとの外部パススルー ネットワーク ロードバランサ転送ルールの割り当て。
- ターゲット プールベースの外部パススルー ネットワーク ロードバランサは、プロジェクトごとのターゲット プールの割り当て、プロジェクトごとのヘルスチェックの割り当て、プロジェクトごとの外部パススルー ネットワーク ロードバランサ転送ルールの割り当てを使用します。