Migrate for Anthos architecture

This topic provides a high-level description of how Migrate for Anthos transforms your applications residing on VMs into containers on Google Kubernetes Engine (GKE) or Anthos.

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.

    The processing cluster can be an existing cluster or a separately configured cluster for migration activities (recommended). The processing cluster is where the Migrate for Anthos components are installed. After containers are generated and no further migrations are needed, you can delete the processing cluster or uninstall the Migrate for Anthos setup.

  • Control -- The migration CRD, CLI utility (migctl), and Google Cloud Console are the main interfaces by which migration is configured and operated. These operations 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 migrations, including status, progress, and logs.

  • Workload execution -- Migrated container workloads can execute on any GKE or Anthos 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. The 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 or Anthos services.

      • Runs the applications and services from the VM's user-space (for example, those launched by SysV-style or systemd init 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.

  • Maintenance -- Once migrated, container workloads typically involve "day-2" maintenance operations -- whether due to required package updates, changes to embedded files, or for 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.

About Migrate for Compute Engine

With Migrate for Anthos, you containerize existing VM-based applications to run on Google Kubernetes Engine (GKE) or Anthos clusters.

Along with Migrate for Anthos, you can also use Migrate for Compute Engine to migrate your workloads to Google Cloud. Use Migrate for Compute Engine to migrate workloads to VMs running on Compute Engine instances on Google Cloud.

You might decide to break your migration journey into two distinct phases, even for workloads that are suitable for containers:

  1. Migrate workloads to Compute Engine with Migrate for Compute Engine.

  2. Migrate from Compute Engine to containers 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 modernize suitable workloads to containers.

Using Migrate for Compute Engine with Migrate for Anthos

In one scenario, you must use Migrate for Compute Engine along with Migrate for Anthos to containerize your VM workloads. For workloads on VMware, AWS, or Azure, when the target is Google Cloud, you must install Migrate for Compute Engine to facilitate the transfer of workloads into Google Cloud.