Skip to content

Commit 2893369

Browse files
schaffererinschaffererin
committed
Upgrade AKS from Windows Server 2019 to 2022 freshness pass
1 parent 461a565 commit 2893369

File tree

1 file changed

+78
-66
lines changed

1 file changed

+78
-66
lines changed

‎articles/aks/upgrade-windows-2019-2022.md

Lines changed: 78 additions & 66 deletions
Original file line numberDiff line numberDiff line change
@@ -1,107 +1,119 @@
11
---
2-
title: Upgrade Kubernetes workloads from Windows Server 2019 to 2022
3-
description: Learn how to upgrade the OS version for Windows workloads on AKS
2+
title: Upgrade Azure Kubernetes Service (AKS) workloads from Windows Server 2019 to 2022
3+
description: Learn how to upgrade the OS version for Windows workloads on Azure Kubernetes Service (AKS).
44
ms.topic: article
55
ms.custom: devx-track-linux
6-
ms.date: 8/18/2022
7-
ms.author: viniap
6+
ms.date: 09/12/2023
87
---
98

10-
# Upgrade Kubernetes workloads from Windows Server 2019 to 2022
9+
# Upgrade Azure Kubernetes Service (AKS) workloads from Windows Server 2019 to 2022
1110

12-
Upgrading the OS version of a running Windows workload on Azure Kubernetes Service (AKS) requires you to deploy a new node pool as Windows versions must match on each node pool. This article describes the steps to upgrade the OS version for Windows workloads and other important aspects.
11+
When upgrading the OS version of a running Windows workload on Azure Kubernetes Service (AKS), you need to deploy a new node pool to ensure the Windows versions match on each node pool. This article describes the steps to upgrade the OS version for Windows workloads on AKS.
1312

1413
> [!NOTE]
1514
> Windows Server 2019 is being retired after Kubernetes version 1.32 reaches end of life (EOL) and won't be supported in future releases. For more information about this retirement, see the [AKS release notes][aks-release-notes].
1615
1716
## Limitations
1817

19-
Windows Server 2019 and Windows Server 2022 can't co-exist on the same node pool on AKS. A new node pool must be created to host the new OS version. It's important that you match the permissions and access of the previous node pool to the new one.
18+
Windows Server 2019 and Windows Server 2022 can't coexist on the same node pool on AKS. You need to create a new node pool to host the new OS version. It's important that you match the permissions and access of the previous node pool to the new one.
2019

2120
## Before you begin
2221

23-
- Update the FROM statement on your dockerfile to the new OS version.
24-
- Check your application and verify that the container app works on the new OS version.
22+
- Update the `FROM` statement in your Dockerfile to the new OS version.
23+
- Check your application and verify the container app works on the new OS version.
2524
- Deploy the verified container app on AKS to a development or testing environment.
26-
- Take note of the new image name or tag. This will be used below to replace the 2019 version of the image on the YAML file to be deployed to AKS.
25+
- Take note of the new image name or tag for use in this article.
2726

2827
> [!NOTE]
29-
> Check out [Dockerfile on Windows](/virtualization/windowscontainers/manage-docker/manage-windows-dockerfile) and [Optimize Windows Dockerfiles](/virtualization/windowscontainers/manage-docker/optimize-windows-dockerfile) to learn more about how to build a dockerfile for Windows workloads.
28+
> To learn how to build a Dockerfile for Windows workloads, see [Dockerfile on Windows](/virtualization/windowscontainers/manage-docker/manage-windows-dockerfile) and [Optimize Windows Dockerfiles](/virtualization/windowscontainers/manage-docker/optimize-windows-dockerfile).
3029
31-
## Add a Windows Server 2022 node pool to the existing cluster
30+
## Add a Windows Server 2022 node pool to an existing cluster
3231

33-
Windows Server 2019 and 2022 can't co-exist on the same node pool on AKS. To upgrade your application, you need a separate node pool for Windows Server 2022.
34-
For more information on how to add a new Windows Server 2022 node pool to an existing AKS cluster, see [Add a Windows Server 2022 node pool](./learn/quick-windows-container-deploy-cli.md).
32+
- [Add a Windows Server 2022 node pool](./learn/quick-windows-container-deploy-cli.md) to an existing cluster.
3533

36-
## Update your YAML file
34+
## Update the YAML file
3735

38-
Node Selector is the most common and recommended option for placement of Windows pods on Windows nodes. To use Node Selector, make the following annotation to your YAML files:
36+
Node Selector is the most common and recommended option for placement of Windows pods on Windows nodes.
3937

40-
```yaml
41-
nodeSelector:
42-
"kubernetes.io/os": windows
43-
```
38+
1. Add Node Selector to your YAML file by adding the following annotation:
4439

