Kubernetes on OpenStack with Octaviaでスケーラブルなロードバランサーを実現する

KubernetesのCloud-ProviderはOpenStackのLoadBalancerをサポートしている。v1.9からOctaviaがサポートされたので、kubesprayで構築して試した。OctaviaについてはOpenStack Octaviaの概要を参照していただきたい。

構築自体はkubesprayのmasterなどv1.9以降が使えるもので設定して、かつcloud-configファイルのLoadBalancerセクションでuse-octavia=trueとなるようにテンプレートを修正する。その後ansibleを適用したらよいのだけど、kubernetes v1.9.1だと動かない。というのも、バグでLoadBalancer作成中に叩くAPIエンドポイントが間違っていた。

すでに修正済みかつv1.9.3に修正が含まれると思われるが、今すぐためしたかったのでv1.9.1のタグからブランチを切り、修正PRをcherry-pickし、イメージをビルドして検証を継続した。gophercloudを使ってOpenStackのAPIを叩いていれば読みやすいので助かる。hyperkubeをビルドする時、デフォルトだと全OSかつ全アーキテクチャ向けにビルドするようで滅茶苦茶時間がかかるので、Kubernetes: Build Your Custom Kubelet Imageのように環境変数で指定してあげるのがよいです。それでもイメージを作るのに15分くらいはかかる(体感)ので、なんかいい方法ないものか。

検証用には microservices-demoを使っていて、front-end ServiceのtypeをLoadBalancerに変更すればよい(portsからnodePortを消すのを忘れずに)。これで、LoadBalancerが作られる。

無事LoadBalancerが作られると、以下のようにfront-end ServiceのTYPEがLoadBlancerとなり、EXTERNAL-IPにLoadBalancerが使うFloatingIPのIPアドレスが割り振られる。このアドレスにブラウザでアクセスすると、microservices-demoのショップ画面を見ることができる。

このとき、インターネットからコンテナへの経路は以下のようになるはず。

front-end Serviceの詳細も見ておこう。とはいっても特別見る点はないが。

Octaviaによって作られたLoadBalancer自体を確認しておく。名前が分かりにくい…(当然だが、各idはダミー)

このLoadBalancerや関連リソース(listener、pool、member)はKubernetes側でリソースを消すと自動的に削除されるので便利である。

なお、デフォルトではマニフェストで許可したポートについて、0.0.0.0/0からのアクセスを許可した状態となっている。要件によってはここを制限したくなることがあると思うが、これをマニフェストから設定できるのかは今後調査したい。さらには、Kubernetes on AWS: LoadBalancer型 Service との決別のように、LoadBalancerをTerraformで作成してKubernetesと繋ぐという手段も考えられるので、そちらも検証したいところである。