記事概要
「Longhorn」についての検証について。
Longhornについて
Longhorn RancherLab（2020/12あたりにSUSEによって買収）によって開発された分散ストレージプラットフォームである。
検証環境
- AKS:1.23.5
- ワーカーノード2台
PostgreSQL をLonghornで使ってみる。
helmでインストールする。
helm repo add longhorn https://charts.longhorn.io
helm repo update
helm template longhorn longhorn/longhorn --namespace longhorn-system --values helm.values.yaml > base/helm.install.yaml
ここまでドキュメント通り。
このまま生成されたhelm.install.yamlをデプロイしたところ、Podが立ち上がらず。。。
helm.install.yamlの中を見ると「longhorn-uninstall」なるJobが立ち上がっていた。
helm-templateの中を見てみると特に条件分岐で入らないようになっていない。。。
というわけでhelm.install.yamlの中から直接削除してインストール。
PostgreSQL(bitnami)をhelmからインストールしたところ、無事立ち上がった。
ここまで問題なさそう。
ここでlonghornのUIを見ておく。
Volumeの画面を見ると、1つ作られているものの、ステータスがDegradedになっていた。
これはワーカーノード構成がケチって2台にしていたが、デフォルトのレプリカ数が3になっているため、レプリカが作れないよ！と怒られていた。
UIもとてもわかりやすい。
というわけでUIからポチポチでレプリカ数を2に変更して無事Healtyになった。
ここでPersistentVolume側の状況を見てみる。
$ kc describe pv pvc-b152eb3f-812b-43bc-bdaa-9f0a5921c089
Name: pvc-b152eb3f-812b-43bc-bdaa-9f0a5921c089
Labels: <none>
Annotations: longhorn.io/volume-scheduling-error:
pv.kubernetes.io/provisioned-by: driver.longhorn.io
Finalizers: [kubernetes.io/pv-protection external-attacher/driver-longhorn-io]
StorageClass: longhorn
Status: Bound
Claim: boundary/data-boundary-postgresql-0
Reclaim Policy: Delete
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 8Gi
Node Affinity: <none>
Message:
Source:
Type: CSI (a Container Storage Interface (CSI) volume source)
Driver: driver.longhorn.io
FSType: ext4
VolumeHandle: pvc-b152eb3f-812b-43bc-bdaa-9f0a5921c089
ReadOnly: false
VolumeAttributes: dataLocality=disabled
fromBackup=
fsType=ext4
numberOfReplicas=3
staleReplicaTimeout=30
storage.kubernetes.io/csiProvisionerIdentity=1655862471036-8081-driver.longhorn.io
Events: <none>
numberOfReplicasが3のままだった。
PVの設定内容は一度作ったら変更できないからしょうがない。
longhorn-engine（データプレーン）の方で管理しているのだろう。
ストレージを作る時、Longhornでは「1.UIから静的に作成」する方法と「2.StorageClassで動的に作成」する方法がある。
「1.UIから静的に作成」の場合はボリューム作成時にポチポチ指定することになる。デフォルト値はConfigMapで管理されている。
対して「2.StorageClassで動的に作成」の場合はStorageClassのパラメーターをいじることになるのだろう。
実際に見てみる。
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
longhorn.io/last-applied-configmap: |
省略！
storageclass.kubernetes.io/is-default-class: "false"
creationTimestamp: "2022-06-22T02:00:34Z"
name: longhorn
resourceVersion: "18430789"
uid: 5736caf4-bdb9-4698-8903-e8359b8a634e
parameters:
dataLocality: disabled
fromBackup: ""
fsType: ext4
numberOfReplicas: "3"
staleReplicaTimeout: "30"
provisioner: driver.longhorn.io
reclaimPolicy: Delete
volumeBindingMode: Immediate
parametersの下に色々あるのでここで設定できる。
numberOfReplicasを4に変更してみたところ、StorageClassの設定がなんと変わらなかった。
といういわけでlonghorn-systemネームスペースへ移動してConfigMapを確認。
「longhorn-storageclass」というConfigMapがあった。
こいつで管理しているらしい。Operatorだったようだ。
変更してみたところ、無事StorageClassに反映された。
Staticにyamlから作ってみる
細かい設定を変えたいがyamlで書いてGitOpsで管理したいというパターンもあるだろう。
自分はArgoCD使いなのでまさにこのパターンでやりたい人だ。
というわけでPVをyamlから作るとどうなるのか見てみた。
結論から言うとUIからでないとできなかった。
GitOpsとは相性悪そう。
PythonクライアントSDKがあるようなのでこれを使ってOperatorを作成すると良さそう。
PythonなのでOperatorSDKはkopfを使う感じで。
とはいえ変更が必要になることなど普通に使っていればなさそうなのでStorageClassでの運用で十分だろう。
Operatorが必要なユースケースが思いつかない。
Backup
バックアップ先に選択できるのがNFSとS3のみとのこと。
少ないのでS3互換のオブジェクトストレージであるminioを経由してAzureBlob等、使っているPaaSのストレージサービスにいれるのが良いのではないだろうか。
まとめ
きれいに動くし悪くないんではないだろうか。