This article is based on reporting originally published on TechRepublic (April 2020). Some cloud provider support details may have changed since publication.
The Container Promise—and Where Windows Fits
Containers have become the default packaging format for modern applications. By isolating only the essential OS components that differ between environments, container images stay small enough to be stored in version control, transferred over a network like ordinary files, and run consistently across machines. For Linux workloads this works almost seamlessly: because of how the Linux kernel manages processes, nearly any modern Linux distribution can host containers built on a different Linux distribution.
Windows does not enjoy that same flexibility. The host OS version—down to the build number—must match the version used to build the container image. That constraint has significant operational consequences: applying a security patch or upgrading the host OS can break container compatibility. Understanding this fundamental difference is essential before planning any Windows container strategy.
A Brief History of Windows Containers
Microsoft has supported running Windows in Docker containers for several years. Azure added Docker support in 2014, though that initially meant running Linux containers in the Azure cloud—not native Windows containers. Native Windows container support in Azure came later and, at the time of the original reporting, was still in a technology preview (beta) phase.
Part of why Windows containerization lags behind Linux is the sheer size and complexity of the codebase. Windows is reported to be one of the largest codebases maintained in a single Git repository. The OS carries decades of backward compatibility requirements, from the Windows XP rewrite era all the way back to MS-DOS compatibility. That legacy makes isolating discrete, portable OS layers far more difficult than it is on Linux.
Kubernetes Support for Windows: What Was Announced
On April 1, 2019, the Kubernetes project announced stable (GA) support for Windows containers. The announcement meant that Windows machines could be registered as worker nodes in a Kubernetes cluster, contributing their CPU, memory, and disk to run Windows container workloads. The Kubernetes control plane itself can run on Linux or Windows.
The Core Constraint: Windows Server 2019
The catch—and it is a significant one—is that both the worker nodes and the container images must be running Windows Server 2019 (at the time of the GA announcement). Because of the OS version-matching requirement described above, mixing versions is not supported. This means:
- Every Windows worker node in your cluster must run the same supported OS build.
- Every Windows container image must be built against that same OS version.
- Patching or upgrading the host OS requires rebuilding or revalidating container images.
For teams accustomed to Linux container workflows—where base images are relatively portable across host versions—this is a meaningful operational overhead to plan for.
Licensing: One Upside of the Must-Match Model
There is at least one benefit to the version-matching requirement: licensing. Because the container OS is the same as the host OS, Microsoft does not require a separate license for the containerized instances. If your Windows Server 2019 host is properly licensed, you are covered for the containers running on it. This removes a potential compliance complexity that might otherwise arise when spinning up many virtual Windows instances.
Cloud Provider Support: A Mixed Picture
At the time of the original reporting (early 2020), cloud provider support for Windows in Kubernetes varied significantly:
- Microsoft Azure (AKS): The most mature option. Azure Kubernetes Service provides a managed front end to create, monitor, and manage clusters that include Windows node pools.
- Amazon EKS: Had a developer preview for Windows node support at the time of reporting.
- IBM Cloud Kubernetes Service: According to a statement from IBM’s program director for Kubernetes and OpenShift included in the original reporting, IBM did not support Windows containers at that time and had no immediate plans to add support, citing insufficient market demand.
Note: Cloud provider support evolves quickly. Verify current support status directly with each provider before making architectural decisions.
The Practical Use Case: Modernizing Legacy .NET Applications
The most compelling near-term use case for Windows containers is running legacy .NET Framework applications. If you have an existing .NET application that cannot easily be ported to .NET Core (and therefore to Linux containers), containerizing it on Windows is a practical modernization step. It allows you to standardize deployment tooling and move toward immutable infrastructure without requiring a full application rewrite.
Developers can build and test Windows containers locally on Windows 10 with Docker Desktop and any edition of Visual Studio. From there, the container can be deployed to production environments.
Azure Service Fabric as an Alternative
For teams not ready to manage the complexity of Windows nodes in a Kubernetes cluster, Azure Service Fabric is worth considering. At the time of the original reporting, Service Fabric offered Windows container support without requiring a full Kubernetes cluster setup. It may be a lower-friction path for teams whose primary goal is running legacy Windows workloads in a managed cloud environment rather than achieving full Kubernetes orchestration.
Key Takeaways for DevOps Teams
- Windows containers in Kubernetes are supported, but require careful OS version alignment between host nodes and container images.
- Patching and upgrades are higher-friction than with Linux containers because any OS version change can break image compatibility.
- Azure is the most mature platform for running Windows containers in Kubernetes; other providers have lagged or had only preview support.
- Licensing is simpler than expected: the matching-OS model means no additional Windows licenses are needed for the containers themselves.
- Legacy .NET modernization is the strongest current justification for investing in Windows containers.
- Azure Service Fabric may be a practical alternative to Kubernetes for Windows container workloads, depending on your requirements.