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:
- Migrated the workload using Migrate for Anthos 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, 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 metadata: name: myworkload labels: app: myworkload spec: replicas: 1 selector: matchLabels: app: myworkload template: metadata: labels: app: myworkload 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 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 this 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 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:
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.
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:
For additional information see: