<p>Let's say that you wanted to create a Jenkins <code>Deployment</code>. As Jenkins uses a local XML file for configuration and state, you would want to create a <code>PersistentVolume</code> so that your data could be saved across <code>Pod</code> evictions and <code>Deployment</code> deletions. I know that the <code>Retain</code> <code>reclaimPolicy</code> will result in the data persisting on the detached <code>PersistentVolume</code>, but the documentation says this is just so that you can manually reclaim the data on it later on, and seems to say nothing about the volume being automatically reused if its mounting <code>Pod</code>s are ever brought back up.</p>

<p>It is difficult to articulate what I am even trying to ask, so forgive me if this seems like a nebulous question, but:</p>

<ul>
<li>If you delete the Jenkins deployment, then later decide to recreate it where you left off, how do you get it to re-mount <em>that exact PersistentVolume</em> on which <em>that specific XML configuration</em> is still stored?</li>
<li>Is this a case where you would want to use a <code>StatefulSet</code>? It seems like, in this case, Jenkins would be considered "stateful."</li>
<li>Is the <code>PersistentVolumeClaim</code> the basis of a volume's "identity"? In other words, is the expectation for the <code>PersistentVolumeClaim</code> to be the stable identifier by which an application can bind to a specific volume with specific data on it?</li>
</ul>

Jonathan Wilbur
<p>you can use stateful sets. scaling down deletes the pod, leaving the claims alone. Persistent volume claims can be deleted only manually, in order to release the underlying PersistentVolume</p>

<p>a scale-up can reattach the same claim along with the bound Persistent Volume and its contents to the newly created pod instance. </p>

<p>If you have accidentally scaled down a StatefulSet, you can scale up again and the new pod will have the same persisted state again. </p>
