K3s-only vs Mixed RKE2/K3s Strategy in Rancher for Edge-Constrained Deployments

Goal: Determine whether to standardize on K3s for all downstream clusters managed by Rancher or to adopt a mixed approach that runs RKE2 in core/regulated workloads and K3s at the edge, while respecting limited CPU and memory budgets on branch hardware.

Constraints: K3s delivers a small footprint with a single binary and SQLite datastore, fitting tightly constrained nodes, but lacks native multi‑server HA without switching to etcd. RKE2 provides etcd‑based HA and CIS‑hardened defaults, yet consumes more resources per node. Rancher provisions both distributions through similar UI and API workflows, so the operational difference lies in maintaining two distinct distributions, testing upgrades, and ensuring compliance parity.

Uncertainty: Whether the simplicity and reduced testing burden of a single K3s‑only fleet outweighs the benefits of running a hardened RKE2 stack in environments that require regulatory alignment, and if the extra resource cost of RKE2 is justifiable for core clusters.

• Is it operationally acceptable to manage both RKE2 and K3s distributions across the fleet?
• Does the resource saving of K3s on edge nodes justify the added complexity of a mixed strategy?
• Can a core cluster’s compliance requirements be met with K3s running etcd instead of RKE2, eliminating the need for two distributions?