<p>I have created several PersistenVolumes through PersistentColumeClaims on the &quot;azure-file&quot; 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.</p>
<p>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?</p>
<p>What would be the best way of forcing that?</p>
<ul>
<li>Delete the PersistentVolume itself?</li>
<li>Delete the Claim?</li>
<li>Delete the where the volumes are bound (I guess not)</li>
<li>Delete and recreate the whole StatefulSet?</li>
</ul>

<p>@SahadatHossain is right with his answer but I would like to expand it a bit with more details and sources.</p>
<p>It is important to understand the <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#lifecycle-of-a-volume-and-claim" rel="nofollow noreferrer">Lifecycle of a volume and claim</a>. The interaction between PVs and PVCs follows this lifecycle:</p>
<ul>
<li><p><a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#provisioning" rel="nofollow noreferrer">Provisioning</a> - which can be <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#static" rel="nofollow noreferrer">static</a> or <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic" rel="nofollow noreferrer">dynamic</a>.</p>
</li>
<li><p><a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#binding" rel="nofollow noreferrer">Binding</a></p>
</li>
<li><p><a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#using" rel="nofollow noreferrer">Using</a></p>
</li>
<li><p><a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming" rel="nofollow noreferrer">Reclaiming</a></p>
</li>
</ul>
<p>The Reclaiming step brings us to your actual use case:</p>
<blockquote>
<p>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.</p>
</blockquote>
<ul>
<li><p><a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#retain" rel="nofollow noreferrer">Retain</a> - The <code>Retain</code> reclaim policy allows for manual reclamation of the resource.</p>
</li>
<li><p><a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#delete" rel="nofollow noreferrer">Delete</a> - For volume plugins that support the <code>Delete</code> reclaim policy, deletion removes both the PersistentVolume object from Kubernetes, as well as the associated storage asset in the external infrastructure.</p>
</li>
<li><p><a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#recycle" rel="nofollow noreferrer">Recycle</a> - If supported by the underlying volume plugin, the Recycle reclaim policy performs a basic scrub (<code>rm -rf /thevolume/*</code>) on the volume and makes it available again for a new claim. <strong>Warning</strong>: The <code>Recycle</code> reclaim policy is deprecated. Instead, the recommended approach is to use dynamic provisioning.</p>
</li>
</ul>
<p>When it comes to updating Pod specs, you can consider <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment" rel="nofollow noreferrer">Updating a Deployment</a> (if possible) with a various <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy" rel="nofollow noreferrer">update strategies</a> like for example <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment" rel="nofollow noreferrer">Rolling Update</a>:</p>
<blockquote>
<p>The Deployment updates Pods in a rolling update fashion when
<code>.spec.strategy.type==RollingUpdate</code>. You can specify <code>maxUnavailable</code>
and <code>maxSurge</code> to control the rolling update process.</p>
</blockquote>
