This documentation is for the most recent version of Anthos clusters on Azure, released on September 29th. See the Release notes for more information.
Stay organized with collections Save and categorize content based on your preferences.

Create a Windows Server node pool

As of Google Kubernetes Engine version 1.22, Anthos clusters on Azure 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 Azure.

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 Azure supports node pools built on the Windows Server 2019 (LTSC) node image and containerd runtime. All Windows containers on Anthos clusters on Azure 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 Azure periodically updates the Windows Server node images with a new Kubernetes version release. When critical security updates are released, Anthos clusters on Azure 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 Azure 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 Azure 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:

  • Permission to use the az command-line tool to retrieve an Azure subnet ID.
  • Access to an SSH key pair to use for the node pool.

To create a node pool, run the following commands:

  1. Save your Azure VNet subnet ID and SSH public key to environment variables:

    SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)
SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

    Replace the following:

    • VNET_RESOURCE_GROUP_NAME: the resource group name that holds your cluster's VNet
    • VNET_NAME: the name of your VNet
    • KEY_PATH: the path to your SSH key pair

  2. Create a node pool with the Google Cloud CLI:

    gcloud alpha container azure node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --node-version }1.24.3-gke.2100 \
    --vm-size VM_SIZE \
    --root-volume-size 128GB \
    --max-pods-per-node 110 \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --ssh-public-key "${SSH_PUBLIC_KEY}" \
    --subnet-id "${SUBNET_ID}" \
    --image-type "windows"

    Replace the following:

    • NODE_POOL_NAME: a unique name for your node pool—for example, node-pool-1
    • CLUSTER_NAME: the name of the Anthos clusters on Azure cluster to create the node pool in
    • GOOGLE_CLOUD_LOCATION: the Google Cloud location that manages your cluster
    • VM_SIZE: a supported Azure VM size
    • MIN_NODES: the minimum number of nodes in the node pool—for more information, see Cluster autoscaler
    • MAX_NODES: the maximum number of nodes in the node pool

  1. Check the status of your node pool:

    gcloud alpha container azure 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 Azure 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 Azure 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 Azure 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 Azure supports logging for Windows nodes and Pods as it does for Linux. When you configure logging, Anthos clusters on Azure 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