Deploy Windows-based workloads to a target cluster
After you build the Windows container, you can deploy the container to another cluster.
Skaffold can handle the workflow for building, pushing and deploying your application. For more information, see Build and deploy multiple images using Skaffold.
Before you begin
Before deploying your workload, you should have first:
- Migrated the workload using Migrate to Containers tools.
- Built the Windows container as described in Building a Windows container image.
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, edit the
deployment_spec.yaml file included in
artifacts.zip to set the location of the container image you built in
Building a Windows container image.
Shown below is an example
deployment_spec.yaml file for a container located at
apiVersion: apps/v1 kind: Deployment metadata: name: myworkload labels: app: myworkload migrate-for-anthos-optimization: "true" migrate-for-anthos-version: "1.15.0" spec: replicas: 1 selector: matchLabels: app: myworkload migrate-for-anthos-optimization: "true" migrate-for-anthos-version: "1.15.0" template: metadata: labels: app: myworkload migrate-for-anthos-optimization: "true" migrate-for-anthos-version: "1.15.0" spec: nodeSelector: kubernetes.io/os: windows containers: - name: myworkload-container image: gcr.io/myproject/myimagename:v1.0.0 ports: - 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:
Create a PFX file with the certificate and password.
Create a configuration YAML file that defines site access:
sites: - sitename: "sitename" sslport: 443 pfxpath: c:\sslconfig\pfx password: "password" thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"
sitenamespecifies the name of the site configured to use SSL. The
sitesproperty can contain multiple
sslportspecifies the port to listen to for SSL connections (typically 443).
pfxpathspecifies the path to the PFX file. Configure it as part of the
volumeMountsof the deployment of the pod as shown below.
passwordspecifies the password for the PFX file.
thumbprintspecifies the SHA1 thumbprint of the PFX file that can be retrieved using the PowerShell command:
Get-PfxCertificate -FilePath "path to pfx"
Or view in the Windows Certificate manager.
Create the Kubernetes secret:
kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config
Create the volume and volume mount in the deployment of the image:
apiVersion: v1 kind: Pod metadata: name: iis-pod labels: app: iis-server-simple spec: nodeSelector: kubernetes.io/os: windows containers: - name: iis-server image: your-image-url volumeMounts: - name: ssl-secret mountPath: c:\sslconfig env: - name: M4A_CERT_YAML value: c:\sslconfig\config volumes: - name: ssl-secret secret: secretName: secret-name
mountPathis the same path as specified by
pfxpathin the configuration file you created in Step 2.
M4A_CERT_YAMLis an environment variable set to the full path to the configuration YAML file you created in Step 2.
secret-nameis the name of the secret you created in step 3.
Deploying a container configured to use gMSA
Migrate to Containers lets you configure a Windows container to use a Group Managed Service Account (gMSA). A gMSA lets you execute the container under a specific service account identity.
To support gMSA in a migrated Windows container, you must:
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 IIS Application workload. See Customizing a migration plan for more.
Configure the target cluster that hosts the deployed container to support gMSA. This configuration process is described below.
Configure a target 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:
For additional information, see:
- Learn how to monitor migrated workloads.