Introduction

Crusoe Managed Kubernetes (CMK) node pools don't apply configuration changes live to running nodes. Every time you change a node pool setting, whether that's toggling Ephemeral Storage for Containerd, adjusting labels, or switching another pool-level option, CMK generates a new instance template: a snapshot of the pool's configuration at that moment.

That template is only consumed when a node is actually built from scratch. First-boot bootstrap runs against the current template and writes things like mount entries, storage paths, and config files onto the node's boot disk. There's no mechanism for reaching into an already-running node and rewriting its disk layout after the fact.

This FAQ covers what actually happens to existing nodes when you change a node pool setting, and how to get a node onto the new configuration if you need it.

Question 1: If I change a node pool setting, does it trigger a rolling update on my existing nodes?

Answer: No. The new setting only affects the instance template used to build future nodes. It does not touch VMs that are already running. There's no rolling update, reboot, remount, or workload disruption. Nodes that were already running before the change keep whatever configuration they booted with.

Question 2: Which nodes actually end up with the new setting, and when?

Answer: Any node created after the change picks up the new template. That includes normal scale-up events and any automatic node replacement or healing event in that pool.

⚠️ Warning: If you don't take deliberate action on your existing nodes, a pool can end up silently split between the old and new configuration, since scale-ups and healing replacements happen automatically and aren't announced. If every node in a pool needs to match, don't rely on organic churn: see Question 4 for how to force it.

Question 3: Will a stop/start or reset of an existing node pick up the new node pool setting?

Answer: No, in either case.

Node pool settings, things like fstab entries, storage paths, and related config files, are written to the boot disk during first-boot bootstrap, when a node first joins the pool. A stop/start recreates the VM on the underlying hypervisor but preserves the original identity and boot disk, so bootstrap never reruns and the original layout persists. Resetting a node reruns startup scripts, not the full bootstrap sequence, so it doesn't pick up the new setting either.

⚠️ Warning: Crusoe does not recommend stop/start operations on CMK nodes. Use a delete operation instead, and let the node pool rebuild the node, as described in Question 4.

Question 4: How do I actually get an existing node onto the new setting?

Answer: Delete the VM and let the node pool's instance group rebuild it. A newly created node gets a fresh boot disk and runs bootstrap against the current template, which is the only path that reliably picks up a node pool setting change.

💡 Tip: If you need an entire pool aligned on one configuration, cycle the nodes deliberately, cordon and drain, then delete, rather than waiting for scale-up or healing events to do it piecemeal.