Skip to content

Commit 6fe2beb

Browse files
abhilashaagarwalaabhilashaagarwala
authored
Create disable-windows-nodepool.md
1 parent 5d12934 commit 6fe2beb

File tree

1 file changed

+147
-0
lines changed

1 file changed

+147
-0
lines changed

‎disable-windows-nodepool.md

Lines changed: 147 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,147 @@
1+
---
2+
title: Disable Windows nodepool feature
3+
description: Learn how to update your Azure Local configuration and disable Windows nodepool feature
4+
ms.topic: how-to
5+
ms.date: 11/18/2024
6+
author: sethmanheim
7+
ms.author: sethm
8+
ms.reviewer: abha
9+
ms.lastreviewed: 11/18/2024
10+
11+
---
12+
13+
# Disable Windows nodepool feature on Azure Local
14+
[!INCLUDE [hci-applies-to-23h2](includes/hci-applies-to-23h2.md)]
15+
16+
When you install Azure Local, three virtual hard disks (VHD) - Azure Linux, Windows Server 2019 and Windows Server 2022 are automatically downloaded. VHDs are needed to deploy AKS on Azure Local because they serve as the base operating system images for the Kubernetes nodes within your AKS cluster. For a mixed-OS environment (both Windows and Linux nodes), a Windows Server 2019 or Windows Server 2022 VHD is necessary for provisioning a Windows Server 2019, or 2022 nodepool. The Linux nodepool uses the Azure Linux VHD that's been optimized for running Kubernetes. In environments where only Linux containers are being used, however, the Windows VHD is unnecessary, and disabling the Windows nodepool feature helps avoid downloading and storing this large file, saving bandwidth and storage space.
17+
18+
This how-to guide walks you through how to disable the Windows nodepool feature for Azure Kubernetes Service (AKS) on Azure Local. Disabling this feature prevents the automatic download of Windows Virtual Hard Disks (VHDs), which are approximately 20GB in size and required for creating Windows-based nodepools. By doing so, enterprises with limited internet bandwidth can avoid unnecessary downloads, especially if their workloads are exclusively using Linux containers. This feature helps optimize bandwidth usage and simplifies resource management for environments where Windows nodes are not needed.
19+
20+
21+
## Before you begin
22+
23+
Before you begin, make sure you have the following:
24+
- **Azure Local deployed**: This how-to is only applicable if you already have Azure Local deployed. The commands in this document cannot be run before Azure Local has been deployed. We currently do not offer the ability to make this change before the initial Azure Local deployment.
25+
- **Custom Location ID** - Azure Resource Manager ID of the custom location. The custom location is configured during the Azure Local deployment. If you're on Azure portal, go to the Overview > Server page in the Azure Stack HCI system resource. You should see a custom location for your cluster.
26+
- **Azure resource group** - The Azure resource group where Azure Local has been deployed.
27+
- Azure RBAC permissions to update Azure Stack HCI configuration. Make sure you have the following roles. To learn more, visit [required permissions for deployment](/hci/deploy/deployment-arc-register-server-permissions?tabs=powershell#assign-required-permissions-for-deployment)
28+
- Azure Stack HCI Administrator
29+
- Reader
30+
31+
## Set environment variables
32+
To help simplify configuration, the steps below define environment variables that are referenced in this how-to article. Remember to replace the values shown with your own values.
33+
34+
Set the custom location and the resource group values in environment variables.
35+
```azcli
36+
$customlocationID = <The custom location ARM ID for Azure Local>
37+
$resourceGroup = <The Azure resource group where Azure Local has been deployed>
38+
```
39+
40+
Next, run the below command to obtain the clusterName parameter. Its the name of the Arc Resource Bridge that's been deployed on Azure Local.
41+
```
42+
az customlocation show -n $customlocationID -g $resourceGroup --query hostResourceId
43+
```
44+
Expected output:
45+
46+
```output
47+
/subscriptions/f3dwer-00000-4383-2345-00000/resourceGroups/SanJose/providers/Microsoft.ResourceConnector/appliances/sanjose-arcbridge
48+
```
49+
50+
In the above output, "sanjose-arcbridge" is the name of the Arc resource bridge that's been deployed on the Azure local cluster. This name will be different for your deployment.
51+
52+
```azcli
53+
$clusterName = <Name of Arc resource bridge deployed on the Azure Local cluster>
54+
```
55+
Next, you need to obtain the name of the AKS Arc extension that's been deployed to the custom location. To get this, run the following command to list the extensions installed on the custom location.
56+
```azcli
57+
az customlocation show -n $customlocationID -g $resourceGroup --query clusterExtensionIds -o tsv
58+
```
59+
Expected output:
60+
61+
```output
62+
/subscriptions/fbaf508b-cb61-4383-9cda-a42bfa0c7bc9/resourceGroups/SanJose/providers/Microsoft.ResourceConnector/appliances/sanjose-arcbridge/providers/Microsoft.KubernetesConfiguration/extensions/hybridaksextension
63+
/subscriptions/fbaf508b-cb61-4383-9cda-a42bfa0c7bc9/resourceGroups/SanJose/providers/Microsoft.ResourceConnector/appliances/sanjose-arcbridge/providers/Microsoft.KubernetesConfiguration/extensions/vmss-hci
64+
```
65+
You should have two extensions installed on your custom location - AKS Arc and Arc VM management. Copy the extension name for AKS into an environment variable. In my output, the extension name is `hybridaksextension`. It maybe different from what you see.
66+
67+
```azcli
68+
$extensionName = <Name of AKS Arc extension that's been deployed on the custom location>
69+
```
70+
71+
Once you have the extension name, create variables for the following parameters.
72+
73+
```azcli
74+
$extensionVersion = "$(az k8s-extension show -n $extensionName -g $resourceGroup -c $clusterName --cluster-type appliances --query version -o tsv)"
75+
$releaseTrain = "$(az k8s-extension show -n $extensionName -g $resourceGroup -c $clusterName --cluster-type appliances --query releaseTrain -o tsv)"
76+
```
77+
78+
## Update the AKS Arc extension to disable Windows nodepool feature
79+
80+
Once you've set the environment variables, you can run the following command from an Azure Shell session to update the AKS Arc k8s extension. This will disable the Windows nodepool feature and delete any associated VHDs.
81+
82+
```azcli
83+
az k8s-extension update --resource-group $resourceGroup --cluster-name $clusterName --cluster-type appliances --name $extensionName --version $extensionVersion --release-train $releaseTrain --config disable-windows-nodepool=true --yes
84+
```
85+
86+
## Validate if Windows nodepool feature has been disabled
87+
88+
You can check if the configuration settings have been applied by running `az k8s-extension show`, as described below.
89+
90+
```azcli
91+
az k8s-extension show --name $extensionName --resource-group $resourceGroup --cluster-name $clusterName --cluster-type appliances --query configurationSettings
92+
```
93+
94+
Expected output:
95+
96+
```
97+
...
98+
"disable-windows-nodepool": "true",
99+
...
100+
```
101+
102+
Next, check if Windows nodepools have been disabled by running the following command.
103+
104+
```
105+
az aksarc get-versions --resource-group $resourceGroup --custom-location $customlocationID
106+
```
107+
108+
The output for `osType=Windows` should say that `"Windows nodepool feature is disabled"` and the `ready` state should be `false`, for each Kubernetes version option.
109+
110+
```output
111+
...
112+
"1.27.7": {
113+
"readiness": [
114+
{
115+
"errorMessage": null,
116+
"osSku": "CBLMariner",
117+
"osType": "Linux",
118+
"ready": true
119+
},
120+
{
121+
"errorMessage": "Windows nodepool feature is disabled",
122+
"osSku": "Windows2019",
123+
"osType": "Windows",
124+
"ready": false
125+
},
126+
{
127+
"errorMessage": "Windows nodepool feature is disabled",
128+
"osSku": "Windows2022",
129+
"osType": "Windows",
130+
"ready": false
131+
}
132+
],
133+
...
134+
```
135+
136+
## FAQ
137+
138+
### What happens if I try disabling Windows nodepool and Windows node pools exist on atleast 1 AKS cluster on the Azure local deployment?
139+
You will have to delete Windows node pool manually before you disable the feature. If there are existing Windows node pools, you will not be able to disable the feature.
140+
141+
### What happens to downloaded Windows VHDs if I disable Windows node pools?
142+
The Windows VHDs that have previously been downloaded are automatically deleted if Windows nodepools is disabled. You can verify if Windows VHDs have been removed from the Azure Local storage paths. Note that deletion can take some time. Wait for 30 minutes before checking. You will need to check all the storage paths since Windows VHDs are assigned to storage paths in round robin fashion based on available storage capacity.
143+
144+
## Next steps
145+
146+
- [What's new in AKS on Azure Stack HCI](aks-overview.md)
147+
- [Create AKS clusters](aks-create-clusters-cli.md)

0 commit comments

Comments
 (0)