Why it matters
Heterogeneous clusters are increasingly common. GPU nodes for ML, SSD nodes for interactive queries, memory-heavy nodes for graph analytics. Without labels, YARN would place containers randomly and defeat the specialization. Users would see performance vary wildly based on where their containers landed.
Labels also improve capacity planning. Track utilization by label to see whether GPU capacity is bottlenecked separately from CPU capacity, and expand each independently.
The architecture
A node label is a string attached to one or more NodeManagers. Common labels are 'gpu', 'ssd', 'highmem'. Nodes without any label are 'DEFAULT'. Labels can be exclusive (only labeled applications can use those nodes) or non-exclusive (labeled applications get priority but default applications can borrow).
Queues can be configured with accessible labels — a mapping specifying which labels each queue can request. A queue with access to 'gpu' can submit applications targeting GPU nodes; a queue without that access cannot even if the user is authorized.
How it works end to end
Configuration flows in two directions. Administrators register labels centrally in the RM, mark nodes with labels using the yarn rmadmin -addToClusterNodeLabels command, and then configure queue access to labels through capacity-scheduler.xml. Once configured, changes to node labels can be dynamic via rmadmin without cluster restart.
Applications request labeled containers by adding a node label expression to their ResourceRequest. The scheduler treats this as a hard constraint (exclusive labels) or preference (non-exclusive) when matching. Applications that do not specify a label expression run on DEFAULT nodes.
Capacity per label is tracked separately. A queue can have 30 percent of DEFAULT capacity and 50 percent of GPU capacity independently. This lets you allocate GPU resources based on ML team needs while allocating general compute based on broader team needs.