Desabilitar o recurso de pool de nós do Windows no Azure Local
Aplica-se a: Azure Local, versão 23H2
Quando você instala o Azure Local, três VHDs (discos rígidos virtuais) - Azure Linux, Windows Server 2019 e Windows Server 2022 - são baixados automaticamente. Os VHDs são necessários para implantar o AKS no Azure Local porque servem como as imagens do sistema operacional base para os nós do Kubernetes dentro do cluster AKS. Para um ambiente de sistema operacional misto (nós Windows e Linux), um VHD do Windows Server 2019 ou Windows Server 2022 é necessário para provisionar um pool de nós do Windows Server 2019 ou 2022. O pool de nós do Linux usa o VHD do Azure Linux otimizado para executar o Kubernetes. Em ambientes onde apenas contêineres Linux são usados, no entanto, o VHD do Windows é desnecessário. Você pode desativar o recurso de pool de nós do Windows para evitar baixar e armazenar esse arquivo grande, o que economiza largura de banda e espaço de armazenamento.
Este artigo de instruções orienta você sobre como desabilitar o recurso de pool de nós do Windows para o Serviço Kubernetes do Azure (AKS) no Azure Local. A desativação desse recurso impede o download automático de VHDs (Discos Rígidos Virtuais) do Windows, que têm aproximadamente 20 GB de tamanho e são necessários para a criação de pools de nós baseados no Windows. Ao fazer isso, as empresas com largura de banda de internet limitada podem evitar downloads desnecessários, especialmente se suas cargas de trabalho estiverem usando exclusivamente contêineres Linux. Esse recurso ajuda a otimizar o uso da largura de banda e simplifica o gerenciamento de recursos para ambientes onde os nós do Windows não são necessários.
Antes de começar
Antes de começar, certifique-se de que tem os seguintes pré-requisitos:
- Azure Local implantado. Este artigo só é aplicável se você já implantou o Azure Local, versão 2411. Não é possível executar os comandos neste artigo antes de implantar o Azure Local versão 2411. Atualmente, não oferecemos suporte à capacidade de fazer essa alteração antes da implantação inicial do Azure Local Release 2411.
- Permissões do RBAC do Azure para atualizar a configuração Local do Azure. Certifique-se de que tem as seguintes funções. Para obter mais informações, consulte as permissões necessárias para implantação:
- Administrador Local do Azure
- Leitor
- Localização personalizada. Nome do local personalizado. O local personalizado é configurado durante a implantação do Azure Local. Se você estiver no portal do Azure, vá para a página Servidor de Visão Geral > no recurso do sistema Local do Azure. Você verá um local personalizado para seu cluster.
- Grupo de recursos do Azure. O grupo de recursos do Azure no qual o Azure Local é implantado.
Opção recomendada: desabilitar o pool de nós do Windows de uma sessão do Azure CloudShell
Para ajudar a simplificar a configuração, as etapas a seguir definem as variáveis de ambiente mencionadas neste artigo. Lembre-se de substituir os valores mostrados pelos seus próprios valores.
Defina o local personalizado e os valores do grupo de recursos em variáveis de ambiente:
$customlocationName = <The custom location name for Azure Local>
$resourceGroup = <The Azure resource group in which Azure Local is deployed>
Em seguida, execute o seguinte comando para obter o clusterName parâmetro. Este parâmetro é o nome do Arc Resource Bridge que você implantou no Azure Local:
az customlocation show -n $customlocationName -g $resourceGroup --query hostResourceId
Resultado esperado:
/subscriptions/f3dwer-00000-4383-2345-00000/resourceGroups/SanJose/providers/Microsoft.ResourceConnector/appliances/sanjose-arcbridge
Nesta saída, sanjose-arcbridge é o nome da ponte de recursos Arc que você implantou no cluster local do Azure. Esse nome é diferente para sua implantação.
$clusterName = <Name of Arc resource bridge deployed on the Azure Local cluster>
Em seguida, obtenha o nome da extensão AKS Arc que você implantou no local personalizado. Para obter esse nome, execute o seguinte comando para listar as extensões instaladas no local personalizado:
az customlocation show -n $customlocationID -g $resourceGroup --query clusterExtensionIds -o tsv
Resultado esperado:
/subscriptions/fbaf508b-cb61-4383-9cda-a42bfa0c7bc9/resourceGroups/SanJose/providers/Microsoft.ResourceConnector/appliances/sanjose-arcbridge/providers/Microsoft.KubernetesConfiguration/extensions/hybridaksextension
/subscriptions/fbaf508b-cb61-4383-9cda-a42bfa0c7bc9/resourceGroups/SanJose/providers/Microsoft.ResourceConnector/appliances/sanjose-arcbridge/providers/Microsoft.KubernetesConfiguration/extensions/vmss-hci
Você deve ter duas extensões instaladas em seu local personalizado: AKS Arc e Arc VM management. Copie o nome da extensão para AKS em uma variável de ambiente. Na saída de exemplo, o nome da extensão é hybridaksextension. Pode ser diferente do que você vê:
$extensionName = <Name of AKS Arc extension you deployed on the custom location>
Depois de ter o nome da extensão, crie variáveis para os seguintes parâmetros e, em seguida, desative o recurso de pool de nós do Windows:
$extensionVersion = "$(az k8s-extension show -n $extensionName -g $resourceGroup -c $clusterName --cluster-type appliances --query version -o tsv)"
$releaseTrain = "$(az k8s-extension show -n $extensionName -g $resourceGroup -c $clusterName --cluster-type appliances --query releaseTrain -o tsv)"
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
Opção alternativa: desabilitar o pool de nós do Windows depois de se conectar a um nó físico local do Azure por meio da Área de Trabalho Remota
Se, por algum motivo, você não puder usar o Azure CloudShell ou uma máquina com conectividade com o Azure para desabilitar o pool de nós do Windows, poderá desabilitar o pool de nós do Windows depois de se conectar a qualquer um dos nós físicos locais do Azure com a Área de Trabalho Remota. Você deve primeiro entrar no Azure:
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
Validar se o recurso de pool de nós do Windows está desabilitado
Você pode verificar se as definições de configuração foram aplicadas executando , da az k8s-extension showseguinte maneira:
az k8s-extension show --name $extensionName --resource-group $resourceGroup --cluster-name $clusterName --cluster-type appliances --query configurationSettings
Resultado esperado:
...
"disable-windows-nodepool": "true",
...
Em seguida, verifique se os pools de nós do Windows foram desabilitados executando o seguinte comando:
az aksarc get-versions --resource-group $resourceGroup --custom-location $customlocationName
A saída para osType=Windows deve dizer "O recurso de pool de nós do Windows está desativado" e o estado deve ser false, para cada opção de versão do ready Kubernetes:
...
"1.27.7": {
"readiness": [
{
"errorMessage": null,
"osSku": "CBLMariner",
"osType": "Linux",
"ready": true
},
{
"errorMessage": "Windows nodepool feature is disabled",
"osSku": "Windows2019",
"osType": "Windows",
"ready": false
},
{
"errorMessage": "Windows nodepool feature is disabled",
"osSku": "Windows2022",
"osType": "Windows",
"ready": false
}
],
...
FAQ
O que acontece se eu tentar desativar o pool de nós do Windows e os pools de nós do Windows existem em pelo menos 1 cluster AKS na implantação local do Azure?
Você deve excluir o pool de nós do Windows manualmente antes de desabilitar o recurso. Se houver pools de nós do Windows existentes, você não poderá desabilitar o recurso.
O que acontece com VHDs do Windows baixados se eu desabilitar os pools de nós do Windows?
Os VHDs do Windows que foram baixados anteriormente são excluídos automaticamente se o recurso de pools de nós do Windows estiver desabilitado. Você pode verificar se os VHDs do Windows foram removidos dos caminhos de armazenamento Local do Azure. A eliminação pode demorar algum tempo. Aguarde 30 minutos antes de verificar. Você deve verificar todos os caminhos de armazenamento, porque os VHDs do Windows são atribuídos aos caminhos de armazenamento de forma round-robin, com base na capacidade de armazenamento disponível.