Skip to main content

Windows Containers

Key Takeaways for AI & Readers
  • Hybrid Cluster Support: Kubernetes supports running both Linux and Windows containers within the same cluster by having nodes with different operating systems.
  • OS Version Dependency: Windows containers have a stricter dependency on the host kernel version, unlike Linux containers.
  • Node Affinity Required: To ensure Windows containers only schedule on Windows nodes, explicit nodeSelector or taints must be used.
  • Legacy Workloads: This feature is crucial for modernizing legacy .NET Framework or other Windows-dependent applications without rewriting them for Linux.

Not everything runs on Linux. Many enterprises still rely on .NET Framework (4.8) or legacy Windows services that cannot be moved to Linux. Kubernetes supports Hybrid Clusters where some nodes run Linux and others run Windows Server.

1. Hybrid Node Anatomy​

Visualize how pods are scheduled based on the OS.

Linux Node (Ubuntu)
Py
Go
Java
Kernel: Shared (Linux)
Windows Node (Server 2022)
.NET FX
IIS
Kernel: Shared (Windows)
A Hybrid Cluster runs both Linux and Windows nodes. Note that containers cannot cross kernel boundaries: Linux containers MUST run on Linux nodes, and Windows containers MUST run on Windows nodes.

2. Key Limitations​

  1. Shared Kernel: A Windows container requires a host kernel that matches its version (e.g., Windows Server 2022).
  2. No Cross-OS Pods: You cannot mix Linux and Windows containers inside the same Pod.
  3. Networking: Windows uses its own networking stack (HNS). Most modern CNIs (Calico, Antrea) support Windows.

3. How to Schedule​

You MUST use Node Selectors or Taints to ensure Windows pods only land on Windows nodes.

spec:
  nodeSelector:
    kubernetes.io/os: windows

4. Active Directory​

You can join Windows nodes to an Active Directory domain and use gMSA (Group Managed Service Accounts) to give pods a domain identity for database authentication.