<p>we have an aks cluster and having one system nodepool and 2 user nodepools (usnp1&amp;usnp2) currently. We have multiple applications pods currently running across the usernodepools.</p>
<p>So now we have a requirement to run one of our existing application pods to dedicately have a seperate nodepool and namespace seperately. Example, our application myapp is currently running in namespace &quot;all-app-ns&quot; which has nodeselector set &quot;usnp1&quot;, and in the same pool we have other application pods also. So need to move the myapp pods and all related components completely to new namespace specifically for &quot;myapp-ns&quot; and it should be allocated only specific to &quot;myapp-pool&quot;</p>
<ol>
<li><p>The myapp-pool&quot; should not allocate any other pods than the myapp. Which option will be more precedence here - node selector with pods or taints? i read like nodeselector will force the scheduler &quot;should assign&quot; to specic node, where taint will do &quot;can assign&quot;.. so nodeselector will be better option?</p>
</li>
<li><p>since myapp deployment and pods are already running currently in &quot;all-app-ns&quot;, whether moving those to new namespace &quot;myapp-ns&quot;,  will these delete existing myapp pods in the namespace -all-app-ns&quot;? will this make any downtime? currentlt we deployed this using helm chart and will the helmstate will delete the old pods and create the newpods, and any downtime will happen ?</p>
</li>
</ol>

Vowneee
<ol>
<li>
<blockquote>
<p>... so nodeselector will be a better option?</p>
</blockquote>
</li>
</ol>
<p>You could use nodeSelector but also nodeAffinity. It is just a matter of configuration. The nodeSelector strictly define that the Pod with e.g</p>
<pre><code>nodeSelector:
   usnp1: &quot;true&quot;
</code></pre>
<p>could only be deployed to node with label <code>usnp1=true</code>.
But you could define same with nodeAffinity in Pod configuration e.g</p>
<pre><code>kind: Pod
metadata:
  name: &lt;your-pod-name&gt;
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: usnp1
            operator: In
            values:
            - &quot;true&quot;
</code></pre>
<p>Those configurations are equal.</p>
<ol start="2">
<li>
<blockquote>
<p>... and any downtime will happen?</p>
</blockquote>
</li>
</ol>
<p>If I understand clearly, you need to move <code>myapp pods</code> which are currently deployed in <code>all-app-ns</code> to <code>myapp-ns</code>. So in this scenario, if you are deploying to the different namespace in your case <code>myapp-ns</code>, the pods in <code>all-app-ns</code> will not be undeployed. I suppose, because in <code>helm install</code> you need to define the <code>--namespace</code> option if you are not already switched with <code>kubectl set-context</code>. So to undeploy you have to <code>helm uninstall &lt;RELEASE&gt; --namespace=all-app-ns</code>. The availability of the application depends on your DNS records, so you will probably need to configure them if you need to expose the app publicly.</p>
<hr />
<p>To answer your questions bellow:</p>
<blockquote>
<p>so for point1. if we have any pods without any nodeselector defined,
there will be chance to allocate that pods to the new nodepool in this
cae right ? the aim here is not allow the new nodepools to have any
other pods otherthan the myapp pods. whether taint will help is this
scenario than nodeselctor or a admission controller called
&quot;podnodeselector&quot; ?</p>
</blockquote>
<p>Use <code>nodeAffinity</code> configuration desribed above for <code>myapp</code> pod configuration.</p>
<p>Add the label to <code>myapp</code> pod configuration e.g</p>
<pre><code>  template:
    metadata:
      labels:
        usnp1: myapp
</code></pre>
<p>For any other pods which you do not want to be scheduled at that node, or better say not scheduled with pods which have a label <code>usnp1: myapp</code> create <code>podAntiAffinity</code> configuration e.g</p>
<pre><code>  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: usnp1
            operator: In
            values:
            - myapp
        topologyKey: &quot;kubernetes.io/hostname&quot;
</code></pre>
<p>Look at <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/</a></p>
<p>Anyway this also doesn't to be 100% solution, because scheduling of pods is complex algorithm with many rules, which are score weighted. You could see the score and weights in schedulerds log.</p>
<p>Look at <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/</a></p>
<blockquote>
<p>Also for point2- we will be proceeding with helm upgrade with the
modified manifests with the namespace changes from pipeline, in that
case whether the helm statefile play a role here to delete the old
pods?</p>
</blockquote>
<p>To this, I don't know about a functionality in helm where you could parallel undeploy from one namespace and deploy to second namespace. Because if I understand clearly the state of deployment applied by <code>helm install</code> is per namespace. So to deploy/undeploy you need to always define <code>--namespace</code> if you are not already switched in. And that probably means that you couldn't interfere with namespace state when deploying same helm chart.</p>
<p>But I'm do not have much experiences with helm.</p>
