This topic provides a high-level description of how Migrate for Anthos transforms your applications residing on VMs into containers on on Google Kubernetes Engine (GKE) or Anthos. At a high level, you can use Migrate for Anthos to migrate workloads residing on either VMware on-prem, AWS, Azure, or from Compute Engine (for previously migrated or cloud-native VM-based workloads).
Migrate for Anthos components
The Migrate for Anthos solution spans four operational tiers:
Processing -- A GKE or Anthos processing cluster to run the Migrate for Anthos components that perform the transformations required during workload migration from a source VM to the target container artifacts.
For Azure and AWS VMs, and for VMware VMs migrated to Google Cloud, the processing clusters can be a GKE or Anthos cluster on Google Cloud.
VMware VMs targeted to be deployed as containers on-prem require a Anthos clusters on VMware cluster.
For Linux workloads, the artifacts include a container image, Dockerfile, data volume and reference deployment YAMLs.
For Windows workloads, the artifacts include a workload's content archive in ZIP file format that includes a Dockerfile. The processing cluster may be an existing workload cluster or a separately-configured cluster for migration activities (recommended). This is where the Migrate for Compute Engine installation is applied. After container artifacts are generated and no further migrations are needed, you can delete the processing cluster or uninstall the Migrate for Compute Engine setup.
Control -- The migration CRD and CLI utility (
migctl) for Linux and Windows workloads, and the Google Cloud Console UI for Linux workloads, are the main interfaces by which migration is configured and operated. These include:
- Installing/uninstalling Migrate for Anthos on a processing cluster, and validating the deployment.
- Configuring migration sources.
- Managing migration workflow actions.
- Providing visibility of your Migrate for Anthos migrations, including status, progress, and logs.
Workload execution -- Migrated workloads can execute on any GKE cluster meeting the minimum requirements.
- For Linux workloads, the Migrate for Anthos runtime software is embedded,
as a Google-provided container image layer, in the migrated workload container
image. This Migrate for Anthos runtime layer:
- Replaces the VM's operating system kernel with the kernel loaded by the GKE node.
- Configures the container's network interfaces, DNS, console output, system and application logging, and health status to use GKE services.
- Runs the applications and services from the VM's user-space (for example,
those launched by SysV-style or
systemdinit scripts) within the container. Certain VM- or hardware-related services are automatically disabled.
- For Windows workloads, Migrate for Anthos generates a detailed Dockerfile. The Dockerfile derives from the official Microsoft Windows Server images and the automatically extracted application content ZIP file to define a ready-to-build, deploy-anywhere, migrated workload image.
- For Linux workloads, the Migrate for Anthos runtime software is embedded, as a Google-provided container image layer, in the migrated workload container image. This Migrate for Anthos runtime layer:
Maintenance -- Once migrated, workload images will typically involve "day-2" maintenance operations -- whether due to required package updates, changes to embedded files, or in case of Linux workloads, updates to the Migrate for Anthos runtime software. The extracted workload content and the generated Dockerfile can be integrated in a CI/CD pipeline for efficient image-based maintenance.