Search code examples
kubernetesazure-akspersistent-volumes

Do I have to recreate already bound PersistentVolumes after reconfiguring StorageClass

I have created several PersistenVolumes through PersistentColumeClaims on the "azure-file" StorageClass in AKS. Now the mount options of the StorageClass as it is delivered by Azure didn't fit our needs, and I had to update/reconfigure it with different MountOptions.

Do I have to manually destroy bound PersistentVolumes now to force a recreation and a reconfiguration (different mount) or is the provisioner taking care of that?

What would be the best way of forcing that?

  • Delete the PersistentVolume itself?
  • Delete the Claim?
  • Delete the where the volumes are bound (I guess not)
  • Delete and recreate the whole StatefulSet?
Solution

  • @SahadatHossain is right with his answer but I would like to expand it a bit with more details and sources.

    It is important to understand the Lifecycle of a volume and claim. The interaction between PVs and PVCs follows this lifecycle:

    The Reclaiming step brings us to your actual use case:

    When a user is done with their volume, they can delete the PVC objects from the API that allows reclamation of the resource. The reclaim policy for a PersistentVolume tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled, or Deleted.

    • Retain - The Retain reclaim policy allows for manual reclamation of the resource.

    • Delete - For volume plugins that support the Delete reclaim policy, deletion removes both the PersistentVolume object from Kubernetes, as well as the associated storage asset in the external infrastructure.

    • Recycle - If supported by the underlying volume plugin, the Recycle reclaim policy performs a basic scrub (rm -rf /thevolume/*) on the volume and makes it available again for a new claim. Warning: The Recycle reclaim policy is deprecated (source). Instead, the recommended approach is to use "Delete" policy (default for dynamic provisioning) or "Retain" if your data is valuable and needs to be persisted between pod runs (see docs).

    When it comes to updating Pod specs, you can consider Updating a Deployment (if possible) with a various update strategies like for example Rolling Update:

    The Deployment updates Pods in a rolling update fashion when .spec.strategy.type==RollingUpdate. You can specify maxUnavailable and maxSurge to control the rolling update process.