When we presented this topic at Microsoft Ignite earlier this year, I asked the audience in the room the regular question we ask: How many of you are running Windows Server 2012 in your environment? Note that I’m not even asking about Windows Server 2008. Windows Server 2012 is already out of support. And more – if you’re not paying attention, Windows Server 2016 is already out of mainstream support! If you haven’t already, you should really start planning your upgrades.
The problem is: Upgrading from old versions is hard. It’s a manual process that requires you to validate the all the components required for your app to work on the new OS version. And more: everything we covered in the previous posts on this blog series are reasons to make the upgrade process harder – making sure you manage the SSL certificates, multiple websites on a single server, hardcoded configurations, and scaling up and down. All of these just complicate the process, but if you’ve been following along and checking on how Windows Containers can help with IIS deployments, you now know how to avoid these pitfalls. Because we addressed the previous items, we’ll show how upgrading to the latest OS version is much easier with Windows containers and Azure Kubernetes Service.
Upgrading a Windows container image
Technically, changing the version of the OS that a container use is relatively simple. Every container image is created by a text file called docker file, which starts with a FROM statement. This is the base image from which your image will be built upon. An IIS based image will most likely have a FROM statement like this:
FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
After that statement on the docker file you can add all other instructions on how to install your app, such as copy files, add other features, install pre-requisites, etc. Once the docker file is completed, you can build and name your container image, with something like:
docker build -t myimage:v2019 .
The command above, will use Docker build to read the docker file instructions and create the image, tagging it as myimage:v2019. To upgrade that container image to Windows Server 2022, you need to update the FROM statement on the docker file:
FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022
With the docker file updated, you can run the same docker build command, but now you can give it a new version name:
docker build -t myimage:v2022 .
Next, it’s important to run this image on a test environment and ensure the app is behaving the same as before. However, because the instructions to install the app are the same on the docker file and, as you learned from the previous blog posts on this series, all the configuration is external to the image, (SSL certificates, hardcoded configs, etc.), we can move to the next version much easier.
Upgrading Windows Containers on Azure Kubernetes Service
I wrote a blog post with detailed instructions on how to upgrade the container version for Windows applications on AKS. In this blog post, I wanted to highlight a few things about that process:
- Windows containers and Windows container hosts versions need to match. A Windows container running Windows Server 2019 cannot run on a Windows Server 2022 node and vice-versa.
- AKS (and Kubernetes for that matter) have this concept of node pools, which is a group of nodes that you can reference for deployment purposes. On AKS, you cannot mix Windows Server versions on the same node pool. A node pool is either for Windows Server 2019 or Windows Server 2022.
- On AKS, Windows Server 2022 is supported on Kubernetes version 1.23 or higher. Starting with Kubernetes 1.25, Windows Server 2022 will be the default Windows node version. If you deploy Windows Server 2019 on AKS with Kubernetes 1.25 and above, the workload will break, unless you explicitly create a Windows Server 2019 node pool and deploy your workload to that node pool.
- Containerd is the default container runtime for Windows Server 2022 and for Windows Server 2019 with Kubernetes version 1.23 and above. While this should not impact your existing workload, it’s important to know as you gain new features (such as Host Process Containers) and better performance and reliability.
On a high level, here’s what you need for a Windows Server 2022 upgrade:
az aks nodepool add --resource-group myResourceGroup --cluster-name myAKSCluster --os-type Windows --name npwin --node-count 1
The command above will create a node pool on the existing cluster you have. Next, you need to update the YAML file for your application:
apiVersion: apps/v1
kind: Deployment
metadata:
name: iis-sample
spec:
replicas: 1
selector:
matchLabels:
app: iis-sample
template:
metadata:
labels:
app: iis-sample
spec:
nodeSelector:
"kubernetes.azure.com/os-sku": Windows2022
containers:
- name: iis-sample
image: myimage:v2022
resources:
limits:
cpu: 1
memory: 800M
requests:
cpu: .5
memory: 400M
ports:
- containerPort: 80
Notice that the image I’m using here is the one I upgraded before with Windows Server 2022. I also used the nodeSelector that specifically uses the Windows Server 2022 node pool, to avoid version mismatch. Finally, you need to ensure no other service is disrupted because of the node pool change, such as gMSA or Managed Identity.
The moment I apply this new YAML specification, AKS will first spin up the new pods to then terminate the old ones. This allows for no interruption to your IIS web application and users.
Conclusion
Upgrading the Windows Server version is always a challenge. Windows containers provide a way to easily move from one version to the next – as long as you follow best practices of SSL certificate management outside of the container instance, have no hardcoded configurations, and deploy websites on its own container instances rather than multiple websites on a single container. These best practices allow for scale-up and down, as well as simpler upgrade process.
Don’t miss the previous blog posts on this series:
I hope this content is useful to you! Let us know what you think in the comments section below.
