Implementation Owner: NickrenREN@
Admin can delete a Persistent Volume (PV) that is being used by a PVC. It may result in data loss.
Postpone the PV deletion until the PV is not used by any PVC.
We can rename and reuse the PVC admission controller, let it automatically add finalizer information into newly created PV’s and PVC’s metadata.
PVC protection proposal: PVC protection
When we look for best matched PV for the PVC, if the PV has the deletionTimestamp set, we will not choose it even if the PV satisfies all the PVC’s requirement.
For pre-bound PVC/PV, if the PV has the deletionTimestamp set, we will not perform the
bind operation and keep the PVC
PV protection controller is a new internal controller.
Since we already have PV controller which is responsible for synchronizing PVs and PVCs, here in PV protection controller, we can just watch PV events.
PV protection controller watches for PV events that are processed as described below:
PV information is kept in a cache that is done inherently for an informer.
The PV queue holds PVs that need to be processed according to the below rules:
bound(synchronized by PV controller), the finalizer removal is attempted. The PV will be re-queued if the finalizer removal operation fails.
If a PV’s deletionTimestamp is set, the commands kubectl get pv and kubectl describe pv will display that the PV is in terminating state.
When we bind PV to PVC, we add finalizer for PV and remove finalizer when PV is no longer bound to a PVC.