why appn pods running on system node

Hello Jena, Tapas Kumar (893) (EXT),

Welcome to the Microsoft Q&A and thank you for posting your questions here.

What I understood in your question is application pods are running on the AKS system node pool instead of the user/agent node pool, and some workloads are also showing Tenant: None.

The issue is usually caused by missing workload scheduling constraints. In AKS, system node pools are intended for critical system pods such as CoreDNS and metrics-server, while user node pools are intended for application workloads. By design application pods can still be scheduled on a system node pool if the cluster does not restrict scheduling, but this is not recommended for production isolation. - https://learn.microsoft.com/en-us/azure/aks/use-system-pools

The best practice resolution is to:

• Keep the system node pool reserved for AKS system components.
• Use a user/agent node pool for application pods.
• Add nodeSelector or node affinity to application deployments.
• Add a taint such as CriticalAddonsOnly=true:NoSchedule on the system node pool to prevent regular application pods from landing there.
• Add labels to the user node pool and target those labels from your application manifests.
• Review the “Tenant: None” value, because AKS does not automatically assign a tenant to pods. If this is from your monitoring, security, or cost workbook, it usually means the pod/namespace is missing the expected tenant label, annotation, or workload identity mapping.

After applying labels, node selectors, and system pool taints, application pods should be recreated on the correct user/agent node pool, while AKS system pods remain on the system node pool.

Use the above and below official resources for more reading and implementation steps:

• https://learn.microsoft.com/azure/aks/use-node-taints
• https://learn.microsoft.com/azure/aks/use-labels
• https://learn.microsoft.com/azure/aks/create-node-pools [learn.microsoft.com]

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

Hello @Jena, Tapas Kumar (893) (EXT),

Thank you for using Q&A forum

Taints: <none>

That single line is the entire reason.

When a pod is created, the scheduler places it on any node that meets the resource requirements (CPU, memory) unless something explicitly blocks it. There are two mechanisms that block scheduling:

• Taints on the node — repel pods that don't tolerate them
• NodeSelector / NodeAffinity on the pod — restrict which nodes the pod can land on

Why the Taint Is Missing

AKS does not automatically taint system node pools. This is a known gap — the CriticalAddonsOnly=true:NoSchedule taint that Microsoft recommends for system pools must be added manually. If the cluster was created without it, or if the taint was removed at some point, application pods will freely schedule on system nodes.

Add the taint that should have been there from the start:

bash

az aks nodepool update \

--resource-group <your-rg> \

--cluster-name <your-cluster> \

--name agentpool \

--node-taints CriticalAddonsOnly=true:NoSchedule

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.