<p>I have a pod that has both node affinity and pod affinity. could some help me understand how would things behave in such a scenario?</p>
<p>Node 1:</p>
<pre><code>   label: 
        schedule-on : gpu
</code></pre>
<p>Node 2:</p>
<pre><code>   label: 
        schedule-on : gpu
</code></pre>
<p>Node 3:</p>
<pre><code>   label: 
        schedule-on : non-gpu
</code></pre>
<p>Manifest</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
spec:
  progressDeadlineSeconds: 600
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/name: test
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:  
        app.kubernetes.io/name: test
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: schedule-on
                operator: In
                values:
                - gpu
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app.kubernetes.io/name
                operator: In
                values:
                - test
            topologyKey: schedule-on
</code></pre>
<p>the output of the above is:
Pods are getting scheduled on a different node [node1,node2]</p>
<p>ideal output: Pod needs to be scheduled on the same node [node1]</p>
<p>Here is my finding.</p>
<p>Finding 1: I believe node affinity is taking  precedence  and pod affinity is getting ignored</p>

RITESH SANJAY MAHAJAN
<p>It's the union of node affinity and pod affinity. since both the pod has the same topology key domain . hence making them in the same colocation the pods can get scheduled in different nodes but in same colocation .</p>
<p>When matching the topology key and placing the pod. Value of the key is also considered</p>
