LoadBalancer Service のパラメータ

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このページでは、LoadBalancer Service の動作と構成を制御する Service マニフェストのパラメータについて説明します。このページを読む前に、Google Kubernetes Engine(GKE)LoadBalancer Service のコンセプトを理解しておく必要があります。

Service のパラメータ

GKE は、LoadBalancer Service で次のパラメータをサポートしています。

パラメータ Service フィールドと説明 内部 外部 バージョン サポート
内部 TCP / UDP ロードバランサ networking.gke.io/load-balancer-type: "Internal"

GKE に内部 TCP/UDP ロードバランサを作成するよう指示します。

詳細については、LoadBalancer Service のコンセプトをご覧ください。

サポートされているすべてのバージョン。
バックエンド サービスベースのネットワーク ロードバランサ cloud.google.com/l4-rbs: "enabled"

バックエンド サービスベースのネットワーク ロードバランサを作成するように GKE に指示します。

詳細については、LoadBalancer Service のコンセプトをご覧ください。

GKE 1.24 以降
外部トラフィック ポリシー spec.externalTrafficPolicy

ロードバランサのヘルスチェックに合格するノード VM と、クラスタ内の準備完了のサービスを提供する Pod へのパケットのルーティング方法を制御します。また、GKE サブセットが有効になっている場合に、ノードを GCE_VM_IP NEG にグループ化する方法を制御します。

詳細については、LoadBalancer Service のコンセプトをご覧ください。

GKE 1.14 以降(Windows ノードプールの場合は 1.23.4-gke.400 以降)。
ヘルスチェック ポート spec.healthCheckNodePort

LoadBalancer Service のロードバランサのヘルスチェックをデプロイします。このパラメータは、spec.externalTrafficPolicyLocal の場合にのみ関係します。

サポートされているすべてのバージョン。
ファイアウォール ルールと送信元 IP アドレスの許可リスト spec.loadBalancerSourceRanges

特定のソース範囲のみを許可するように、GKE と VPC ネットワークでオプションのファイアウォール ルールを構成します。

サポートされているすべてのバージョン。
静的 IP アドレス spec.loadBalancerIP

ロードバランサの転送ルールに割り当てられた静的 IP アドレスを指定します。

サポートされているすべてのバージョン。
Network Service Tiers metadata:annotations:cloud.google.com/network-tier

GKE が外部転送ルールと IP アドレスに使用する Network Service Tiers を指定します。アノテーションの有効な値は StandardPremium(デフォルト)です。

GKE 1.19 以降
カスタム サブネット networking.gke.io/internal-load-balancer-subnet: SUBNET_NAME

内部 TCP/UDP ロードバランサの転送ルールの IP アドレスに使用する、クラスタの VPC ネットワークとリージョン内のサブネットを指定します。

GKE 1.17 以降と 1.16.8-gke.10 以降はプレビュー。GKE 1.17.9-gke.600 以降で一般提供しています
グローバル アクセス networking.gke.io/internal-load-balancer-allow-global-access: "true"

VPC ネットワークまたは接続されたネットワークの任意のリージョンにあるクライアントが、転送ルールの IP アドレスにアクセスできるようにします。

GKE 1.16 以降はプレビュー。GKE 1.17.9-gke.600 以降では一般提供しています。
すべてのポート

アノテーションは不要ですが、GKE サブセットを有効にする必要があります。

spec.ports[].port で少なくとも 6 つ(最大 100)の一意のポートが指定されている場合、GKE はすべてのポートを使用するように自動的に転送ルールを構成します。

GKE バージョン 1.18.19-gke.1400 以降

ヘルスチェック ポート

ロードバランサのヘルスチェックと externalTrafficPolicy で説明されているように、GKE は外部ネットワーク ロードバランサまたは内部 TCP / UDP ロードバランサを作成するときに、常にロードバランサのヘルスチェックをデプロイします。

healthCheckNodePort パラメータを設定できるかどうかは、次の externalTrafficPolicy 構成によって異なります。

externalTrafficPolicy ヘルスチェック ポート
Cluster

spec.healthCheckNodePort は利用できません。

Local

spec.healthCheckNodePort を使用してカスタムポートを選択できます。指定しない場合、Kubernetes コントロール プレーンはノードポート範囲からヘルスチェック ポートを割り当てます。

ファイアウォール ルールと送信元 IP アドレスの許可リスト

