Node affinity lets a Pod require or prefer nodes with particular labels. This is useful when workloads need GPUs, a CPU architecture, a specific operating system, or another node property. Kubernetes evaluates the Pod’s affinity rules against node labels during scheduling. section 8.1 section 8.1.1
A required rule permits placement only when its expressions match. A preferred rule expresses a best-effort choice, such as preferring Arm nodes for a multi-architecture container while still allowing x86 placement. Preferred rules can behave unexpectedly with cluster autoscaling: available capacity on a less-preferred node may be used before new preferred nodes are added. section 8.1.2
Affinity expressions provide more choices than a simple node selector:
- In matches one of several supplied label values, such as arm64 or amd64. section 8.1.2
- NotIn avoids nodes whose label value appears in the supplied list. section 8.1.2
- Exists and DoesNotExist test whether a label key is present. section 8.1.2
- Additional match expressions can require multiple conditions to be satisfied. section 8.1.2
Selecting Arm nodes
A Deployment can use requiredDuringSchedulingIgnoredDuringExecution with a match expression for kubernetes.io/arch equal to arm64. Kubernetes then places the Pod only on a node carrying that label. Verify placement with kubectl get pods -o wide, then inspect the node with kubectl describe node. section 8.1.1
Affinity depends on the labels actually present on nodes. Managed platforms may provision suitable capacity from the requested labels, while traditional platforms may require a node pool or node group configured separately. Node affinity differs from Pod affinity: Pod affinity places Pods near other matching Pods, whereas node affinity targets node features. section 8.1.1 section 8.2.2
