Versões do Kubernetes com suporte no AKS (Serviço de Kubernetes do Azure)

A comunidade do Kubernetes lança versões secundárias aproximadamente a cada quatro meses.

As versões secundárias incluem novos recursos e aprimoramentos. As versões de patch são mais frequentes (às vezes, semanais) e são destinadas a correções de bugs críticas dentro de uma versão menor. As versões de patch incluem correções para vulnerabilidades de segurança ou bugs principais.

Versões do Kubernetes

O Kubernetes usa o esquema de controle de versão Controle de Versão Semântico padrão para cada versão:

[major].[minor].[patch]

Cada número na versão reflete a compatibilidade com versões anteriores:

• Versões principais: introduzir alterações incompatíveis da API ou interromper a compatibilidade com versões anteriores.
• Versões menores: Adicionam novos recursos. ApIs estáveis geralmente permanecem compatíveis, mas APIs e recursos preteridos podem ser removidos de acordo com a Política de Substituição do Kubernetes.
• Versões de patch: incluem correções de bugs que são compatíveis com as versões anteriores.

Sempre use a versão de correção mais recente para a sua versão menor atual. Quando um patch mais recente estiver disponível para sua versão secundária, atualize assim que possível para garantir que seu cluster esteja plenamente corrigido e com suporte.

Calendário de lançamento do Kubernetes do AKS e versões futuras

Verifique o lançamento de versões futuras no calendário de lançamento do Kubernetes do AKS. Para visualizar as atualizações em tempo real do status da versão da região e das notas sobre a versão, visite a página da Web status de versão do AKS. Para saber mais sobre a página da Web de status da versão, confira Rastreador de versão do AKS.

A coluna de atualização iniciada pela plataforma mostra o mês de distribuição planejado para clusters que ainda executam essa versão após o período de carência de suporte da plataforma de 60 dias. O mês listado é uma estimativa de planejamento, não uma data exata de atualização para um cluster. As atualizações podem ocorrer durante ou após o mês listado porque o AKS aplica limitação de taxa a elas por região, assinatura e versão. As versões incluídas na distribuição inicial compartilham junho de 2027 como mês de distribuição. Para obter mais informações, consulte atualizações iniciadas pela plataforma.

Para obter o histórico de lançamentos anteriores, consulte Histórico do Kubernetes.

Versões do LTS

Você precisa habilitar o LTS (suporte de longo prazo) para obter suporte estendido. Para obter mais informações, consulte Habilitar suporte a longo prazo.

Para clusters LTS, o mês de atualização iniciado pela plataforma vem após o período de carência de 60 dias após a data de fim de vida útil do LTS. O AKS atualiza esses clusters para a próxima versão LTS compatível. O registro no LTS nunca é automático. O mês listado é uma estimativa de planejamento, não uma data exata de atualização para um cluster.

Gráfico de Gantt do cronograma de versões do AKS Kubernetes

O gráfico de Gantt a seguir exibe as versões atuais:

Alterações interruptivas dos componentes do AKS por versão

Observe as seguintes alterações importantes antes de atualizar para qualquer uma das versões secundárias disponíveis:

Kubernetes 1.37

Kubernetes 1.36

Kubernetes 1.35

Kubernetes 1.34

Kubernetes 1.33

Kubernetes 1.32

Kubernetes 1.31

Kubernetes 1.30

Versão secundária do alias no AKS

Você pode criar um cluster do AKS sem especificar uma versão de patch. Quando você cria um cluster sem designar um patch, o cluster executa o patch GA mais recente da versão menor. Se quiser atualizar a versão do patch na mesma versão secundária, use a atualização automática.

Para visualizar em qual patch você está, execute o comando az aks show --resource-group myResourceGroup --name myAKSCluster. Na saída, a currentKubernetesVersion propriedade mostra toda a versão do Kubernetes. Por exemplo:

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.eastus.azmk8s.io",
  "currentKubernetesVersion": "<major>.<minor>.<patch>",
}

Política de suporte de versão do Kubernetes

