In-place k3os upgrades versus CAPI-managed node replacement for etcd quorum safety

Maintaining etcd quorum across a k3os control plane during OS and k3s updates forces a choice between two documented paths: running k3os upgrade in place on each node and manually sequencing reboots, or adopting Cluster API (CAPI) to replace nodes immutably. The in-place approach is operationally simpler but risks quorum loss if multiple control-plane members reboot simultaneously, because k3os does not coordinate upgrade ordering across the cluster. The CAPI path avoids in-place mutation and supports rolling replacement, yet it introduces a separate management cluster and additional infrastructure overhead.

Because k3os is in maintenance mode, it is unclear whether native rolling upgrade coordination for etcd members will be implemented, leaving operators to weigh manual orchestration risk against CAPI complexity. Behavior may vary by release, so current rancher/k3os documentation and release notes should be consulted before relying on either path.

Which trade-off is more sustainable for a small production control plane: manually sequencing k3os upgrade reboots to preserve quorum, or standing up a CAPI management cluster for immutable replacement? Are there documented constraints on how many control-plane nodes can be safely upgraded in place before etcd loses quorum? If k3os remains in maintenance mode, what is the recommended upgrade strategy for teams that want to avoid both manual reboot orchestration and a separate CAPI cluster?