GKE で NFS を自前で構築する

はじめに

k8s に NFS サーバーを構築する話です。
Filestore のようなマネージドなものが高価で使えない方々に読んで欲しい話です。

nfs が必要な理由

• Job 間でデータを引継ぎたい。
• オブジェクトストレージだと使いづらい。
• Read-Write-Many に扱いたい。

そこで、NFS の Pod(deployment) を構築したい。
参考にした投稿は、こちら。
NFS Persistent Volumes with Kubernetes on GKE — A Case Study

これで、ハッピー。とはなりませんでした。
なぜか。
Pod は、node や　Pod の状態により、restart される。結果、clusterIP が新しく付与される。
これは、NFS として、運用しづらい。

プラン A

Job(Pod) に pv/pvc をマウントする。
最初にトライした方法です。

job.yaml

    volumes:
    - name: nfs
      persistentVolumeClaim:
        claimName: nfs-pvc

pros

• clusterIP の定義が1回で済む。
• pv/pvc にすることで、疎結合に運用できる。

cons

• nfs-pod(deployment) が restart されたとき、 clusterIP が新しく付与されるため、pv/pvc を再作成する必要がある。
• pv がマウントされていると、マウントが解除されるまで、新しい pv を作成できない。

プラン B

Job(Pod) に NFS を volumes 直接に定義する

job.yaml

    volumes:
    - name: nfs
      nfs:
        path: /
        server: 172.24.10.24  # nfs-pod の clusterIP

pros

• Job に直接 clusterIP が付与されるため、他のリソースからロック（マウント）されない。

cons

• clusterIP を定義している Resources すべてのマニフェストを修正する必要がある。

選んだのは

プラン B
Job のマニフェストに clusterIP を定義するのは、抵抗がありますが、pv/pvc の再作成やロックを考慮すると、この方法が運用し易いためです。
argo-workflow の yaml が複数あると、それぞれの clusterIP を変更してあげないといけない。
ここは、sed で置換してあげることで、clusterIP が変更されてもOK。

まとめ

これがベストな選択ではないと思います。
聞くところによると、Read-Write-Many な PV がリリースされるという噂もあります。
今後も考察を続けたいと思います。

以上。

皆さんの参考になれば幸いです。