O AKS define uma versão em disponibilidade geral (GA) como uma versão disponível em todas as regiões e habilitada em todas as medições de SLO ou SLA. O AKS é compatível com três versões secundárias GA do Kubernetes:

• A versão mais recente de GA (N).
• As duas versões secundárias anteriores (N-1 e N-2).
  • Cada versão menor com suporte pode suportar qualquer número de patches ao mesmo tempo. O AKS se reserva o direito de preterir patches se uma CVE ou vulnerabilidade críticas forem detectadas. Para saber mais sobre a disponibilidade de patch e qualquer substituição ad hoc, consulte as notas de versão da versão e visite a página da Web de status de versão do AKS.

O AKS também pode dar suporte a versões prévias, que estão explicitamente rotuladas e sujeitas aos termos e às condições da versão prévia.

O AKS fornece suporte de plataforma somente para uma versão secundária em GA do Kubernetes após as versões regulares com suporte. A janela de suporte da plataforma das versões do Kubernetes no AKS é conhecida como N-3. Para obter mais informações, consulte a política de suporte da plataforma.

A janela com suporte de versões secundárias do Kubernetes no AKS é conhecida como N-2, em que N se refere à versão mais recente, o que significa que duas versões secundárias anteriores também têm suporte.

Por exemplo, no dia em que o AKS apresenta a versão 1.29, o suporte é fornecido para as seguintes versões:

Quando uma nova versão secundária é introduzida, a versão secundária mais antiga é preterida e removida. Por exemplo, digamos que a lista de versões secundárias com suporte atual seja 1.29, 1.28 e 1.27. Quando o AKS lançar a versão 1.30, todas as versões 1.27 ficam sem suporte 30 dias depois e entram no suporte à plataforma.

O AKS pode dar suporte a qualquer número de patches com base na disponibilidade de versões upstream da comunidade para uma determinada versão secundária. O AKS se reserva o direito de preterir quaisquer patches a qualquer momento devido a uma CVE ou a uma possível preocupação com bugs. Recomendamos que você use o patch mais recente para uma versão secundária.

A política de suporte da plataforma

A política de suporte à plataforma é um plano de suporte reduzido para determinadas versões do Kubernetes sem suporte. Durante o suporte à plataforma, os clientes só recebem suporte da Microsoft para problemas relacionados à plataforma AKS/Azure. Não há suporte para qualquer problema relacionado à funcionalidade e aos componentes do Kubernetes.

A política de suporte da plataforma se aplica a clusters em uma versão N-3 (em que N é a última versão secundária em GA do AKS com suporte), antes que o cluster caia para N-4. Por exemplo, o Kubernetes v1.26 é considerado suporte à plataforma quando a v1.29 é a versão GA mais recente. Digamos que você esteja executando uma versão N-2 . No momento em que a versão se torna N-3, ela também encerra seu suporte oficial e você entra na política de suporte da plataforma.

O suporte à plataforma oferece um período de carência de 60 dias para atualizar em seus próprios termos. Quando o período de carência termina, o AKS atualiza automaticamente o cluster para uma versão com suporte. Para obter mais informações, consulte atualizações iniciadas pela plataforma.

O AKS depende das versões e patches do Kubernetes, que é um projeto de software livre que dá suporte apenas a uma janela deslizante de três versões secundárias. O AKS só pode garantir suporte total enquanto essas versões estão sendo atendidas em upstream. Como não há mais patches sendo produzidos em upstream, o AKS pode deixar essas versões sem patch ou bifurcá-las. Devido a essa limitação, o suporte à plataforma não dá suporte a nada que dependa do upstream do Kubernetes.

A tabela a seguir descreve as diretrizes de suporte para o suporte da comunidade em comparação com o suporte à plataforma:

Atualizações iniciadas pela plataforma

O AKS atualiza clusters que permanecem em uma versão sem suporte do Kubernetes após o término do período de carência de suporte da plataforma. Essa política garante que nenhum cluster permaneça indefinidamente em uma versão que não recebe mais patches de segurança.

