Modernize: Migrate from SUSE Rancher RKE1 to Red Hat OpenShift

SUSE Rancher RKE1 reached its end-of-life (EOL) on July 31, 2025. As with any EOL software, continuing to use it could leave your production workloads vulnerable to security risks, without vendor support, and facing compatibility challenges.

If you’re considering a change, Red Hat OpenShift offers an enterprise-grade application platform that can support your Kubernetes container strategy today and scale for the future. 

Why Red Hat OpenShift is the right choice for your business

Red Hat OpenShift is a complete, enterprise-focused container application platform built on a hardened, consistent Red Hat Enterprise Linux (RHEL) foundation. Red Hat OpenShift offers the following benefits for your organization:

Enhanced consistency with a hardened operational backbone

• Proactive, integrated security - Red Hat OpenShift provides built-in, proactive security features, including Security Context Constraints (SCCs) that are more restrictive than standard Kubernetes role-based access control (RBAC), and a foundation built on Red Hat Enterprise Linux CoreOS for immutable, managed-host operating systems (OSs).
• Greater consistency - Red Hat OpenShift delivers a more consistent experience across on-premise, public cloud, and edge deployments. This consistency simplifies operations, troubleshooting, and compliance.
• Compliance and policy enforcement - Integrating Red Hat OpenShift compliance operator and applying enterprise security policies helps harden clusters against potential security challenges.

A rich developer experience and ecosystem

• Integrated developer tools - Red Hat OpenShift features an integrated web console, built-in CI/CD tools, and ArgoCD for GitOps-based continuous deployment and developer tools. Red Hat OpenShift Pipelines and Source-to-Image (S2I) workflows help boost developer productivity.
• The operator framework - Red Hat OpenShift takes advantage of operators (software extensions that manage the lifecycle of an application)—from deployment to upgrades, backups, and scaling—making Day 2 operations simpler and more reliable.
• Integration with existing DevOps toolchains, including GitHub, GitLab, and Jira.
• Ingress OpenShift offers the Gateway API for modern ingress and Red Hat OpenShift Virtualization for migrating and managing virtual machines (VMs) alongside containers.

Enterprise support

• Comprehensive support: Migrating to Red Hat OpenShift provides end-to-end, enterprise-grade support from Red Hat for the entire platform, including the Linux OS, Kubernetes, and integrated services like networking, storage, and monitoring. 

How to migrate from RKE1 to Red Hat OpenShift 

A side-by-side migration is the recommended approach for migrating RKE1 to Red Hat OpenShift, providing minimal downtime and allowing for rigorous testing.

Assessment and planning (Pre-migration)

1. Inventory RKE1 clusters: You must do a full audit of your cluster and document its mission critical components.

Get a report of all persistent volumes (PV) and persistent volume claims (PVC) on your cluster:

kubectl get pv,pvc

Get a report of all storage classes you have set up:

kubectl get sc

For ingress routes  

For ingress and routing, take note of the namespaces, hosts, destination addresses, and ports:

kubectl get ingress -A

If you treat your configuration as code, then you likely have the original YAML used to create each of these objects. Failing that, you can see a YAML representation of each object by adding --output yaml to these commands. Review the metadata section of the output YAML for the source configuration.

1.  Finally, document any external dependencies (databases, load balancers, and so on) your cluster is using.

2. Container image analysis: In Kubernetes, security context constraints (SCC) allow you to control permissions for pods. OpenShift tends to have a strict SCC policy, and technology such as SELinux can change what permissions are available to a container. For example, you may need to update an image that runs as the root user to run with an unprivileged user ID. Visit documentation for OpenShift and Kubernetes to learn more about managing SCCs.
3. Dependency mapping: Identify non-core Kubernetes resources (like Helm charts for logging, monitoring, and service mesh) and find their corresponding OpenShift sources.
4. Operators or supported configurations. Visit Red Hat Ecosystem Catalog to browse available operators from Red Hat, Red Hat partners, and the open source community at large.
5. Target cluster provisioning: Deploy a new OpenShift cluster. Utilize OpenShift's guided installer for your chosen infrastructure (on-premise or cloud).

Platform and configuration migration

1. Networking setup: Configure OpenShift's networking, including ingress controllers and software-defined networking (SDN), to align with your RKE1 network setup. You will move from RKE1's Ingress Controller to OpenShift Routes or the Gateway API. You may also decide to use an OpenShift operator for load balancing, or a third-party (such as Amazon Web Services).

An OpenShift route is an ingress controller, similar to the default one in Kubernetes. A route can be secured or unsecured (HTTP) or secured. Here's an example of a basic unsecured route to a sample hello-openshift application:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: hello-openshift
spec:
  host: hello-openshift-hello-openshift.<Ingress_Domain>
  port:
    targetPort: 8080
  to:
    kind: Service
    name: hello-openshift

For full details on configuring an OpenShift route (both unsecured and secured), read the documentation for route configuration.

2. Security adaptation: Translate RKE1's custom security policies into OpenShift's native Security Context Constraints (SCCs).
3. Platform services: Install necessary operators on OpenShift for core services (such as Red Hat OpenShift Service Mesh, Red Hat OpenShift Data Foundation for storage) to replace existing RKE1 add-ons.

Workload migration and validation

1. Data migration: Use tools like the OpenShift migration toolkit for containers (MTC) to automate the transfer of persistent volume data from RKE1 storage to OpenShift storage.
2. Resource deployment: Deploy application manifests (YAML, Helm charts) to your new OpenShift cluster, using native OpenShift resources like DeploymentConfigs or standard Kubernetes deployments managed by operators.
3. Application testing: Perform thorough functional, performance, and security testing on the new OpenShift environment.

Cutover and decommissioning

1. Traffic cutover: Once validation is complete, update your DNS or load balancer to gradually shift traffic from the old RKE1 clusters to your OpenShift clusters. A phased, canary-style cutover is recommended to minimize risk.
2. Final decommissioning: After a stable period and full traffic migration, decommission the old RKE1 clusters.

Why choose Red Hat?

Red Hat has long been a contributor and leader in open source software development. Today, Red Hat OpenShift allows IT teams to provide a modern cloud-native application platform.

You can automate the migration process with Red Hat Ansible Automation Platform and rely on Red Hat Advanced Cluster Management to streamline maintenance of the platform―all from a single console that tracks and reports issues and across private and public cloud locations, including the edge.

Want help? Red Hat Consulting can provide hands-on collaboration and technical expertise to help you strategize and execute your migration.