Migrating containers to Google Cloud: Migrating from OpenShift to GKE Enterprise

This document helps you plan, design, and implement your migration from OpenShift to GKE Enterprise. If done incorrectly, moving your workloads from one environment to another can be a challenging task, so plan and execute your migration carefully.

This document is part of a multi-part series about migrating to Google Cloud. If you're interested in an overview of the series, see Migration to Google Cloud: Choosing your migration path.

This document is part of a series that discusses migrating containers to Google Cloud:

This document is useful if you're planning to migrate from OpenShift running in an on-premises or private hosting environment, or in another cloud provider, to GKE Enterprise. This document is also useful if you're evaluating the opportunity to migrate and want to explore what it might look like. The target environment can be one of the following:

  • A hosted environment entirely on Google Cloud.
  • A hybrid environment where you maintain part of your workload on-premises or in a private hosting environment and migrate the rest to Google Cloud.

To decide which environment suits your needs, consider your requirements. For example, you can focus on increasing the value of your business instead of worrying about the infrastructure, by migrating to a public cloud environment and outsourcing some responsibilities to Google. You benefit from an elastic consumption model to optimize your spending and resource usage. If you have any requirements, such that you have to keep some of your workloads outside Google Cloud, you might consider a hybrid environment, for example, if you're required to keep part of your workloads in your current environment to comply with data location policies and regulations. Or, you can implement an improve and move migration strategy, where you first modernize your workloads in place, and then migrate to Google Cloud.

Regardless of your target environment type, the goal of this migration is to manage your workloads running in that environment using GKE Enterprise. By adopting GKE Enterprise, you have access to a range of services, including the following:

  • Multi-cluster management to help you and your organization manage clusters, infrastructure, and workloads across cloud and on-premises environments from a single place.
  • Config Sync and Policy Controller to create a common configuration and policies across all your infrastructure, and to apply them both on-premises and in the cloud.
  • Anthos Service Mesh to adopt a fully managed service mesh that simplifies operating services, traffic management, telemetry, and securing communications between services.
  • Binary Authorization to help ensure that the containers you deploy in your environments are trusted.
  • Cloud Run for Anthos to support your serverless workloads in your GKE Enterprise environment.

We recommend that you evaluate these services early in your migration process while you're still designing your migration. It's easier to adopt these services now, instead of modifying your processes and infrastructure later. You can start using these services immediately, or when you're ready to modernize your workloads.

In this migration, you follow the migration framework defined in Migration to Google Cloud: Getting started. The framework has four phases:

  1. Assessing and discovering your workloads.
  2. Planning and building a foundation.
  3. Deploying your workloads.
  4. Optimizing your environment.

The following diagram illustrates the path of your migration journey.

Migration path with four phases.

This document relies on concepts covered in Migrating containers to Google Cloud: Migrating Kubernetes to GKE, so there are links to that document, where appropriate.

Assessing and discovering your workloads

In the assessment phase, you determine the requirements and dependencies to migrate to your workloads from OpenShift to GKE Enterprise:

  1. Build a comprehensive inventory of your processes and apps.
  2. Catalog your processes and apps according to their properties and dependencies.
  3. Train and educate your teams on Google Cloud.
  4. Build experiments and proofs-of-concept on Google Cloud.
  5. Calculate the total cost of ownership (TCO) of the target environment.
  6. Choose the workloads that you want to migrate first.

The following sections rely on Migration to Google Cloud: Assessing and discovering your workloads, but they provide information that is specific to assessing workloads that you want to migrate from OpenShift to GKE Enterprise.

Build your inventories

To build the inventory of the components of your environment, consider the following:

  • Service delivery and platform management model
  • OpenShift projects
  • Build and deployment process
  • Workloads, requirements, and dependencies
  • OpenShift clusters configuration

Service delivery and platform management model

To migrate workloads from OpenShift to GKE Enterprise, you assess the current service delivery and platform management model of your OpenShift environment. This model probably reflects your current organizational structure and needs. If you realize that the current model doesn't satisfy the organization needs, you can use this migration as an opportunity to improve the model.

First, you gather information about the teams responsible for the following aspects:

  • Application development and deployment, including all OpenShift users, typically development, or workload release teams.
  • OpenShift platform management, including creating OpenShift projects, assigning roles to users, configuring security contexts, and configuring CI/CD pipelines.
  • OpenShift installation and cluster management, including OpenShift installation, upgrade, cluster scaling, and capacity management.
  • Infrastructure management. These teams manage physical servers, storage, networking, the virtualization platform, and operating systems.

A service delivery and platform management model can consist of the following teams:

  • The development team. This team develops workloads and deploys them on OpenShift. When dealing with complex production environments, the team that deploys workloads might be different from the development team. For simplicity in this document, we consider this team to be part of the development team. In self-service environments, the development team also has the responsibility of creating OpenShift projects.
  • The platform team. This team is responsible for OpenShift platform management, typically referred to as OpenShift cluster administrators. This team configures OpenShift project templates for different development teams and, in more managed environments, creates OpenShift projects. This team also assigns roles and permissions, configures security contexts and role-based access control (RBAC), defines quotas for compute resources and objects, and defines build and deployment strategies. They are sometimes referred to as the DevOps team or as the middleware team, if they manage middleware and application server configurations for developers. The platform team and the infrastructure team might also be involved in low-level OpenShift cluster management activities, such as software installation and upgrade, cluster scaling, and capacity management.
  • The infrastructure team. This team manages the underlying infrastructure that supports the OpenShift environment. For example, they're in charge of servers, storage, networking, the virtualization platform, and the base operating system. This team is sometimes referred to as the data center team or operations team. If OpenShift is deployed in a public cloud environment, this team is responsible for the infrastructure as a service (IaaS) services that a public cloud provider offers.