O AKS atualiza o cluster para a versão mais baixa com suporte em sua camada de suporte atual: os clusters de suporte da comunidade passam para a versão secundária da comunidade com suporte mais baixa e os clusters LTS passam para a versão LTS aplicável. O AKS não inscreve clusters no LTS e não altera sua camada de cobrança.

Ao contrário de uma atualização manual, uma atualização automática de cluster ou uma execução de atualização do Fleet Manager, uma atualização iniciada pela plataforma não segue a janela de manutenção e não executa a verificação de API preterida. Manter seu cluster em uma versão com suporte é a única maneira de evitar uma atualização iniciada pela plataforma.

Para obter a política completa, incluindo como você é notificado e como se preparar, consulte atualizações iniciadas pela plataforma.

Versõeskubectl suportadas

Você pode usar uma versão kubectl que seja uma versão secundária mais antiga ou mais recente que a versão do kube-apiserver. Para obter mais informações, consulte a política de suporte do Kubernetes para kubectl.

Por exemplo, se o kube-apiserver estiver na versão 1.28, você poderá usar as versões 1.27 a 1.29 de kubectl.

Para instalar ou atualizar kubectl para a versão mais recente, use o comando com base em sua ferramenta preferida:

az aks install-cli

Install-AzAksKubectl -Version latest

LTS (suporte de longo prazo)

O AKS oferece um ano de Suporte à Comunidade e um ano de Suporte de Longo Prazo (LTS), incluindo correções de segurança retroportadas da comunidade upstream. Nosso grupo de trabalho upstream LTS contribui com esforços para a comunidade para fornecer aos nossos clientes uma janela de suporte mais longa.

Para obter mais informações sobre LTS, consulte suporte de longo prazo para o AKS (Serviço de Kubernetes do Azure).

Processo de liberação e de desativação

Para os próximos lançamentos de versão e descontinuações, consulte o calendário de versões do Kubernetes do AKS.

Para novas versões secundárias do Kubernetes:

• O AKS anuncia as datas de lançamento da nova versão e a substituição de versão antiga nas notas de versão do AKS pelo menos 30 dias antes da remoção.

• O AKS usa o Assistente do Azure para alertar você se uma nova versão pode causar problemas no cluster devido a APIs preteridas. O Assistente do Azure também alerta você caso esteja sem suporte.

• O AKS publica uma notificação de integridade do serviço disponível para todos os usuários com acesso ao portal e do AKS e envia um email para os administradores de assinatura com as datas de remoção da versão planejada.

  Note

  Para exibir ou alterar seus administradores de assinatura, consulte gerenciar assinaturas do Azure.

• Você tem um período de carência de suporte de plataforma de 60 dias após a data de fim de vida publicada para atualizar para uma versão secundária com suporte. A remoção de versão regional pode ocorrer em um momento diferente da data de publicação. Se o cluster permanecer em uma versão sem suporte após o período de carência, o AKS o atualizará automaticamente. Para obter mais informações, consulte atualizações iniciadas pela plataforma.

Para novas versões de patch do Kubernetes:

• Devido à natureza urgente das versões de patch, elas podem ser introduzidas no serviço no Azure à medida que se tornam disponíveis. Depois de disponíveis, os patches têm um ciclo de vida mínimo de dois meses.
• Em geral, o AKS não comunica de maneira ampla o lançamento das novas versões de patch. No entanto, o AKS monitora e valida constantemente os patches de CVE disponíveis para dar suporte a eles em AKS em tempo hábil. Se for encontrado um patch crítico ou se for necessária uma ação do usuário, o AKS o notificará para fazer upgrade para o patch recém-disponível.
• Você tem 60 dias após a remoção de uma versão de patch do AKS para atualizar para um patch com suporte e continuar recebendo suporte. No entanto, você não poderá mais criar clusters ou pools de nós depois que a versão for descontinuada ou removida.

Exceções de política de versões com suporte

O AKS reserva o direito de adicionar ou remover versões novas/existentes com um ou mais bugs críticos que afetam a produção ou problemas de segurança sem aviso prévio.

As versões de patch específicas podem ser ignoradas ou ter a distribuição acelerada, dependendo da severidade do bug ou do problema de segurança.