LoadBalancer Service を作成すると、GKE により Service に対応する VPC ファイアウォール ルールが作成されます。各ファイアウォール ルールには、以下の特性があります。

  • ファイアウォール ルールの方向は上り(内向き)で、アクションは allow です。 Google Cloud の暗黙の上り(内向き)拒否ファイアウォール ルールでは、GKE は上り(内向き)ファイアウォール ルールの作成時に許可リストモデルを使用します。
  • GKE により、ファイアウォール ルールのプロトコルと宛先ポートは、Service の spec.ports[] リストで指定されたものに設定されます。
  • ターゲット パラメータをクラスタのすべてのノードに割り当てられたターゲットタグを設定することで、GKE によりファイアウォール ルールの宛先が設定されます。
  • Service に spec.loadBalancerSourceRanges[] が含まれている場合、GKE により、ファイアウォール ルールの送信元パラメータは、そのリスト内の IP アドレスに設定されます。Service に loadBalancerSourceRanges[] が含まれていない場合、GKE により、ファイアウォール ルールの送信元パラメータは、すべての IP アドレス (0.0.0.0/0) に設定されます。

LoadBalancer Service 用に作成されたファイアウォール ルールでは、Service のプロトコルと宛先ポートに一致するパケットを、次のすべての宛先 IP アドレスに対して許可します。

  • クラスタ内のすべての Pod の IP アドレス。
  • クラスタ内のすべてのノードの IP アドレス。
  • クラスタの LoadBalancer Service のすべての転送ルール IP アドレス。

ファイアウォール ルールによって IP アドレスの宛先が制限されることはありませんが、次の条件によりトラフィックの動作が制限されます。

  • LoadBalancer Service 用に作成された転送ルールでは、パケットが転送ルールのプロトコル、宛先 IP アドレス、ポートに一致する場合にのみパケットを転送します。
  • 有効な宛先 IP アドレスとポートの組み合わせに一致する場合を除き、ノードはパケットを拒否します。有効な送信先 IP アドレスとポートの組み合わせは次のとおりです。

    • Pod の IP アドレスと、その Pod のコンテナの containerPort
    • ノードの IP アドレスと nodePort
    • 転送ルールの IP アドレスと LoadBalancer Service の spec.ports[].port
  • ネットワーク ポリシーを使用すると、ノードでパケットを許可または拒否する方法をさらにカスタマイズできます。

共通ポートを使用する Service

クラスタに少なくとも 1 つの共通プロトコルと宛先ポートを共有する 2 つ以上の Service が含まれている場合、有効なソース範囲のセットは、そのプロトコルと宛先ポートの組み合わせを指定するすべての Service に対する loadBalancerSourceRanges のユニオンになります。これは、上り(内向き)ファイアウォール ルールの target パラメータでは、宛先 IP アドレスが VM に関連付けられたすべての IP アドレスとして定義されているためです。

2 つの LoadBalancer Service があるクラスタについて考えてみましょう。

  • 最初の Service の spec.ports[0].port は、TCP ポート 80 で、spec.loadBalancerSourceRanges=[100.10.0.0/16] です。この Service に対応するロードバランサは結果として、IP アドレス 192.0.2.2 を持ちます。
  • 2 番目の Service の spec.ports[0].port は TCP ポート 80spec.ports[1].port は TCP ポート 90 で、spec.loadBalancerSourceRanges=[172.16.0.0/24] です。この Service に対応するロードバランサは結果として、IP アドレス 198.51.100.3 を持ちます。

GKE は、クラスタの Virtual Private Cloud ネットワークに 2 つの上り(内向き)許可ファイアウォール ルールを作成します。どちらのファイアウォール ルールも、クラスタのすべてのノードをターゲットとして指定します。

  • 最初のファイアウォール ルールは、送信元 100.10.0.0/16 から TCP 宛先ポート 80 へのパケットを許可します。
  • 2 番目のファイアウォール ルールは、送信元 172.16.0.0/24 から TCP 宛先ポート 8090 へのパケットを許可します。

最初の転送ルールは、192.0.2.2:80 の宛先に一致するトラフィックをルーティングします。2 番目の転送ルールは、198.51.100.3:80198.51.100.3:90 の両方の宛先に一致するトラフィックをルーティングします。各ノードで有効な宛先は、192.0.2.2:80198.51.100.3:80198.51.100.3:90 の 3 つです。これは次のことを意味します。

  • どちらの Service も、IP アドレスの送信元範囲の組み合わせから、100.10.0.0/16 または 172.16.0.0/24 からの TCP ポート 80 へのパケットを受け入れます。
  • 2 番目の Service は、172.16.0.0/24 から TCP ポート 90 へのパケットを受け入れます。

