Atualizar a versão do sistema operacional para suas cargas de trabalho do Windows No AKS (Serviço de Kubernetes do Azure)
Ao atualizar da versão do sistema operacional de uma carga de trabalho do Windows em execução no AKS (Serviço de Kubernetes do Azure), você deve implantar um novo pool de nós para garantir que as versões do Windows correspondam em cada pool de nós. Este artigo descreve as etapas para atualizar a versão do sistema operacional para cargas de trabalho do Windows no AKS. Embora este exemplo se concentre na atualização do Windows Server 2019 para o Windows Server 2022, o mesmo processo pode ser seguido para atualizar de qualquer versão do Windows Server para outra.
Suporte à versão do sistema operacional do Windows Server
Quando uma nova versão do sistema operacional do Windows Server é lançada, o AKS se compromete a dar suporte a ela e recomenda que você atualize para a versão mais recente para aproveitar as correções, melhorias e novas funcionalidades. O AKS fornece um ciclo de vida de suporte de cinco anos para cada versão do Windows Server, a partir do Windows Server 2022. Durante esse período, o AKS lançará uma nova versão que dá suporte a uma versão mais recente do sistema operacional do Windows Server para a qual você atualizará.
Observação
- O Windows Server 2019 será desativado após a versão 1.32 do Kubernetes chegar ao EOL (fim da vida útil). Para obter mais informações, confira Notas sobre a versão do AKS.
- O Windows Server 2022 será desativado após a versão 1.34 do Kubernetes chegar ao EOL (fim da vida útil). Para obter mais informações, confira Notas sobre a versão do AKS.
Limitações
O Windows Server 2019 e o Windows Server 2022 não podem coexistir no mesmo pool de nós no AKS. Você deve criar um pool de nós para hospedar a nova versão do sistema operacional. É importante que você corresponda as permissões e o acesso do pool de nós anterior ao novo.
Antes de começar
- Atualize a instrução
FROM
no Dockerfile para a nova versão do sistema operacional. - Confira seu aplicativo e verifique se o aplicativo de contêiner funciona na nova versão do sistema operacional.
- Implante o aplicativo de contêiner verificado no AKS em um ambiente de desenvolvimento ou de teste.
- Anote o novo nome ou tag da imagem para uso neste artigo.
Observação
Para saber como criar um Dockerfile para cargas de trabalho do Windows, consulte Dockerfile no Windows e Otimizar Dockerfiles do Windows.
Adicionar um pool de nós do Windows Server 2022 a um cluster existente
- Adicione um pool de nós do Windows Server 2022 a um cluster existente.
Atualizar o arquivo YAML
O Seletor de Nós é a opção mais comum e recomendada para o posicionamento de pods do Windows em nós do Windows.
Adicione o Seletor de Nós ao arquivo YAML incluindo a seguinte anotação:
nodeSelector: "kubernetes.io/os": windows
A anotação encontra qualquer nó do Windows disponível e coloca o pod nesse nó (seguindo todas as outras regras de agendamento). Ao atualizar do Windows Server 2019 para o Windows Server 2022, você precisará impor o posicionamento em um nó do Windows e um nó que esteja executando a versão mais recente do sistema operacional. Para fazer isso, uma opção é usar uma anotação diferente:
nodeSelector: "kubernetes.azure.com/os-sku": Windows2022
Depois de atualizar o
nodeSelector
no arquivo YAML, você também precisa atualizar a imagem de contêiner que deseja usar. Você pode obter essas informações da etapa anterior na qual criou uma versão do aplicativo conteinerizado alterando a instruçãoFROM
no Dockerfile.
Observação
Você deve usar o mesmo arquivo YAML usado para implantar inicialmente o aplicativo. Isso garante que nenhuma outra configuração seja alterada além de nodeSelector
e a imagem de contêiner.
Aplicar o arquivo YAML atualizado à carga de trabalho existente
Exiba os nós no cluster usando o comando
kubectl get nodes
.kubectl get nodes -o wide
A saída de exemplo a seguir mostra todos os nós no cluster, incluindo o novo pool de nós que você criou e os pools de nós existentes:
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME 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 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 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 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 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 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 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
Aplique o arquivo YAML atualizado à carga de trabalho existente usando o comando
kubectl apply
e especifique o nome do arquivo YAML.kubectl apply -f <filename>
A saída de exemplo a seguir mostra um status configurado para a implantação:
deployment.apps/sample configured service/sample unchanged
Neste ponto, o AKS inicia o processo de encerramento dos pods existentes e a implantação de novos pods nos nós do Windows Server 2022.
Verifique a status da implantação usando o comando
kubectl get pods
.kubectl get pods -o wide
A saída de exemplo a seguir mostra os pods no namespace
default
:NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES sample-7794bfcc4c-k62cq 1/1 Running 0 2m49s 10.240.0.238 akspoolws000000 <none> <none> sample-7794bfcc4c-rswq9 1/1 Running 0 2m49s 10.240.1.10 akspoolws000001 <none> <none> sample-7794bfcc4c-sh78c 1/1 Running 0 2m49s 10.240.0.228 akspoolws000000 <none> <none>
Considerações sobre segurança e autenticação
Se você estiver usando as Contas de Serviço Gerenciado de Grupo (gMSA), será necessário atualizar a configuração de Identidade Gerenciada para o novo pool de nós. O gMSA usa um segredo (conta de usuário e senha) para que o nó que executa o pod do Windows possa autenticar o contêiner no Microsoft Entra ID. Para acessar esse segredo no Azure Key Vault, o nó usa uma Identidade Gerenciada que permite que o nó acesse o recurso. Como as Identidades Gerenciadas são configuradas por pool de nós e o pod agora reside em um novo pool de nós, você precisa atualizar essa configuração. Para obter mais informações, confira Habilitar GMSA (Contas de Serviço Gerenciado de Grupo) em seus nós do Windows Server no cluster do AKS (Serviço de Kubernetes do Azure).
O mesmo princípio se aplica às Identidades Gerenciadas para qualquer outro pool de pods ou nós ao acessar outros recursos do Azure. Você precisa atualizar qualquer acesso que a Identidade Gerenciada fornece para refletir o novo pool de nós. Para exibir as atividades de atualização e entrada, veja Como exibir a atividade de Identidade Gerenciada.
Próximas etapas
Neste artigo, você aprendeu a atualizar a versão do sistema operacional para cargas de trabalho do Windows no AKS. Para saber mais sobre as cargas de trabalho do Windows no AKS, consulte Implantar um aplicativo de contêiner do Windows no AKS (Serviço de Kubernetes do Azure).
Azure Kubernetes Service