aws / aws/containers-roadmap

Static provisioning of PVC on EFS does not delete the data from mount path once we delete the pv and pvc.

Open
#1,769 0 comments 0 reactions 0 assignees View on GitHub
EKS Proposed
Dominant language
Shell
Stars
5.4k
Forks
334
PR merge metrics
No merged PRs in 30d

Description

Hello Team,

/kind bug

What happened?
I'm using Static Provisioning and I was wondering if it is expected behavior or a bug for my files to still be in the EFS file system even after we have cleaned up our pods and PVC/PVs. This is resulting in our meter usage keep going up even though we are redeploying new pods and the old files from already deleted pods and PVs are still in the file system.

I expected the Reclaim Policy: Delete option should be worked for static provisioning to delete the files on mount point+ mount path.

I tried replicated the issue but its working for dynamic provisioning but it is not working for static provisioning.

What you expected to happen?
After we delete the PVC/PV that was being used by the pods, it should have deleted the files in the attached Filesystem

How to reproduce it (as minimally and precisely as possible)?

1) The persistentVolumeReclaimPolicy: Delete should delete the mounth path in EFS and then need to delete the PVC.

--------------------------------------------------
```
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Delete
```
--------------------------------------------------

Environment

Kubernetes version (use kubectl version): 1.20*
Driver version: latest

As per the kubernetes document, https://kubernetes.io/docs/concepts/storage/persistent-volumes/, It is working with AWS [awsElasticBlockStore](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS)

Contributor guide

Open the contributing guide

Research direction

The issue names no repository files, tests, or entry points. Start by checking Kubernetes reclaim-policy semantics for statically provisioned EFS volumes and comparing them with the dynamic-provisioning behavior described here; done means confirming whether Delete should remove the EFS mount path and documenting or addressing the expected cleanup behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, kubernetes
Domain
cloud, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.