<p>we would like to merge 2 kubernetes cluster because we need to establish a communication between the pods and it should also be cheaper.</p>
<p>Cluster 1 should stay intact and cluster 2 will be deleted. The pods in cluster 2 have very high requirements for resources and we would like to create node pool dedicated to these pods.</p>
<p>So the idea is to label the new nodes and also label the pods that were part of cluster 2 before to enforce that they run on these nodes.</p>
<p>What I cannot find an answer for is the following question: How can I ensure that no other pod is scheduled to run on the new node pool without having to redeploy all pods and assigning labels to them?</p>

SebastianStehle
<p>There are 2 problems you have to solve:</p>
<ol>
<li>Stop cluster 1 pods from running on cluster 2 nodes</li>
<li>Stop cluster 2 pods from running on cluster 1 nodes</li>
</ol>
<p>Given your question, it looks like you can make changes to cluster 2 deployments, but don't want to update existing cluster 1 deployments.</p>
<p>The solution to problem 1 is to use <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/" rel="nofollow noreferrer">taints and tolerations</a>. You can taint your cluster 2 nodes to stop all pods from being scheduled there then add tolerations to your cluster 2 deployments to allow them to ignore this taint. This means that cluster 1 pods cannot be deployed to cluster 2 nodes and problem 1 is solved.</p>
<p>You add a taint like this:</p>
<pre class="lang-sh prettyprint-override"><code>kubectl taint nodes node1 key1=value1:NoSchedule-
</code></pre>
<p>and tolerate it in your cluster 2 pod/deployment spec like this:</p>
<pre class="lang-yaml prettyprint-override"><code>tolerations:
- key: &quot;key1&quot;
  operator: &quot;Equal&quot;
  value: &quot;value1&quot;
  effect: &quot;NoSchedule&quot;
</code></pre>
<p>Problem 2 cannot be solved the same way because you don't want to change deployments for cluster 1 pods. This is a shame because taints are the easiest solution to this. If you could make that change, then you'd simply add a taint to cluster 1 nodes and tolerate it only in cluster 1 deployments.</p>
<p>Given these constraints, the solution is to use <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity" rel="nofollow noreferrer">node affinity</a>. You'd need to use the <code>requiredDuringSchedulingIgnoredDuringExecution</code> form to ensure that the rules are always followed. The rules themselves can be as simple as a node selector based on labels. A shorter version of the example from the linked docs:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: a-node-label-key
            operator: In
            values:
            - a-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0
</code></pre>