Versões de CLI e portal do Azure

Se você implantar um cluster do AKS usando o portal do Azure, a CLI do Azure ou o Azure PowerShell, o cluster usa por padrão a versão secundária N-1 e o patch mais recente.

Para descobrir quais versões estão disponíveis no momento para sua assinatura e região, use o comando com base em sua ferramenta preferida:

# The following example lists the available Kubernetes versions for the EastUS region:

az aks get-versions --location eastus --output table

# The following example lists the available Kubernetes versions for the EastUS region:

Get-AzAksVersion -Location eastus

Perguntas frequentes (FAQ)

Como a Microsoft me notificará sobre as novas versões do Kubernetes?

A equipe do AKS anuncia novas datas de lançamento da versão do Kubernetes em nossa documentação, no GitHub e por email para administradores de assinatura com clusters próximos ao fim do suporte. O AKS também usa o Assistente do Azure para alertá-lo no portal do Azure se você estiver sem suporte e informá-lo sobre APIs obsoletas que podem afetar seu aplicativo ou processo de desenvolvimento.

Um cluster que executa uma versão sem suporte também apresenta o status Degradado no Azure Resource Health e mostra um banner no recurso de cluster no portal do Azure, informando quando o AKS atualizará o cluster. Para obter mais informações, consulte atualizações iniciadas pela plataforma.

Com que frequência devo esperar para atualizar as versões do kubernetes para manter o suporte?

A partir do Kubernetes 1.19, a comunidade de código aberto expandiu o suporte para um ano. O AKS confirma a habilitação de patches e o suporte correspondentes aos compromissos upstream. Para os clusters do AKS da versão 1.19 e superior, você pode atualizar, no mínimo, uma vez por ano para permanecer em uma versão compatível.

O que acontece quando você atualiza um cluster do Kubernetes com uma versão secundária sem suporte?

Se sua versão ficar sem suporte de acordo com a lista de versões do Kubernetes com suporte, você precisará atualizar. Você pode atualizar de versões sem suporte para versões com suporte. Por exemplo:

• Se a versão secundária do AKS com suporte mais baixa for a 1.33 e você estiver na versão 1.32 ou mais antiga, você estará fora do suporte.
• Se você atualizar com sucesso da versão 1.32 para a versão 1.33 ou superior, estará novamente em conformidade com as políticas de suporte.

Não há suporte para downgrades ou reversão para uma versão sem suporte. Quanto mais antiga for a versão do cluster compatível, maior será o número de APIs removidas e complementos autogerenciados incompatíveis; talvez seja necessário resolver antes de atualizar.

Se você não atualizar, o AKS atualizará o cluster para você quando o período de carência de suporte da plataforma terminar. O AKS move o cluster uma versão secundária de cada vez até atingir uma versão compatível. Para obter mais informações, consulte atualizações iniciadas pela plataforma.

O que significa estar "fora do suporte"?

"Fora do suporte" significa:

• A versão que você está executando está fora da lista de versões compatíveis.
• Você será solicitado a atualizar o cluster para uma versão com suporte ao solicitar suporte, a menos que esteja dentro do período de carência de suporte da plataforma de 60 dias após a descontinuação da versão.

Além disso, o AKS não oferece garantias de funcionamento nem outras garantias para clusters fora da lista de versões suportadas.

Você pode permanecer em uma versão do Kubernetes para sempre?

No. Um cluster que permanece em uma versão sem suporte não recebe mais patches de segurança, portanto, o AKS o atualiza automaticamente quando o período de carência de suporte da plataforma de 60 dias termina. Azure também notifica você por Azure Resource Health, Assistente do Azure e email antes da execução da atualização.

Você mantém o controle ao manter o cluster em uma versão secundária da comunidade com suporte ou em uma versão LTS (suporte de longo prazo) à qual você adere explicitamente. Não é possível cancelar a participação. Para saber mais, confira Atualizações iniciadas pela plataforma.

O que acontece se você escala um cluster do Kubernetes com uma versão secundária sem suporte?

