Create a Windows Server node pool
As of Google Kubernetes Engine version 1.23.7-gke.1300, Anthos clusters on Azure offers 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:
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 VNetVNET_NAME
: the name of your VNetKEY_PATH
: the path to your SSH key pair
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.25.5-gke.1500 \ --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 inGOOGLE_CLOUD_LOCATION
: the Google Cloud location that manages your clusterVM_SIZE
: a supported Azure VM sizeMIN_NODES
: the minimum number of nodes in the node pool—for more information, see Cluster autoscalerMAX_NODES
: the maximum number of nodes in the node pool
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 clusterGOOGLE_CLOUD_LOCATION
: the Google Cloud location that manages your cluster
The output includes the status of your node pool, indicating whether it is
PROVISIONING
orRUNNING
.
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.
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
Create the deployment and expose it as a service with this command:
kubectl create -f iis.yaml
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
.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.
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.