同じプロトコルと宛先ポートの組み合わせを使用するすべてのサービスの有効な送信元範囲のセットは、そのプロトコルと宛先ポートの組み合わせを使用する少なくとも 1 つの Service で spec.loadBalancerSourceRanges が省略されると、すべての IP アドレスになります。たとえば、2 番目の Service で spec.loadBalancerSourceRanges を省略した場合、2 番目のファイアウォールの送信元は 0.0.0.0/0 になります。

  • どちらのサービスも、IP アドレスの送信元範囲の組み合わせから(100.10.0.0/16 または 0.0.0.0/0 のいずれかから)、TCP ポート 80 へのパケットを受け入れます。0.0.0.0/0 の範囲には 100.10.0.0/16 の範囲が含まれるため、TCP ポート 80 へのパケットの有効な送信元は任意の IP アドレスになります。
  • 2 番目の Service は 0.0.0.0/0(任意の IP アドレス)から TCP ポート 90 へのパケットを受け入れます。

静的 IP アドレス

静的 IP アドレスを作成し、その静的 IP アドレスをロードバランサの転送ルールに割り当てるように GKE を構成できます。これにより、LoadBalancer Service に変更を加えても、ロードバランサの IP アドレスは変わりません。このアノテーションがない場合、外部ネットワーク ロードバランサまたは内部 TCP / UDP ロードバランサの転送ルールに割り当てられる IP アドレスは、LoadBalancer Service を更新するときに変更される可能性があります。

一貫した IP アドレスを維持するには、spec.loadBalancerIP パラメータを使用して 1 つ以上の LoadBalancer Service に静的 IPv4 アドレスを指定します。

2 つ以上の LoadBalancer Service が同じ spec.loadBalancerIP を参照する場合、各 LoadBalancer Service では、次のルールに従って一意のプロトコルとポートの組み合わせを使用する必要があります。

内部 外部
転送ルール 内部 TCP/UDP ロードバランサの転送ルールは、内部 IP アドレス、プロトコル、ポートの一意の組み合わせを使用する必要があります。 外部ネットワーク ロードバランサの転送ルールは、外部 IP アドレス、プロトコル、ポート範囲の一意の組み合わせを使用する必要があります。
ポート範囲

内部 LoadBalancer Service に 6 つ以上の spec.ports[] を指定すると、GKE はすべてのポートを使用するように内部 TCP/UDP ロードバランサの転送ルールを構成します。

転送ルールですべてのポートが使用される場合、他の転送ルール(つまり、他の内部 LoadBalancer Service)が同じ IP アドレスを使用することはできません。

ポート範囲には、Service が必要とするすべてのポートが含まれますが、Service で使用されていないポート番号が含まれることもあります。

たとえば、Service マニフェストにポート 80 と 443 を指定するターゲット プールベースの外部ネットワーク ロードバランサを利用する外部 LoadBalancer Service では、ポート範囲80 ~ 443 を割り当てる転送ルールを使用する必要があります。このポート範囲により、他の外部 LoadBalancer Service が 80 から 443 までのポートを使用できなくなります。

静的 IP アドレスのリージョン 内部 TCP/UDP ロードバランサには、クラスタと同じリージョン内にリージョン内部 IPv4 アドレスが必要です。 外部ネットワーク ロードバランサには、クラスタと同じリージョン内にリージョン外部 IPv4 アドレスが必要です。
静的 IP アドレス Network Service Tiers すべての内部アドレスがプレミアム ティアであるため、構成できません。

外部ネットワーク ロードバランサの転送ルール用に予約する静的外部 IP アドレスは、Service マニフェストの metadata:annotations:cloud.google.com/network-tier アノテーションで指定された階層と同じ階層を使用する必要があります。

metadata:annotations:cloud.google.com/network-tier アノテーションが存在しない場合、外部ネットワーク ロードバランサの転送ルール用に予約した静的外部 IP アドレスは、プロジェクトのデフォルト階層(別の構成でない限りプレミアム)を使用する必要があります。

