Node maintenance
Cordon and drain fleet nodes, validate their health, and replace retired hardware.
Node maintenance removes a host from placement and evacuates its compute workloads before service work. Storage evacuation is a separate requirement when the node also holds volume replicas.
Cordon a node
Open Fleet → Nodes → Node → Cordon, enter a reason, and confirm. Cordoning prevents new placements, including migration destinations. It leaves existing droplets running and does not release their capacity reservations.
Use a maintenance plan when the change needs a schedule, concurrency limit, or a reviewed sequence across several hosts.
Preview a drain
Select Drain → Preview. Infra checks every droplet and proposes destination nodes. Review the complete set before starting the operation.
Read each blocker's affected droplet IDs before choosing a remedy. CPU incompatibility requires compatible hardware or a stopped profile transition. Capacity shortage requires more eligible headroom, not only a higher quota. Required affinity can make several guests a single evacuation problem.
Local disks require a supported cold copy. Passthrough devices require a stopped move and compatible destination hardware. An active conflicting operation must finish or reach a cancelable boundary before drain can proceed.
A drain preview never converts one of these blockers into a forced guest stop. Use a separately reviewed disruptive action when live evacuation is unavailable.
The preview does not reserve every destination indefinitely. Execution repeats admission checks, so concurrent activity can invalidate a proposed placement.
Run the drain
From the node's Drain → Preview, start the reviewed drain and open its parent operation. Follow the child migration results by droplet ID. If a child fails, successful migrations remain at their destinations and the source stays cordoned. Use the remaining-workload list to correct the failed placement before retrying that part of the drain.
Canceling the drain stops scheduling additional children. A migration already in its commit phase finishes according to its own lifecycle. Canceling does not return migrated droplets to the source.
After compute evacuation, verify Running droplets: 0. If the host contributes storage, follow Remove a storage node and wait for replica replacement before shutting it down.
Return a node to service
- Start the host and verify its agent identity and current version.
- Check CPU profile, devices, storage health, and mesh peers.
- Confirm host reserve and admission limits still match the hardware.
- Clear the maintenance condition and select Uncordon.
Uncordoning does not move previous workloads back. Run a separate rebalance if redistribution is required.
Replace a node
Enroll replacement hardware under a new node ID, validate it while cordoned, and admit it to the pool. Drain the old node, evacuate storage, and revoke its agent identity through Retire node. Remove the old host from mesh and provisioning inventories after retirement completes.
A retired identity cannot reconnect as an active node. Historical metrics, operations, and audit records continue to reference the old ID.
An unavailable source host
Drain requires a responsive source for live migration. If the host has failed, use the node failure procedure. Infra must establish that the original workload cannot write before starting a replacement from shared storage. Losing network contact alone does not prove that the host or its droplets have stopped.