ロードバランサーの種類

各ロード・バランシング・オプションの基本的な特性を以下の表にまとめます。

VPC 用のアプリケーション・ロード・バランサー

レイヤー 7 のマルチゾーン対応の VPC 用アプリケーション・ロード・バランサー (VPC ALB) を、クラスター内のアプリに対する着信要求のための外部エントリー・ポイントとして動作するようにセットアップします。 VPC ALBのセットアップを計画する際には、以下の点に留意してください。

VPC 用アプリケーション・ロード・バランサーを Red Hat OpenShift on IBM Cloud Ingress のアプリケーション・ロード・バランサーと混同しないでください。 VPC アプリケーション・ロード・バランサー (VPC ALB) は、VPC 内のクラスターの外で実行され、ユーザーが作成する Kubernetes LoadBalancer サービスによって構成されます。 Ingress アプリケーション・ロード・バランサー (ALB) は、クラスター内部のワーカー・ノードで実行される Ingress コントローラーです。

• VPC ALB名には kube-<cluster_ID>-<kubernetes_lb_service_UID>.VPC ALB名という形式があります。 クラスター ID を確認するには、ibmcloud oc cluster get --cluster <cluster_name> を実行します。 Kubernetes LoadBalancer サービスの UID を調べるには、oc get svc myloadbalancer -o yaml を実行して出力中の metadata.uid フィールドを確認します。 VPC ALB 名の Kubernetes LoadBalancer サービス UID からハイフン（-）が削除されます。

• デフォルトでは、クラスター内のアプリ用に Kubernetes の LoadBalancer サービスを作成すると、VPC 用アプリケーション・ロード・バランサーが VPC のクラスター外部に作成されます。 この VPC ALB が、ワーカー・ノードで自動的に開かれるプライベート NodePort を介して、アプリに要求を転送します。

• パブリック Kubernetes LoadBalancer サービスを作成する場合は、VPC ALB によって Kubernetes LoadBalancer サービスに割り当てられたホスト名 (1234abcd-<region>.lb.appdomain.cloud の形式) を使用して、インターネットからアプリにアクセスできます。 ワーカー・ノードがプライベート VPC サブネットにしか接続されていなくても、VPC ALB が、パブリック要求を受け取って、アプリを公開しているサービスに転送することができます。 VPC ALB へのパブリック要求を許可するために VPC サブネットにパブリック・ゲートウェイを置く必要はないことに注意してください。 一方、アプリからパブリック URL にアクセスする必要がある場合は、ワーカー・ノードが接続される VPC サブネットにパブリック・ゲートウェイを接続する必要があります。

• プライベートの Kubernetes LoadBalancer サービスを作成する場合は、同じリージョンおよび同じ VPC のプライベート・サブネットに接続されているシステムしかアプリにアクセスできません。 プライベート VPC ネットワークに接続している場合は、VPC ALB によって Kubernetes LoadBalancer サービスに割り当てられたホスト名 (1234abcd-<region>.lb.appdomain.cloud の形式) を使用してアプリにアクセスできます。

• VPC ALBの名前を変更することで、既存のVPC ALBを別のクラスタで使用できます。

以下の図は、ユーザーが VPC ALB を介してインターネットからアプリにアクセスする方法を示しています。

1. アプリへの要求には、VPC ALB によって Kubernetes LoadBalancer サービスに割り当てられたホスト名 (1234abcd-<region>.lb.appdomain.cloud など) を使用します。
2. 要求は自動的に VPC ALB によってワーカー・ノードのノード・ポートの 1 つに転送され、さらにアプリ・ポッドのプライベート IP アドレスに転送されます。
3. 複数のアプリ・インスタンスがクラスター内の複数のワーカー・ノードにデプロイされている場合、ロード・バランサーはさまざまなワーカー・ノード上のアプリ・ポッド間で要求を転送します。 また、マルチゾーン・クラスターの場合は、VPC ALB は、クラスター内のすべてのサブネットおよびゾーンのワーカー・ノードに要求を転送します。

VPC 用のネットワーク・ロード・バランサー

VPCクラスタでは、クラスタの各ゾーンに layer-4 Network Load Balancer for VPC (VPC NLB)をクラスタの各ゾーンに設定し、アプリへの着信リクエストの外部エントリーポイントとして機能させます。

