<p>I'm trying to use Kubernetes to manage a scenario where I need to run several instances of an application (that is, several Pods). These are my requirements:</p>

<ol>
<li>When I need to scale up my application, I want to deploy one single Pod on a specific Node (not a random one).</li>
<li>When I need to scale down my application, I want to remove a specific Pod from a specific Node (not a random one).</li>
<li>When a new Pod is deployed, I want it to mount a specific PersistentVolume (not a random one) that I have manually provisioned.</li>
<li>After a Pod has been deleted, I want its PersistentVolume to be re-usable by a different Pod.</li>
</ol>

<p>So far, I used this naive solution to do all of the above: every time I needed to create a new instance of my application, I created one new Deployment (with exactly one replica) and one PersistentVolumeClaim. So for example, if I need five instances of my application, then I need five Deployments. Though, this solution is not very scalable and it doesn't exploit the full potential of Kubernetes.</p>

<p>I think it would be a lot smarter to use one single template for all the Pods, but I'm not sure whether I should use a Deployment or a Statefulset. </p>

<p>I've been experimenting with Labels and Node Affinity, and I found out that I can satisfy requirement 1, but I cannot satisfy requirement 2 this way. In order to satisfy requirement 2, <strong>would it be possible to delete a specific Pod by writing my own custom scheduler?</strong></p>

<p>I don't understand how Kubernetes decides to tie a specific PersistentVolume to a specific PersistentVolumeClaim. <strong>Is there a sort of volume scheduler? Can I customize it somehow?</strong> This way, every time a new Pod is created, I'd be able to tie it to a specific volume.</p>

<p>There may be a good reason for these requirements so I'm not going to try to convince you that it may not be a good idea to use Kubernetes for this...</p>

<p>Yes - with nodeSelector using labels, <a href="https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature" rel="nofollow noreferrer">node affinity</a>, and <a href="https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/" rel="nofollow noreferrer">anti-affinity</a> rules, pods can be scheduled on "appropriate" nodes.</p>

<p><a href="https://kubernetes.io/docs/tasks/administer-cluster/static-pod/" rel="nofollow noreferrer">Static Pods</a> may be something close to what you are looking for. I've never used static pods/bare pods on Kubernetes...they kind of don't (to quote something from the question) "...exploit the full potential of Kubernetes" ;-)</p>

<p>Otherwise, here is what I think will work with out-of-the-box constructs for the four requirements:</p>

<p>Use Deployment like you have - this will give you requirements #1 and #2. I don't believe requirement #2 (nor #1, actually) can be satisfied with StatefulSet. Neither with a <a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/" rel="nofollow noreferrer">ReplicaSet</a>.</p>

<p>Use statically provisioned PVs and <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#selector" rel="nofollow noreferrer">selector(s)</a> to (quote) "...tie a specific PersistentVolume to a specific PersistentVolumeClaim" for requirement #3.</p>

<p>Then requirement #4 will be possible - just make sure the PVs use the proper <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaim-policy" rel="nofollow noreferrer">reclaim policy</a>.</p>
