Supported Kubernetes versions in Azure Kubernetes Service (AKS) (Versões do Kubernetes suportadas no Azure Kubernetes Service [AKS])

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

As versões secundárias incluem novos recursos e melhorias. Os lançamentos de patches são mais frequentes (às vezes semanalmente) e destinam-se a correções de bugs críticos dentro de uma versão secundária. As versões de patches incluem correções para vulnerabilidades de segurança ou bugs importantes.

Versões do Kubernetes

O Kubernetes usa o esquema de versionamento semântico padrão para cada versão:

[major].[minor].[patch]

Examples:
  1.29.2
  1.29.1

Cada número na versão indica compatibilidade geral com a versão anterior:

• As versões principais mudam quando atualizações de API incompatíveis ou compatibilidade com versões anteriores podem ser interrompidas.
• As versões secundárias mudam quando são feitas atualizações de funcionalidade que são compatíveis com versões anteriores das outras versões secundárias.
• As versões de patch mudam quando correções de bugs compatíveis com versões anteriores são feitas.

Procure executar a versão de patch mais recente da versão secundária que você está executando. Por exemplo, se o cluster de produção estiver ativado 1.29.1 e 1.29.2 for a versão de patch mais recente disponível para a versão secundária 1.29 , você deverá atualizar para o 1.29.2 mais rápido possível para garantir que o cluster seja totalmente corrigido e suportado.

Calendário de lançamento do AKS Kubernetes

Veja os próximos lançamentos de versões no calendário de lançamentos do AKS Kubernetes. Para ver atualizações em tempo real do status de liberação da região e das notas de versão da versão, visite a página de status da versão do AKS. Para saber mais sobre a página de status da versão, consulte AKS release tracker.

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

Versões LTS

AKS Kubernetes cronograma de lançamento Gráfico de Gantt

Se você preferir ver essas informações visualmente, aqui está um gráfico de Gantt com todas as versões atuais exibidas:

Componentes AKS quebrando alterações por versão

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

Kubernetes 1,30

Kubernetes 1,29

Kubernetes 1,28

Kubernetes 1,27

Alias versão secundária

O AKS permite que você crie um cluster sem especificar a versão exata do patch. Quando você cria um cluster sem designar um patch, o cluster executa o patch GA mais recente da versão secundária. Por exemplo, se você criar um cluster com 1.29 e 1.29.2 for o patch GA'd mais recente disponível, seu cluster será criado com 1.29.2. Se você quiser atualizar sua versão do patch na mesma versão secundária, use a atualização automática.

Para ver em que patch você está, execute o az aks show --resource-group myResourceGroup --name myAKSCluster comando. A currentKubernetesVersion propriedade mostra toda a versão do Kubernetes.

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.eastus.azmk8s.io",
  "currentKubernetesVersion": "1.29.2",
}

Política de suporte da versão do Kubernetes

