We Upgraded K3s to RKE2, and Only Production Went Down
K3s vs RKE2 — both are CNCF-certified, "lightweight" Kubernetes distributions, and that shared reputation is exactly why teams tend to reduce the comparison to a feature checklist and treat migration as a formality.
Here's what actually happened to one operations team. They upgraded two K3s clusters to RKE2. The test environment (10 VMs) completed without a hitch. But in production — an air-gapped environment running on 30 bare-metal servers — the team experienced roughly two hours of downtime (rancher/rke2 Discussion #7627).
The root cause: taints left on the K3s control-plane nodes were incompatible with the RKE2 install process. RKE2's default Canal CNI (a Calico-based CNI) refused to install because of those old taints. In a separate migration, Rancher mistakenly re-registered an RKE2 cluster as K3s and attempted a nonexistent "upgrade," leaving the cluster unschedulable (rancher/rancher Issue #46776). Another report found that after a Backup/Restore Operator migration, clusters took 7–15 minutes to return to Active status instead of the expected 2–5 minutes (rancher/rancher Issue #42834).
In every case, the team followed the documentation. What these incidents reveal is that the real risk in a K3s vs RKE2 decision isn't the feature gap — it's the differences in underlying assumptions that documentation alone doesn't surface.
K3s vs RKE2: What Actually Differs
Before getting into the differences, it's worth noting what K3s and RKE2 share. Both are CNCF-certified Kubernetes distributions that ship as a single binary and support automated upgrades via the system-upgrade-controller — both designed around operational simplicity.
The biggest divergence is the datastore. K3s defaults to SQLite, which is used automatically whenever no other datastore configuration is present. Embedded etcd is only selected automatically if K3s is configured to initialize or join an etcd cluster, or if etcd database files already exist on disk (K3s official documentation). In other words, running a multi-server HA setup on K3s requires explicitly opting into etcd.
RKE2, by contrast, is etcd-only — SQLite isn't even an option. That design choice reflects RKE2's "built for production" posture. The gap widens further on CIS hardening: RKE2 is hardened by default and passes the majority of CIS controls without additional configuration. K3s offers only partial CIS Benchmark support, requiring manual hardening work to reach production-grade compliance (per this comparison from oneuptime.com). FIPS 140-2 compliant builds and DISA STIG certification are, as of now, available only for RKE2.
The HA Requirements Nobody Reads Until It's Too Late
The operational requirements for high availability also differ in the details, whichever side of the K3s vs RKE2 decision you land on.
For RKE2 HA, you need an odd number of server nodes (3 is recommended), a constraint driven by etcd's need to maintain quorum. In front of those server nodes, you place a "fixed registration address" — implemented via a layer-4 (TCP) load balancer, round-robin DNS, or a virtual/elastic IP. The rke2 server process listens for node registration on port 9345 and serves the Kubernetes API on port 6443 (RKE2 official documentation). If you use a fixed registration address, you must add it as a SAN via the tls-san parameter to avoid certificate errors.
K3s running embedded etcd for HA has the same odd-node requirement, and the first server node must be started with the --cluster-init flag. The takeaway isn't "K3s is easy, RKE2 is hard" — once HA enters the picture, both distributions demand the same level of design discipline.
The Storage and Network "No Opinion" Trap
One thing comparison tables rarely mention, but that matters enormously in practice, is the initial storage design.
K3s ships with local-path-provisioner as its default StorageClass. It assumes node-local disks, which means any PersistentVolumeClaim is implicitly bound to a specific node at creation time. The result: node drains or OS patching routinely trigger downtime because the bound pod can't simply move to another node (this comparison of storage assumptions across K3s, RKE2, and Talos).
RKE2 ships CNI and an Ingress controller, but takes no opinion on storage — there's no default StorageClass at all. That can look like more freedom than K3s offers, but as the same article points out, teams under deployment pressure tend to reach for the same node-local provisioner anyway, landing in the identical trap. RKE2 doesn't automatically save you from a bad storage decision.
So Which Should You Actually Choose in Production?
Putting the differences together, the decision frame looks like this:
- If third-party audit requirements — CIS Benchmark, FIPS 140-2, DISA STIG — are mandatory (finance, healthcare, government), RKE2 is the pragmatic choice. Being hardened by default significantly cuts the audit-prep workload.
- If you're resource-constrained with light HA needs — edge, IoT, ARM devices, dev/CI environments — K3s's lightweight footprint is the better fit.
- The moment you need production HA, both distributions demand the same groundwork: odd-node etcd quorum design, SAN certificate configuration, and storage node-affinity mitigation. Neither gives you a free pass.
The real question behind "K3s vs RKE2" isn't which distribution is technically superior — it's whether your team can sustain HA design, CIS compliance, and storage architecture as an ongoing operational commitment. Get that wrong, and you end up like the team in our opening example: "we followed the docs, and production still went down."
If you'd rather hand off that operational burden, Kubo is a managed Kubernetes service built on K3s with a Rancher management layer, where HA design, etcd backup operations, and certificate management are handled for you. Instead of building "K3s's lightness" and "RKE2-grade operational quality" yourself, Kubo Cloud gives you AI-Driven Deployment and Captain UI at roughly 58% of AWS EKS's cost and about 56% of Azure AKS's — production-grade K3s without the DIY overhead.
For organizations where CIS/FIPS-equivalent audit requirements are a baseline, not an exception — finance, healthcare, government — Kubo On-Premise keeps data sovereignty entirely in-house. It supports air-gapped environments, absorbing the full weight of running RKE2-grade CIS compliance yourself.
The Bottom Line
K3s vs RKE2 isn't a question that a binary-size-and-datastore comparison table can settle. You need to factor in CIS hardening, FIPS support, HA prerequisites, storage design, and migration-compatibility risk before you can answer "which one for production?"
As the opening incident shows, a detail as small as a leftover taint can take production down. Before you commit to a distribution or a migration, go beyond the feature comparisons — read the real migration reports and the official hardening guides. And if you decide the operational burden itself isn't worth owning, a managed Kubernetes service like Kubo is worth a serious look.