It's also important to assess if you have dedicated OpenShift clusters for different environments. For example, you might have different environments for development, quality assurance, and production, or to segregate different network and security zones, such as internal zones and de-militarized zones.

OpenShift projects

An OpenShift project is a Kubernetes namespace with additional annotations that lets developers manage resources in isolation from other teams to logically separate resources. To build the inventory of your OpenShift projects, consider the following for each project:

  • Cluster roles and local roles. OpenShift supports both roles that are local to an OpenShift project, or cluster-wide roles. You assess if you created any cluster and local roles to design an effective access control mechanism in the target environment.
  • Role bindings, both for cluster roles and local roles. Users and groups are granted permissions to perform operations on OpenShift projects by assigning them role bindings. Roles can be at the cluster level or the local level. Often, local role bindings are bound to predefined cluster roles. For example, the default OpenShift project admin role binding might be bound to the default cluster admin role.
  • ResourceQuotas. To constrain aggregate resource consumption, OpenShift lets you define both OpenShift project-level quotas, and quotas across multiple OpenShift projects. You assess how they map to Kubernetes ResourceQuotas, and populate a list of all ResourceQuotas that you provisioned and configured in your OpenShift environment.

Assessing your environment describes how to assess Kubernetes resources, such as ServiceAccounts, and PersistentVolumes.

Build and deployment processes

After gathering information about the service delivery and platform management model, and about OpenShift projects, you assess how you're building your workloads and deploying them in your environment.

In your existing OpenShift environment, you might have the same building and deployment process for all your workloads, or there might be different processes to assess. Artifacts of the building process for a containerized workload are container images. In an OpenShift environment, you might be building container images, storing them, and deploying them in different ways:

After building each container image, you store it in a container registry that you can later deploy. Your container registry can be hosted either on OpenShift, or outside your OpenShift environment. Assess this aspect because you might need a similar system in your target environment.

Workloads, requirements, and dependencies

Each OpenShift application contains the following components:

Depending on the purpose of the application, you can use different objects to define the app instead of using the Deployment or DeploymentConfig objects:

  • Define batch applications using Job or cron job.
  • Define stateful applications using StatefulSets.
  • If you have operations-related workloads that need to run on every node, or be bound to specific nodes, you can define them by using DaemonSets.

The following table lists the most important specs and parameters that you gather from OpenShift resources in order to migrate the applications to the target GKE Enterprise environment.

Source OpenShift resource manifest Most important specs and parameters
Deployment, DeploymentConfig, StatefulSet, Job, cron job Container image and repository, container port, number of Pod replicas, ConfigMaps, Secrets, PersistentVolumeClaims, resource requests and limits, update strategy, StatefulSet Service Name, cron job schedule
ImageStream Container image, image pull policy, container image repository
Horizontal Pod Autoscaler Autoscale criteria
Service Hostname used to connect to the application from inside the cluster, IP address and port on which the Service is exposed, endpoints created for external resources
Route Hostname and resource path that is used to connect to the application from outside the cluster, routing rules, encryption, certificate chain information

Assessing your environment describes how to assess Kubernetes resources such as the following:

OpenShift 4 introduced the Operator Framework. If you are using this OpenShift version, you might have deployed some applications using installed Operators. In this case, you get the list of the installed Operators and you gather information for each of them about the deployed Operator instances. These instances are Operator-defined Custom Resources that deploy some of the previously listed Kubernetes Resources.

In addition to assessing these resources, you assess the following:

  • Application's network connectivity requirements. For example, do your Services or Pods need to be exposed to a specific network? Do they need to reach specific backend systems?
  • Constraints to run workloads in a specific location. For example, do any workloads or datasets need to remain on-premises to comply with requirements such as latency in communicating with other workloads, policies related to data location, and proximity to users?

OpenShift clusters configuration

Next, you assess your OpenShift clusters. To complete this task, you gather the following information:

  • OpenShift version. OpenShift major versions in scope of this document are OpenShift 3 and OpenShift 4. Different OpenShift versions might have different capabilities. You assess which version of OpenShift you're running to know whether you're using any OpenShift version-specific features.
  • Identity provider used for authentication. For authentication, you might be using the built-in OAuth server, and one or more identity providers.
  • Security Context Constraints. Assess the OpenShift Security Context Constraints that you defined in your clusters, their configuration, and to which users, groups, and service accounts they are assigned.
  • Network policy and isolation. Assess NetworkPolicies, how you configured Pod network isolation, and which OpenShift SDN mode that you configured in your clusters.
  • Monitoring. Assess your current monitoring requirements, and how you provisioned and configured your current monitoring system to decide how to design and implement a monitoring solution in the target environment. This assessment can help you determine whether to use a new monitoring solution or if you can continue to use the existing solution. Many OpenShift versions include a monitoring stack based on Prometheus to monitor system components, which can also be used for application monitoring. When designing your target solution, consider the following:

    • The monitoring solution that you're currently using in your OpenShift environment, for example, an OpenShift-hosted Prometheus, an independent Prometheus- Grafana stack,