This topic describes the recommended sequence of steps that you should take when migrating workloads to GKE.
At a high level, you need to go through a discovery and assessment phase in which you identify what workloads you have, dependencies between them, whether they can be migrated to the cloud.
Next, you engage in a migration planning phase, in which you break down your workload fleet into groups of workloads that are related and should migrate together (based on the outcome of the assessment) and then determine an order of the groups to be migrated.
In addition, you determine which workloads should migrate to GKE versus those that are not suitable for GKE, but can migrate to Compute Engine with Migrate for Compute Engine. Note that you might elect to break the workload migration challenge into two distinct phases, even for workloads that are suitable for GKE:
- Migrate workloads to Compute Engine with Migrate for Compute Engine.
- Migrate from Compute Engine to GKE with Migrate for Anthos.
This method makes sense, for instance, in cases where you want to conduct a data-center migration and migrate all workloads into Compute Engine, and only at a second stage selectively migrate suitable workloads to GKE. As shown in the diagram, once you select the desired path for a certain workload, you have to go through a landing-zone setup migration, and then post migration optimization phases.
Gather the information needed for a migration by understanding your applications and their dependencies. This includes an inventory of:
- The VMs whose workloads you want to migrate.
- Your applications' required network ports and connections.
- Dependencies across app tiers.
- Service name resolution or DNS configuration.
- IT analyst with knowledge of the application's topologies and migration.
Divide your applications into batches and translate the information collected during the discovery step into the Kubernetes model. Your application environments, topologies, namespaces, and policies are centralized in Kubernetes YAML configuration files. Sample YAML files are available.
- Application migration engineer or analyst. This person needs a beginner-level knowledge of the Kubernetes managed object model, GKE deployments, and YAML files.
Landing zone setup
In this step, you will:
- Create or identify the GKE cluster to host your migrated workloads.
- Create VPC network rules and Kubernetes network policies for your applications.
- Apply Kubernetes service definitions.
- Make load balancing choices.
- Configure DNS.
- GKE cluster administrator, familiar with cluster deployment, Google Cloud networking, firewall rules, Cloud Identity and Access Management service accounts and roles, and launching deployments from the Google Cloud marketplace.
Migration to GKE and validation
After your GKE cluster, VPC network, and Migrate for Anthos components are ready to process workloads, you may start the Migrate for Anthos migration workflow for each source VM you wish to migrate. Make sure to assess the compatibility of the source workload and operating system with Migrate for Anthos, following these guidelines. The migration workflow is depicted in the following diagram:
The migration workflow contains the following five steps:
- Generate and review the migration plan -- Using the Migrate for Anthos
migctlCLI for Linux workloads, or migration script for Windows workloads, generate a migration plan, then review and update the plan with input from key stakeholders, such as the application owner, security admin, storage admin, etc.
- Generate artifacts -- Use the migration plan as input to the CLI to process
the source VM and produce the relevant artifacts:
- For Linux workloads -- Container image, Dockerfile, reference deployment YAMLs and, if specified for stateful workloads -- a data volume.
- For Windows workloads -- Extracted application files in a ZIP archive, and a Dockerfile. Note: You will need to build a container image using the Dockerfile and extracted content before you can proceed to the next step.
- Test -- Before you proceed with deployment of the workload for end-to-end application-level validation in a test, staging or production cluster of choice, you may want to verify that the extracted container image and data volume (if applicable) function correctly when executed in a container. You may run a "sanity test" on the processing cluster, identify any issues or edits needed to the migration plan, then repeat step 2 and test again.
- Data sync -- When a stateful workload is being migrated (Linux only) and the workload continues to accumulate new data and state while running at the source, you may want to iterate through one or more data sync cycles before performing a final data sync with the source shut down. This will allow reducing the final cut over downtime. Each data sync execution will only transfer the changed data since the last data sync cycle.
- Deploy or integrate with CI/CD -- With the container artifacts now ready and validated, you may continue with deployment in a test, staging, or production cluster. Alternatively, you may use the artifacts to integrate with a builda nd deploy pipeline using an orchestration tool such as Cloud Build.
- For workload migration:
- Application owner, or Application migration analyst, with beginner knowledge of the Kubernetes managed object model, GKE deployments, and YAML editing.
- OPTIONAL: For data storage migration to a Persistent Volume other than a
- Storage administrator or GKE administrator, familiar with Kubernetes persistent volume management on GKE.
Operate and Optimize
You can now leverage tools provided by Anthos and the larger Kubernetes ecosystem. In this step, you can add access policies, encryption and authentication using Istio, monitoring and logging with Cloud Logging and Cloud Monitoring, all through changing configuration and not rebuilding your applications. You may also integrate with a CI/CD pipeline using tools like Cloud Build to implement day-2 maintenance procedures, such as software package and version updates