<p>I know that DaemonSets ensure only one pod running in every node.
I know that ReplicaSets ensure the number of pod replicas defined are running but doesn't ensure every node gets a pod.</p>

<p>My requirement is every Node should be occupied by one POD and also I should be able to increase pod replica count! Is there any way we can achieve this?</p>

<p>If we can deploy application 2 times with different names i.e 1st time with Daemonsets and next with Replicasets! But is there any better approach? So that deployment can have a single manifest file with single name.</p>

<p>FYI, his am trying to achieve in Google Cloud- GKE.</p>

sudhir tataraju
<blockquote>
<p>My requirement is every Node should be occupied by one POD and also I should be able to increase pod replica count! Is there any way we can achieve this?</p>
</blockquote>
<p><strong>No, at the moment kubernetes doesn't provide a mechanism which would enable you to achive exactly what you want.</strong></p>
<p>Having read carefully your question I would summarize your key requirements as follows:</p>
<ol>
<li><code>Pods</code> should be scheduled <strong>on every node</strong> (as <code>Daemonset</code> does).</li>
<li>At the same time you need to be able to <strong>schedule desired number of <code>Pods</code> of a certain kind on all nodes</strong>. And of course the <strong>number of such <code>Pods</code> will be much bigger than the number of nodes</strong>. So you need to be able to schedule more than one <code>Pod</code> of a certain type on each node.</li>
<li>When one of the nodes becomes temporarily unavailable, missing <code>Pods</code> should be scheduled to the remaing nodes to be able to handle same workload.</li>
<li>When node becomes available again, <code>Pods</code> that were moved before to other nodes should be rescheduled on the newly recovered node.</li>
</ol>
<p>If you need to have more than just a one <code>Pod</code> on every node <code>Daemonset</code> definitely is not a solution you look for as it ensures that <strong>exactly one copy of a <code>Pod</code> of a certain kind is running on every node</strong>. A few different <code>Daemonsets</code> doesn't seem a good solutions either as <code>Pods</code> would be managed separately in such scenario.</p>
<p>I would also like to refer to @redzack's answer. Taking into consideration all the above requirements, <code>podAntiAffinity</code> doesn't solve this problem at all. Let's suppose you have only those 3 nodes. If you increase your <code>replicas</code> number e.g. to 6 you'll see something like below:</p>
<pre><code>NAME                           READY     STATUS    RESTARTS   AGE       IP           NODE
web-server-1287567482-5d4dz    1/1       Running   0          7m        10.192.2.3   kube-node-1
web-server-1287567482-6f7v5    1/1       Running   0          7m        10.192.4.3   kube-node-3
web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3.2   kube-node-2
web-server-1287567482-5ahfa    1/1       Pending   0          7m        &lt;none&gt;       &lt;none&gt;
web-server-1287567482-ah47s    1/1       Pending   0          7m        &lt;none&gt;       &lt;none&gt;
web-server-1287567482-ajgh7    1/1       Pending   0          7m        &lt;none&gt;       &lt;none&gt;
</code></pre>
<p>Due to <code>podAntiAffinity</code> new <code>Pods</code> won't be eligible to be scheduled on those <code>nodes</code>, on which one <code>Pod</code> of this kind is already running. Even if you change the type of <code>podAntiAffinity</code> from <code>requiredDuringSchedulingIgnoredDuringExecution</code> to <code>preferredDuringSchedulingIgnoredDuringExecution</code> it won't meet your requirement as you may end up with any scenario like: 3 pods on node1, 2 pods on node2 and 1 pod on node3 or even only 2 nodes may be used. So in such case it won't work any better than a normal deployment without any affinity/anti-affinity rules.</p>
<p>Furthermore it won't cover point <em>4</em> from the above requirements list at all. Once missing node is recovered, nothing will re-schedule to it those <code>Pods</code> that are already running on different nodes. The only solution that can guarantee that when new node appeares/re-appeares, <code>Pod</code> of a certain kind is scheduled on such node, is <code>Daemonset</code>. But it won't cover point <em>2</em> and <em>3</em>. So there is no ideal solution for your use case.</p>
<p>If someone has some better ideas how it cannot be achieved, feel free to join this thread and post your own answer but in my opinion such sulution is simply unavailable at the moment, at least not with the standard kube-scheduler.</p>
<p>If a single copy of a <code>Pod</code>, running on each node is not enough to handle your workload, I would say: simply use standard <code>Deployment</code> with desired numbers of replicas and rely on <strong>kube-scheduler</strong> to decide on which node it will be scheduled and you can be pretty sure that in most cases it will do it properly and distribute your workload evenly. Well, it won't re-destribute already running <code>Pods</code> on new/recovered node so it's not perfect but I would say for most scenarios it should work very well.</p>
