Scheduling and placement
Control node eligibility, placement groups, taints, and capacity admission.
Scheduling selects a node that satisfies a droplet's placement requirements and has reservable capacity. It runs during creation, recovery, and migration.
Admission checks
Infra first checks project access and quotas, then region and pool eligibility, required labels, taints, CPU compatibility, volume access, placement groups, and allocatable capacity. Preferences rank the remaining candidates.
A failed requirement blocks placement. Preferences cannot override a region restriction, an unhealthy node, or an exhausted memory reservation. The placement preview shows excluded nodes and their reasons.
A region, an explicitly selected pool, a CPU profile, and a node selector are
requirements. For example, cpu.family=zen4 excludes nodes that do not advertise
that exact label pair. A preference can rank eligible candidates but cannot
make an excluded node eligible.
Placement groups add required or preferred affinity and spread. A required three-zone spread needs three eligible zones even if two zones have unused capacity. Tolerations permit a matching tainted node without requiring the scheduler to select it.
Volume access is also a requirement. A node with enough memory is still excluded when it cannot reach an attached storage policy or provide an exclusive passthrough device.
Placement groups
Placement groups documents membership revisions, noncompliant existing guests, and explicit reconciliation.
Create a group under Compute → Placement groups and select its scope. Spread places members in different nodes or zones. Affinity places members together where the selected mode permits. Required groups reject a placement when no candidate satisfies the rule; preferred groups permit a fallback and report the unmet preference.
A zone spread rule needs enough eligible zones for the member count. Adding replicas to a required group can fail even when the region has unused capacity in a zone that already hosts another member.
Changing a group's configuration affects future placements. Use an explicit migration plan to reconcile existing placements. The preview identifies workloads that remain outside the requested policy.
Taints and tolerations
Node labels, taints, and tolerations documents exact matching, replacement semantics, and policy changes affecting running guests.
A node taint reserves admission for selected workloads. A droplet must contain a matching toleration to be placed there. A toleration permits the node; it does not require or prefer that node.
Use a selector with a toleration to target dedicated capacity. Adding a taint to a running node does not evict droplets. Draining is an explicit operation with its own checks and progress.
Capacity reservation
An accepted placement reserves resources while provisioning proceeds. A failed operation releases reservations after its cleanup completes. A temporarily unreachable agent can leave an operation reconciling while Infra determines whether a resource exists on the host.
Do not retry creation repeatedly to bypass a reservation. Inspect the operation and use the same idempotency key for a retried API request.
Diagnose unschedulable droplets
Open Droplet → Placement → Explain. Check the first failed requirement on each excluded node. Common causes include a required zone spread, an unsupported CPU profile, a local-only volume, or capacity held by another operation.
Add eligible capacity or revise the intended requirement. Infra does not change required placement constraints automatically. See Capacity for headroom and Live migration for destination compatibility.