おうちkubernetes向けのストレージとしてLonghornを採用してみた経緯と感想

はじめに

kubernetesを自宅にたてて色々サービスを動かそうとすると色々なものが不足していることに気が付くと思います。

type: LoadBalancer の Service を作ることが出来ない
Ingress を作ることが出来ない
Persistent Volume Claim(PVC) を作っても dynamic provisioner が居ないので Persistent Volume を自分で作成しないといけない

他にも細かいところがあると思いますが、この辺りが目だって不便なところだと思います。
MetalLBやIngress-Nginx Controllerなどがあり、LoadBalancerやIngressは定番の解決方法があると思います。

一方でPVCをどうするかというのは環境毎に解決手段が違ったりするので定番の解決手段というものは無いのが現状だと思います。この記事では、自宅のkubernetes のストレージ関連の構成について簡単にまとめておこうかと思います。これから構築するぞ、という方の参考になれば幸いです。

自宅のkubernetesの構成とストレージ構成

前回の記事で自宅のインフラを紹介しました。
https://light-of-moe.ddo.jp/~sakura/diary/?p=1528

3台のマシン
OpenStackを構築している
それぞれのマシンにストレージがある

このような構成になっています。
この環境に3つの仮想マシンを建ててkubernetesクラスタを構築しています。

cinderのCSIドライバーを使っていて出てきた課題

CSI driverを利用することでノードにcinderのVolumeが接続され、Podから使うことが可能になります。
使い勝手としては悪くなく、これで良いかもしれないと考えていました。

ただ、cinderのVolume自体がホスト自体の物を公開している関係で、ciderのVolumeが存在しているホストとPodが動作しているホストの組み合わせが悪いと性能が出なかったりします。

以下の図のようにストレージとPodが動いているホストが同じ場合には高速で動作します。

しかし、以下の例のようにストレージがあるホストとPodが違っている場合、ネットワーク経由のiSCSIで接続してしまうため速度が出なくなってしまいます。

対策としては、node affinityを指定して、性能がでる組み合わせだけで起動させることは可能です。しかし、Podを起動するたびに構成について考えないといけなくなるので手間です。また、この方法だとストレージが読めなくなった場合にPodが起動できなくなってしまいオートヒーリングの恩恵がなくなってしまいます。

そこで、速度、性能が特に求められるサービスを構築する場合にはcinderのCSI driverを使って構築し、そうでない通常のサービスは別の手段でPersistent Volumeを構築するのが良さそうと考えてストレージサービスの検討を開始しました。

kubernetes向けのストレージの候補

kubernetesでストレージを扱うための仕組みはCSIといって仕様が定められています。
これに従っているdriverのCSI driverをインストールすることでkubernetesからストレージを操作することが可能になります。
CSI driverで比較的良く利用されていそうな以下のものを候補として検討してみることにしました。

ストレージに求めている要件

基準として定めた要件は以下のような感じです

kubernetesのクラスタが壊れてもデータの復旧が可能
3台のマシンのストレージを全て利用したい
ストレージとノードに依存関係がない
特定のノードが死んでしまうと読めなくなるストレージが出ない

候補の絞り込み

事前の調査で

TopoLVMはノードとストレージに依存関係が出来そうなので不採用
local-path-provisionerもノードに依存関係が出来るので不採用
Rook Cephは仕組みとしては良さそうなのですが、kubernetesがダウンしてしまったときに読む手段が無さそうに見えたので不採用
nfs-subdir-external-provisionerは悪くなさそう。NFSサーバをどうするのかがネックになるため不採用
- 自宅内にNASがあるのでそれを利用することは出来る、ノード自体のストレージを全く利用しないことになってしまう
- 一方でホスト3台全てのストレージを使おうとするとそれぞれにNFSサーバを建てるようなことになってしまう

ここまででOpenEBSとLonghornの2つが候補として残りました。どっちを選んでも不幸にはならなそうです。この2つから選ぼうかと思います。

結論

マニュアルを見て色々親切に書いてあるLonghornを選ぶことにしました。特にこのあたりのデータリカバリーの手段について色々書いてあるのは心強いです。
https://longhorn.io/docs/1.4.2/advanced-resources/data-recovery/

ノードのReplicaから復旧する手段やシステムが無くなってもバックアップからとりもどす手段まで書いてあります。自前のバックアップを取ったりすることは勿論実施しますが、こういう手段もあるというのは良いですね。また、管理画面のGUIがついていて便利に使えるというのも気に入りました。

Longhornで採用しているディスク構成と運用してみての感想

Longhornは、デフォルトだと /var/lib/longhorn にファイルを作っていきます。このディレクトリに専用のストレージ(cinderで作ったただのストレージ)を割り当てて構成することにしました。つまり、以下のような構成のマシンが3台ほどあることになります。

NFSへのバックアップ機能などを設定して、毎週自動バックアップを取って運用しています。以下のような画面でそういったメンテナンスの作業も自動実行することが出来ます。

kubernetesで運用しているのもあってまず落ちることは無いですし、バックアップなどもしっかり取ることが出来るので運用していて安心感があります。今のところトラブルなく運用で来ていて非常に便利に使えています。

ただ、replica数を3にしたのでディスクの利用効率はちょっと悪いです。自分の構成では700GBのストレージを3つ割り当てています。なので、以下の画面でTotalが2.16Tiになっています。しかし、実際に使える容量としては700GB相当になります、動画の配信サーバーみたいなものにするには少し容量不足かなという感じがあります。

これについては、kubernetesのクラスタとは別にNASが動作しているので、それのストレージをkubernetesから見えるようにすることで解決しようと考えています。

NASのNFSを対象としたnfs-subdir-external-provisionerを構築するのも良いかもと考えています。
Longhornのストレージのバックアップは行われているのですが、それとは別に扱いやすい形でのバックアップはあると便利なので、その領域をNFSで用意するのは1つの方法として良さそうと考えています。

まとめ

自宅で動かしているkubernetesのストレージ事情とLonghornを採用した経緯とLonghornを使った感想についてまとめてみました。

cinderの提供するストレージを直接Podで読み書きする cinder CSI driverは便利だったのですが、ノードを固定して使う都合で状況に拠っては不便な時がありました。それを解決するために複数ノードに跨ってストレージを構築するLonghornを導入しましたが、抱えていた問題を解決してくれて便利に使っています。

kubernetesのストレージ関連についてこれから検討してみる方の参考になれば幸いです。