O AKS define uma versão geralmente disponível (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 suporta três versões secundárias GA do Kubernetes:

• A última versão secundária do GA lançada em AKS (que chamamos de N).
• Duas versões secundárias anteriores.
  • Cada versão secundária suportada pode suportar qualquer número de patches em um determinado momento. A AKS reserva-se o direito de substituir patches se for detetada uma vulnerabilidade crítica de CVE ou de segurança. Para saber mais sobre a disponibilidade de patches e qualquer substituição ad-hoc, consulte as notas de versão da versão e visite a página de status da versão do AKS.

O AKS também pode suportar versões de visualização, que são explicitamente rotuladas e sujeitas aos termos e condições de visualização.

O AKS fornece suporte de plataforma apenas para uma versão secundária GA do Kubernetes após as versões regulares suportadas. 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 suportada das versões secundárias do Kubernetes no AKS é conhecida como "N-2", onde N se refere à versão mais recente, o que significa que duas versões secundárias anteriores também são suportadas.

Por exemplo, no dia em que o AKS introduz a versão 1.29, é fornecido suporte 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 atual de versões secundárias suportadas seja:

1.29
1.28
1.27

Quando o AKS lança a versão 1.30, todas as versões 1.27 saem do suporte 30 dias depois.

O AKS pode suportar qualquer número de patches com base na disponibilidade de lançamento da comunidade upstream para uma determinada versão secundária. A AKS reserva-se o direito de depreciar qualquer um desses patches a qualquer momento devido a um CVE ou potencial problema de bug. Você é sempre encorajado a usar o patch mais recente para uma versão secundária.

Política de suporte da plataforma

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

A política de suporte da plataforma aplica-se a clusters em uma versão n-3 (onde n é a versão secundária AKS GA suportada mais recente), antes que o cluster caia para n-4. Por exemplo, o Kubernetes v1.26 é considerado suporte de plataforma quando a v1.29 é a versão mais recente do GA. No entanto, durante a versão v1.30 GA, a v1.26 será então atualizada automaticamente para a v1.27. Se você estiver executando uma versão n-2, no momento em que ela se torna n-3, ela também se torna obsoleta e você entra na política de suporte da plataforma.

O AKS conta com os lançamentos e patches do Kubernetes, que é um projeto Open Source que suporta apenas 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 a montante. Como não há mais patches sendo produzidos a montante, o AKS pode deixar essas versões sem patches ou bifurcação. Devido a essa limitação, o suporte à plataforma não suporta nada de depender do Kubernetes upstream.

Esta tabela descreve as diretrizes de suporte para o Suporte da Comunidade em comparação com o suporte da Plataforma.

Versões suportadas kubectl

Você pode usar uma versão secundária mais antiga ou mais recente em relação à sua versão kube-apiserver, consistente com a política de kubectl suporte do Kubernetes para kubectl.

Por exemplo, se o seu kube-apiserver estiver em 1.28, então você pode usar as versões 1.27 a 1.29 do kubectl com esse kube-apiserver.

Para instalar ou atualizar kubectl para a versão mais recente, execute:

az aks install-cli

Install-AzAksKubectl -Version latest

Suporte de Longo Prazo (LTS)

O AKS fornece um ano de Suporte à Comunidade e um ano de Suporte de Longo Prazo (LTS) para fazer backup de correções de segurança de porta da comunidade upstream em nosso repositório público. Nosso grupo de trabalho LTS upstream contribui com esforços de volta para a comunidade para fornecer aos nossos clientes uma janela de suporte mais longa.

Para obter mais detalhes sobre LTS, consulte Suporte de longo prazo para o Serviço Kubernetes do Azure (AKS).

Processo de liberação e depreciação

Você pode fazer referência aos próximos lançamentos e descontinuações de versões no calendário de lançamentos do AKS Kubernetes.

Para novas versões secundárias do Kubernetes:

• O AKS publica um anúncio com a data planejada de lançamento de uma nova versão e respetiva descontinuação da versão antiga nas notas de versão do AKS pelo menos 30 dias antes da remoção.
• O AKS usa o Azure Advisor para alertá-lo se uma nova versão pode causar problemas em seu cluster devido a APIs obsoletas. O Azure Advisor também alerta você se você estiver sem suporte
• O AKS publica uma notificação de integridade do serviço disponível para todos os usuários com acesso ao AKS e ao portal e envia um e-mail para os administradores de assinatura com as datas de remoção da versão planejadas.

  Nota

  Para descobrir quem são seus administradores de assinatura ou alterá-lo, consulte gerenciar assinaturas do Azure.

• Você tem 30 dias a partir da remoção da versão para atualizar para uma versão secundária suportada para continuar recebendo suporte.

Para novas versões de patch do Kubernetes:

• Devido à natureza urgente das versões de patch, elas podem ser introduzidas no serviço à medida que ficam disponíveis. Uma vez disponíveis, os adesivos têm um ciclo de vida mínimo de dois meses.
• Em geral, o AKS não comunica amplamente o lançamento de novas versões de patches. No entanto, o AKS monitora e valida constantemente os patches CVE disponíveis para apoiá-los no AKS em tempo hábil. Se um patch crítico for encontrado ou uma ação do usuário for necessária, o AKS notificará você para atualizar para o patch recém-disponível.
• Você tem 30 dias a partir da remoção de uma versão de patch do AKS para atualizar para um patch suportado e continuar recebendo suporte. No entanto, você não poderá mais criar clusters ou pools de nós quando a versão for preterida/removida.

Exceções à política de versões suportadas

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

Lançamentos de patches específicos podem ser ignorados ou a implantação acelerada, dependendo da gravidade do bug ou do problema de segurança.

Portal do Azure e versões da CLI

Quando você implanta um cluster AKS com o portal do Azure, CLI do Azure, Azure PowerShell, o cluster assume como padrão a versão secundária N-1 e o patch mais recente. Por exemplo, se o AKS suportar 1.29.2, 1.29.1, 1.28.7, 1.28.6, 1.27.11 e 1.27.10, a versão padrão selecionada será 1.28.7.

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

Get-AzAksVersion -Location eastus

FAQ

Como a Microsoft me notifica sobre novas versões do Kubernetes?

A equipe do AKS publica anúncios com datas planejadas das novas versões do Kubernetes em nossa documentação, GitHub, e em e-mails para administradores de assinatura que possuem clusters que ficarão sem suporte. O AKS também usa o Azure Advisor para alertá-lo dentro do portal do Azure se você estiver sem suporte e informá-lo sobre APIs preteridas que podem afetar seu aplicativo ou processo de desenvolvimento.

Com que frequência devo esperar atualizar as versões do Kubernetes para permanecer no suporte?

Começando com o Kubernetes 1.19, a comunidade de código aberto expandiu o suporte para um ano. A AKS compromete-se a permitir patches e suporte que correspondam aos compromissos upstream. Para clusters AKS na versão 1.19 ou superior, você pode atualizar no mínimo uma vez por ano para permanecer em uma versão suportada.

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

Se você estiver na versão n-3 ou mais antiga, isso significa que você está fora do suporte e será solicitado a atualizar. Quando a sua atualização da versão n-3 para n-2 for bem-sucedida, você estará de volta às nossas políticas de suporte. Por exemplo:

• Se a versão secundária mais antiga suportada do AKS for 1.27 e você estiver na 1.26 ou mais antiga, você está fora do suporte.
• Quando você atualiza com êxito da versão 1.26 para a 1.27 ou superior, você está de volta às nossas políticas de suporte.

Não há suporte para downgrades.

O que significa "Fora do Suporte"?

«Fora do Apoio» significa que:

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

Além disso, o AKS não faz nenhum tempo de execução ou outras garantias para clusters fora da lista de versões suportadas.

O que acontece quando você dimensiona um cluster do Kubernetes com uma versão secundária que não é suportada?

Para versões secundárias não suportadas pelo AKS, a expansão para dentro ou para fora deve continuar a funcionar. Como não há garantias com a qualidade do serviço, recomendamos atualizar para trazer seu cluster de volta ao suporte.

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

Se um cluster tiver estado sem suporte durante mais de três (3) versões secundárias e tiver sido detetado que comporta riscos de segurança, o Azure contacta-o proativamente para atualizar o cluster. Se você não tomar mais medidas, o Azure reserva-se o direito de atualizar automaticamente seu cluster em seu nome.

O que acontece se você dimensionar um cluster do Kubernetes com uma versão secundária que não é suportada?

Para versões secundárias não suportadas pelo AKS, a expansão para dentro ou para fora deve continuar a funcionar. Como não há garantias com a qualidade do serviço, recomendamos atualizar para trazer seu cluster de volta ao suporte.

Qual versão o plano de controle suporta se o pool de nós não estiver em uma das versões AKS suportadas?

O plano de controle deve estar dentro de uma janela de versões de todos os pools de nós. Para obter detalhes sobre como atualizar o plano de controle ou os pools de nós, visite a documentação sobre como atualizar os pools de nós.

Qual é a diferença permitida nas versões entre o plano de controle e o pool de nós?

A política de distorção de versão agora permite uma diferença de até 3 versões entre o plano de controle e os pools de agentes. O AKS segue esta mudança de política de versão distorcida a partir da versão 1.28.

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

Quando atualiza um cluster do AKS suportado, as versões secundárias do Kubernetes não podem ser ignoradas. A política de distorção de versão dos planos de controle do Kubernetes não suporta pular versões secundárias. Por exemplo, upgrades entre:

• 1.28.x ->1.29.x: permitido.
• 1.27.x ->1.28.x: permitido.
• 1.27.x ->1.29.x: não permitido.

Observe que, para atualizações de versão do plano de controle, você pode ir até 3 versões secundárias para versões suportadas pela comunidade de forma sequencial.

Para atualizar de 1.27.x ->1.29.x:

1. Atualize de 1.27.x para> 1.28.x.
2. Atualize de 1.28.x para> 1.29.x.

Observação A partir da versão 1.28, as versões do agentpool podem ter até 3 versões mais antigas para controlar as versões do plano por política de distorção de versão. Quando sua versão está muito atrás da versão mínima suportada, você pode ter que fazer mais de uma operação de atualização do plano de controle para chegar à versão mínima suportada. Por exemplo, se a versão atual do plano de controle for 1.23.x e você pretende atualizar para uma versão mínima suportada de 1.27.x como exemplo. Você pode ter que atualizar sequencialmente 4 vezes de 1.23.x para chegar a 1.27.x. Observe também que as versões do pool de agentes podem ser atualizadas para a versão secundária do plano de controle. Isso significa que, no exemplo acima, você pode atualizar a versão do agentpool duas vezes, ou seja, uma vez de 1.23.x para 1.25.x, quando a versão do plano de controle estiver em 1.25.x. E posteriormente de 1.25.x para 1.27.x , quando a versão do plano de controle está em 1.27.x. Ao atualizar in-loco, ou seja, o plano de controle e o pool de agentes juntos, aplicam-se as mesmas regras aplicáveis à atualização do plano de controle descritas acima.

Ao executar uma atualização de uma versão não suportada - a atualização é realizada sem qualquer garantia de funcionalidade e é excluída dos contratos de nível de serviço e garantia limitada. Os clusters que executam versões sem suporte têm a flexibilidade de desacoplar atualizações de plano de controle com atualizações de pool de nós. No entanto, se a sua versão estiver significativamente desatualizada, recomendamos que recrie o cluster.

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 recém-preterida que está fora do suporte da plataforma, ainda posso adicionar novos pools de nós? Ou terei que atualizar?

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

Próximos passos

Para obter informações sobre como atualizar seu cluster, consulte:

• Atualizar um cluster do Azure Kubernetes Service (AKS)
• Atualizar vários clusters AKS através do Azure Kubernetes Fleet Manager