Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O recurso de reversão da versão do pool de nós no Serviço de Kubernetes do Azure (AKS) permite recuperar comportamentos inesperados após atualizações do Kubernetes. Se ocorrerem problemas, você pode reverter os pools de nós para a versão anterior do Kubernetes e a combinação de imagens de nós, garantindo a continuidade dos negócios e minimizando o tempo de inatividade. Este artigo explica quando e como usar o recurso de reversão, seus recursos e limitações e práticas recomendadas para ações pós-reversão.
Pré-requisitos
- CLI do Azure versão 2.64.0 ou superior. Localize sua versão usando o
az --versioncomando. Se precisar instalar ou atualizar, consulte Instalar CLI do Azure. - A extensão
aks-previewCLI do Azure instalada e atualizada para a versão mais recente. - Versão da API
2025-08-02-previewou posterior.
Instalar a extensão aks-preview CLI do Azure
Importante
As funcionalidades em versão preliminar do AKS estão disponíveis de forma optativa e por autoatendimento. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:
- Políticas de suporte do AKS
- perguntas frequentes Suporte do Azure
Instale ou atualize a extensão aks-preview usando os comandos az extension add e az extension update.
# Install the aks-preview extension
az extension add --name aks-preview
# Update the aks-preview extension
az extension update --name aks-preview
Recursos suportados para reversão da versão do pool de nós
O recurso de reversão da versão do pool de nós oferece suporte aos seguintes recursos:
| Característica | DESCRIÇÃO |
|---|---|
| Reverter versão | Restaura as versões do Kubernetes e da imagem do nó ao seu estado anterior. |
| Gatilho manual, execução automática | A reversão requer iniciação manual, mas, uma vez disparada, o sistema lida automaticamente com todo o processo de reversão sem intervenção adicional. |
| Compatibilidade do pool de nós | Funciona em todos os tipos de pools de nós, incluindo pools de máquinas virtuais (VMs) e pools de nós baseados em Conjuntos de Dimensionamento de Máquinas Virtuais (VMSS). |
| Suporte ao sistema operacional | Compatível com todas as SKUs (unidades de manutenção de estoque do sistema operacional), incluindo Ubuntu, Azure Linux e pools de Windows. |
| Processo simplificado | Não é necessário gerenciamento de instantâneos. |
Limitações e considerações sobre a reversão do pool de nós
Tenha em mente as seguintes limitações ao usar o recurso de reversão do pool de nós:
- Limitado apenas a alterações de versão. Outras alterações no pool de nós não são revertidas.
- Não são permitidas operações simultâneas durante a reversão.
- Se estiver configurado, você deve desabilitar a atualização automática do cluster antes da reversão.
- Disponível somente por sete dias após a conclusão da atualização.
- Não é possível fazer reversões em sequência para retornar a várias versões anteriores.
- Rollback não suporta a reversão de alterações de SKU do sistema operacional. Se você alterou a SKU do sistema operacional do pool de nós (por exemplo, do Ubuntu para o Linux do Azure), a reversão tentará restaurar a versão anterior da imagem do nó, que pertence a um SKU do sistema operacional diferente e é rejeitada. Para reverter uma alteração de SKU do sistema operacional, use o
az aks nodepool update --os-skucomando.
Tenha em mente as seguintes considerações ao usar a reversão do pool de nós:
| Implicações de segurança | Considerações operacionais |
|---|---|
| * Exposição à vulnerabilidade: Reverter para a versão anterior remove os patches de segurança e as atualizações da versão mais recente. Portanto, recomendamos usar a reversão apenas temporariamente enquanto resolve os problemas e, em seguida, atualizar novamente assim que possível. |
*
Interrupção do serviço: o processo de reversão pode causar interrupções temporárias na carga de trabalho. * Disponibilidade de recursos: verifique a capacidade suficiente para a operação de reversão. * Requisitos de teste: planeje corrigir problemas subjacentes antes de tentar atualizações novamente. |
Por que usar rollback
A reversão fornece um mecanismo de recuperação crítico para ambientes de produção:
- Continuidade dos negócios: minimizar o tempo de inatividade quando as atualizações causam problemas inesperados
- Mitigação de risco: restaurar rapidamente configurações conhecidas sem procedimentos de recuperação complexos
- Recuperação simplificada: evite intervenção manual ou recompilação de clusters de backups
Quando usar a reversão do pool de nós
Considere a reversão como sua opção de recuperação nos seguintes cenários:
- Ocorrem falhas de atualização: problemas de infraestrutura, restrições de recurso ou problemas de compatibilidade impedem atualizações bem-sucedidas.
- Quebra de aplicativos: as cargas de trabalho enfrentam falhas críticas ou dados corrompidos com versões mais recentes do Kubernetes.
- Degradação de desempenho: novas versões causam latência inaceitável, problemas de taxa de transferência ou consumo de recursos.
- Lacunas de teste surgem: problemas na produção que não foram capturados durante o teste de pré-produção.
Fluxo de trabalho de reversão do pool de nós
O diagrama a seguir ilustra o workflow de rollback do node pool:
O processo de reversão restaura todos os nós em um pool de nós para o estado da versão anterior. Os principais aspectos do fluxo de trabalho incluem:
- Abordagem tudo ou nada: todos os nós devem reverter com sucesso para a versão anterior para que a reversão seja concluída com sucesso. Se algum nó não conseguir reverter, toda a operação falhará, a fim de comunicar claramente o estado do cluster, semelhante à operação de atualização.
- Rastreamento de progresso: Monitore o status de reversão usando o Log de Atividades do Azure para obter o histórico de operações e a API de Status da Operação para atualizações em tempo real.
Reverter uma versão do pool de nós
Importante
Tenha em mente as seguintes informações ao reverter uma versão do pool de nós:
- Permanecer em versões mais antigas a longo prazo aumenta os riscos de segurança e pode eventualmente impedir atualizações devido a limitações de distorção de versão. Trate a reversão como um mecanismo de recuperação temporária, não como uma solução permanente.
- Ao usar a API REST, você pode chamar a API Obter Perfil de Atualização primeiro para recuperar as versões usadas recentemente. Use essas informações para especificar a versão de destino em sua solicitação de reversão.
Reverta uma versão do pool de nós usando o comando
az aks nodepool rollback. O exemplo a seguir reverte o pool de nós chamadomyNodePoolno cluster AKS chamadomyAKSClusterno grupo de recursosmyResourceGroup:az aks nodepool rollback --name myNodePool --resource-group myResourceGroup --cluster-name myAKSCluster
Monitorar o status de reversão do pool de nós
Você pode usar os seguintes métodos para monitorar o status de uma operação de reversão do pool de nós e validar uma reversão bem-sucedida:
- Pesquise os logs de atividades no cluster.
- Procure eventos específicos relacionados à atualização em seu cluster.
- Assine os eventos AKS com o Grade de Eventos do Azure.
- Se você assinar um canal de atualização automática, poderá usar o Gerenciador de Comunicações do AKS para notificações de atualização.
Práticas recomendadas de pós-reversão
Após reverter com sucesso seu pool de nós, use as seguintes práticas recomendadas para garantir estabilidade e segurança:
- Investigue a causa raiz: identifique por que a atualização falhou antes de tentar outra atualização. Examine os logs de aplicativos, as métricas de recurso e os requisitos de compatibilidade.
- Teste em ambiente não-produtivo: valide a versão mais recente em um ambiente de desenvolvimento ou homologação para reproduzir e resolver problemas antes de fazer uma nova atualização em produção.
-
Planeje sua nova atualização: não fique na versão revertida indefinidamente. Agende uma nova atualização para manter os patches de segurança e o suporte:
- Para problemas críticos de segurança: atualize novamente em poucos dias após a validação das correções.
- Para problemas de compatibilidade do aplicativo: atualize novamente em semanas após ajustes de código.
- Período máximo recomendado: 30 dias para evitar o acúmulo de vulnerabilidades de segurança.
Perguntas frequentes (FAQs)
Posso realizar outras operações durante uma reversão do pool de nós?
Não, a reversão deve ser concluída antes de iniciar outras operações. Para executar operações diferentes, anule a reversão primeiro.
A reversão do pool de nós reverte tanto a versão do Kubernetes quanto a imagem do nó?
Sim, a reversão volta para a versão mais recente do Kubernetes e sua imagem de nó correspondente. Se ambos os componentes forem alterados, o sistema restaurará a versão anterior do Kubernetes com a última imagem de nó compatível com essa versão.
Posso reverter apenas a imagem do nó sem alterar a versão do pool de nós?
Sim, se você realizou apenas uma atualização da imagem do nó nos últimos sete dias (sem atualizar a versão do pool de nós), a reversão restaura a imagem anterior do disco rígido virtual (VHD), mantendo a mesma versão do Kubernetes.
Posso reverter para uma versão sem suporte?
Não, você não pode reverter para uma versão do Kubernetes que não tem mais suporte do AKS. Por exemplo, se o pool de nós estiver na versão 1.27.9 (agora sem suporte) e você tiver atualizado para 1.28.5, não poderá reverter para 1.27.9 porque ele não está mais na lista de versões com suporte. Sempre verifique a política de suporte à versão do Kubernetes do AKS para verificar a disponibilidade da versão.
Preciso desativar a atualização automática antes de realizar uma reversão do pool de nós?
Sim, se o cluster tiver autoupgrade ativado, você deverá desativá-lo antes de realizar um rollback. Além disso, se o cluster estiver incluído em um grupo de atualização em um perfil de atualização automática do Azure Kubernetes Fleet Manager, você deverá remover o cluster do grupo de atualizações antes de executar a reversão. Caso contrário, o processo de atualização automática poderá atualizar automaticamente seu pool de nós novamente após a conclusão da reversão.
Posso reverter depois de alterar o SKU do sistema operacional (por exemplo, do Ubuntu para Azure Linux)?
Não. A reversão do pool de nós é limitada a alterações de versão e não reverte as alterações de SKU do sistema operacional. Depois de migrar de um SKU do sistema operacional para outro (por exemplo, Ubuntu para Azure Linux), a versão anterior da imagem do nó pertence ao SKU do sistema operacional antigo e é incompatível com a configuração atual. A operação de reversão rejeita a versão anterior da imagem com um erro semelhante a:
NodeImageVersion 'AKSUbuntu-2204gen2containerd-202602.13.5' is not accepted. NodeImageVersion can only be current version 'AKSAzureLinux-V3gen2-202602.13.5' or 'latest'
Para reverter o SKU do sistema operacional, use o az aks nodepool update comando com o --os-sku parâmetro. Para obter mais informações, consulte Restaurar a versão do sistema operacional.
Conteúdo relacionado
Para saber mais sobre atualizações de pool de nós no AKS, consulte os seguintes artigos: