こんにちは、藤城（@tafujish）です。今回も「IDCFクラウド コンテナ」サービスについてです。
www.idcf.jp
IDCFクラウドでは、無料のロードバランサー （仮想ルーター）と高性能・高機能のインフィニットLBがあります。これらは、IDCFクラウド コンテナと連携しています。一方で、KubernetesとしてはService Type LoadBalancerやIngressといった実装があります。これらがどのように連携して、どのような用途でどのロードバランサーを選択するのがよいか紹介します。
Kubernetesにおけるロードバランサー
Kubernetesにおいて、ロードバランサーはService Type LoadBalancerとして抽象化されています。Service Type LoadBalancerとしては、ポート番号を指定してバランシングしますので、レイヤー4（以下L4）のロードバランサー として利用できます。
一方で、SSLターミネーション（終端）やパスパターン（名前）によるバランシングといったレイヤー7（以下L7）のロードバランサーは、Ingressとして抽象化されています。ちなみに、ロードバランサー含めたIngress対応の実装がIngressコントローラーです。OSSとしては、NGINX Ingress Controllerがあります。
以上から、L4のロードバランサー として利用するならService Type LoadBalancer、L7のロードバランサーとして利用するならIngressとなります。IDCFクラウド コンテナでは、両方利用することが可能です。
IDCFクラウドで利用するロードバランサーの選び方
ここでは、IDCFクラウド コンテナ for IDCFクラウド（IDCFクラウド コンピュートサービスにKubernetesクラスターを作成する）における、ロードバランサーの選択肢とどのように選択するかを紹介します。まとめると次の表のようになります。
| 対応 | Kubernetes側 | IDCFクラウド側 | 特徴 |
| L4 | Service Type LoadBalancer | 仮想ルーター | 無料のロードバランサーをコンテナサービスでも同様に利用可能で、3240GBの転送量無料分も付きます。UIから直接設定可能で簡単に使い始められます。 |
| L4 | Service Type LoadBalancer | インフィニットLB | 仮想ルーターを超える処理性能が必要な場合は、インフィニットLBに置き換えることも可能です。 |
| L7 | Ingress | インフィニットLB | SSLターミネーションやパスパターンによるバランシングなどの高機能と、オートスケールする処理性能を持ちます。UIから直接設定可能で簡単に使い始められます。 |
| L7 | Ingress | NGINX Ingress | どこのインフラ上でも動作可能なロードバランサーとして提供しています。ご利用のKubernetesクラスター上で動作するためロードバランサーを使うための追加費用は不要です。IDCFクラウド上の利用においても、複数の証明書によるSSLターミネーションなどといったインフィニットLBのコストインパクトが大きくなる場合は選択の候補となります。 |
4つ選択肢はありますが、よく使うものは2つです。
1つは、簡単にはじめられて低コストで利用できるService Type LoadBalancerの仮想ルーター。
もう1つは、高性能や高機能を必要とする場合にIngressのインフィニットLB。
Service Type LoadBalancerとしては、高性能を目的にインフィニットLBも選べますが、Ingressから利用する方がUIの操作性や今後の拡張を考えると良いです。Kubernetesクラスターの内部で更にバランシングするといった構成の場合は、シンプルな構成を組めるのでService Type LoadBalancerでインフィニットLBを使うケースもあります。
Ingressとしては、NGINX Ingressも選べますが、IDCFクラウドで利用する場合はインフィニットLBがより便利です。コスト的な問題があり、スケール性が必要ない場合は利用するケースもあります。
まとめ
以上のように、IDCFクラウド コンテナ for IDCFクラウド におけるロードバランサーは、バランシングの要件（レイヤー）と、性能/費用の観点にて4つのパターンから選べます。次回は、実際の設定方法や仮想マシン含めたネットワーク構成がどうなるか詳細を紹介します。
