<p>I have 3 nodes, each of them labeled like following:</p>

<ul>
<li>node-0 -> mongo-volume=volume-0</li>
<li>node-1 -> mongo-volume=volume-1</li>
<li>node-2 -> mongo-volume=volume-2</li>
</ul>

<p>I'm looking for a way to schedule the replicas of a statefulset on a special node.</p>

<p>I first used the hard way with requiredDuringSchedulingIgnoredDuringExecution and everything works well. </p>

<p>Then I wanted to test the soft way by using preferredDuringSchedulingIgnoredDuringExecution. </p>

<p>I first tell to my statefulset to have a preference for the node having the label <strong>volume-0</strong>, no problems the pods were all deployed on the <strong>node-0</strong>. </p>

<p>Then I changed the preference for the node having the label <strong>volume-1</strong>. And there is my problem, the pods were deployed on the <strong>node-0</strong> and <strong>node-2</strong> but node on the <strong>node-1</strong>.</p>

<p>I did the same with the label volume-2 and it works well again, the pods were all deployed on the <strong>node-2</strong>. </p>

<p>Node Affinity configuration:</p>

<pre><code>affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      preference:
        matchExpressions:
        - key: mongo-volume
          operator: In
          values:
          - volume-1  
</code></pre>

<p>When I looked for the resource usage of the nodes, I noticed that the node-1 had a bit more load than the others. Could it explain why the sheduler refuses to deploy the pods on this node ? </p>

<pre><code>NAME    CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node-0   63m          6%     795Mi           41%
node-1   116m         11%    978Mi           51%
node-2   78m          7%     752Mi           39%
</code></pre>

<p>I'm wondering why it works for the node-0 and the node-2 but not for the node-1. And if there is a possible way to fix it.</p>

LaurentP22
<p>Affinity policy is <strong>prefer</strong> to run on this node, not <strong>select directly</strong> the node.</p>
<p>The weight of your affinity is the priority of your affinity policies. For example:</p>
<pre class="lang-sh prettyprint-override"><code>podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: k1
          operator: In
          values:
          - &quot;v1&quot;
      topologyKey: kubernetes.io/hostname
  - weight: 30
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: k2
          operator: In
          values:
          - &quot;v2&quot;
      topologyKey: kubernetes.io/hostname
</code></pre>
<p><a href="https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/" rel="nofollow noreferrer">K8s scheduler</a> doc says:</p>
<blockquote>
<p>kube-scheduler selects a node for the pod in a 2-step operation:</p>
<ol>
<li><p>Filtering</p>
</li>
<li><p>Scoring</p>
</li>
</ol>
<p>The filtering step finds the set of Nodes where it’s feasible to schedule the Pod. For example, the PodFitsResources filter checks whether a candidate Node has enough available resource to meet a Pod’s specific resource requests. After this step, the node list contains any suitable Nodes; often, there will be more than one. If the list is empty, that Pod isn’t (yet) schedulable.</p>
<p>In the scoring step, the scheduler ranks the remaining nodes to choose the most suitable Pod placement. The scheduler assigns a score to each Node that survived filtering, basing this score on the active scoring rules.</p>
<p>Finally, kube-scheduler assigns the Pod to the Node with the highest ranking. If there is more than one node with equal scores, kube-scheduler selects one of these at random</p>
</blockquote>
<p>Affinity is part of the consideration but not all.</p>
