Migrate for Anthos supplies tools that you run on a VM workload to determine the workload's fit for migration to a container. For more information, see:
Migrate for Anthos is recommended for certain types of Linux and Windows workloads, which are detailed below.
Linux applications that are a good fit for migration using Migrate for Anthos include the following application architectures:
- Web / Application Servers
- Business logic Middleware (for example, Tomcat)
- Multi-VM, multi-tier stacks (for example, LAMP)
- Small/Medium sized Databases (for example, MySQL and PostgreSQL)
In addition, applications best suited for migration with Migrate for Anthos have the following operational characteristics:
- Low duty-cycle & bursty workloads
- Development, testing and training lab environments
- Always-on, low load services
In general, most Linux workloads are compatible with migration, except for those explicitly listed below under Not a good fit.
Windows applications that are a good fit for migration using Migrate for Anthos include workloads that meet all of the following characteristics:
- IIS 7 or later, ASP.NET with .NET Framework 3.5 or later
- Web and logic tiers
- WS2008 R2 or higher
Operating system support
Migrate for Anthos is compatible with these VM operating systems.
Not a good fit
For Linux, applications and servers that are not a good fit for migration with Migrate for Anthos include:
- High performance and large in-memory databases
- VMs with special kernel drivers (for example, kernel-mode NFS)
- Dependencies on specific hardware
- Software with licenses tied to certain hardware ID registration
For Windows, workloads without IIS 7 or higher installed are not a fit for migration. Other types of applications not fit for migration include:
- Applications with dependencies on GPUs or TPUs
- Low level networking applications
- Desktop, RDP, and VDI applications
- Applications with BYOL
DNS and network access rules
Before migrating to GKE, be sure you understand the network resources and services used by your migrated workloads, and ensure that they are accessible and addressable from your Virtual Private Cloud.
Plan your Kubernetes service names
The deployment spec generated by the migration process
contains a suggested headless
Service object of type "ClusterIP". This means
no load-balancing, and a single cluster internal IP reachable only from within
the cluster. The Kubernetes endpoints controller will modify the DNS configuration
to return records (addresses) that point to the Pods, which are labeled with
"app": "app-name" in the deployment_spec.yaml.
Create and apply services for connections to pods and containers
After migrating a workload, hostnames are no longer applicable. To allow connections to your workloads, create and apply services.
Identify and configure migrated names and IPs
GKE manages the /etc/hosts file. In Migrate for Anthos, adapting the hosts file from the source VM to GKE is not yet automated. The names and IPs in the hosts file on the migrated VM need to be identified and configured as hostAliases.
Place dependent services in the same namespace
Services that are dependent on each other should be co-located in the same
and use short DNS names (for example
db) to communicate. This
configuration also helps to replicate multiple application environments, such
as production, staging, and test.
Control access surface with GKE networking
GKE has sophisticated networking controls. Pods can be accessed from different networks, such as the public Internet, VPC network, or internal cluster network. This offers the opportunity to further control and restrict the access surface to a workload without the added complexity of managing VLANs, filters, or routing rules.
For example, a typical three-tier application has frontend, application, and database tiers. When migrated to Google Cloud, the frontend service is configured with a LoadBalancer on the VPC network.The other tiers will not be directly accessible from outside the GKE cluster. A network access policy ensures the application service is accessible only by the frontend pods from inside the internal cluster network. Another policy ensures the database pods are accessible only by the application pods.
Define NFS mounts as Persistent Volumes
NFS client mounts are not configured automatically after migration with Migrate for Anthos. These NFS mounts will need to be defined in the Pod's YAML as NFS Persistent Volumes. See detailed instructions on mounting external volumes in Migrate for Anthos containers at Mounting external volumes.
Kernel-mode NFS servers
VMs with NFS servers running in kernel-mode cannot be migrated into GKE with Migrate for Anthos. They will need to be migrated into VMs on Compute Engine. Alternatively, you can use Filestore for a cloud-native NFS solution.
Migrating data from source NFS shares
If your source VM is using an NFS share mount, this data will not be migrated automatically. Either mount the share on the migrated workload container using an NFS persistent volume, or -- if the source NFS share is remote -- copy the data to another file share that provides lower latency access to the cluster.
For data copy options, see the following:
Cloud Data Transfer Service or Data Transfer Appliance
Copying data with gsutil rsync (from source file share to bucket and then from bucket to the file share in cloud).
3rd party solutions, such as NetApp SnapMirror to NetApp Cloud Volumes.
OSS utilities such as Rsync.
Ensure that injected metadata is available
If your applications rely on injected metadata (for example, environment variables), you will need to ensure that these are available on GKE. If the same metadata injection method is not available, GKE offers ConfigMaps and Secrets.
Configure necessary services to start at runlevel 3
Migrate for Anthos workloads reach runlevel 3 only. VMs migrated into GKE with Migrate for Anthos will be booted in the container at Linux runlevel 3. Certain services (for example X11 or XDM, for remote GUI access using VNC) are configured by default to start only at runlevel 5. Any necessary services should be configured to start at runlevel 3.
Disable unneeded services
Migrate for Anthos will automatically disable hardware- or environment- specific services, as well as a pre-defined set of additional services running on VMs. The list of these services is below.
Services disabled by Migrate for Anthos
|Type of Service||Service names|
|Boot||boot.apparmor, boot.clock, boot.crypto, boot.crypto-early, boot.debugfs, boot.device-mapper, boot.dmraid, boot.kdump, boot.klog, boot.loadmodules, boot.lvm, boot.lvm_monitor, boot.md, boot.multipath, boot.open-iscsi, boot.sysctl|
|Compute Engine||cloud-init, cloud-init-local, cloud-final, cloud-config, google-accounts-daemon, google-clock-skew-daemon, google-instance-setup, google-network-daemon, google-shutdown-scripts, google-startup-scripts|
|Firewalls||iptables, ip6tables, firewalld|
|GUI||xdm, splash, splash_early|
|Hardware related||microcode, microcode.ctl, mcelog, irqbalance, irq_balancer, acpid, hald, - haldaemon, alsasound, ondemand|
|Linux Volume Manager||lvm2-lvmetad, lvm2-monitor|
|Multipath and iSCSI||multipathd, iscsid, iscsi, open-iscsi|
|Snap||snapd, snapd.autoimport, snapd.core-fixup, snapd.seeded|
|Systemd||systemd-modules-load, sys-kernel-config.mount, dev-hugepages.mount, systemd-journald-audit.socket, var-lib-nfs-rpc_pipefs.mount|
Customizing disabled services
By default, Migrate for Anthos disables the unneeded services listed above. You can also define your own custom list of services to disable in a migrated container by using a custom blocklist. With a blocklist, you specify one or more services to disable in a migrated container.
Maintain and update migrated VMs
Using the artifacts you generate during migration, you can apply application and user-mode OS software updates, security patches, editing embedded configurations, adding or replacing files, and for updating the Migrate for Anthos runtime software.
For more, see Post-migration image updates.