Rancher and Cloudfleet: keep Rancher and drop RKE2/K3s operations, or move off it

Rancher gives you one place to see and manage many Kubernetes clusters. It does not run those clusters for you. Behind the Rancher UI, your team still installs, upgrades, backs up, and patches every RKE2 or K3s cluster, with its own control plane nodes at every site. That work, not Rancher itself, is what most teams want to get rid of.

Cloudfleet takes over the cluster side. You can keep Rancher as your console and import Cloudfleet clusters into it, or move off Rancher entirely and run everything through standard Kubernetes tooling. This post explains where the operating work in a Rancher setup sits, and walks through both paths.

Rancher, RKE2, and K3s: who does what

A Rancher setup has two layers. The Rancher server is the management layer: a web UI, authentication, role-based access across clusters, an app catalog, monitoring charts, and Fleet, Rancher’s GitOps engine. It runs on its own Kubernetes cluster, which you also operate. Underneath are the downstream clusters that run your workloads, usually built with one of SUSE’s two Kubernetes distributions.

The last row is the one that matters for this post. Whichever distribution you choose, every cluster needs etcd snapshots and restore tests, certificate rotation, Kubernetes upgrades through the system upgrade controller or the Rancher UI, operating system patches, and control plane nodes sized and kept healthy. Rancher Prime, SUSE’s subscription, adds support for this software, licensed per core or vCPU of every managed cluster as Rancher Prime pricing explained shows, but your team still does the work. Ten sites usually means ten clusters, and ten of everything above.

RKE2 vs OpenShift

Teams that compare RKE2 with OpenShift are usually comparing two different things. RKE2 is a Kubernetes distribution: it gives you a hardened cluster and leaves the platform on top to you. OpenShift is a full platform with its own APIs, developer tooling, and a required operating system, sold per core. RKE2 runs on most Linux distributions and is free to use, with optional support through Rancher Prime. For a deeper look at the platforms, see Rancher vs OpenShift, and if you are leaving OpenShift, the guide to migrating from OpenShift to Kubernetes.

Either way, both leave you operating clusters. That is the part Cloudfleet removes.

Path 1: keep Rancher, let Cloudfleet run the clusters

If your teams know the Rancher UI, rely on its project-level access control, or deploy with Fleet, you do not have to give any of that up. A Cloudfleet cluster is a CNCF-conformant Kubernetes cluster, so Rancher can manage it like any other cluster it did not create.

To register the cluster, you need cluster-admin rights in it.

1. Fetch the kubeconfig of the Cloudfleet cluster with cloudfleet clusters kubeconfig CLUSTER_ID.
2. In Rancher, open ☰ > Cluster Management, click Import Existing on the Clusters page, and choose Generic.
3. Name the cluster, add the users who need access under Member Roles, and click Create.
4. Copy the kubectl command that Rancher generates and run it with the Cloudfleet kubeconfig. It installs the Rancher cluster agent in the cattle-system namespace. If your Rancher server uses a self-signed certificate, use the curl variant that Rancher shows instead.
5. Click Done. The cluster shows as Pending while the agent connects to your Rancher server, then as Active.

From then on, the work is split cleanly:

Rancher manages Kubernetes versions and day 2 operations such as etcd snapshots only for clusters it knows how to operate, such as RKE2 and K3s. For a generic cluster, it leaves both to the cluster’s provider, which is exactly the split you want: Cloudfleet handles versions, upgrades, and the cluster data store.

There is a second benefit. A Cloudfleet cluster can span several clouds and on-premises sites at once, so the ten clusters you ran for ten sites can become one cluster with nodes in all of them. Rancher then shows fewer, larger clusters, and there is no control plane to run at any site. On-premises and edge servers join as self-managed nodes with a single command and outbound connections only.

Path 2: move off Rancher

Some teams find that once the clusters are managed, the Rancher server itself is the last piece of infrastructure they still operate. Every Rancher component has a standard replacement:

Fleet deserves a note, because the names collide. Rancher’s Fleet is a GitOps engine that deploys from Git repositories to many clusters. A Fleet in Cloudfleet is a group of nodes with its own cloud providers and constraints. They do different jobs, and you can run Rancher’s Fleet on a Cloudfleet cluster.

Next Generation Kubernetes

From datacenter to cloud to edge, Cloudfleet delivers the Kubernetes experience as it was meant to be. Fully managed control plane, just-in-time infrastructure, automated upgrades, all seamlessly controlled through a single pane of glass for your clusters.

Sign Up Now →

How to migrate from RKE2 or K3s to Cloudfleet

Workloads on RKE2 and K3s are standard Kubernetes, so the migration is mostly about moving them, not rewriting them. A typical migration looks like this:

1. Create the Cloudfleet cluster and, for path 1, import it into Rancher right away, so your teams keep the same view.
2. Install the shared tooling your workloads expect, such as your ingress or Gateway API implementation, cert-manager, monitoring, and storage.
3. Point your GitOps tool at the new cluster. With Rancher’s Fleet, add the cluster to the right cluster group. With Argo CD or Flux, register it as a new target. The same manifests and Helm charts deploy unchanged.
4. Move stateful data with application-level replication, or with Velero for namespaces and persistent volumes.
5. Shift traffic with weighted DNS records, site by site.
6. Reuse your servers. Drain a node from the old cluster, uninstall RKE2 or K3s, and join the machine to Cloudfleet as a self-managed node. Repeat until the old cluster is empty, then retire its control plane nodes too.

An RKE2 or K3s cluster cannot be converted in place, so plan the move as a gradual parallel run. The hardware is the part you keep. Cloudfleet Kubernetes architects plan and run this migration with you, and the Rancher alternative page describes the Migration Acceleration Program.

Frequently asked questions

RKE2 vs K3s: which should I use?

K3s is built for small footprints: edge devices, IoT gateways, and development clusters. RKE2 is built for data centers and regulated environments, with CIS hardening and FIPS 140 validated cryptography. Both are SUSE distributions, and both leave cluster operations to your team.

Can I import a Cloudfleet cluster into Rancher?

Yes. In Rancher’s Cluster Management, click Import Existing, choose Generic, and run the generated kubectl command against the Cloudfleet cluster. Rancher then manages access, apps, and GitOps, while Cloudfleet runs the control plane and upgrades.

Do I still need Rancher with Cloudfleet?

No. Cloudfleet runs the control plane and needs no management server. Teams that like Rancher’s UI and project model can keep it on top, and teams that want one less system to run can replace it with the Cloudfleet Console and standard tools.

How do I migrate clusters from Rancher?

Create the new cluster, deploy the same manifests to it through your GitOps tool, move stateful data, and shift traffic gradually. Rancher-specific components such as Projects, Rancher Monitoring, and ServiceLB have standard replacements.

What is the difference between Rancher Fleet and Cloudfleet Fleets?

Rancher Fleet is a GitOps engine that deploys from Git to many clusters. A Cloudfleet Fleet is a group of nodes with shared cloud providers, constraints, and taints. You can use both together.