こんにちわ!サーバーワークス日本最南端社員の久保玉井(くぼたまい)です。今日も元気にピチピチしてます!
さて今回は調べ物がありましたので、備忘録的にブログ記事を書いてみました。
もしもこの記事が誰かの参考になれば幸いです!
今回の状況
今回とある状況で以下のようなシチュエーションがありました。
EFS をEKSクラスターの永続ボリュームとして設定をしている、EKSの当該Podを削除してもEFSのデータが減らない!
図説だと以下ですね! EKSのPodで永続ボリューム設定して、データをEFSに保存する
当該Podを削除したら、EFSの対象データも消したいが残る。
なぜに?
とりあえず調べて対処策など後ほど記載します。
参考資料はAWS公式ドキュメント
さて今回のシチュエーションですが、やはり真っ先に確認するにはAWSの公式ドキュメントでしょう。
GitHUBにて公開されているCSI インターフェイスを用いると、AWS で動作する Kubernetes クラスターが Amazon EFS ファイルシステムを管理することが可能になります。
静的プロビジョニングの場合
AWS公式ドキュメントを確認するに、EFSのデータを保持するような設定方法がいくつか見られました。
なるほど静的プロビジョニング時に「persistentVolumeReclaimPolicy: 」にてRetain指定するとデータが残るのか・・
apiVersion: v1 kind: PersistentVolume metadata: name: efs-pv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain storageClassName: efs-sc csi: driver: efs.csi.aws.com volumeHandle: fs-582a03f3
じゃぁ「persistentVolumeReclaimPolicy: 」にてDelete指定すれば良さそうだなと判断できます。
動的プロビジョニングだった
でも今回は永続ボリューム設定は動的プロビジョニングで準備でした。 動的プロビジョニングの場合、RecalimPolicyはデフォルトではDeleteになります。
$kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE efs-pv 5Gi RWO Delete Available
あれじゃぁなんでデータが残っちゃうんだろう??となりました。
調査方法
とりあえず今回の調査方法です。
- AWSドキュメントを見ながら利用する技術要素をリストアップする
- 当該箇所のマニュアルやFAQなどを確認する
こんな流れです。 今回はEKSやEFSの調査というよりも、GitHUBにて公開されているCSI インターフェイスの挙動の問題っぽいので、GitHubリポジトリを中心に確認していきます。
だいたいこういったトラブルは、Issuesあたりに書いてそうなのでそこを中心に探していきます。
Issuesで発見
しばらく確認してみると、当該内容がみつかりました。 Files not getting deleted on the EFS when PVCs & Access Points are Deleted
なるほど!EFS CSIドライバーのパラメーターを変更すれば対応できそうです。
spec: containers: - args: - --delete-access-point-root-dir=true - --endpoint=\$(CSI_ENDPOINT) - --logtostderr - --v=5
CSIドライバー側で設定すると、Pod全てに影響しちゃうのでPod内のパラメーターで変更出来ないか?とも考えたのですが、どうやら出来ない様子(´・ω・`)ショボーン
I did think of providing the option through storage class, but I couldn't find a clean way to do it since DeleteVolume does not have access to storage class parameters.
ストレージクラスのパラメーターにアクセス出来ないとの事でした。
やってみた!
ではIssuesで記載している内容で本当にできるのか試してみます。
ドライバーファイルのパラメーターを変更
まずは当該となるドライバーファイルのパラメーターを変更します。
当該Podをapplyする前の状況
とりあえずPodをApplyする前に一覧で確認します。
$kubectl get pods -o wide
CSIドライバーも読み込み済な状況ですね!
当該Podをapplyした!
動的プロビジョニングを行う当該PodをApplyして再度確認します。
$kubectl apply -f 対象Podのyamlファイル $kubectl get pods -o wide
無事に動きました!
EFS側の永続データを確認する
別で準備したEC2にてEFSの状況を確認してみます。
データがアクセスポイント経由で作成出来てますね。
当該Podをdeleteした!
EFS側にデータが作成されたのが判りました。では当該PodをDeleteして挙動がどうなるか確認しましょう!
$kubectl delete -f 対象Podのyamlファイル $kubectl get pods -o wide
無事消えました!
EFS側の永続データが消えたか確認する
別で準備したEC2にてEFSのデータが消えたか確認してみます。 ちゃんと消えてました!よかったよかった。
使い道は?
Pod削除するというシチュエーションを考慮するに、このような使い道は検証目的で利用するのに適しているでしょう。
本番環境でデータを削除するというのも運用上怖いのですものね!
テストを何度も行うにつれて、EFS側のデータが肥大化したくないという要望にはマッチするかと思います。
まとめ
以上、AWS EKSにてEFSを永続ボリュームとして指定し、Pod削除と同時にEFSデータも消し去りたいという調査内容でした。
この記事が誰かの参考になれば幸いです!
では(^^)/
参考ドキュメント
Amazon EFS CSI ドライバー
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/efs-csi.html
Files not getting deleted on the EFS when PVCs & Access Points are Deleted
https://github.com/kubernetes-sigs/aws-efs-csi-driver/issues/411
久保玉井純(執筆記事の一覧)
アプリケーションサービス部
サーバーワークス日本最南端社員。
最近、AWS Authorized Instructor Award 2022で表彰いただきました。引き続きわかりやすいトレーニング提供できるように頑張ります!