このページでは、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 が少ないノードと比較して、新しい接続の割合を増やすことができます。
図に示すように、重み付けロード バランシングが有効になっている 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 のサブセット化が有効になっています。各サービスには 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 アドレスから常に同じバックエンドにトラフィックを送信するためです。トラフィック量が多いクライアントが少数の場合、一部のバックエンドが過負荷になり、他のバックエンドが十分に使用されない可能性があります。
詳細については、セッション アフィニティのオプションをご覧ください。
ノードのグループ化
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 コントロール プレーンがノードポートの範囲からヘルスチェック ポートを割り当てます。 |
重み付きロード バランシングが有効になっている場合、kube-proxy または cilium-agent ソフトウェアは、ロードバランサのヘルスチェックへの応答にレスポンス ヘッダーを含めます。このレスポンス ヘッダーは、ノード上の準備完了状態でサービスを提供している Pod の数に比例する重みを定義します。ロードバランサは、この重みに基づき、サービスを提供する Pod に新しい接続を転送します。
パケット処理
以下の各セクションでは、ロードバランサとクラスタノードが連携して 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 は、ノードレベルのパケット処理が、送信元ネットワーク アドレス変換（SNAT）と、パケットがノードから Pod へたどるパスを実行するかどうかも決定します。
externalTrafficPolicy |
ノードの SNAT の動作 | 転送の動作 |
|---|---|---|
Cluster |
GKE Dataplane V2 が有効になっていない GKE クラスタでは、ノードはロードバランスされたパケットの送信元 IP アドレスを変更して、ロードバランサから受信したノードの IP アドレスと一致させます。 GKE Dataplane V2 を使用する GKE クラスタでは、ノードは、同じノード上のサービスを提供する Pod にトラフィックを転送するときに、ロードバランスされたパケットの送信元 IP アドレスを変更しません。ただし、トラフィックが別のノード上の Pod に転送される場合は、SNAT が実行されます。 |
ノードは、サービスを提供する任意の 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 Service について学習する。