This post has been republished via RSS; it originally appeared at: Containers articles.
Today we announced the upcoming release of Windows Server 2022 - and yes, it is packed with many new features across the board, including Security, Hybrid, and Application Platform. In this blog, we’ll go over some details about what’s new for Windows Containers in this next release.Before we dive into the bits, it’s important to reiterate that we’ve been listening to customer feedback and your input has been driving our work across platform improvements, application compatibility, and better Kubernetes experience. In fact, many of the new features below are the result of work made upstream in direct collaboration with the Kubernetes community, benefiting not only Windows Server 2022, but also Windows Server 2019. Furthermore, we’ve been hard at work enhancing our tooling to help you containerize existing applications with Windows Containers.
With that, let’s take a look at what’s new for containers in Windows Server 2022:
Platform improvements
General size improvements
Image size plays a big role in the container’s world. When you deploy a containerized application, you want it to start as fast as it can, but before the container can start the container image layers need to be downloaded and extracted on the container host. Since the launch of Windows containers in Windows Server 2016 we’ve made huge improvements to the Server Core container image, which is recommended for Lift and Shift scenarios. In Windows Server 2022, we continued to make progress in reducing the size of that image:
Insider build 10.0.20292.1
LTSC 2019 (RTM)
Size uncompressed, on disk (GB)
2.73
3.7
Image name
mcr.microsoft.com/window/servercore/insider:10.0.20292.1
mcr.microsoft.com/windows/servercore: ltsc2019
As you can see from the table above, we have almost a full gig reduction in terms of size. Keep in mind that the image used for comparison is the latest Insiders build for Windows Server 2022 and final size can change until general availability.
Comparing these images is not trivial, as every month said images are serviced with feature and security updates - which end up increasing the image size. In a future blog, we will go into more details on how we compare the image sizes, how monthly updates affect them, and explain how the team is constantly working to reduce the Server Core image size overall.
Nano Server support lifecycle changes and update
Nano Server has been our recommended base container image for new modern applications since its launch with Windows Server 2016. Over the years we’ve seen the adoption of this image grow and one of the feedbacks on it was the support lifecycle - for customers running on a Windows Server 2019 host, the corresponding Nano Server 1809 image had the support lifecycle ending back in November 2020. We heard your feedback and worked to extend that support period until Jan-9-2024 - aligning with the Server Core LTSC 2019/1809 base container image.
With the upcoming release of Windows Server 2022, we also decided to release the Nano Server base container image with a longer support cycle - that image will be supported until 2026. This aligns with the mainstream support of Windows Server 2022 and gives customers peace of mind to use that image for that period.
Virtualized time zone
With Windows Server 2022 you can now configure the time zone of a container without needing access to the host. Previously containers were required to mirror the time zone of the host, but now these configurations are virtualized entirely within the container. Upon boot the container starts by referencing the host time zone to set its virtual configuration. If at any time you configure the container to follow a specific time zone then that configuration will persist across boots throughout the end of the container's lifetime. This feature is essential for many applications which localize time-sensitive data to the region they are serving.
To configure the time zone within a container you can simply use the tzutil command or Set-TimeZone Powershell cmdlet.
Scalability improvements enhancing overlay networking support
Windows Server 2022 aggregates several performance and scale improvements which have been made across the last 4 Semi-Annual Channel (SAC) releases of Windows Server but have not been backported into Windows Server 2019. The areas of improvement are:
Fix port exhaustion issue with 100s of Kubernetes services and pods on a node.
Improved packet forwarding performance in vSwitch.
Increased reliability across CNI restarts in Kubernetes.
Several other improvements in the HNS control plane and in the data plane used by Windows Server Containers and Kubernetes networking.
Direct Server Return (DSR) routing for overlay and l2bridge networks
DSR is an implementation of asymmetric network load distribution in load balanced systems, meaning that the request and response traffic use a different network path. The use of different network paths helps avoid extra hops and reduces the latency by which not only speeds up the response time between the client and the service but also removes some extra load from the load balancer.
Using DSR is a transparent way to achieve increased network performance for your applications with little to no infrastructure changes.
Application Compatibility
gMSA updates
Group Managed Service Accounts (gMSA) can be used with Windows containers to enable Active Directory (AD) authentication scenarios. The utilization of gMSA has been introduced in Windows Server 2019 and is documented. So far, it has required domain joining the container host to retrieve the gMSA’s password from AD.
With Windows Server 2022, you can now use gMSAs with Windows containers without having to domain join the host. We have introduced a new model where an AD identity protected in a secret store can be used by the un-joined host to retrieve the gMSA password. Not having to domain join the host will make usage of gMSA in Kubernetes environments much more manageable and scalable. We will update our documentation when this feature is available.
IPv6 support
As part of the upstream work mentioned above, we have introduced the first step to full dual stack IPv6 support for Kubernetes in Windows. The implementation enables IPv6 dual stack support for L2Bridge based networks in the platform. There is a dependency on the CNI used in Kubernetes and the Kubernetes version > 1.20 to enable the IPv6 support end to end. We’ll share more details about this implementation and how you can leverage it on a dedicated blog post soon.
Better Kubernetes experience
Multi-subnet support for Windows worker nodes with Calico for Windows
The Host Network Service (HNS) was restricting Kubernetes container endpoint configurations to only use the prefix length of the underlying subnet. We have improved HNS to allow the use of more restrictive subnets (i.e. subnets with a longer prefix length) as well as multiple subnets per Windows worker node. The first CNI making use of this functionality is Calico for Windows. You can find more information on Calico for Windows in this blog post.
HostProcess containers for node management
Alongside Windows Server 2022 we will be introducing a new container type called HostProcess containers, which aims to extend the Windows container model to enable a wider range of Kubernetes cluster management scenarios. HostProcess containers run directly on the host and maintain behavior and access similar to that of a regular process. With HostProcess containers, users can package and distribute management operations and functionalities that require host access while retaining versioning and deployment methods provided by containers. This allows Windows containers to be used for a variety of device plugin, storage, and networking management scenarios in Kubernetes. With this comes the enablement of host network mode - allowing HostProcess containers to be created within the host's network namespace instead of their own.
Using HostProcess containers, cluster operators no longer need to log onto and individually configure each Windows node for administrative tasks and management of Windows services. Operators can now utilize the container model to deploy management logic to as many clusters as needed with ease. HostProcess containers can be built on top of existing Windows server 2019 (or later) base images, managed through the Windows container runtime, and run as any user that is available on or in the domain of the host machine. All in all, HostProcess containers are the best way to manage Windows nodes in Kubernetes and we’ll share more information on it as we approach the release of Windows Server 2022.
Containerization tooling
Updates to Windows Admin Center experience
Back in June last year we embarked on a journey to create new tooling to help you containerize your existing applications. This work started after we talked to many customers who inquired us on how they could leverage Windows containers to not only modernize existing applications that are not maintained by developers any more, but also how to get rid of legacy systems such as Windows Server 2003 and 2008. We then added new functionality to the Containers extension on Windows Admin Center to help you containerize existing web applications based on ASP.Net from .Net Framework. You could either provide a static folder or a Visual Studio solution from your developer. However, we also heard that in many cases the web application was deployed to a server and that was all Operations teams had, so we added support for Web Deploy files, allowing you to extract the app and its configuration from a running server to then containerize the application. We also added mechanisms to validate the image locally and push that image to Azure Container Registry.
Next, we added basic management of Azure Container Registry and Azure Container Instance. This allows you to create and delete registries, manage images, start and stop new container instances - all directly from the Windows Admin Center UI.
The functionality above on the Containers extension is available already and currently documented here. This allows you to go from having an application back in a legacy system all the way to having a container image ready to be deployed on AKS or other Azure services. We have more to come for Windows Admin Center, so stay tuned for new updates soon.
Azure Migrate App Containerization tooling now in Public Preview
While Windows Admin Center provides a modular approach to containerize existing applications, giving you the ability to choose which source type you have to containerize the existing application, how to deal with the image you create and where to deploy that image, we also heard from customers that a focused solution for AKS was necessary. Azure Migrate App Containerization is an end-to-end solution to containerize and move existing web applications to AKS. It’s step-by-step approach provides functionality to assess existing web servers, create a container image, push the image to ACR, create a Kubernetes deployment, and finally deploy it to AKS.
This functionality is reaching Public Preview today and you can try it out here. For this public preview, we’re targeting scenarios for Windows applications for ASP.Net on IIS and Linux with Java on Tomcat. More scenarios and functionalities will be added soon.
Keep sending your feedback!
Please continue sending us your feedback! Each new feature we design and ship is informed by your input. Some of the features above are still being worked on and your help and support in validating it is extremely valuable!
You can send your comments and feedback our way either via comments below, or our GitHub repo by opening a new issue.