PV TrashCan - Protection against accidental deletion of PVs or Namespaces (DoK Day EU 2022) // Veda Talakad, Aditya Kulkarni & Aditya Dani

Data on Kubernetes Community

https://go.dok.community/slack

https://dok.community/

From the DoK Day EU 2022 (https://youtu.be/Xi-h4XNd5tE)

Accidental PVC delete or namespace delete can cause the Persistent Volume to get deleted. Such volumes lose their data and the stateful applications lose their state. By the use of Persistent Volume TrashCan, users can get a grace period to undo such unintended delete operation.

The deleted Persistent Volumes are staged for delayed deletes. They continue to live even after being deleted from k8 perspective, for a configurable time(retention period) and based on the system’s usage. The storage class of the PVC can dictate if they need to be staged for a delayed delete. StorageClass can also allow for configurable retention period.

To recover a deleted PersistentVolume, users can create a new namespace with the same name and reapply the original PVC spec. The PVC will reference a special StorageClass to indicate that the new PersistentVolume needs to be restored from the TrashCan. This will allow the application to restart with the right state and data.

This talk will showcase how to overcome one of the admin’s pain point seen in field involving accidental deletions of PVCs by using advanced storage management solutions in Kubernetes.

Veda Talakad is a Software professional with BS in electronics and communications mostly working in storage domain. Some of the professional areas of interests include scalability in distributed environment and cloud-native technologies for data management,

Aditya Kulkarni: I have 10 years of experiance in Enterprise Data management. I have worked on All Flash Array at Netapp from the device driver layer to WAFL Filesystem. Next, I worked at Portworx where I developed and enhanced the number one data platform for Kubernetes. Then I moved to Pure Storage as part of Portworx acquisition.

Aditya Dani is an architect at Portworx by PureStorage, that enables users to run any cloud-native data service, in any cloud, using any Kubernetes platform. He is one of the contributors to the open source project Stork that provides storage awareness to the Kubernetes scheduler. Prior to Portworx, Aditya worked for Amazon on their Music Recommendations Engine. He enjoys working on distributed systems and loves programming in Go.