Nodes and fleets
Inspect and manage Linux hosts that provide compute and storage capacity.
Nodes provide compute, storage, or both to an Infra region. Each node runs an agent that reports health and applies authorized infrastructure changes.
Node roles and pools
A compute node requires KVM/QEMU and a supported CPU architecture. A storage node contributes devices to a storage pool. A combined node performs both roles and must satisfy both maintenance procedures.
Node pools group compatible hardware and admission policy. A project can be allowed to use selected pools without receiving permission to manage their hosts. Use separate pools for different CPU generations, licensed workloads, or hardware with distinct availability requirements.
Inventory
Fleet → Nodes lists region, zone, rack, pool, roles, agent version, and health. The capacity columns distinguish physical capacity, allocatable capacity, reserved resources, and observed usage.
A Ready node has passed its required component checks. A Degraded node has a named dependency or redundancy condition that needs inspection. Unreachable means its observation path is not current; it does not establish that the host is powered off.
Admission appears separately. Cordoned prevents new destinations while existing guests continue. Draining means evacuation children are active. A Retired identity cannot return as active capacity without a new authorized enrollment.
Open the condition itself for its source, last transition, and related operation. A recently received inventory update does not make an older storage observation current.
Scheduling eligibility and health are separate. A healthy cordoned node still runs existing droplets. An uncordoned node with failed health checks cannot accept a new placement.
Capacity and reservations
Infra reserves configured vCPU, memory, and local storage for admitted droplets. CPU profiles constrain compatible destinations independently of these totals. Hypervisor overhead and host reserve are deducted before allocatable capacity is calculated. Overcommit changes scheduling limits; it does not increase physical memory or CPU throughput.
Per-node limits can reduce allocatable capacity below physical capacity. A new limit below existing reservations prevents additional placements and reports an overallocated condition. It does not terminate existing droplets.
Labels and taints
Labels describe capabilities such as cpu.family=zen4 or disk.class=nvme.
Taints restrict admission to droplets that
explicitly tolerate them. A node selector is a requirement; a preference is
only a scheduling input.
Changing a label or adding a taint affects subsequent placements. Running workloads remain in place until an operator initiates a compatible move. Review live migration compatibility before treating two pools as interchangeable.
Node details
The node page includes CPU and memory charts, interface traffic, storage health, a droplet inventory, active migration progress, and a streaming journal. The last observed time applies to the source of each measurement; a recent console update does not imply every subsystem reported recently.
Use enrollment to add hardware, maintenance to remove it from service, and Troubleshooting for unreachable agents or unhealthy hosts.
Public and declarative host configuration
Owned-node public IPv4 and IPv6 assignments are managed through fleet networking and remain separate from a project's droplet public-address resources. Restrict management exposure even when edge protection is active.
Use declarative node configuration for owned field sets and Git-driven drift. NUMA placement and time synchronization can independently exclude a host from new admission.