VPC NLB にはいくつかの利点があります。例えば、直接サーバー・リターン (DSR) によってスループットが高くなり、パフォーマンスが向上します。 DSR を使用すると、ワーカー・ノードは NLB をスキップして、アプリケーション応答パケットをクライアント IP アドレスに直接送信できるので、NLB が処理するトラフィックの量が減ります。 さらに、externalTrafficPolicy: Local 指定 を含めることで、すべてのクライアントリクエストにソースIPアドレスの保存を含めるようにVPC NLBを設定できます。

• 標準的なVPCのNLB名は kube-<cluster_ID>-<kubernetes_lb_service_UID> という形式です。 クラスター ID を確認するには、ibmcloud oc cluster get --cluster <cluster_name> を実行します。 Kubernetes LoadBalancer サービスの UID を調べるには、oc get svc myloadbalancer -o yaml を実行して出力中の metadata.uid フィールドを確認します。 VPC NLB 名の Kubernetes LoadBalancer サービス UID からハイフン（-）が削除されます。

• クラスターでアプリの Kubernetes LoadBalancer サービスを作成し、service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb" アノテーションを指定すると、VPC NLB が VPC のクラスター外部に作成されます。 この VPC NLB は、ワーカー・ノードで自動的に開かれるプライベート NodePort を介して、アプリに対する要求を転送します。

• パブリックの Kubernetes LoadBalancer サービスを作成する場合は、VPC NLB によって Kubernetes LoadBalancer サービスに割り当てられる外部パブリック IP アドレスを使用して、インターネットからアプリにアクセスできます。 ワーカー・ノードがプライベート VPC サブネットにしか接続されていなくても、VPC NLB が、パブリック要求を受け取って、アプリを公開しているサービスに転送することができます。 VPC NLB へのパブリック要求を許可するために VPC サブネットにパブリック・ゲートウェイを置く必要はないことに注意してください。 一方、アプリからパブリック URL にアクセスする必要がある場合は、ワーカー・ノードが接続される VPC サブネットにパブリック・ゲートウェイを接続する必要があります。

• プライベートの Kubernetes LoadBalancer サービスを作成する場合は、同じリージョンおよび同じ VPC のプライベート・サブネットに接続されているシステムしかアプリにアクセスできません。 プライベート VPC ネットワークに接続されている場合、VPC NLB によって Kubernetes LoadBalancer サービスに割り当てられる外部プライベート IP アドレスを使用してアプリにアクセスできます。

以下の図は、ユーザーが VPC NLB を介してインターネットからアプリにアクセスする方法を示しています。

1. アプリへの要求には、VPC NLB によって Kubernetes LoadBalancer サービスに割り当てられた外部 IP アドレスを使用します。
2. 要求は自動的に VPC NLB によってワーカー・ノードのノード・ポートの 1 つに転送され、さらにアプリ・ポッドのプライベート IP アドレスに転送されます。
3. アプリインスタンスがクラスタ内の複数のワーカーノードにデプロイされている場合、VPC NLBはクラスタのすべてのゾーンにわたって、さまざまなワーカーノード上のアプリポッド間でリクエストをルーティングします。

制限

以下のデフォルト設定と制限について確認してください。

