3

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?
Jürgen Zornig
  • 1,174
  • 20
  • 48

2 Answers2

3

@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.

mirekphd
  • 4,799
  • 3
  • 38
  • 59
Wytrzymały Wiktor
  • 11,492
  • 5
  • 29
  • 37
  • ok, thanks for the comprehensive clarification. According to my original question, I assume reconfiguring the StorageClass makes it mandatory to recreate all Volumes (and Pods) to make those changes active? – Jürgen Zornig Feb 24 '21 at 14:03
  • 1
    It would be better to restart the pods to make sure they got the right config. – Wytrzymały Wiktor Feb 24 '21 at 14:32
1

Basically if you delete a PVC then the state of PV will be according to it's ReclaimPolicy. PV can have three reclaim policies, named: Retain, Recycle, and Delete.
For Delete, the PV will be deleted automatically when the respected PVC is deleted. But remember a pv cannot be deleted without deleted it's bounded pvc. Also for dynamic provisioning the default policy is Delete. Again, pvc cannot be deleted if currently any pod is using it.

Now, things depends on you.

Sahadat Hossain
  • 3,583
  • 2
  • 12
  • 19
  • Yes Reclaim policy is default "Delete"... The most critical app here is Strimzi Operator/Kafka... So my strategy will be to upscale it from 3 to let's say 6 and then deleting the "old" pods one after another to downscale it afterwards back to three. So it should be possible to get three freshly mounted PVs without loss of data – Jürgen Zornig Feb 24 '21 at 10:41