Rancher can run Windows workloads, but it’s not a "set it and forget it" situation.
Let’s see it in action. Imagine you have a Windows containerized application, maybe an old .NET Framework app you’re migrating. You’ve built your Dockerfile, and you’re ready to deploy it. In Rancher, you’d navigate to your cluster, go to "Workloads," and click "Create." Instead of selecting "Deployment" or "DaemonSet" like you would for Linux, you’d choose "Windows Deployment."
Here’s a sample YAML for a simple Windows container:
apiVersion: apps/v1
kind: Deployment
metadata:
name: windows-iis
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: iis
template:
metadata:
labels:
app: iis
spec:
containers:
- name: iis
image: mcr.microsoft.com/windows/servercore:ltsc2022
ports:
- containerPort: 80
protocol: TCP
nodeSelector:
beta.kubernetes.io/os: windows
Notice the nodeSelector: beta.kubernetes.io/os: windows. This tells Kubernetes (and by extension, Rancher) to only schedule this workload onto nodes that have the windows operating system label. This is the fundamental mechanism that allows Windows containers to run. Rancher leverages Kubernetes’ built-in node selection capabilities.
The problem this solves is extending containerization to the vast ecosystem of Windows-based applications that can’t (or shouldn’t) be immediately refactored for Linux. This includes legacy .NET applications, IIS web servers, and Windows-specific services. By supporting Windows nodes, Rancher allows organizations to modernize their infrastructure incrementally, containerizing existing Windows workloads without a full rewrite.
Internally, it works by having Kubernetes schedule Windows containers onto Windows worker nodes. The container runtime on those nodes (like containerd or Docker) is configured to handle Windows containers. Rancher then provides the UI and API layer to manage these deployments, just as it does for Linux. The key is ensuring the Kubernetes scheduler knows which nodes are Windows and which are Linux, and that the container runtime is properly set up.
The exact levers you control are primarily around node configuration and workload scheduling. You need to ensure your Windows worker nodes are properly registered with the Kubernetes cluster and have the correct labels. When creating a workload, you use nodeSelector or nodeAffinity to explicitly target Windows nodes. You can also use tolerations if your Windows nodes have taints that your Windows workloads need to tolerate.
Most people focus on the nodeSelector or nodeAffinity for scheduling. But what’s often overlooked is the underlying Windows container image itself. Not all Windows images are created equal for containerization. You need images that are specifically built for Windows containers, often using the Nano Server or Server Core variants. For example, using mcr.microsoft.com/windows/servercore:ltsc2022 is crucial. Trying to run a standard Windows Server VM image directly as a container base will likely fail because it’s not optimized for the container isolation model.
The next concept you’ll likely explore is managing Windows persistent storage, which has its own set of considerations compared to Linux.