トップ > Amazon EKS > EKS + EFS で EFSのデータを自動削除する方法

EKS + EFS で EFSのデータを自動削除する方法

Amazon EKS Amazon EFS
記事タイトルとURLをコピーする

こんにちわ！サーバーワークス日本最南端社員の久保玉井（くぼたまい）です。今日も元気にピチピチしてます！

さて今回は調べ物がありましたので、備忘録的にブログ記事を書いてみました。

もしもこの記事が誰かの参考になれば幸いです！

今回の状況

今回とある状況で以下のようなシチュエーションがありました。

EFS をEKSクラスターの永続ボリュームとして設定をしている、EKSの当該Podを削除してもEFSのデータが減らない！

図説だと以下ですね！ EKSのPodで永続ボリューム設定して、データをEFSに保存する

当該Podを削除したら、EFSの対象データも消したいが残る。

なぜに？

とりあえず調べて対処策など後ほど記載します。

参考資料はAWS公式ドキュメント

さて今回のシチュエーションですが、やはり真っ先に確認するにはAWSの公式ドキュメントでしょう。

docs.aws.amazon.com

GitHUBにて公開されているCSI インターフェイスを用いると、AWS で動作する Kubernetes クラスターが Amazon EFS ファイルシステムを管理することが可能になります。

github.com

静的プロビジョニングの場合

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リポジトリを中心に確認していきます。

github.com

だいたいこういったトラブルは、Issuesあたりに書いてそうなのでそこを中心に探していきます。

github.com

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で表彰いただきました。引き続きわかりやすいトレーニング提供できるように頑張ります！