Deploying a Linux workload to a target cluster

After you have migrated a workload from your source platform, you can use the deployment artifacts generated by that process to deploy the migrated workload container to another cluster.

The following lists the artifacts that you generate when you execute a migration. For more details, see Reviewing generated deployment files.

  • For using the Image intent in the migration plan:

    • Deployment
    • Service of type ClusterIP.
  • For using the ImageAndData intent in the migration plan:

    • StatefulSet
    • Service of type ClusterIP.
    • PersistentVolumeClaim and PersistentVolume
  • For using the Data intent in the migration plan:

    • PersistentVolumeClaim and PersistentVolume

Before you begin

Before deploying your workload, you should have first:

Apply generated deployment YAML file

Use kubectl to apply the deployment spec to your target cluster, such as a production cluster.


kubectl apply -f deployment_spec.yaml

Anthos clusters on VMware

Before you can deploy a container to your Anthos clusters on VMware cluster, you must ensure that the cluster has access to your private GCR (Google Container Registry). To allow access, create a Kubernetes secret that contains the credentials required to access GCR.

  1. Create a service account for deploying a migration as described in Creating a service account for accessing Container Registry and Cloud Storage.

  2. Create a Kubernetes secret that contains the credentials required to access GCR:

    kubectl create secret docker-registry gcr-json-key \ --docker-username=_json_key --docker-password="$(cat ~/sa.json)" \


    • docker-registry specifies the name of the Kubernetes secret, gcr-json-key in this example.
    • specifies GCR as the server.
    • docker-username=_json_key specifies that the username is contained in the JSON key file.
    • docker-password specifies to use password from the JSON key file.
    • docker-email specifies the email address of the service account.
  3. Set the Kubernetes secret by either:

    • Changing the default imagePullSecrets value:
    kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}
    • Editing the deployment_spec.yaml file to add the imagePullSecrets value to the spec.template.spec definition, as shown below:
      - image:
        name: mycontainer-instance
      - hostPath:
          path: /sys/fs/cgroup
          type: Directory
        name: cgroups
      - name: gcr-json-key
  4. Deploy the container:

    kubectl apply -f deployment_spec.yaml

Deploying a workload to a project other than the one used for migration

Often you will have multiple Google Cloud projects in your environment. If you perform a migration in one project, but then want to deploy the migrated workload to a cluster in a different project, you must ensure that you have the permissions configured correctly.

For example, you perform the migration in project A. In this case, the migrated workload is copied into a Cloud Storage bucket in project A. For example:

You then want to deploy the workload to a cluster in project B. If you do not configure permissions correctly the workload pod fails to run because the cluster in project B has no image pull access to project A. You then see an event on the pod containing a message in the form:

Failed to pull image "
pull access denied...
repository does not exist or may acquire 'docker login'...

All projects that have enabled the Compute Engine API have a Compute Engine default service account, which has the following email address:

Where PROJECT_NUMBER is the project number for project B.

To work around this issue, ensure that the Compute Engine default service account for project B has the necessary permissions to access the Cloud Storage bucket. For example, you can use the following gsutil command to enable access:

gsutil iam ch gs://