TCP / UDP 負荷分散の構成

概要

TCP / UDP ロードバランサを作成するには、その仕様で type: LoadBalancer を使用して Service を作成します。このページでは、LoadBalancer Service の構成に使用できるパラメータについて説明します。内部ロードバランサに固有の詳細については、内部 TCP / UDP ロードバランサの使用をご覧ください。外部ロードバランサの詳細については、サービスを使用したアプリケーションの公開をご覧ください。

Service のパラメータ

Google Kubernetes Engine(GKE)LoadBalancer Service では、次のパラメータがサポートされています。

機能 概要 サービス フィールド GKE バージョンのサポート
ローカル外部トラフィック ポリシー 外部トラフィックを GKE ノード間でロードバランサするかどうかを構成します。 spec:externalTrafficPolicy:Local GKE 1.14 以降
ロードバランサのソース範囲 特定のソース範囲のみを許可するように、GKE と VPC でオプションのファイアウォール ルールを構成します。 spec:loadBalancerSourceRanges サポートされているすべてのバージョン
ロードバランサの IP ロードバランサの IP を指定します。 spec:loadBalancerIP サポートされているすべてのバージョン
All-ports TCP / UDP ロードバランサが特定のポートではなくすべてのポートを転送する機能です なし 内部 TCP / UDP ロードバランサの場合、サブセット化でサポートされます。外部ロードバランサの場合、すべてのバージョンでサポートされます。
Network Service Tiers Google Cloud ロードバランサで使用するネットワーク階層を指定します。有効な値は StandardPremium(デフォルト)です。 metadata:annotations:cloud.google.com/network-tier GKE 1.19 以降

外部トラフィック ポリシー

externalTrafficPolicy は、GKE ノードに着信するトラフィックのロードバランサの方法と有無を定義する標準サービス オプションです。Cluster はデフォルトのポリシーですが、クラスタノードに着信するトラフィックのソース IP を保持するために Local がよく使用されます。Local は、クラスタノードのロードバランサを効果的に無効にして、ローカル Pod が受信するトラフィックに元の送信元 IP アドレスが表示されるようにします。

externalTrafficPolicy は、内部の LoadBalancer Service(TCP / UDP ロードバランサ経由)でサポートされていますが、ロードバランサの動作はトラフィックの送信元と構成されたトラフィック ポリシーによって異なります。

クラスタに Service の正常な Pod が 1 つ以上ある場合、クラスタ外からの TCP / UDP ロードバランサへのトラフィックは次のように動作します。

  • Cluster ポリシー: トラフィックはクラスタ内の正常な GKE ノードにロードバランサされ、kube-proxy がそれを Pod を持つノードに送信します。
  • Local ポリシー: バックエンド Pod を持たないノードは、TCP / UDP ロードバランサの異常状態とみなされます。トラフィックは、Pod がある残りの正常なクラスタノードの 1 つにのみ送信されます。トラフィックは kube-proxy によって再度ルーティングされることはなく、その IP ヘッダー情報がそのままの状態でローカル Pod に直接送信されます。

特定の LoadBalancer Service IP へのトラフィックがクラスタ内の GKE ノードから送信された場合、トラフィックの動作は異なります。次の表は、LoadBalancer Service のメンバー Pod を宛先とするクラスタ内のノードまたは Pod をソースとするトラフィックの動作をまとめたものです。

externalTrafficPolicy トラフィックが発生した同一のノードで実行されているサービス メンバー Pod かどうか トラフィックの動作
クラスタ はい パケットは、同じノードまたは別のノードのメンバーポッドに配信されます。
クラスタ いいえ パケットは、別のノードにあるメンバーポッドに配信されます。
ローカル はい パケットは、同じノードのメンバーポッドに配信されます。
ローカル いいえ

Kubernetes 1.14 以前: パケットはドロップされます。

Kubernetes 1.15 以降: パケットは、別のノードのメンバー Pod に配信されます。

ロードバランサのソース範囲

spec: loadBalancerSourceRanges 配列は、1 つ以上の内部または外部 IP アドレス範囲を指定します。loadBalancerSourceRanges は、ロードバランサ経由のトラフィックをこのフィールドに指定された IP に制限します。この構成では、kube-proxy が Kubernetes ノード内に対応する iptables ルールを作成します。GKE により、自動的に VPC ネットワーク内にファイアウォール ルールも作成されます。このフィールドを省略すると、Service は任意の IP アドレス(0.0.0.0/0)からのトラフィックを受け入れます。

Service の仕様の詳細については、Service API リファレンスをご覧ください。

ロードバランサの IP

spec: loadBalancerIP を使用すると、ロードバランサに特定の IP アドレスを選択できます。他の内部 TCP / UDP ロードバランサまたは Service で使用されていない IP アドレスを選択する必要があります。省略した場合、エフェメラル IP が割り当てられます。詳細については、静的内部 IP アドレスの予約をご覧ください。

spec: loadBalancerIP の IP アドレスがスタンダード ティアの IP の場合、値 Standard を含むアノテーション cloud.google.com/network-tier が必須です。Google Kubernetes Engine は、指定された IP アドレスと同じネットワーク階層を持つ転送ルールを作成する必要があるからです。Google Kubernetes Engine 1.17 以降では、転送ルール作成に使用されるデフォルトのネットワーク階層は、プロジェクトのデフォルトのネットワーク階層にかかわらず Premium になります。

All-ports

GKE バージョン 1.20.6 以降またはバージョン 1.21 以降でサービス仕様にポートが 5 つ以上ある場合、GKE コントローラは転送ルールに allPorts フィールドを自動的に設定します。この動作は、クラスタで内部 TCP / UDP ロードバランサのサブセット化を有効にしている場合、GKE バージョン 1.18 以降と 1.19 以降でも利用できます。

内部 TCP / UDP ロードバランサを手動で作成する場合は、バックエンドとして Google Kubernetes Engine ノードのインスタンス グループを選択できます。type: NodePort の Kubernetes Services は、内部 TCP / UDP ロードバランサを介して利用できます。

次のステップ