Node Affinity Calculator
Estimate how many nodes match a given nodeAffinity rule across your cluster.
About Node Affinity Calculator
nodeAffinity restricts scheduling to nodes carrying specific labels (instance type, GPU presence, availability zone, custom taints-free pools). The narrower the matching label set, the fewer nodes are eligible, directly capping how many replicas can be scheduled regardless of overall cluster size. This calculator estimates matching node count from a match percentage and checks whether that's enough capacity for your required replica count.
Formula
matchingNodes = floor(totalNodes × labelMatchPercent / 100)
- N
- Total nodes in the cluster
- L
- Percentage of nodes matching the label selector
- M
- Number of nodes matching the affinity rule
Worked example
With the default values below, Node Affinity Calculator returns Matching Nodes of 12. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Total Nodesaccepts 1–100,000 nodes
- 30 nodes
- Nodes Matching Label Selectoraccepts 0–100 %
- 40 %
- Required Replicasaccepts 1–100,000 pods
- 8 pods
- Pods Fit per Matching Nodeaccepts 1–1,000 pods
- 4 pods
Results
- Matching Nodes
- 12 nodes
- Max Schedulable Pods
- 48 pods
- Can Schedule All Required Replicas
- true
- Shortfall (If Any)
- 0 pods
Step by step
- 1Matching nodes = total × match%= 12 nodes
- 2Max schedulable pods= 48 pods
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to whole numbers, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
What's the difference between requiredDuringScheduling and preferredDuringScheduling?
requiredDuringSchedulingIgnoredDuringExecution is a hard constraint — pods that can't find a matching node stay Pending. preferredDuringSchedulingIgnoredDuringExecution is a soft weighted preference the scheduler tries to honor but will violate rather than leave a pod unscheduled.
Why would matching nodes be less than expected?
Label match percentage often shrinks unexpectedly when combined with other constraints — a GPU-labeled node pool might also be tainted for a different workload, or already saturated by another team's pods, netting out effective availability lower than raw label matching alone suggests.
How does this interact with the cluster autoscaler?
The autoscaler only adds nodes from node groups capable of satisfying a Pending pod's affinity rules — if no node group carries the required labels, autoscaling won't help and the pod stays Pending indefinitely.