As a Red Hat partner since 2015, intive has over a decade of experience in delivering practical solutions with OpenShift. Across many of our projects, we’ve seen companies increasingly standardize on OpenShift as their container orchestration platform - especially in multi-cloud or hybrid-cloud environments. Why? Because OpenShift offers a unified management and security model, stronger governance, and the flexibility to avoid vendor lock-in.
This case study highlights one such project, sharing technical insights into how we successfully migrated an application from Google Kubernetes Engine (GKE) to Red Hat OpenShift (OCP).
The AI Chat Application: At the Heart of the Project
The application we migrated was a proof of concept (POC): an AI-powered chat tool designed to help users search for local support services across parts of the UK. Instead of relying on traditional keyword searches, users could ask free-form questions and get conversational, context-aware responses. The application had backend and frontend components to manage the chat and used path-based routing to determine which subcomponent handled a particular request.
While initially deployed in Google Kubernetes Engine (GKE), the customer required the application to be hosted on Red Hat OpenShift (OCP), benefiting from its enhanced enterprise features, operational consistency, and additional management support.
Code Migrated Unchanged
The application was originally packaged as a set of Helm charts deploying container images and Kubernetes resources. One of the advantages of migrating between Kubernetes-based platforms is the reusability of existing resources. Much of the Kubernetes configuration remained unchanged, since both GKE and OCP share Kubernetes at their core. The same Helm charts were used to deploy onto OpenShift, ensuring a smoother transition.
The following Kubernetes resource types were migrated without modification:
- AppProject
- Application
- Deployment
- ExternalSecret
- Kustomization
- Namespace
- RoleBinding
- Secret
- Service
- ServiceAccount
Required Changes
OpenShift also uses Kubernetes to provide a container runtime environment but takes a different approach to available interfaces and some underlying mechanisms. As a result, adjustments were required:
1. Application Images
The same container images can be used on GKE and OpenShift. OpenShift, however, imposes some additional security constraints compared with standalone Kubernetes. For example, by default, OpenShift does not allow images to run as root.
OpenShift can pull images directly from the GKE repository, as long as the repository is reachable. If not (as was the case in this migration), images can be copied from GKE to OpenShift repositories using the skopeo command. Alternatively, the build pipeline can be modified to push images directly to the OpenShift repository instead of GKE.
2. Ingress of Data to the Application
Kubernetes (including GKE) uses Ingress to define how external users and processes connect to application images. OpenShift uses Routes for the same purpose. In OpenShift, Ingress resources can be defined, but they are automatically converted to Routes, which also provide extra functionality.
The application images were designed for insecure HTTP connections, making inter-image traffic simpler. For external access, however, HTTPS is recommended. In GKE, this is handled via a Frontend resource. In OpenShift, the same effect is achieved by setting the Route as edge-terminated.
TLS certificates, which validate HTTPS connections, are stored as secrets in GKE and referenced from the Frontend. In OpenShift, the certificate is stored directly in the Route definition.
For path-based routing (where the text after the hostname determines the target image), GKE uses paths like “/users/*”, while OpenShift uses “/users” (covering both “/users” and “/users/*”).
To enforce HTTPS and reject HTTP on those external connections, set insecureEdgeTerminationPolicy on the Route.
3. Running Images as Root
As noted, images typically cannot run as root. Images that require root should ideally be rewritten to avoid assuming a specific user (OpenShift assigns a random user ID) or configured to use a specified non-root user. If neither is possible, containers can run as root by adding the anyuid Security Context Constraint (SCC) to the Deployment.
4. Google Resource Credentials
In GKE, resource credentials are accessed internally within the Google domain.
In OpenShift, credentials are stored as secrets, with a GOOGLE_APPLICATION_CREDENTIALS environment variable added to the Deployment referencing that secret.
Changes not done
While the migration focused primarily on moving the application logic and containerized workloads, some components were intentionally left unchanged to reduce complexity. The AI chat application relied on a database hosted on Google Cloud Platform (GCP). Instead of migrating the database as part of this project, the OpenShift deployment continued to connect securely to the existing GCP-hosted database. This approach allowed the team to focus on the core objective - migrating the application itself- while maintaining operational stability.
Future Considerations
If we undertake similar migrations in the future, additional improvements could include:
- Retaining Kubernetes Ingress definitions for hybrid compatibility, though this may introduce extra complexity.
- Migrating supporting services (e.g., databases) into OpenShift for tighter integration, unified management, and improved performance.
These steps could help streamline operations further and fully leverage OpenShift’s enterprise-grade capabilities across the entire workload ecosystem.
Summary
This case study of migrating from GKE to OpenShift demonstrates how containerized workloads can be transitioned with minimal changes to existing Kubernetes configurations while taking full advantage of OpenShift’s enterprise features. Red Hat OpenShift provides a robust, enterprise-ready Kubernetes platform for AI-powered applications.
At intive, our decade-long experience as a Red Hat partner ensures migrations are smooth, efficient and aligned with best practices. If you’re looking to migrate or scale your applications on Red Hat OpenShift - explore our Red Hat services.
.png)
.png)
.png)
.png)
.png)
.png)