Overview
This is a typical engagement for a software company whose production workloads run on downstream clusters that were built as RKE1 clusters and are managed from one Rancher server. RKE1 reached end of life on 31 July 2025, and the team now needs a replatform plan it can schedule. AceMQ and a partner Kubernetes specialist inventory the estate and plan the move to new RKE2 or K3s clusters.
Challenge
SUSE states that replatforming RKE1 in place is not possible, so every cluster has to be replaced by a new one and every workload moved. The difficulty is the order. Stateless services move easily, stateful ones need data movement and a rollback, ingress and load balancer connectivity has to exist before anything cuts over, and the Rancher server itself has to be on a version that supports the clusters on both sides of the move.
Environment
A Rancher server on a Kubernetes cluster of its own, several downstream RKE1 clusters on virtual machines in two locations, ingress controllers and load balancers per cluster, and a mix of stateless services and stateful workloads with persistent volumes.
Approach
The engagement starts read-only. AceMQ builds an inventory of workloads and classifies each as stateless or stateful, checks the Rancher version against SUSE's support matrix and lifecycle dates, and writes the plan before any new cluster is created. Application code is not changed.
Solution
- Inventories every workload on the RKE1 clusters and classifies it as stateless or stateful
- Checks the Rancher server version and the target Kubernetes versions against SUSE's support matrix and lifecycle dates
- Designs the new RKE2 or K3s clusters beside the old ones, including node sizing, network plugin and ingress
- Plans the cut-over in waves, with stateful workloads last and a data movement and verification step for each
- Defines the rollback for every wave and the point after which it is no longer possible
- Tests the Rancher backup and restore and the etcd snapshots on the new clusters before the first wave
Outcome
The engagement delivers a workload inventory with each workload classified, a written replatform plan with the order of waves and owners, the target cluster design, a rollback plan for every wave and a tested Rancher backup and restore. The platform team learns which clusters move first, what each move depends on and when the old clusters can be retired.
Technologies
Kubernetes
OpenShift
RabbitMQ
Kafka
Terraform
OpenTelemetry
Kong
PostgreSQL
Elasticsearch
