クラシック: ネットワーク・ロード・バランサー (NLB) について
ネットワーク・ロード・バランサーは、クラシック・クラスターでのみ作成できます。 VPC クラスターでロード・バランシングを行うには、VPC ロード・バランサーを使用したアプリの公開を参照してください。
標準クラスターを作成すると、IBM Cloud® Kubernetes Service は、ポータブル・パブリック・サブネットとポータブル・プライベート・サブネットを自動的にプロビジョンします。
- ポータブル・パブリック・サブネットでは、5 つの IP アドレスを使用できます。ポータブル・パブリック IP アドレスの 1 つは、デフォルトのパブリック Ingress ALB に使用されます。 残りの 4 つのポータブル・パブリック IP アドレスは、パブリック・ネットワーク・ロード・バランサー・サービス (NLB) を作成して単一アプリをインターネットに公開するために使用できます。
- ポータブル プライベート サブネットは、使用可能な IP アドレスを 5 つ提供します。 1 つのポータブル プライベート IP アドレスは、デフォルトのプライベート Ingress ALB によって使用されます。 残りの 4 つのポータブル・プライベート IP アドレスは、プライベート・ロード・バランサー・サービス (NLB) を作成して単一アプリをプライベート・ネットワークに公開するために使用できます。
ポータブル・パブリック IP アドレスでもポータブル・プライベート IP アドレスでもアプリにアクセスできるようにするには、パブリック NLB とプライベート NLB の両方を作成する必要があります。 ポータブル・パブリック IP アドレスとポータブル・プライベート IP アドレスは静的浮動 IP であり、ワーカー・ノードが削除されても変わりません。 NLB IPアドレスが割り当てられているワーカーノードが削除された場合、IPを常時監視しているKeepaliveデーモンが自動的にIPを別のワーカーノードに移動させます。
任意のポートを NLB に割り当てることができます。 NLB は、アプリに対する着信要求のための外部エントリー・ポイントとして機能します。 インターネットから NLB にアクセスするには、NLB のパブリック IP アドレスと割り当てられたポートを、<IP_address>:<port> という形式で使用します。 また、サブドメインとともに NLB IP アドレスと登録して NLB の DNS エントリーを作成することもできます。
NLB サービスを使用してアプリを公開した場合、自動的にそのアプリはサービスの NodePort 経由でも使用できるようになります。 NodePort には、クラスター内のすべてのワーカー・ノードのすべてのパブリック IP アドレスおよびプライベート IP アドレスでアクセスできます。 NLB を使用しつつ、NodePort へのトラフィックをブロックするには、ロード・バランサー・サービスまたはノード・ポート・サービスへのインバウンド・トラフィックの制御を参照してください。
Kubernetes SCTP プロトコル は Kubernetes コミュニティー・リリースで一般出荷可能ですが、このプロトコルを使用するロード・バランサーの作成は、 IBM Cloud Kubernetes Service クラスターではサポートされていません。
バージョン 1.0 と 2.0 の NLB での基本ロード・バランシングと DSR ロード・バランシングの比較
NLB の作成時に、基本ロード・バランシングを実行するバージョン 1.0 NLB、または直接サーバー・リターン (DSR) ロード・バランシングを実行するバージョン 2.0 NLB を選択できます。
- 1.0 と 2.0 のNLBはどのように似ているのでしょうか？
- バージョン 1.0 と 2.0 の NLB はどちらもレイヤー 4 のロード・バランサーであり、Linux カーネル・スペースにあります。 どちらのバージョンもクラスター内で実行され、ワーカー・ノードのリソースを使用します。 したがって、NLB の対応能力は常にお客様のクラスターにのみ使用されます。 また、どちらのバージョンの NLB も接続を終了しません。 代わりに、アプリ・ポッドに接続を転送します。
- 1.0 と 2.0 のNLBはどのように異なるのですか？
- クライアントがアプリに要求を送信すると、NLB は、アプリ・ポッドが存在するワーカー・ノードの IP アドレスに要求パケットをルーティングします。 バージョン 1.0 の NLB は、ネットワーク・アドレス変換 (NAT) を使用して、要求パケットのソース IP アドレスを、ロード・バランサー・ポッドが存在するワーカー・ノードの IP に書き換えます。 ワーカー・ノードは、アプリの応答パケットを返すときに、その NLB が存在するワーカー・ノードの IP を使用します。 そして、NLB がクライアントに応答パケットを送信します。 IP アドレスの書き換えを回避するには、ソース IP 保持を有効にします。 ただし、ソース IP 保持を利用するには、要求を別のワーカーに転送しなくてもよいように、ロード・バランサー・ポッドとアプリ・ポッドを同じワーカー上で実行する必要があります。 ノードのアフィニティーと耐障害性をアプリ・ポッドに追加する必要があります。 バージョン 1.0 NLB を使用した基本ロード・バランシングについて詳しくは、NLB 1.0 のコンポーネントおよびアーキテクチャーを参照してください。
バージョン 1.0 の NLB とは異なり、バージョン 2.0 の NLB は、他のワーカー上のアプリ・ポッドに要求を転送する際に NAT を使用しません。 NLB 2.0 は、クライアント要求をルーティングするときに、IP over IP (IPIP) を使用して、元の要求パケットを別のパケットに入れてカプセル化します。 このカプセル化された IPIP パケットには、ロード・バランサー・ポッドが存在するワーカー・ノードのソース IP が含まれているので、元の要求パケットはクライアント IP をそのソース IP アドレスとして保持できます。 そして、ワーカー・ノードは、直接サーバー・リターン (DSR) を使用して、アプリの応答パケットをクライアント IP に送信します。 応答パケットは NLB をスキップしてクライアントに直接送信されるので、NLB が処理する必要のあるトラフィックの量が減少します。 バージョン 2.0 NLB を使用した DSR ロード・バランシングについて詳しくは、NLB 2.0 のコンポーネントおよびアーキテクチャーを参照してください。
NLB 1.0 のコンポーネントおよびアーキテクチャー
TCP/UDP ネットワーク・ロード・バランサー (NLB) 1.0 は、Linux カーネルの機能である Iptables を使用して、アプリのポッド間で要求の負荷分散を行います。
単一ゾーン・クラスター内のトラフィック・フロー
次の図は、NLB 1.0 がインターネットから単一ゾーン・クラスター内のアプリに通信を転送する方法を示しています。
-
アプリに対する要求では、NLB のパブリック IP アドレスとワーカー・ノードに割り当てられたポートを使用します。 NLB 用に DNS サブドメインを作成すると、お客様のユーザーは代わりに NLB のサブドメインを介してアプリにアクセスできるようになることに注意してください。 DNS システム・サービスが、サブドメインを NLB のポータブル・パブリック IP アドレスに解決します。
-
NLB は要求を受け取り、それをプライベート・ネットワークを介してアプリ・ポッドのプライベート IP アドレスに転送します。 要求パッケージのソース IP アドレスが、NLB ポッドが実行されるワーカー・ノードのパブリック IP アドレスに変更されます。 複数のアプリ・インスタンスがクラスターにデプロイされている場合、NLB は、アプリ・ポッド間で要求をルーティングします。
-
アプリが応答パケットを返す際には、クライアント要求を転送した NLB が存在するワーカー・ノードの IP アドレスが使用されます。 そして、NLB がクライアントに応答パケットを送信します。
複数ゾーン・クラスター内のトラフィック・フロー
次の図は、ネットワーク・ロード・バランサー (NLB) 1.0 がインターネットから複数ゾーン・クラスターのアプリに通信を転送する方法を示しています。
-
アプリに対する要求では、NLB 用に DNS サブドメインを使用します。 ワーカー・ノード上のパブリック IP アドレスとポートを使用して、各ゾーン内の NLB にアクセスすることもできます。 デフォルトでは、各 NLB 1.0 が 1 つのゾーンにのみセットアップされることに注意してください。 高可用性を確保するには、アプリ・インスタンスが存在するすべてのゾーンに NLB 1.0 をデプロイする必要があります。
-
DNS システム・サービスが、サブドメインを、NLB の 1 つに属するポータブル・パブリック IP アドレスと、ワーカー・ノードに割り当てられたポートに解決します。 ラウンドロビン・サイクルでさまざまなゾーンの NLB が要求を処理します。
-
NLB は要求を受け取り、それをプライベート・ネットワークを介してアプリ・ポッドのプライベート IP アドレスに転送します。 要求パッケージのソース IP アドレスが、NLB ポッドが実行されるワーカー・ノードのパブリック IP アドレスに変更されます。 各 NLB は、デプロイ先のゾーンのアプリ・インスタンスへの要求と、他のゾーンのアプリ・インスタンスへの要求を転送します。 さらに、複数のアプリ・インスタンスが 1 つのゾーンにデプロイされている場合、NLB はそのゾーン内のアプリ・ポッド間で要求をルーティングします。
-
アプリが応答パケットを返す際には、クライアント要求を転送した NLB が存在するワーカー・ノードの IP アドレスが使用されます。 そして、NLB がクライアントに応答パケットを送信します。
NLB 2.0 のコンポーネントおよびアーキテクチャー
NLB 2.0 はレイヤー 4 のロード・バランサーであり、Linux カーネルの IP Virtual Server (IPVS) を使用します。 NLB 2.0 は TCP と UDP をサポートし、複数のワーカー・ノードの前で実行され、IP over IP (IPIP) トンネリングを使用して、単一の NLB IP アドレスに到着するトラフィックをそれらのワーカー・ノードに分散させます。
単一ゾーン・クラスター内のトラフィック・フロー
次の図は、NLB 2.0 がインターネットから単一ゾーン・クラスターのアプリに通信を転送する方法を示しています。
-
アプリへのクライアント要求には、NLB のパブリック IP アドレスと、ワーカー・ノードに割り当てられたポートが使用されます。 この例では、NLB の仮想 IP アドレスは 169.61.23.130 であり、プライベート IP アドレスが 10.73.13.25 のワーカー・ノード上で NLB は実行されます。 NLB 用に DNS サブドメインを作成すると、お客様のユーザーは代わりに NLB のサブドメインを介してアプリにアクセスできるようになることに注意してください。 DNS システム・サービスが、サブドメインを NLB のポータブル・パブリック IP アドレスに解決します。
-
NLB が、クライアント要求パケット (図中の「CR」ラベルが付いたもの) を IPIP パケット (「IPIP」ラベルのもの) の中にカプセル化します。 クライアント要求パケットは、そのソース IP アドレスとしてクライアント IP を保持します。 IPIP カプセル化パケットは、そのソース IP アドレスとしてワーカー・ノードの 10.73.14.25 IP を使用します。
-
アプリ・ポッドが存在するプライベート IP アドレス 10.73.13.26 のワーカーに、NLB が IPIP パケットを転送します。 複数のアプリ・インスタンスがクラスターにデプロイされている場合、NLB はアプリ・ポッドがデプロイされているワーカー間で要求をルーティングします。
-
ワーカー 10.73.14.26 が、IPIP カプセル化パケットをアンパックしてから、クライアント要求パケットをアンパックします。 そのワーカー・ノード上のアプリ・ポッドにクライアント要求パケットが転送されます。
-
次に、ワーカー 10.73.14.26 は、元の要求パケットのソース IP アドレス (クライアント IP) を使用して、アプリ・ポッドの応答パケットをクライアントに直接返します。
複数ゾーン・クラスター内のトラフィック・フロー
次の図は、各ゾーンに存在するバージョン 2.0 の NLB が、インターネットから複数ゾーン・クラスターのアプリにトラフィックを転送する方法を示しています。
-
アプリに対する要求では、NLB 用に DNS サブドメインを使用します。 ワーカー・ノード上のパブリック IP アドレスとポートを使用して、各ゾーン内の NLB にアクセスすることもできます。 デフォルトでは、各 NLB 2.0 が 1 つのゾーンにのみセットアップされることに注意してください。 高可用性を確保するには、アプリ・インスタンスが存在するすべてのゾーンに NLB 2.0 をデプロイする必要があります。
-
DNS システム・サービスが、サブドメインを、NLB の 1 つに属するポータブル・パブリック IP アドレスと、ワーカー・ノードに割り当てられたポートに解決します。 この例では、NLB の仮想 IP アドレスは 169.61.23.130 であり、プライベート IP アドレスが 10.73.13.25 のワーカー・ノード上で NLB は実行されます。 ラウンドロビン・サイクルでさまざまなゾーンの NLB が要求を処理します。
-
NLB が、クライアント要求パケット (図中の「CR」ラベルが付いたもの) を IPIP パケット (「IPIP」ラベルのもの) の中にカプセル化します。 クライアント要求パケットは、そのソース IP アドレスとしてクライアント IP を保持します。 IPIP カプセル化パケットは、そのソース IP アドレスとしてワーカーの 10.73.14.25 IP を使用します。
-
アプリ・ポッドが存在するプライベート IP アドレス 10.73.13.26 のワーカーに、NLB が IPIP パケットを転送します。 各 NLB は、デプロイ先のゾーンのアプリ・インスタンスへの要求と、他のゾーンのアプリ・インスタンスへの要求をルーティングすることに注意してください。 さらに、複数のアプリ・インスタンスが 1 つのゾーンにデプロイされている場合、NLB はそのゾーン内のアプリ・ポッド間で要求をルーティングします。
-
ワーカー 10.73.14.26 が、IPIP カプセル化パケットをアンパックしてから、クライアント要求パケットをアンパックします。 そのワーカー・ノード上のアプリ・ポッドにクライアント要求パケットが転送されます。
-
次に、ワーカー 10.73.14.26 は、元の要求パケットのソース IP アドレス (クライアント IP) を使用して、アプリ・ポッドの応答パケットをクライアントに直接返します。