Atualizar o plano de controle de cluster do AKS (Serviço de Kubernetes do Azure)

Os clusters do AKS (Serviço de Kubernetes do Azure) consistem em dois componentes principais: o plano de controle gerenciado pelo Azure e os pools de nós em que as cargas de trabalho são executadas. Este artigo se concentra na atualização do plano de controle de forma independente, o que permite que você adote novas versões do Kubernetes para recursos do servidor de API, gerenciando separadamente as atualizações do pool de nós.

Antes de começar

• Se você estiver usando a CLI do Azure, este artigo vai requerer a CLI do Azure versão 2.34.1 ou posterior. Use o az --version comando para localizar a versão. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure.
• Se estiver usando o Azure PowerShell, este artigo vai requerer o Azure PowerShell versão 5.9.0 ou posterior. Use o Get-InstalledModule -Name Az cmdlet para localizar a versão. Se precisar instalar ou atualizar, consulte Instalar o Azure PowerShell.
• Para executar operações de atualização, você precisa da função de colaborador Serviço de Kubernetes do Azure ou permissões equivalentes.
• As APIs beta são desabilitadas por padrão quando você atualiza para versões do Kubernetes versão 1.30 e 1.27 LTS.

Visão geral dos tipos de atualização do AKS

A tabela a seguir descreve três tipos de atualizações do AKS, destacando o escopo e os casos de uso:

Regras de atualização de versão do Kubernetes

Ao atualizar um cluster AKS não LTS com suporte, não é possível ignorar versões secundárias do Kubernetes. Você deve executar todas as atualizações sequencialmente por número de versão menor. Por exemplo, são permitidas atualizações entre 1.28.x ->1.29.x ou 1.29.x ->1.30.x . 1.28.x ->1.30.x não é permitido.

Um cluster LTS pode ignorar versões secundárias ao migrar para uma versão lts mais alta oferecida pelo AKS, desde que a atualização atenda aos requisitos de distorção de versão e às verificações de validação. Para obter mais informações, confira Posso ignorar várias versões do AKS durante uma atualização de cluster?.

A partir do Kubernetes 1.28, o painel de controle pode ter até três versões secundárias à frente dos pools de nós. Por exemplo, se o plano de controle estiver em 1,35.x, os pools de nós poderão estar em 1.32.x, 1.33.x, 1.34.x ou 1.35.x. Para restrições atuais, consulte a política de distorção de versão do AKS.

Verificar se há atualizações disponíveis do AKS

az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output table

Name     ResourceGroup          MasterVersion    Upgrades
-------  ---------------        ---------------  --------------
default  <resource-group-name>  1.28.9           1.29.2, 1.29.4

Get-AzAksVersion -Location <your-region> | Where-Object { $_.OrchestratorVersion }

Atualizar somente o plano de controle do AKS

Atualizar o cluster completo do AKS

az aks upgrade \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --kubernetes-version 1.29.4

Set-AzAksCluster -ResourceGroupName <resource-group-name> -Name <cluster-name> -KubernetesVersion 1.29.4

Perguntas frequentes sobre a atualização do plano de controle do AKS

Uma atualização somente de plano de controle também atualiza pools de nós?

Não. Uma atualização somente do plano de controle não altera os pools de nós. O gerenciamento automático do cluster funciona de forma diferente: ele não dá suporte a atualizações somente de plano de controle e atualiza o plano de controle e todos os pools de nós juntos.

Posso atualizar os pools de nós antes do plano de controle?

Não. A versão do plano de controle deve ser sempre igual ou superior a qualquer versão do pool de nós. Você deve atualizar o plano de controle primeiro.

Quanto tempo leva uma atualização do plano de controle?

A duração da atualização varia de acordo com o estado do cluster e Azure condições. Monitorar provisioningState usando az aks show ou Get-AzAksCluster. A atualização é concluída quando o estado de provisionamento é Succeeded.

Resolver problemas de atualização do plano de controle

Nenhuma atualização disponível

Para um cluster sem suporte, use az aks get-upgrades para verificar se o AKS oferece um destino qualificado com suporte. Se um destino estiver disponível, execute uma atualização de cluster completo. Não há suporte para atualizações somente de plano de controle para esse caminho de recuperação.

Se nenhum destino estiver disponível, o cluster poderá já estar na versão mais recente com suporte. Se o cluster estiver executando uma versão sem suporte, crie um novo cluster com uma versão com suporte e migre suas cargas de trabalho.

Falha na atualização devido a APIs preteridas

Antes de atualizar, verifique se há APIs preteridas usando ferramentas como kube-no-trouble (kubent):

kubent

O comando verifica os recursos acessíveis por meio do contexto kubeconfig atual para versões preteridas da API do Kubernetes. A saída agrupa as descobertas da versão do Kubernetes e identifica cada recurso afetado por KIND, NAMESPACEe NAMEAPI_VERSION. Atualize o manifesto de origem para cada recurso listado para usar uma versão de API com suporte antes de atualizar.

Conteúdo relacionado

• Configurar atualizações contínuas para pools de nós
• Configurar atualizações automáticas de cluster
• Configurar atualizações automáticas de imagem do sistema operacional do nó