Migrate to Containers architecture
Migrate to Containers components
The Migrate to Containers solution spans four operational tiers:
Processing -- A GKE or Anthos processing cluster to run the Migrate to Containers 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 to Containers components are installed. After containers are generated and no further migrations are needed, you can delete the processing cluster or uninstall the Migrate to Containers setup.
VMware VMs targeted to be deployed as containers on-premises require an Anthos clusters on VMware.
AWS VMs targeted to be deployed as containers on-premises require an Anthos clusters on AWS.
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 to Containers 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 to Containers runtime software is embedded, as a Google-provided container image layer, in the migrated workload container image. The Migrate to Containers 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
systemdinit scripts) within the container. Certain VM- or hardware-related services are automatically disabled.
For Windows workloads, Migrate to Containers 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 to Containers 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 to VMs
Along with Migrate to Containers, you can also use Migrate to VMs to migrate your workloads to Google Cloud. Use Migrate to VMs 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:
Migrate workloads to Compute Engine with Migrate to VMs.
Migrate from Compute Engine to containers with Migrate to Containers.
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 to VMs with Migrate to Containers
In one scenario, you must use Migrate to VMs along with Migrate to Containers to containerize your VM workloads. For workloads on VMware, AWS, or Azure, when the target is Google Cloud, you must install Migrate to VMs to facilitate the transfer of workloads into Google Cloud.