Para as versões secundárias sem suporte do AKS, a redução ou a escala horizontal deve continuar funcionando. Como não há garantias de qualidade de serviço, recomendamos a atualização para colocar seu cluster de volta ao suporte.

Qual versão é compatível com o plano de controle se o pool de nós não estiver em uma das versões de AKS compatíveis?

O plano de controle e todos os pools de nós devem permanecer dentro da janela de defasagem de versão com suporte. A partir do Kubernetes 1.28, o plano de controle pode estar até três versões menores à frente em relação aos pools de nós. Para obter detalhes, consulte as regras de atualização de versão do Kubernetes.

Qual é a diferença máxima permitida nas versões entre o plano de controle e os conjuntos de nós?

A política de desvio de versão agora permite uma diferença de até três versões entre o plano de controle e os pools de agentes. O AKS segue essa alteração de política de versão distorcida a partir da versão 1.28 em diante.

Posso ignorar várias versões do AKS durante uma atualização de cluster?

Sim, você pode ignorar versões secundárias em alguns casos. No entanto, se você atualizar o plano de controle independentemente dos pools de nós, deverá satisfazer as políticas de distorção de versão do Kubernetes. Atualmente, a política de distorção de versão do Kubernetes dá suporte apenas a N-3, portanto, o plano de controle e os pools de agentes devem estar dentro de N-3 uns dos outros.

• LTS: uma versão com o plano de Suporte de Longo Prazo do AKS habilitado. Consulte as versões do LTS.
• LTS sem suporte: uma versão com LTS habilitado que já passou da data de fim da vida útil do LTS na tabela de versões LTS.
• Versão não-LTS com suporte: Uma versão que não é LTS, mas ainda consta como suportada no calendário de lançamentos do Kubernetes no AKS.
• Versão não LTS sem suporte: Uma versão que não é LTS e não consta mais como suportada no calendário de lançamentos do Kubernetes no AKS.

Exemplos:

• Se o cluster estiver no 1.29 LTS e você quiser migrar para 1.32 LTS, você poderá ignorar várias versões secundárias, desde que o 1.32 LTS ainda seja oferecido pelo AKS e a atualização satisfaça as verificações de distorção e validação de versão.
• Se o cluster estiver na versão 1.28 não LTS, você poderá migrar para o AKS LTS 1.30 LTS usando o caminho de recuperação sem suporte, contanto que a versão de destino seja listada pelo AKS, satisfaça as verificações de validação e execute uma atualização completa do cluster em vez de control-plane-only.
• Se o seu cluster estiver na versão não LTS 1.33, com suporte, e você quiser migrar para a versão não LTS 1.35, com suporte, não será possível pular diretamente da versão 1.33 para 1.35. Você deve atualizar uma versão secundária de cada vez, como 1.33 para 1.34 e, em seguida, 1.34 para 1.35.

Na tabela anterior, indica que o caminho de atualização é executado de uma maneira que não pode ser garantida como segura e, Unsupported recovery path portanto, é considerada fora do suporte. O AKS permite que a atualização prossiga, mas não tem suporte e pode trazer riscos.

Para escolher o caminho correto, verifique os destinos disponíveis executando az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>. Examine a tabela anterior e considere o risco de atualizar versus recriar o cluster e migrar cargas de trabalho.

Posso criar um novo cluster 1.xx.x durante a janela de suporte da plataforma?

Não, a criação de novos clusters não é possível durante o período de suporte da plataforma.

Estou em uma versão descontinuada recentemente, que está fora do suporte da plataforma. Ainda posso adicionar novos pools de nodos ou devo atualizar?

Sim, você pode adicionar pools de agentes desde que eles sejam compatíveis com a versão do painel de controle.

Conteúdo relacionado

Para obter informações sobre atualizações de cluster do AKS, consulte:

• Atualizar um cluster do Serviço de Kubernetes do Azure (AKS)
• Atualizações iniciadas pela plataforma no AKS
• Upgrade de vários clusters do AKS por meio do Gerenciador de Frota de Kubernetes do Azure