Introduction

Running Windows workloads in GKE is possible, but it requires more planning than a standard Linux-only cluster. The key idea is that GKE can run Linux and Windows node pools side by side, while your manifests must target the correct operating system and container image family.

How Windows Fits into GKE

GKE supports Windows Server containers in GKE Standard mode through Windows node pools. That lets teams keep one Kubernetes control plane while scheduling Linux pods onto Linux nodes and Windows pods onto Windows nodes. It is a practical option for legacy .NET Framework services, IIS-based apps, or other workloads that still depend on Windows userland.

There are two design constraints to keep in mind from the start. First, Windows node pools are not available in GKE Autopilot. Second, your container image must match the Windows host version family closely enough to run on that node pool.

Scheduling a Windows Workload

The most important manifest change is pinning the pod to Windows nodes. Without that, Kubernetes may try to schedule the pod onto Linux capacity.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: iis-demo
5spec:
6  replicas: 2
7  selector:
8    matchLabels:
9      app: iis-demo
10  template:
11    metadata:
12      labels:
13        app: iis-demo
14    spec:
15      nodeSelector:
16        kubernetes.io/os: windows
17      containers:
18        - name: iis
19          image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022
20          ports:
21            - containerPort: 80
22---
23apiVersion: v1
24kind: Service
25metadata:
26  name: iis-demo
27spec:
28  selector:
29    app: iis-demo
30  ports:
31    - port: 80
32      targetPort: 80

That example is intentionally small, but it shows the main idea: the deployment asks for Windows nodes, and the image is a Windows container image rather than a Linux base image.

Building the Cluster Layout

A mixed cluster is common. Linux nodes usually host ingress controllers, operators, and many shared services, while Windows node pools run only the workloads that require Windows. Keeping those concerns separated helps with upgrades, cost control, and troubleshooting.

Some teams dedicate a tainted Windows node pool so only explicitly allowed pods land there. If you take that route, add matching tolerations to Windows workloads. That keeps Linux-first workloads from consuming more expensive or specialized Windows capacity.

Version and Image Compatibility

Windows containers are stricter than many Linux workloads about host and image compatibility. If you build an image for one Windows Server LTSC version and schedule it onto a different host family, the pod may fail before your application code starts.

A reliable process is to standardize on one Windows Server LTSC release per node pool and build images against that target. Treat the base image tag as part of cluster compatibility, not just an application detail.

Operational Differences You Should Expect

Windows containers on Kubernetes work well, but not every Kubernetes ecosystem component has identical behavior across operating systems. Storage plugins, security tooling, logging agents, and network assumptions should all be validated for Windows before you depend on them in production.

It also helps to keep bootstrap scripts and health checks simple. The smaller the operating-system-specific surface area, the easier the workload is to maintain alongside your Linux services.

Common Pitfalls

• Assuming GKE Autopilot supports Windows node pools leads to the wrong cluster design. Windows support is a GKE Standard mode feature.
• Forgetting nodeSelector can send a Windows workload to Linux nodes, where it cannot start.
• Using a Windows image that does not match the node pool’s host family is a common source of startup failures.
• Treating Windows nodes exactly like Linux nodes can hide differences in storage, networking, and operational tooling.
• Moving every workload onto Windows usually increases cost and complexity without benefit. Keep only the workloads that truly need it there.

Summary

• GKE can run Linux and Windows node pools in the same Standard mode cluster.
• Windows workloads must be scheduled explicitly onto Windows nodes.
• Container image and host version compatibility matters much more for Windows workloads.
• Mixed-cluster design usually works better than an all-Windows cluster.
• Validate storage, networking, and observability choices against Windows before production rollout.