Migrate for Anthos — Application Migration and Modernization
Migration involves lifting and shifting virtual machines/legacy applications running on physical servers into public cloud platforms which offer many benefits, including enhanced agility, significantly reduced overhead compared to a data center, and a standard usage and management environment. The first step of modernizing an application is to break an application into a set of container images that include everything needed to run a portion of the application: code, runtime, system tools, system libraries, and settings. With Kubernetes all these containers can be hosted on a “managed” cluster where all the underlying Hardware, OS/Kernel and Cluster SRE (Site Reliability Engineering) become the responsibility of the cloud provider.
Migrate for Anthos addresses both migration and modernization providing an almost real-time solution to take an existing VM and make it available as a Kubernetes hosted pod with all the values associated with executing the applications in a Kubernetes cluster. This framework minimizes the manual effort required to move and convert existing applications into containers on Anthos GKE and Google Kubernetes Engine. Users can target workloads from virtual machines or physical servers running on-premises, in Compute Engine, or in other clouds.
For containerizing the virtual machines Migrate for Anthos creates a wrapper container image from the source VM, the OS is replaced with the one supported by GKE, the filesystem is analyzed by parsing fstab and then a Persistent Volume is mounted using Migrate for Anthos Container Storage Interface (CSI) driver which streams the data from the source VM.
Migrate for Anthos converts the source VMs to system containers running in GKE. System containers when compared to application containers run multiple processes and applications in a single container. Although, the application is not converted to true microservice architecture, there are some basic advantages with containerizing the monolith application which includes portability, better packing and containerization virtualize applications at the operating system level, with multiple containers running atop the OS kernel directly, making them far more lightweight and agile than VMs, providing developers with a sandboxed view of the OS logically isolated from other applications.
The tool provides an easy-to-use interface to plan, execute and manage the migration using declarative specification. All controllers run on a processing-cluster (GKE Cluster), users can manage all aspects of migration using CRD’s.
Migrate for Anthos works alongside Migrate for Compute Engine (in cloud-to-cloud migration scenario, not needed when the SourceProvider is Google Compute Engine) which uses streaming technology, where the complete VM storage need not be migrated to run the container in GKE, this speeds up the entire migration process. Formerly Velostrata — this cloud migration technology was acquired by Google last year to augment Kubernetes, and it does so by delivering on two significant capabilities — converting existing VMs into Pods (Kubernetes applications) and streaming on-premise virtual and physical machines to generate clones in GCE instances.
Migration — Sequence of Steps
Google Compute Engine (Virtual Machine) to Google Kubernetes Engine (Kubernetes Deployment)
A sample workflow below shows sequence of steps and explanation of components involved in migrating a sample Apache Tomcat application running as virtual machine on GCE (Google Compute Engine) to a Kubernetes Deployment running on GKE (Google Kubernetes Engine) using Migrate for Anthos.
The migration source here is GCE and there is no need of Migrate for Compute Engine (formerly Velostrata).
The migration architecture involves a GKE cluster to host various controllers required for migration and is referred as ‘processing cluster’. Once the migration is complete all the artifacts are stored in GCS (Google Cloud Storage) and the generated container image is pushed to GCR (Google Container Registry).
Migration (setting up and managing a Migrate) can be performed using Migrate for Anthos CLI (migctl) available in cloud shell or using the Anthos portal (Migrate to containers).
The sequence of steps in migrating a VM to a container, followed by its deployment on GKE is as shown below:
A sample Tomcat application deployed from marketplace is used for tryout, the application is deployed to a single Compute Engine instance.
As shown below the application is fully functional displaying default webpage when accessed using the External_IP.
Setup Migrate for Anthos
A GKE cluster called ‘processing cluster’ is created, this will host all required Migrate for Anthos controllers, CRD’s and other components required to perform the migration.
Once the GKE cluster is available, users can use ‘migctl’ (Migrate for Anthos CLI) to bootstrap required infra.
As shown below the ‘migctl setup install’ creates an admission-validator, csi-vlsdisk-controller, csi-vlsdisk-node, v2k-controller-manager, v2k-generic-csi-controller, v2k-generic-csi-node. Apart from these, a cert-deploy job is created which creates required certificates for webhook authentication and a controllers-upgrade job which upgrades the controllers to the latest version.
As part of bootstrap, multiple CRD’s are installed on the cluster. Every migration unit/step/configuration persists in the cluster as a custom resource.
As part of bootstrap a bucket is created in GCS (Google Cloud Storage) which stores the artifacts once the migration is complete.
Configuring Source Provider and Machine
The migration requires users to define a source where the instance is migrated from. Supported sources include VMware, AWS, Azure, or Compute Engine. If the migration is from CE (Google Compute Engine) there is no need for Migrate for Compute Engine, Migrate for Compute Engine is required when migrating virtual machines (VMs) running on other clouds including on-premises (VMware).
The SourceProvider is used in migration configuration. Migration configuration can be customized: Selection of areas excluded from containerization, Selection of area to be extracted as Persistent Volume, Artifacts storage location information, storage settings, etc. , shown below is the SourceProvider (for CE) and Migration CRD:
Users can use ‘migctl’ to configure the SourceProvider and the cluster can have multiple SourceProvider(s) objects which can be used in different Migration configurations.
As shown above, the controller manager watches for Anthos Migrate related objects and realize the same on the cluster.
A CRD SourceProvider holds the information provided above, here the SourceProvider is Compute Engine.
Create Migration Plan
Migration of a VM is initiated by starting migration from portal or using the CLI. This results in creation of a migration plan file. This is implemented as a Kubernetes Custom Resource Definition (CRD) and is contained along with additional resources such as a Kubernetes PersistentVolumeClaim in the migration plan file.
The migration plan is created as a custom resource and the same can be edited using Anthos portal or editing the Migration object from the cluster.
A migration plan can be customized based on the nature of the workload using an intent flag. The flag’s value determines the contents of your migration plan, which in turn guides the migration.
There are three intents supported in the migration schema. Image: Used with stateless workloads, ImageAndData: Used with stateful workloads where the application and user mode system is extracted to a container image, and data is extracted to a persistent volume, Data: Used with stateful workloads where only the data portion of the migration plan will be extracted into a persistent volume.
- Specifying content to exclude from the migration (Intent: Any):
By default, Migrate for Anthos will exclude typical VM content that isn’t relevant in the context of GKE. The filters field value lists paths that should be excluded from migration and will not be part of either the container image or the data volume.
- Setting handling for the data volume (Intent: Data or ImageAndData):
The dataVolumes field specifies a list of folders to include in the data volume as part of the migration. This must be edited for a migration with an intent of Data or ImageAndData.
- Setting the migration’s name and namespace (Intent: Any):
Using the metadata field, users can specify the name and namespace for the migration. By default, Migrate for Anthos uses the values specified in the migration spec.
- Setting the name of the container image (Intent: Image or ImageAndData):
Name of the image that will be created from the VM files and directories copied from the source platform. This image will not be runnable on GKE because it hasn’t been adapted for deployment there.
- Setting the Cloud Storage location for deployment artifacts (Intent: Any):
Migrate for Anthos uses Cloud Storage to store files related to migration, bucket and folder names can be customized.
This step also creates initial disk snapshots/copies and stores the same in a persistent volume and seamlessly creates PV’s and PVC’s required for the same.
Migration Plan Execution
This stage executes the migration plan and the following tasks are executed:
- Copy files and directories representing the VM to a container image registry as images.
- Migrate for Anthos creates two images: a runnable image for deployment to another cluster and a non-runnable image layer that can be used to update the container image in the future. All the images along with the layers are pushed to GCR.
- Generate configuration YAML files that can be used to deploy the VM to Kubernetes cluster.
The controller creates a job for generating the artifacts and uploading the image to GCR:
Once the migration is complete the migration details — artifacts section will list all the resource URL’s. Generate artifacts creates a Dockerfile, Container image for deployment (ready-to-use image), Container image base layer (non-runnable image layers), Kubernetes deployment spec, Migration plan and a file with all artifact links.
All the artifacts generated above are stored in GCS (Google Cloud Storage):
Separate buckets are created for artifacts and image layers:
The buckets are created by PVC’s requesting storage (StorageClass: <GCS>) and the corresponding persistent volumes are created in the cluster.
Generated image is pushed to GCR (Google Container Registry) and the same is configured in deployment spec.
Generated Dockerfile:
File with all artifact links:
Generated Deployment spec:
The generated deployment file can be used to deploy the migrated application as a Kubernetes deployment.
The deployment spec will be configured with the image pushed to GCR:
As shown below the application is fully functional and running as a Kubernetes pod.
Users can use all the features of GKE and other supporting operations, monitoring and networking features available on GCE with the migrated application.
Virtual Machines from other Clouds and On-Premises (VMware) to Google Kubernetes Engine (cloud-to-cloud migrations)
In this scenario, Migrate for Anthos uses Migrate for Compute Manager which streams cloud or on-premise virtual and physical machines to generate clones in GCE instances.
As the other scenario discussed above is within GCP there is no need for this entity, here VM’s from external cloud providers are migrated (cloned) to GCE and follows the same steps to migrate the VM to a container once the VM is available on GCE. Communication between Migrate for Compute Engine and the source cloud will be via VPN.
Apart from setting up VPN and configuring a Migrate for Compute manager, the VM -> Container migration involves the same steps as CE — SourceProvider.
Migrate for Compute Engine (formerly Velostrata) is available in marketplace and is deployed as a managed instance.
Deploying Migration Manager requires users to enable site-to-site VPN and required firewalls to enable communication between the VPC in which the manager is positioned and the VPC of the source VM on the other cloud.
As shown in the scenario below, a site-to-site VPN is created between GCP and AWS. The same implies to Azure:
As shown below GCP uses Cloud Router that works over Cloud VPN or Cloud Interconnect connections to provide dynamic routing by using the Border Gateway Protocol (BGP) for your VPC networks.
AWS site-to-site VPN:
The manager requires specific permissions to handle the instances like switch-off, switch-on etc., this can be enabled using policies attached to a user and providing the user keys while configuring the manager. An example on AWS is as below:
Once the migration manager is deployed users can configure the same using the portal/UI. Users should provide authentication to both source and destination clouds. For GCP it is using the service-account-json file and for AWS it is AcessKey and SecurityKey.
A Cloud Extension is configured which creates required VM’s on GCP (destination). A Cloud Extension uses a dual-node active/passive configuration for high availability; each node serves its own workloads while providing backup for the other.
Runbooks are configured which define the VMs to be migrated, their order, and additional configuration parameters.
Migrate for Anthos ServiceProvider spec should be configured with the manager information to enable migration, in this case there are two steps where the first migrates (technically creates a clone as GCE instances) the VM from an other cloud provider and secondly containerizing the same. Spec for migrating to compute engine from other clouds and on-prem is as shown below:
*******************************************************************
Accelerating the migration and adoption of the modern platform enables the business to operate more efficiently with unified policy, management, and skill sets across existing and newly developed apps.
When workloads are upgraded to containers running on managed Kubernetes clusters like GKE, IT departments can eliminate OS-level maintenance and security patching for VMs and automate at scale. Legacy apps that are migrated into GKE can be easily upgraded with modern functionality and a large set of available/maintained add-ons can be used for integration without having to rewrite application code.
