Have a question about Windows Server containers, see if it's answered in the list below.
What's the difference between Linux and Windows Server containers?
Linux and Windows Server both implement similar technologies within their kernel and core operating systems. The difference comes from the platform and workloads that run within the containers.
When a customer uses Windows Server containers, they can integrate with existing Windows technologies, such as .NET, ASP.NET, and PowerShell.
What are the prerequisites for running containers on Windows?
Containers were introduced to the platform with Windows Server 2016. To use containers, you'll need either Windows Server 2016, the Windows 10 Anniversary update (version 1607) or newer, or Windows 10 IoT Enterprise or newer. Read the System Requirements to learn more.
What of the Windows operating systems are supported in Kubernetes?
Support for Windows containers is dependent on the Kubernetes platform on which it runs. Azure Kubernetes Service (AKS) and AKS on Azure Stack HCI and Windows Server supports both Windows Server 2019 and Windows Server 2022 Windows nodes. Azure Kubernetes Service Edge Essentials support Windows Server 2019, Windows Server 2022, and Windows 10/11 Enterprise or Pro. For Windows container version compatibility, see Windows container version compatibility.
How do I patch my Windows nodes?
Windows Server nodes in AKS and AKS on Azure Stack HCI and Windows Server must be upgraded to get the latest patch fixes and updates. Windows Updates are not enabled on Windows nodes on those services. However, both services provide mechanisms to update the Windows node images.
Can my Windows Server containers use gMSA?
Yes, gMSA is supported with domain-joined Windows worker nodes. To learn more about using gMSA with Windows containers, see Prepare Windows nodes for gMSA.
What are WCOW and LCOW?
WCOW is short for "Windows containers on Windows." LCOW is short for "Linux containers on Windows."
How are containers licensed? Is there a limit to the number of containers I can run?
The Windows container image EULA describes a usage that depends on a user having a validly licensed host OS. The number of containers a user is allowed to run depends upon the host OS edition and the isolation mode a container is being run with, as well as whether these containers are running for dev/test purposes or in production.
| Host OS | Process-isolated container limit | Hyper-V-isolated container limit |
|---|---|---|
| Windows Server Standard | Unlimited | 2 |
| Windows Server Datacenter | Unlimited | Unlimited |
| Windows Pro and Enterprise | Unlimited (for test or development purposes only) | Unlimited (for test or development purposes only) |
| Windows 10 IoT Core | Unlimited* | Unlimited* |
| Windows IoT Enterprise | Unlimited* | Unlimited* |
Windows Server container image usage is determined by reading the number of virtualization guests supported for that edition.
Note
*Production usage of containers on an IoT edition of Windows depend on if you have agreed to the Microsoft Commercial Terms of Use for Windows Core Runtime Images or the Windows IoT Enterprise Device License (“Windows IoT Commercial Agreement”). Additional terms and restrictions in the Windows IoT Commercial Agreements apply to your use of Container Image in a production environment. Please read the container image EULA to understand exactly what is permitted and what is not.
As a developer, do I have to rewrite my app for each type of container?
No. Windows container images are common across both Windows Server containers and Hyper-V isolation. The choice of container type is made when you start the container. From a developer standpoint, Windows Server containers and Hyper-V isolation are two flavors of the same thing. They offer the same development, programming, and management experience, and are open and extensible and include the same level of integration and support with Docker.
A developer can create a container image using a Windows Server container and deploy it in Hyper-V isolation or vice-versa without any changes other than specifying the appropriate runtime flag.
Windows Server containers offer greater density and performance for when speed is key, such as lower spin-up time and faster runtime performance compared to nested configurations. Hyper-V isolation, true to its name, offers greater isolation, ensuring that code running in one container can't compromise or impact the host operating system or other containers running on the same host. This is useful for multitenant scenarios with requirements for hosting untrusted code, including SaaS applications and compute hosting.
Can I run Windows containers in process-isolated mode on Windows 10?
Starting with the Windows 10 October 2018 update, you can run a Windows container with process isolation, but you must first directly request process isolation by using the --isolation=process flag when running your containers with docker run. Process-isolation is compatible on Windows 10 11 Pro (or newer), Windows 10 Enterprise (or newer), Windows 10 IoT Core and Windows 10 IoT Enterprise (or newer).
If you want to run your Windows containers this way, you'll need to make sure your host is running Windows 10 build 17763+ and you have a Docker version with Engine 18.09 or newer.
Warning
Aside from on IoT Core and IoT Enterprise hosts (after accepting additional terms and restrictions), this feature is only meant for development and testing. You should continue to use Windows Server as the host for production deployments. By using this feature, you must also ensure that your host and container version tags and build number match, otherwise the container may fail to start or exhibit undefined behavior.
How do I make my container images available on air-gapped machines?
Windows container base images contain artifacts whose distribution is restricted by license. When you build on these images and push them to a private or public registry, you'll notice the base layer is never pushed. Instead, we use the concept of a foreign layer that points to the real base layer residing in Azure cloud storage.
This can complicate things when you have an air-gapped machine that can only pull images from the address of your private container registry. In this case, attempts to follow the foreign layer to get the base image won't work. To override the foreign layer behavior, you can use the --allow-nondistributable-artifacts flag in the Docker daemon.
Important
Usage of this flag shall not preclude your obligation to comply with the terms of the Windows container base image license; you must not post Windows content for public or third-party redistribution. Usage within your own environment is allowed.
Additional feedback
Want to add something to the FAQ? Open a new feedback issue in the comments section or set up a pull request for this page with GitHub.