• VPC ALB の既知の制限と VPC NLB の既知の制限を確認してください。
• プライベート VPC ALB は、すべてのトラフィックを受け入れるわけではなく、RFC 1918 トラフィックのみを受け入れます。
• プライベート VPC NLB を作成する専用の VPC サブネットは、クラスターと同じ VPC の同じロケーションに存在する必要がありますが、そのサブネットをクラスターやワーカー・ノードに接続することはできません。
• Red Hat OpenShift です：Kubernetes SCTP プロトコル は Kubernetes コミュニティ リリースで一般的に利用可能ですが、このプロトコルを使用するロードバランサの作成は IBM Cloud Kubernetes Service クラスタではサポートされていません。
• VPC ロード・バランサーは、作成した Kubernetes LoadBalancer サービスごとに 1 つ作成され、その Kubernetes LoadBalancer サービスにのみ要求を転送します。 VPC 内のすべての VPC クラスターで、最大 50 個の VPC ロード・バランサーを作成できます。 詳しくは、VPC の割り当て量の資料を参照してください。
• VPC ロードバランサーは、限られた数のワーカーノードにリクエストをルーティングすることができます。 リクエストをルーティングできるノードの最大数は、externalTrafficPolicy アノテーションの設定方法によって異なります。
  • ロードバランサーの設定で externalTrafficPolicy: Cluster を設定した場合：
    • VPC ロードバランサは、各ゾーンで発見された最初の 8 つのワーカーノードにルーティングします。 3つのゾーンにワーカーノードがあるクラスタの場合、ロードバランサは合計24のワーカーノードにルーティングすることになります。 シングルゾーンのクラスタでは、ロードバランサは合計8つのワーカーノードにルーティングします。 ロードバランサがルーティングするゾーンごとのワーカーノード数は service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota で変更できますが、全ゾーン合計で50を超えることはできません。 クラスタの全ゾーンのワーカーノード数が 50 未満の場合は、0 を指定してゾーン内のすべてのワーカーノードにルーティングします。 kube-proxy は、ワーカーノードからの受信トラフィックを、アプリケーションポッドが存在するノードのアプリケーションポッドにルーティングするように IP テーブルを設定します。
  • ロードバランサの設定で externalTrafficPolicy: Local を設定すると、クラスタ上のワーカーノードが50以下の場合のみVPCロードバランサが作成されます。 この制限は、VPCロードバランサープールあたり50プールメンバーというVPCクォータ制限によって設定されます。 この制限を避けるには、service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector アノテーションを使って、ロードバランサープールに入るワーカーノードを制限します。 例えば、このアノテーションを使って、受信トラフィックを特定のワーカープールに強制することができます。 このアノテーションを使用して特定のワーカープールにトラフィックを強制する場合、アプリケーションポッドも同じワーカープールで実行されるようにする必要があります。
• Kubernetes LoadBalancer サービスの構成 YAML ファイルを定義する場合、以下の注釈と設定はサポートされません。
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
  • spec.loadBalancerIP
  • spec.loadBalancerSourceRanges
  • VPC NLB のみ: service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
  • VPC ALB のみ: externalTrafficPolicy: Local 設定はサポートされますが、この設定では要求の送信元 IP が保存されません。
• VPC クラスタを削除すると、kube-<cluster_ID>-<kubernetes_lb_service_UID> 形式で命名され、Red Hat OpenShift on IBM Cloud によってそのクラスタ内の Kubernetes LoadBalancer サービス用に自動的に作成される、永続的でない VPC ロードバランサも自動的に削除されます。 ただし、一意の名前を持つ 永続ロードバランサー と、VPCに手動で作成したVPCロードバランサーは削除されません。
• VPC ロード・バランサーのホスト名には、最大 128 個のサブドメインを登録できます。 この制限は、サポート Caseを開いて、要求によって解除できます。
• VPCロードバランサーに登録するサブドメインは130文字以内に制限されています。
• VPC ALB は、Kubernetes ロードバランサーサービスが特定のノードにトラフィックを制限する service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets または service.kubernetes.io/ibm-load-balancer-cloud-provider-zone アノテーションで作成されない限り、クラスタのワーカーノードが割り当てられているのと同じ VPC サブネット上でリッスンします。
  • VPC ALB のサブネットとゾーンは、ALB の作成後に更新または変更できます。 クラスタにさらにゾーンを追加するか、service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets または service.kubernetes.io/ibm-load-balancer-cloud-provider-zone アノテーションで Kubernetes ロードバランサーサービスを更新すると、VPC ALB は新しいサブネットでリッスンするように更新されます。
• VPC NLBは単一ゾーン内の単一VPCサブネットでのみリッスンします。 複数のVPCサブネットをリッスンしたり、複数のゾーンをリッスンするように設定することはできない。 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets または service.kubernetes.io/ibm-load-balancer-cloud-provider-zone アノテーションで、NLBがリッスンする単一のサブネットを指定できます。
  • VPC NLB は、service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector または service.kubernetes.io/ibm-load-balancer-cloud-provider-zone annotations で特定のワーカーノードに受信トラフィックを制限しない限り、クラスタ内のすべてのワーカーノードに受信トラフィックを転送します。 特定のゾーンへのトラフィックを制限するには、これらのアノテーションを使って、そのゾーン内のワーカーノードを指定します。
• ロード・バランサーの NodePort 割り振りの無効化は、VPC ロード・バランサーではサポートされていません。
• VPC NLBは、同じVPC LB上でUDPとTCPの両方を設定できますが、リスニングポートは異なる必要があります。