45-
The above annotation finds *any* Windows node available and places the pod on that node (following all other scheduling rules). When upgrading from Windows Server 2019 to Windows Server 2022, you need to enforce not only the placement on a Windows node, but also on a node that is running the latest OS version. To accomplish this, one option is to use a different annotation:
40+
```yaml
41+
nodeSelector:
42+
"kubernetes.io/os": windows
43+
```
4644
47-
```yaml
48-
nodeSelector:
49-
"kubernetes.azure.com/os-sku": Windows2022
50-
```
45+
The annotation finds any available Windows node and places the pod on that node (following all other scheduling rules). When upgrading from Windows Server 2019 to Windows Server 2022, you need to enforce the placement on a Windows node and a node running the latest OS version. To accomplish this, one option is to use a different annotation:
5146
52-
Once you update the nodeSelector on the YAML file, you should also update the container image to be used. You can get this information from the previous step on which you created a new version of the containerized application by changing the FROM statement on your dockerfile.
47+
```yaml
48+
nodeSelector:
49+
"kubernetes.azure.com/os-sku": Windows2022
50+
```
51+
52+
2. Once you update the `nodeSelector` in the YAML file, you also need to update the container image you want to use. You can get this information from the previous step in which you created a new version of the containerized application by changing the `FROM` statement on your Dockerfile.
5353

5454
> [!NOTE]
55-
> You should leverage the same YAML file you used to deploy the application in the first place - this ensures no other configuration is changed, only the nodeSelector and the image to be used.
55+
> You should use the same YAML file you used to initially deploy the application. This ensures that no other configuration changes besides the `nodeSelector` and container image.
56+
57+
## Apply the updated YAML file to the existing workload
58+
59+
1. View the nodes on your cluster using the `kubectl get nodes` command.
60+
61+
```bash
62+
kubectl get nodes -o wide
63+
```
64+
65+
The following example output shows all nodes on the cluster, including the new node pool you created and the existing node pools:
66+
67+
```output
68+
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
69+
aks-agentpool-18877473-vmss000000 Ready agent 5h40m v1.23.8 10.240.0.4 <none> Ubuntu 18.04.6 LTS 5.4.0-1085-azure containerd://1.5.11+azure-2
70+
akspoolws000000 Ready agent 3h15m v1.23.8 10.240.0.208 <none> Windows Server 2022 Datacenter 10.0.20348.825 containerd://1.6.6+azure
71+
akspoolws000001 Ready agent 3h17m v1.23.8 10.240.0.239 <none> Windows Server 2022 Datacenter 10.0.20348.825 containerd://1.6.6+azure
72+
akspoolws000002 Ready agent 3h17m v1.23.8 10.240.1.14 <none> Windows Server 2022 Datacenter 10.0.20348.825 containerd://1.6.6+azure
73+
akswspool000000 Ready agent 5h37m v1.23.8 10.240.0.115 <none> Windows Server 2019 Datacenter 10.0.17763.3165 containerd://1.6.6+azure
74+
akswspool000001 Ready agent 5h37m v1.23.8 10.240.0.146 <none> Windows Server 2019 Datacenter 10.0.17763.3165 containerd://1.6.6+azure
75+
akswspool000002 Ready agent 5h37m v1.23.8 10.240.0.177 <none> Windows Server 2019 Datacenter 10.0.17763.3165 containerd://1.6.6+azure
76+
```
77+
78+
2. Apply the updated YAML file to the existing workload using the `kubectl apply` command and specify the name of the YAML file.
79+
80+
```bash
81+
kubectl apply -f <filename>
82+
```
5683

57-
## Apply the new YAML file to the existing workload
84+
The following example output shows a *configured* status for the deployment:
5885

59-
If you have an application deployed already, follow the recommended steps to deploy a new node pool with Windows Server 2022 nodes. Once deployed, your environment will show Windows Server 2019 and 2022 nodes, with the workloads running on the 2019 nodes:
86+
```output
87+
deployment.apps/sample configured
88+
service/sample unchanged
89+
```
6090

61-
```bash
62-
kubectl get nodes -o wide
63-
```
64-
This command shows all nodes on your AKS cluster with extra details on the output:
91+
At this point, AKS starts the process of terminating the existing pods and deploying new pods to the Windows Server 2022 nodes.
6592

66-
```output
67-
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
68-
aks-agentpool-18877473-vmss000000 Ready agent 5h40m v1.23.8 10.240.0.4 <none> Ubuntu 18.04.6 LTS 5.4.0-1085-azure containerd://1.5.11+azure-2
69-
akspoolws000000 Ready agent 3h15m v1.23.8 10.240.0.208 <none> Windows Server 2022 Datacenter 10.0.20348.825 containerd://1.6.6+azure
70-
akspoolws000001 Ready agent 3h17m v1.23.8 10.240.0.239 <none> Windows Server 2022 Datacenter 10.0.20348.825 containerd://1.6.6+azure
71-
akspoolws000002 Ready agent 3h17m v1.23.8 10.240.1.14 <none> Windows Server 2022 Datacenter 10.0.20348.825 containerd://1.6.6+azure
72-
akswspool000000 Ready agent 5h37m v1.23.8 10.240.0.115 <none> Windows Server 2019 Datacenter 10.0.17763.3165 containerd://1.6.6+azure
73-
akswspool000001 Ready agent 5h37m v1.23.8 10.240.0.146 <none> Windows Server 2019 Datacenter 10.0.17763.3165 containerd://1.6.6+azure
74-
akswspool000002 Ready agent 5h37m v1.23.8 10.240.0.177 <none> Windows Server 2019 Datacenter 10.0.17763.3165 containerd://1.6.6+azure
75-
```
93+
3. Check the status of the deployment using the `kubectl get pods` command.
7694

