RKE1 cluster provisioning shift to Cluster API v2prov in Rancher 2.6+

Direct answer

Rancher announced the deprecation of RKE1 in the Rancher 2.6 release notes (November 2021). Support continued in a deprecated state through Rancher 2.7, and official RKE1 support was removed in Rancher 2.8 (released May 2023). Therefore, for any Rancher 2.6+ installation, RKE1 is already deprecated and will be unsupported once you upgrade to 2.8 or later.

How to evaluate the trade‑offs

1. Check your Rancher version – if you are still on 2.6 or 2.7, RKE1 clusters can still be created but are marked deprecated; upgrading to 2.8+ will block new RKE1 clusters and may remove existing management capabilities.
2. Review the support matrix – confirm whether your current Rancher version lists RKE1 as "supported (deprecated)" or "unsupported". This determines how long you can safely keep the legacy clusters.
3. Assess workload compatibility – verify that your applications do not rely on Kubernetes APIs removed in RKE2/K3s (e.g., PodSecurityPolicy, certain beta APIs). Update manifests if needed.
4. Estimate migration effort – calculate the time and resources required to back up etcd and persistent volumes, spin up a new RKE2/K3s cluster via the v2prov driver, and restore workloads.
5. Consider operational impact – plan for any required downtime, validate CNI compatibility (RKE1 uses Canal by default; RKE2/K3s default to Canal or Calico), and update Rancher‑managed monitoring/alerting after migration.

Available workload migration aids

• Velero (or commercial alternatives such as Kasten K10/Trilia) – Rancher‑endorsed method: take a backup of etcd, Kubernetes resources, and PVs from the RKE1 cluster, then restore onto a newly provisioned RKE2/K3s cluster. Helm charts or Kustomize can redeploy applications.
• Storage‑specific tools – Rook‑based CSI migration, Portworx Backup, or other DR solutions can move persistent volumes without requiring a new cluster for the storage layer, but a new control plane is still needed.
• Manual Helm/Kustomize re‑apply – after cluster creation, re‑apply your application manifests; this works well for stateless workloads.

Rancher‑endorsed procedures for transition

Rancher does not provide an in‑place control‑plane upgrade from RKE1 to RKE2/K3s. The recommended path is:

1. Provision a new RKE2/K3s cluster using the v2prov driver in Rancher.
2. Run a Velero backup of the RKE1 cluster (etcd + resources + PVs).
3. Restore the backup onto the new cluster.
4. Validate application functionality and cut over traffic.

No Rancher‑provided tool skips the new cluster provisioning step for the control plane.

Missing diagnostic detail

To give a precise recommendation on whether you can stay on RKE1 longer or must migrate now, please confirm your current Rancher version (e.g., 2.6.x, 2.7.x, or 2.8+). This determines if RKE1 is still manageable in your environment.