This documentation is for the most recent version of Anthos clusters on AWS, released on September 29th. See the Release notes for more information. For documentation on the previous generation of Anthos clusters on AWS, see Previous generation.

Create a Windows Server node pool

Stay organized with collections Save and categorize content based on your preferences.

As of Google Kubernetes Engine version 1.22, Anthos clusters on AWS adds public preview support for node pools built on Windows Server instances. This page describes how to create a Windows Server node pool in Anthos clusters on AWS.

Before you begin

Windows node pools restrictions differ from those for Linux node pools. Before creating a Windows node pool, we recommend you review the limitations below.

Allowlist your cluster

Because this is a preview feature, Google support must allowlist your cluster first. Please contact your account team to opt into the preview.

Windows Server node image

Anthos clusters on AWS supports node pools built on the Windows Server 2019 (LTSC) node image and containerd runtime. All Windows containers on Anthos clusters on AWS must be built on Windows Server 2019 (LTSC). For more information, see Matching container host version with container image versions.

Windows Updates

Windows Updates are disabled for Windows Server nodes. Automatic updates can cause node restarts at unpredictable times, and any Windows Updates installed after a node starts would be lost when Anthos recreates the node. Instead, Anthos clusters on AWS periodically updates the Windows Server node images with a new Kubernetes version release. When critical security updates are released, Anthos clusters on AWS updates Windows Server node images as quickly as possible. You must then perform a node pool update to adopt the OS image changes.

One OS throughout a node pool

All nodes in a node pool must run the same operating system. Anthos clusters on AWS doesn't support node pools with both Linux and Windows nodes, even if the hardware configuration is identical.

Clusters must have a Linux node

All Anthos clusters on AWS clusters must have at least one Linux node. Because all nodes in a node pool must have the same configuration including the same operating system, a cluster with a Windows Server node pool must have a second node pool with at least one Linux node. This node is used to run cluster infrastructure components such as the Connect agent.

Create a Windows Server node pool

Before you create a Windows Server node pool, you need the following:

  • The name of an existing AWS cluster to create the node pool in
  • An IAM instance profile for node pool VMs
  • A subnet where the node pool VMs will run

Once these resources are available, you can create a node pool with this command:

gcloud alpha container aws node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --image-type "windows" \
    --instance-type INSTANCE_TYPE \
    --root-volume-size ROOT_VOLUME_SIZE \
    --iam-instance-profile NODEPOOL_PROFILE \
    --node-version "1.24.3-gke.2100" \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --max-pods-per-node MAX_PODS_PER_NODE \
    --location GOOGLE_CLOUD_LOCATION \
    --subnet-id NODEPOOL_SUBNET \
    --ssh-ec2-key-pair SSH_KEY_PAIR_NAME \
    --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN

Replace the following:

  • NODE_POOL_NAME: a name you choose for your node pool
  • CLUSTER_NAME: the name of the cluster to attach the node pool to
  • INSTANCE_TYPE: the desired AWS machine instance type for this node pool— for example, m5.large
  • ROOT_VOLUME_SIZE: the desired size for each node's root volume, in Gb
  • NODEPOOL_PROFILE: the name of the IAM instance profile associated with the cluster
  • NODE_VERSION: the Kubernetes version to install on each node in the node pool (for example 1.24.3-gke.2100)
  • MIN_NODES: the minimum number of nodes the node pool can contain
  • MAX_NODES: the maximum number of nodes the node pool can contain
  • MAX_PODS_PER_NODE: the maximum number of pods that can be created on any single node in the pool
  • GOOGLE_CLOUD_LOCATION: the name of the Google Cloud location from which this node pool will be managed
  • NODEPOOL_SUBNET: the ID of the subnet the node pool will run on. If this subnet is outside of the VPC primary CIDR block, some additional steps are needed. For more information, see security groups.
  • SSH_KEY_PAIR_NAME: the name of the AWS SSH key pair created for SSH access (optional)
  • CONFIG_KMS_KEY_ARN with the Amazon Resource Name (ARN) of the AWS KMS key to encrypt user data

If you're familiar with creating Linux node pools already, note the --image-type "windows" parameter, which creates a Windows node pool instead of a Linux one, and the use of the gcloud alpha command.

  1. Check the status of your node pool:

    gcloud alpha container aws node-pools describe NODE_POOL_NAME \
        --cluster CLUSTER_NAME \
        --location GOOGLE_CLOUD_LOCATION
    

    Replace the following:

    • NODE_POOL_NAME: a unique name for your node pool—for example, node-pool-1
    • CLUSTER_NAME: the name of your Anthos clusters on AWS cluster
    • GOOGLE_CLOUD_LOCATION: the Google Cloud location that manages your cluster

    The output includes the status of your node pool, indicating whether it is PROVISIONING or RUNNING.

Windows node taints

To ensure that Linux containers don't run on Windows Server nodes, Anthos clusters on AWS automatically taints Windows Server nodes with the key-value pair node.kubernetes.io/os=windows:NoSchedule.

To force the scheduler to run your workload on a Windows Server node, add the following spec.nodeSelector section to the manifest of all your Windows workloads:

nodeSelector:
  kubernetes.io/os: windows

When Anthos clusters on AWS finds this section in a workload manifest, it adds the following toleration to the manifest. This forces the scheduler to run the workload only on a Windows Server node with a matching taint.

   tolerations:
   - key: "node.kubernetes.io/os"
     operator: "Equal"
     value: "windows"
     effect: "NoSchedule"

Example: Deploy IIS to a Windows Server node

This example deploys Microsoft's official IIS (Internet Information Server) image to a Pod.

  1. Create an IIS file named iis.yaml with the following content:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: iis
      labels:
        app: iis
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: iis
      template:
        metadata:
          labels:
            app: iis
        spec:
          nodeSelector:
            kubernetes.io/os: windows
          containers:
          - name: iis-server
            image: mcr.microsoft.com/windows/servercore/iis
            ports:
            - containerPort: 80
    ---
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: iis
      name: iis
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        app: iis
      sessionAffinity: None
      type: LoadBalancer
    
  2. Create the deployment and expose it as a service with this command:

    kubectl create -f iis.yaml
    
  3. Check the pod status:

    kubectl get pods
    

    The results will be similar to what is shown here.

    NAME                   READY     STATUS    RESTARTS   AGE
    iis-5c997657fb-w95dl   1/1       Running   0          28s
    

    Re-run this command until the Pod status shows as Running.

  4. Get the status of the service:

    kubectl get service iis
    

    The output will be similar to this:

    NAME   TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
    iis    LoadBalancer   10.44.2.112   198.51.100.0  80:32233/TCP   17s
    

    You might need to run this command several times until the service is running and the external IP address field in the output is populated.

  5. Use your browser to open

    http://EXTERNAL_IP
    

    to see the default IIS web page.

    Replace EXTERNAL_IP with the value of the EXTERNAL-IP field from the previous command.

Network Policy with Windows workloads

You can configure Network Policy to control inbound and outbound traffic from your Windows workload.

Cloud Logging

Anthos clusters on AWS supports logging for Windows nodes and Pods as it does for Linux. When you configure logging, Anthos clusters on AWS deploys agents on Windows nodes. These agents collect, process, and export the node's logs and metrics. The Windows Logging agent can collect logs from Pods (both system and user application workload) and Nodes (kubelet, kube-proxy, antrea-agent).

To install Anthos Cloud Logging, see Cloud logging.

What's next