This article is based on reporting originally published by SearchITOperations / TechTarget in October 2019.
Overview
In October 2019, Rancher 2.3 and Amazon EKS became the first two Kubernetes management platforms to declare general availability (GA) for Windows worker nodes — including mixed-mode clusters that run both Windows and Linux nodes side by side. The milestone mattered because it brought Windows-native enterprise workloads into the same orchestration model already used for cloud-native Linux applications.
What Changed: Windows Worker Nodes in Kubernetes
Before this release, most Kubernetes distributions could run Windows containers, but only when the underlying host node was Linux. Rancher 2.3 and Amazon EKS extended that to let Windows Server machines serve as worker nodes directly, meaning Windows container workloads run on genuine Windows hosts within the cluster.
One constraint remains: the Kubernetes control-plane (master) node still must run on Linux — a requirement imposed upstream. Rancher CEO Sheng Liang hinted that future work derived from the company’s lightweight k3s distribution might eventually relax that requirement, describing it as “really just packaging,” but offered no timeline or commitment to upstream contribution.
Windows node support in upstream Kubernetes reached stable status in Kubernetes 1.14, released in March 2019. Rancher and AWS were first to ship GA-grade management tooling around it; Docker Enterprise, Red Hat OpenShift, VMware PKS, Azure Kubernetes Service, and Google Kubernetes Engine were reported to have support in progress, with most targeting GA by end of 2019.
Why Windows Node Support Matters for Enterprise Teams
Enterprise IT teams have large portfolios of Windows-only applications — workloads dependent on Active Directory, IIS, Windows-specific libraries, or .NET Framework — that cannot easily be ported to Linux. Windows node support lets those teams adopt Kubernetes-based orchestration without requiring an immediate OS migration.
Matthew Esser, product owner of container services and infrastructure at satellite telecommunications company Viasat, described the practical impact:
“Previously, we skipped over these because Linux-based applications were the easier, lower-hanging fruit. Support for a more ephemeral Windows deployment model enables things like test environments to be candidates for Kubernetes. I also suspect that as container support for Windows matures, more applications that rely on Windows libraries to run will start to crop up in Kubernetes environments.”
— Matthew Esser, Viasat
For other shops, the feature may be a bridge rather than a destination. David Sanftenberg, a DevOps engineer at Cardano Risk Management Ltd., noted that his team was evaluating Windows Kubernetes support for tools like Octopus Deploy, specifically for applications not yet ported to .NET Core — adding that the rest of their stack had already moved to Linux.
Industry consultants, however, cautioned against treating Windows Kubernetes support as a short-term measure. Chris Riley, cloud delivery director at Cprime, pointed to the depth of the Windows ecosystem:
“The whole Windows ecosystem that exists to support Active Directory, IIS, etc., is a force to be reckoned with. I don’t think it will be a temporary measure for most. Enterprises that have adopted Windows also have the administrative muscle to support it appropriately, and won’t be interested in making a wholesale OS switch unless there are cost benefits that they can achieve.”
— Chris Riley, Cprime
Known Limitations as of Kubernetes 1.14
Windows node support in Kubernetes 1.14 shipped with notable gaps that teams should account for:
- Privileged containers not supported on Windows nodes. Many third-party security tools in Linux Kubernetes environments rely on privileged containers; those tools will not work on Windows nodes.
- Read-only file systems not supported. A common hardening technique on Linux nodes, read-only root file systems, is not available for Windows containers.
- Control-plane (master) node must run on Linux. There is no mechanism in upstream Kubernetes to run the control plane on Windows, regardless of what worker nodes are used.
Viasat’s Esser summarized the pragmatic stance many teams took at the time: “It’s still early in the game for Windows containers, and honestly, we are going to just have to wait it out to see how it starts to mature before putting a large effort behind it.”
Other Rancher 2.3 Highlights
Istio Service Mesh Integration
Rancher 2.3 added built-in support for the Istio service mesh. Rancher CEO Sheng Liang stated the company would continue to support Istio as long as market demand remained strong, despite ongoing controversy at the time about Istio’s open source governance model. Rancher also continued to support Linkerd, the CNCF-graduated service mesh project.
Kubernetes Security Hardening
Rancher 2.3 introduced tooling to help operators harden cluster configurations in line with CIS and NIST guidelines. Key capabilities included:
- Cluster scanning — scan existing clusters for security misconfigurations.
- Hardened cluster templates — deploy new clusters from reusable templates pre-configured to meet hardening guidelines.
- Template enforcement — enforce template use across clusters to reduce configuration drift.
Cardano’s Sanftenberg highlighted the value for production infrastructure: “We have SonarQube scans and governance around what happens at deploy time for applications. But we also need to detect vulnerabilities in what we’re running, as well as what we’re building.”
A compatibility issue between the hardening guidelines and the Rancher UI was acknowledged at launch. According to a Rancher spokesperson at the time, the issue was targeted for resolution in version 2.3.2, with single-click cluster scanning from the Rancher GUI planned for version 2.4.
Summary
Rancher 2.3 and Amazon EKS marked a meaningful milestone for Kubernetes in the enterprise by making Windows worker nodes production-ready in managed clusters. The feature opens Kubernetes-based orchestration to a wide class of legacy Windows workloads, though gaps in privileged container support and the Linux-only control plane mean Windows Kubernetes environments require additional evaluation before being treated as equivalent to their Linux counterparts. The Rancher 2.3 release also added Istio integration and security hardening tooling aligned with CIS and NIST guidelines, addressing two of the most common concerns for teams moving Kubernetes into regulated or security-sensitive production environments.