Windows containers in Kubernetes [page]deterministic
Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications.
Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system.
## Windows nodes in Kubernetes
To enable the orchestration of Windows containers in Kubernetes, include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](#gloss:pod) on Kubernetes is similar to scheduling Linux-based containers.
In order to run Windows containers, your Kubernetes cluster must include multiple operating systems. While you can only run the [control plane](#gloss:control-plane) on Linux, you can deploy worker nodes running either Windows or Linux.
Windows [nodes](#gloss:node) are [supported](#windows-os-version-support) provided that the operating system is Windows Server 2022 or Windows Server 2025.
This document uses the term *Windows containers* to mean Windows containers with process isolation. Kubernetes does not support running Windows containers with [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container).
## Compatibility and limitations {#limitations}
Some node features are only available if you use a specific [container runtime](#container-runtime); others are not available on Windows nodes, including:
* HugePages: not supported for Windows containers * Privileged containers: not supported for Windows containers. [HostProcess Containers](/docs/tasks/configure-pod-container/create-hostprocess-pod/) offer similar functionality. * TerminationGracePeriod: requires containerD
Not all features of shared namespaces are supported. See [API compatibility](#api) for more details.
See [Windows OS version compatibility](#windows-os-version-support) for details on the Windows versions that Kubernetes is tested against.
From an API and kubectl perspective, Windows containers behave in much the same way as Linux-based containers. However, there are some notable differences in key functionality which are outlined in this section.
### Comparison with Linux {#compatibility-linux-similarities}
Key Kubernetes elements work the same way in Windows as they do in Linux. This section refers to several key workload abstractions and how they map to Windows.
* [Pods](/docs/concepts/workloads/pods/)
A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers:
* Single or multiple containers per Pod with process isolation and volume sharing * Pod `status` fields * Readiness, liveness, and startup probes * postStart & preStop container lifecycle hooks * ConfigMap, Secrets: as environment variables or volumes * `emptyDir` volumes * Named pipe host mounts * Resource limits * OS field:
The `.spec.os.name` field should be set to `windows` to indicate that the current Pod uses Windows containers.
If you set the `.spec.os.name` field to `windows`, you must not set the following fields in the `.spec` of that Pod:
* `spec.hostPID` * `spec.hostIPC` * `spec.securityContext.seLinuxOptions` * `spec.securityContext.seccompProfile` * `spec.securityContext.fsGroup` * `spec.securityContext.fsGroupChangePolicy` * `spec …(trimmed)