Migrate and deploy applications to GKE Autopilot clusters

To deploy your migrated container workloads to GKE Autopilot clusters, you use the same procedure to migrate your workloads as you use for the existing architecture. The only changes are that:

  • You have to set v2kServiceManager to true in the migration plan before you generate the container artifacts.

  • You have to review the new services-config.yaml file and make any edits to the initialization services. See Using services-config.yaml.

To perform a migration:

  1. Install Migrate to Containers version 1.15.0.

  2. Add a migration source and create a migration as you do today with the existing runtime.

  3. Customize your migration plan as necessary.

    1. Download the migration plan. The migration plan is represented by AppXGenerateArtifactsFlow.

      For example, for a migration named "my-migration":

      migctl migration get my-migration

    2. Open the downloaded migration plan, my-migration.yaml, in a text editor.

    3. Verify the enhanced Linux service manager. The v2kServiceManager flag is set to true by default. However, if Migrate to Containers detects a system service that is not supported by the service manager, you will be alerted and the v2kServiceManager flag will be set to false. When the flag is false the migration will use a legacy runtime which supports your service.

      The following alert is provided alongside the unsupported service:

      Service is not supported by v2k service manager, therefore legacy runtime
will be used instead of v2k service manager, and migrated workload would
not fit running on Autopilot clusters of Cloudrun.

      When an unsupported service is found, you can also choose to manually set the flag to true. In this instance, you can either choose to keep the unsupported service on the generated image where it may not run or you can exclude the service by removing it from the migration plan.

      To enable the new service manager, reset the flag to true:

      v2kServiceManager: true

    4. Perform any other customizations necessary for your migration as described in Customize the migration plan.

    5. When your edits are complete, save the edited file.

    6. Upload the edited migration plan:

      migctl migration update my-migration --main-config my-migration.yaml

  4. Generate and review the migration artifacts as you do today with the existing runtime.

  5. Edit the new services-config.yaml file to configure the initialization properties of the container. Save the file and rebuild your container image to apply the changes.

    See Using services-config.yaml for more.

  6. Deploy the container to a GKE Autopilot cluster using kubectl:

    kubectl apply -f deployment_spec.yaml

Example: Deploying the Quickstart container on an Autopilot cluster

Use the current Quickstart guide to migrate a container containing a simple web server and then deploy it on an Autopilot cluster. The only changes that you have to make to the Quickstart process are:

  1. In Step 3 of Migrating the VM, where you review the migration plan, set v2kServiceManager to true in the migration plan and then save the plan:

     
v2kServiceManager: true

  2. In the Deploying the migrated workload section, create and connect to a GKE Autopilot cluster before you deploy the container:

    1. Create a GKE Autopilot cluster:

      gcloud container clusters create-auto "CLUSTER_NAME"
--project "PROJECT_NAME"  --region "REGION" --release-channel "regular"
--subnetwork "projects/PROJECT_NAME/regions/us-central1/subnetworks/default"

    2. Connect to the cluster:

      gcloud container clusters get-credentials CLUSTER_NAME 
  --zone REGION --project PROJECT_NAME

    3. Deploy the container as described in the Deploying the migrated workload section.

Changes to the AppXGenerateArtifactsFlow CRD

If you are using CRD files to control your migration, edit the AppXGenerateArtifactsFlow CRD to set v2kServiceManager to true. See Customizing a migration plan for more on using CRD files to control migration.

What's next