Atualizar o plano de controlo do cluster do Azure Kubernetes Service (AKS)

Os clusters Azure Kubernetes Service (AKS) consistem em dois componentes principais: o plano de controlo gerido pelo Azure e os pools de nós onde as suas cargas de trabalho são executadas. Este artigo foca-se na atualização independente do plano de controlo, o que permite adotar novas versões do Kubernetes para funcionalidades do servidor API, gerindo separadamente as atualizações do pool de nós.

Antes de começar

• Se você estiver usando a CLI do Azure, este artigo exigirá a CLI do Azure versão 2.34.1 ou posterior. Use o az --version comando para localizar a versão. Se precisar de instalar ou atualizar, consulte Install CLI do Azure.
• Se você estiver usando o Azure PowerShell, este artigo requer o Azure PowerShell versão 5.9.0 ou posterior. Usa o Get-InstalledModule -Name Az cmdlet para encontrar a versão. Se você precisar instalar ou atualizar, consulte Instalar o Azure PowerShell.
• Para realizar operações de atualização, precisa do Azure Kubernetes Service Contributor Role ou permissões equivalentes.
• As APIs beta são desativadas por defeito quando atualizas para as versões 1.30 e 1.27 LTS do Kubernetes.

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

A tabela seguinte apresenta três tipos de atualizações do AKS, destacando o seu âmbito e casos de uso:

Regras de atualização da versão Kubernetes

Quando atualizas um cluster AKS suportado que não seja LTS, não podes saltar versões menores do Kubernetes. Você deve executar todas as atualizações sequencialmente por número de versão menor. Por exemplo, atualizações entre 1.28.x ->1.29.x ou 1.29.x ->1.30.x são permitidas. 1.28.x ->1.30.x não é permitido.

Um cluster LTS pode saltar versões menores ao passar para uma versão LTS superior oferecida pelo AKS, desde que a atualização satisfaça os requisitos de desajustamento de versão e verificações de validação. Para mais informações, veja Posso saltar várias versões do AKS durante uma atualização do cluster?.

A partir do Kubernetes 1.28, o plano de controlo pode estar até três versões menores à frente dos pools de nós. Por exemplo, se o teu plano de controlo estiver em 1.35.x, os teus pools de nós podem estar em 1.32.x, 1.33.x, 1.34.x ou 1.35.x. Para as restrições atuais, veja a política de envioiamento da versão AKS.

Verifique as atualizações disponíveis para o 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 }

Atualize apenas o plano de controlo 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 atualização do plano de controlo do AKS (FAQ)

Uma atualização só com plano de controlo também melhora os pools de nós?

Não. Uma atualização só para plano de controlo não altera os pools de nós. A atualização automática do cluster funciona de forma diferente: não suporta upgrades apenas do plano de controlo e melhora o plano de controlo e todos os pools de nós em conjunto.

Posso atualizar os agrupamentos de nós antes do plano de controlo?

Não. A versão do plano de controlo deve ser sempre igual ou maior do que qualquer versão do pool de nós. Tens de atualizar primeiro o plano de controlo.

Quanto tempo demora uma atualização de plano de controlo?

A duração da atualização varia consoante o estado do cluster e as condições do Azure. Monitorize provisioningState usando az aks show ou Get-AzAksCluster. A atualização está completa quando o estado de provisionamento é Succeeded.

Resolver problemas de atualização do plano de controlo

Não há upgrades disponíveis

Para um cluster não suportado, use az aks get-upgrades para verificar se o AKS oferece um alvo suportado elegível. Se houver um alvo disponível, realizar uma atualização completa do cluster. Atualizações apenas com plano de controlo não são suportadas para este caminho de recuperação.

Se não houver alvo disponível, o teu cluster pode já estar na versão mais recente suportada. Se o cluster estiver a correr uma versão não suportada, crie um novo cluster com uma versão suportada e migre as suas cargas de trabalho.

A atualização falhou devido a APIs obsoletas

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

kubent

O comando analisa recursos acessíveis através do contexto atual do kubeconfig para versões obsoletas da API Kubernetes. A saída agrupa as conclusões pela versão Kubernetes e identifica cada recurso afetado por KIND, NAMESPACE, NAME, e API_VERSION. Atualize o manifesto de origem de cada recurso listado para usar uma versão da API suportada antes de atualizar.

Conteúdo relacionado

• Configurar atualizações progressivas para pools de nós
• Configurar atualizações automáticas do cluster
• Configurar atualizações automáticas de imagens do sistema operativo dos nós