The PV may be in a Terminating state and cannot be deleted when the pod are created and then the pod and pvc are quickly force deleted . about kubernetes HOT 6 OPEN

/sig storage

from kubernetes.

I think it is expected behavior. PV is not belong to any pod as long as it is bound to PVC

from kubernetes.

I think it is expected behavior. PV is not belong to any pod as long as it is bound to PVC

as the bound pv's persistentVolumeReclaimPolicy is Delete, When the PVC is deleted, the PV should be deleted successfully;

In my test, Most of the time, the PV can be deleted successfully, but occasionally the PV may remain in a terminating state and cannot be deleted.

from kubernetes.

ping @gnufied @jsafrane @jingxu97 @xing-yang Could you please take a look at this issue

from kubernetes.

Based on the log content, I carefully analyzed the code and found that the issue occurs because of a failure during the mountVolume operation. This failure causes AWS to record the VolumeMountState as VolumeNotMounted. Consequently, during the unmountVolume operation, nothing need to do as VolumeMountState is VolumeNotMounted in ASW. This results in the unmountDevice operation detecting that the volume is still in use by a pod (due to residual pod ID information in the path /var/lib/kubelet/plugins/kubernetes.io/csi/volumeDevices/pv-dc3407bc-6c3f-4123-bcf8-8f28b7575820/dev/42077f53-c1df-4b6f-8647-f06100647095), preventing the PV from being deleted.

the detail time-series is shown in the diagram

from kubernetes.

/triage accepted

from kubernetes.