Static provisioning of PVC on EFS does not delete the data from mount path once we delete the pv and pvc.
- 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
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