Deploying a Windows workload to a target cluster

After you build the Windows container, you can deploy the container to another cluster.

Before you begin

Before deploying your workload, you should have first:

Deploying the container image

With your container image in Container Registry, you can deploy the image to a GKE cluster. See Deploying a Windows Server application for more.

As part of deploying the container, you have to create a Deployment manifest file. Shown below is an example Deployment manifest file for a container located at

apiVersion: apps/v1
kind: Deployment
  name: myworkload
    app: myworkload
  replicas: 1
      app: myworkload
        app: myworkload
      nodeSelector: windows
      - name: myworkload-container
        - containerPort: 80

Deploying a container when storing SSL certificates as Kubernetes secrets

We recommend that you use a Cloud Load Balancing, Ingress, or Anthos Service Mesh as an HTTPS frontend to secure external access to your deployed container. This option let you secure external communication without including any certificates inside the cluster. See Customizing a migration plan for more.

However, you can also store SSL certificates as Kubernetes secrets and mount them at runtime into the container.

To use Kubernetes secrets:

  1. Create a PFX file with the certificate and password.

  2. Create a configuration yaml that defines site access:

     - sitename: "sitename"
       sslport: 443
       pfxpath: c:\sslconfig\pfx
       password: "password"
       thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"


    • sitename specifies the name of the site configured to use SSL. The sites property can contain multiple sitename entries.

    • sslport specifies the port to listen to for SSL connections (typically 443).

    • pfxpath specifies the path to the PFX file. Configure it as part of the volumeMounts of the deployment of the pod as shown below.

    • password specifies the password for the PFX file.

    • thumbprint specifies the SHA1 thumbprint of the PFX file this can be retrieved using the PowerShell command:

    Get-PfxCertificate -FilePath "path to pfx"

    Or view in the Windows Certificate manager.

  3. Create the Kubernetes secret:

    kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config
  4. Create the volume and volume mount in the deployment of the image:

    apiVersion: v1
    kind: Pod
     name: iis-pod
       app: iis-server-simple
       nodeSelector: windows
       - name: iis-server
         image: your-image-url
         - name: ssl-secret
           mountPath: c:\sslconfig
         - name: M4A_CERT_YAML
           value: c:\sslconfig\config
       - name: ssl-secret
           secretName: secret-name


    • mountPath is the same path as specified by pfxpath in the configuration file you created in Step 2.
    • M4A_CERT_YAML is an environment variable set to the full path to the configuration yaml file you created in Step 2.
    • secret-name is the name of the secret you created in step 3.

Deploying a container configured to use gMSA

Migrate for Anthos lets you configure a Windows container to use a Group Managed Service Account (gMSA). A gMSA lets you to execute the container under a specific service account identity.

To support gMSA in a migrated Windows container, you must:

  1. Edit the migration plan to set the necessary properties to configure the migrated container to use a gMSA. You must perform this step before you migrate the Windows VM workload. See Customizing a migration plan for more.

  2. Configure the processing cluster that hosts the deployed container to support gMSA. This configuration process is described below.

Configure a processing cluster to support gMSA

You attach a gMSA in the Kubernetes cluster as part of the pod configuration, rather than as a static identity configuration inside the container image.

To configure a cluster hosting the migrated Windows container to support gMSA, you must have:

  1. Configured Active Directory for VMs to automatically join a domain.

  2. Configure GMSA for Windows Pods and containers.

For additional information see:

Next Steps