8.19 Kubernetes Pod Scheduling Inputs

Kubernetes Pod Scheduling Inputs is the set of fields, constraints, and cluster metadata that the Kubernetes scheduler consults when deciding which node a Pod should run on. These inputs range from explicit user-specified constraints in the Pod specification to implicit cluster state such as node capacity, existing workload placement, and taints applied to nodes, all of which the scheduler evaluates together to arrive at a placement decision that satisfies both feasibility and preference.

Resource Requests and Limits

CPU and Memory Requests

The resources.requests field on each container specifies the minimum amount of CPU and memory that container is expected to need. The scheduler uses the sum of requests across all containers in a Pod, together with any init containers, to determine whether a candidate node has sufficient allocatable capacity remaining before placing the Pod there. A Pod cannot be scheduled onto a node that lacks enough unreserved capacity to satisfy its requests.

The Role of Limits in Scheduling

While resources.limits primarily governs runtime enforcement rather than scheduling feasibility, extended resources with only a limit defined are treated as though the limit were also the request for scheduling purposes. This distinction matters when working with specialized resources such as GPUs, which are typically requested and limited to the same value since they are not compressible resources.

Node Selection Mechanisms

nodeSelector

The nodeSelector field provides the simplest mechanism for constraining Pod placement, requiring the target node to carry all of the specified key-value labels. If no node matches every label in the selector, the Pod remains unschedulable until such a node becomes available.

Node Affinity and Anti-Affinity

Node affinity, configured under affinity.nodeAffinity, offers a more expressive alternative to nodeSelector, supporting both hard requirements through requiredDuringSchedulingIgnoredDuringExecution and soft preferences through preferredDuringSchedulingIgnoredDuringExecution. This allows Pods to express nuanced placement logic, such as strongly preferring nodes in a particular availability zone while still tolerating placement elsewhere if no such node is available.

Pod Affinity and Anti-Affinity

Pod affinity and anti-affinity rules allow scheduling decisions to be influenced by the placement of other Pods rather than node labels alone. Pod affinity can be used to co-locate related Pods on the same node or topology domain to reduce network latency, while Pod anti-affinity is commonly used to spread replicas of the same application across different nodes or zones to improve fault tolerance.

Taints and Tolerations

Node Taints

Taints are applied directly to nodes and repel Pods that do not explicitly tolerate them. Each taint consists of a key, a value, and an effect, with common effects including NoSchedule, which prevents new Pods from being placed on the node, PreferNoSchedule, which is a softer form the scheduler attempts to honor, and NoExecute, which additionally evicts existing Pods that do not tolerate the taint.

Pod Tolerations

Tolerations are specified on the Pod and allow it to be scheduled onto nodes carrying a matching taint. Tolerations are commonly used to reserve specialized nodes, such as those with GPUs or dedicated hardware, for specific workloads by tainting the nodes and only granting the corresponding toleration to Pods intended to run there.

Topology Spread Constraints

Even Distribution Across Domains

The topologySpreadConstraints field allows a Pod to specify how it should be distributed relative to other Pods across a defined topology domain, such as zones, regions, or individual nodes, identified by a topology key label. The maxSkew parameter bounds the acceptable difference in Pod count between the most and least populated matching domains.

whenUnsatisfiable Behavior

The whenUnsatisfiable field determines how the scheduler responds when the spread constraint cannot be satisfied, with DoNotSchedule treating the constraint as a hard requirement and ScheduleAnyway treating it as a best-effort preference, allowing the Pod to be placed even if perfect distribution is not achievable.

Priority and Preemption

PriorityClass

Pods can reference a PriorityClass resource through the priorityClassName field, assigning the Pod a numeric priority value used by the scheduler when the cluster is under resource pressure. Higher-priority Pods are considered ahead of lower-priority ones when contending for the same scheduling slot.

Preemption of Lower-Priority Pods

When a higher-priority Pod cannot be scheduled due to insufficient resources, the scheduler may evict, or preempt, lower-priority Pods on a node to make room, provided doing so would allow the pending Pod to fit. This behavior can be disabled on a per-Pod basis through the preemptionPolicy field.

Node Capacity and Allocatable Resources

Allocatable Versus Capacity

Each node reports both its total capacity and its allocatable resources, with allocatable representing the portion of capacity available for Pod scheduling after reserving resources for system daemons and the kubelet itself. The scheduler always evaluates Pod fit against the allocatable figures rather than raw hardware capacity.

Node Conditions

Node conditions such as MemoryPressure, DiskPressure, and PIDPressure act as implicit scheduling inputs, since the scheduler avoids placing new Pods on nodes reporting these adverse conditions until they are resolved.