こんにちは、藤城（@tafujish）です。前回↓の続きで「IDCFクラウド コンテナ」のロードバランサーについてです。
前回は、IDCFクラウド コンピュート上でコンテナサービスを利用するときに利用できる4つのロードバランサーを紹介しました。今回は、それぞれの設定方法や仮想マシン含めたネットワーク構成がどうなるか紹介していきます。
Service Type LoadBalancer (L4)
仮想ルーター
Service Type LoadBalancer の仮想ルーターが最も簡単に利用開始できます。ワークロードのデプロイのときに「L4 ロードバランサー 」を選ぶだけです。
デプロイすると、IDCFクラウド コンピュートの方に自動で設定されますので、コンピュートの方での操作は不要です。serviceではじまるIPアドレスが該当のものです。
ファイアウォールの設定など詳細はご利用ガイドのp.18「ロードバランサー を作成する」を参照ください。
ネットワーク構成は次のようになります。
仮想ルーターから各ノードとなる仮想マシンにバランシングされ、ノード上で動作するコンテナに直接繋がります。
インフィニットLB
Service Type LoadBalancer でもインフィニットLBを利用可能です。ただしL4としての動作のみとなります。
仮想ルーターのときと違って2ステップでの設定となります。まず、バランシング対象のワークロードをデプロイします。このとき、ポートマッピングの設定は不要です（L4 ロードバランサーを選ばないでください）。
また、「詳細オプションを表示」を開き、分散対象として指定ために利用するラベルを設定します。ここでは、keyにapp、valueにワークロード名としています。
ワークロードがデプロイできたら次にロードバランサー をデプロイします。以下のようなYamlを投入します。nginxtest-ilbという名前のロードバランサーをTCP80番で作成する例です。分散対象の設定は、selectorのところにワークロードデプロイ時に設定したラベルを入れます。ポイントは、アノテーション loadbalancer.idcfcloud.com/loadbalancer-class で ilb とすることで仮想ルーターではなく、インフィニットLBを利用します。
kind: Service
apiVersion: v1
metadata:
name: nginxtest-ilb
annotations:
loadbalancer.idcfcloud.com/loadbalancer-class: "ilb"
spec:
type: LoadBalancer
selector:
app: nginxtest
ports:
- name: http
protocol: TCP
port: 80
targetPort: 80Yamlの投入は、kubectlコマンドを利用してもよいですし、UIからも可能で、「YAMLをインポート」にて可能です。
デプロイが完了すると、インフィニットLBのコンソールに作成されています。インフィニットLBの方での操作は不要です。svcではじまるインフィニットLBが該当のものです。
ファイアウォールの設定など、詳細はご利用ガイドのp.20「ロードバランサーにILBを利用する」を参照ください。
ネットワーク構成は次のようになります。
インフィニットLBから各ノードとなる仮想マシンにバランシングされ、ノード上で動作するコンテナに直接繋がります。動きとしては、仮想ルーターと同じです。
Ingress (L7)
インフィニットLB
IDCFクラウド コンピュート上でIngressを利用する場合、基本的にはインフィニットLBを利用することとなります。使い始める前に、利用するリージョン（現状、東日本リージョン3のみ）のインフィニットLBの利用申し込みが完了していることをご確認ください。
また、インフィニットLBでSSL証明書をターミネーションする場合は、2つ事前準備があります。1つ目にインフィニットLBでSSLポリシーを作成しておくこと。2つ目にSSL証明書をシークレットに登録しておくこと。
分散先のワークロードについては、ノードポートでデプロイしておきます。
以上準備ができると、「イングレスを追加」からインフィニットLBをデプロイできます。デプロイが完了すると、ingからはじまる名前でインフィニットLBが自動で作成されます。ここまでの流れや詳細は、ご利用ガイドのp.12「http(s)でインターネットからコンテナに接続する」を参照ください。
ネットワーク構成はType LoadBalancerのときと同じで、インフィニットLBから各ノードとなる仮想マシンにバランシングされ、ノード上で動作するコンテナに直接繋がります。
NGINX Ingress
NGINX Ingressは、オンプレミスやプライベートクラウドなどロードバランサーがない構成での利用を想定し提供していますが、IDCFクラウド コンピュート上で利用することもできます。本機能はデフォルト無効に設定していますので、クラスター作成時または作成後にクラスターの「編集」から有効化できます。
「拡張オプション」の「イングレス プロバイダー」を「有効」にし、保存してください。
これで各ノードに nginx-ingress-controller が「System」プロジェクト上にデプロイされます。これで準備完了です。
分散先のワークロードについては、ノードポートでデプロイしておきます。
以上準備ができると、「イングレスを追加」からNGINX Ingressをデプロイできますが、そのままだとインフィニットLBになるので、アノテーション kubernetes.io/ingress.class に nginx と指定します。
ネットワーク構成は次のようになり、これまでの構成とは異なります。
ロードバランサーとなる NGINX Ingress は、コンテナとして稼働しています。NGINX Ingressから各コンテナへバランシングされます。ポイントは、インターネット（グローバル側）との接続は NGINX Ingress の範囲外であるということです。そのため構成にあるとおり、仮想ルーターなど従来のロードバランサーやファイアウォールといったインターネットに接続可能なマシンから NGINX Ingress が稼働するノードまで接続する必要があります。ただし、この部分はコンテナサービスの範囲外ですので、コンピュートサービス側での操作が必要となります。
まとめ
前回と今回で見てきたとおり、基本は Service Type LoadBalancer であれば仮想ルーターを、IngressであればインフィニットLBをご利用いただくのが性能や操作上適していると思います。構成やコストなど要件次第では他の選択肢もあり得ますが、まずはこの2つで検討し始めてみてください。