その他の静的 IP アドレス要件 内部 TCP/UDP ロードバランサの転送ルール用に予約した静的内部 IP アドレスは、SHARED_LOADBALANCER_VIP 目的を持ち、次のいずれかのサブネット IP アドレス範囲から送信されている必要があります。
  • Service マニフェストで networking.gke.io/internal-load-balancer-subnet アノテーションを使用してカスタム サブネットが指定されている場合、予約する静的内部 IP アドレスは、そのカスタム サブネットのプライマリ サブネットの IPv4 アドレス範囲から取得する必要があります。
  • Service マニフェストでカスタム サブネットが指定されていない場合、予約する静的内部 IP アドレスは、クラスタのサブネットのプライマリ サブネットの IPv4 アドレス範囲から取得する必要があります。
なし

カスタム サブネット

内部 LoadBalancer Service では、networking.gke.io/internal-load-balancer-subnet アノテーションを使用して、クラスタと同じ VPC ネットワークとリージョンに既存のサブネットを指定できます。

   metadata:annotations: networking.gke.io/internal-load-balancer-subnet: SUBNET_NAME

GKE は、指定したサブネットのプライマリ IPv4 アドレス範囲から、ロードバランサの転送ルールに内部 IPv4 アドレスを選択します。詳細については、内部 TCP / UDP ロードバランサ転送ルールをご覧ください。

ロードバランサの転送ルールを別のサブネットに作成すると、次のような場合に便利です。

  • ロードバランサの IP アドレスをノードの IP アドレス範囲から分離すると、クラスタの Service とノードに接続するクライアントに適用される下り(外向き)ファイアウォール構成に役立ちます。

  • 同じ VPC ネットワークとリージョン内の 1 つ以上のクラスタから共通の IP アドレス範囲に Service をグループ化する。

networking.gke.io/internal-load-balancer-subnet アノテーションなしで内部 LoadBalancer Service を指定すると、GKE はクラスタのサブネットのプライマリ IPv4 アドレス範囲からロードバランサの IP アドレスを選択します。ロードバランサの転送ルールとクラスタ内のノードは、同じサブネットのプライマリ IPv4 アドレス範囲を使用します。

内部ロードバランサのカスタム サブネットは、次の GKE バージョンで作成できます。

  • GKE 1.17 以降と 1.16.8-gke.10 以降のプレビュー版
  • GKE 1.17.9-gke.600 以降の一般提供

サブネットのプライマリ IPv4 アドレス範囲内に静的 IP アドレスを割り当てる方法の詳細については、静的 IP アドレスをご覧ください。

グローバル アクセス

networking.gke.io/internal-load-balancer-allow-global-access アノテーションが false であるか、内部 LoadBalancer Service で指定されていない場合、GKE は転送ルールでグローバル アクセスが無効になっている内部 TCP / UDP ロードバランサを作成します。グローバル アクセスが無効になっている場合、ロードバランサにアクセスする必要があるクライアントは、同じリージョンと VPC ネットワーク、またはクラスタの VPC ネットワークに接続されているネットワークに配置する必要があります。

内部 LoadBalancer Service の networking.gke.io/internal-load-balancer-allow-global-access アノテーションが true の場合、GKE は内部 TCP / UDP ロードバランサの転送ルールでグローバル アクセス オプションを有効にします。VPC ネットワークの任意のリージョンに配置されているクライアント、またはクラスタの VPC ネットワークに接続されているネットワーク内のクライアントは、ロードバランサにアクセスできます。

接続されているネットワーク内のクライアントへのグローバル アクセスの詳細については、以下をご覧ください。

すべてのポート転送ルール

内部 TCP / UDP ロードバランサの転送ルールは、5 つの一意のポート番号またはすべてのポートをサポートします。

GKE のサブセット化が無効になっている GKE クラスタでは、内部 LoadBalancer Service は、Service の spec.ports[].port で 5 つの一意のポートのみをサポートします。

GKE サブ設定が有効になっている GKE クラスタでは、内部 LoadBalancer Service は、Service の spec.ports[].port で最大 100 ポートまでしかサポートできません。6~100 個の一意の spec.ports[].port エントリを持つ内部 LoadBalancer Service の場合、GKE では、内部 TCP / UDP ロードバランサの転送ルールが、作成時からすべてのポートを使用するように構成されます。サービスに存在するポート数が 5 つを超えるため、GKE コントローラは転送ルールですべてのポートを有効にします。すべてのポートを使用するように転送ルールを構成する場合、GKE は、Service の spec.ports[].port に構成されている特定のポートに対してのみ、上り(内向き)許可ファイアウォール ルールを作成します。

内部 TCP / UDP ロードバランサの転送ルールと有効なポート指定の詳細については、転送ルールとポート指定をご覧ください。