77-
With the Windows Server 2022 node pool deployed and the YAML file configured, you can now deploy the new version of the YAML:
95+
```bash
96+
kubectl get pods -o wide
97+
```
7898

79-
```bash
80-
kubectl apply -f <filename>
81-
```
99+
The following example output shows the pods in the `defualt` namespace:
82100

83-
This command should return a "configured" status for the deployment:
101+
```output
102+
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
103+
sample-7794bfcc4c-k62cq 1/1 Running 0 2m49s 10.240.0.238 akspoolws000000 <none> <none>
104+
sample-7794bfcc4c-rswq9 1/1 Running 0 2m49s 10.240.1.10 akspoolws000001 <none> <none>
105+
sample-7794bfcc4c-sh78c 1/1 Running 0 2m49s 10.240.0.228 akspoolws000000 <none> <none>
106+
```
84107

85-
```output
86-
deployment.apps/sample configured
87-
service/sample unchanged
88-
```
89-
At this point, AKS starts the process of terminating the existing pods and deploying new pods to the Windows Server 2022 nodes. You can check the status of your deployment by running:
108+
## Security and authentication considerations
90109

91-
```bash
92-
kubectl get pods -o wide
93-
```
94-
This command returns the status of the pods on the default namespace. You might need to change the command above to list the pods on specific namespaces.
110+
If you're using Group Managed Service Accounts (gMSA), you need to update the Managed Identity configuration for the new node pool. gMSA uses a secret (user account and password) so the node that runs the Windows pod can authenticate the container against Azure Active Directory (Azure AD). To access that secret on Azure Key Vault, the node uses a Managed Identity that allows the node to access the resource. Since Managed Identities are configured per node pool, and the pod now resides on a new node pool, you need to update that configuration. For more information, see [Enable Group Managed Service Accounts (GMSA) for your Windows Server nodes on your Azure Kubernetes Service (AKS) cluster](./use-group-managed-service-accounts.md).
95111

96-
```output
97-
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
98-
sample-7794bfcc4c-k62cq 1/1 Running 0 2m49s 10.240.0.238 akspoolws000000 <none> <none>
99-
sample-7794bfcc4c-rswq9 1/1 Running 0 2m49s 10.240.1.10 akspoolws000001 <none> <none>
100-
sample-7794bfcc4c-sh78c 1/1 Running 0 2m49s 10.240.0.228 akspoolws000000 <none> <none>
101-
```
112+
The same principle applies to Managed Identities for any other pod or node pool when accessing other Azure resources. You need to update any access that Managed Identity provides to reflect the new node pool. To view update and sign-in activities, see [How to view Managed Identity activity](../active-directory/managed-identities-azure-resources/how-to-view-managed-identity-activity.md).
102113

103-
## Active Directory, gMSA and Managed Identity implications
114+
## Next steps
104115

105-
If you're using Group Managed Service Accounts (gMSA), update the Managed Identity configuration for the new node pool. gMSA uses a secret (user account and password) so the node on which the Windows pod is running can authenticate the container against Active Directory. To access that secret on Azure Key Vault, the node uses a Managed Identity that allows the node to access the resource. Since Managed Identities are configured per node pool, and the pod now resides on a new node pool, you need to update that configuration. Check out [Enable Group Managed Service Accounts (GMSA) for your Windows Server nodes on your Azure Kubernetes Service (AKS) cluster](./use-group-managed-service-accounts.md) for more information.
116+
In this article, you learned how to upgrade the OS version for Windows workloads on AKS. To learn more about Windows workloads on AKS, see [Deploy a Windows container application on Azure Kubernetes Service (AKS)](./learn/quick-windows-container-deploy-cli.md).
106117

107-
The same principle applies to Managed Identities used for any other pod/node pool when accessing other Azure resources. Any access provided via Managed Identity needs to be updated to reflect the new node pool. To view update and sign-in activities, see [How to view Managed Identity activity](../active-directory/managed-identities-azure-resources/how-to-view-managed-identity-activity.md).
118+
<!-- LINKS - External -->
119+
[aks-release-notes]: https://github.com/Azure/AKS/releases

0 commit comments

Comments
 (0)