2

Let's say that you wanted to create a Jenkins Deployment. As Jenkins uses a local XML file for configuration and state, you would want to create a PersistentVolume so that your data could be saved across Pod evictions and Deployment deletions. I know that the Retain reclaimPolicy will result in the data persisting on the detached PersistentVolume, 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 Pods are ever brought back up.

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

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

1 Answers1

2

Yes, the PersistentVolumeClaim is the workhorse here. You can evict pods, delete deployments, etc., to your heart's content and so long as you don't delete the PVC, your data will be there.

You don't need to use StatefulSet for this. From the docs:

Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

You might want that anyway, but it does nothing for keeping your PV/PVCs around.

Matthew
  • 261
  • 2
  • 5