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

A comunidade do Kubernetes libera 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]

Examples:
  1.29.2
  1.29.1

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 secundárias: adicione novos recursos, mantendo a compatibilidade com versões anteriores.
• 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. Por exemplo, se o seu cluster de produção estiver na versão 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 1.29.2 o mais rápido possível para garantir que seu cluster esteja totalmente corrigido e tenha suporte.

Calendário de versão do AKS Kubernetes

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.

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

Versões LTS

O LTS (suporte de longo prazo) precisa ser habilitado para obter suporte estendido. Você pode encontrar mais informações sobre Como habilitar o suporte a longo prazo.

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

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

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.33.0

Kubernetes 1.32

Kubernetes 1.31

Kubernetes 1.30

Kubernetes 1.29

Versão secundária do alias

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. Por exemplo, se você criar um cluster com 1.29 e 1.29.2 for o patch em GA mais recente disponível, seu cluster será criado com 1.29.2. 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. A propriedade currentKubernetesVersion 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 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:

O AKS dá suporte a três versões menores de GA.

• A última versão 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 de versões secundárias do Kubernetes com suporte no AKS é conhecida como "N-2", em que N se refere à versão mais recente, significando que as 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 atual de versões com suporte seja:

1.29
1.28
1.27

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

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. Você é sempre encorajado a usar o patch mais recente para uma versão menor.

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. Se você estiver executando uma versão n-2, no momento em que ela se tornar n-3, a versão também ficará sem suporte oficial, e você se submeterá às regras da política de suporte da plataforma.

O AKS depende das versões e dos patches do Kubernetes, que é um projeto de código aberto que dá suporte apenas para 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.

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

Versõeskubectl suportadas

Você pode usar uma versão do kubectl que seja uma versão secundária mais antiga ou mais recente que a versão do kube-apiserver, Política de suporte do Kubernetes para kubectl.

Por exemplo, se o seu Kube-apiserver estiver na versão 1.28, você poderá usar as versões 1.27 a 1.29 do kubectl com o Kube-apiserver em questão.

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

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

Você pode consultar lançamentos de versões e descontinuações futuras no Calendário de lançamento do AKS Kubernetes.

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 se você não tiver 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 descobrir quem são seus administradores de assinatura ou alterá-la, consulte gerenciar assinaturas do Azure.

• Você tem 30 dias desde a remoção da versão até a atualização para uma versão secundária com suporte 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 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 30 dias após a remoção de uma versão de patch do AKS para fazer a atualização para um patch compatível e continuar recebendo suporte. No entanto, não será mais possível criar clusters ou pools de nós depois que a versão for preterida/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 com o portal do Azure, a CLI do Azure, o Azure PowerShell, o cluster usará como padrão a versão secundária N-1 e o patch mais recente. Por exemplo, se o AKS der suporte às versões 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á a 1.28.7.

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

Get-AzAksVersion -Location eastus

perguntas frequentes

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.

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 você estiver na versão n-3 ou mais antiga, isso significa que você está fora do suporte e precisa atualizar. Se a atualização da versão n-3 para n-2 for bem-sucedida, você estará de volta em nossas políticas de suporte. Por exemplo:

• Se a versão mais antiga do AKS com suporte for 1.27 e você estiver na versão 1.26 ou anterior, estará fora do suporte.
• Se você atualizar com êxito de 1.26 para 1.27 ou superior, retornará às nossas políticas de suporte.

Não há suporte para fazer downgrade.

O que significa "fora de suporte"?

'Fora do suporte' significa que:

• A versão que você está executando está fora da lista de versões compatíveis.
• Você precisará atualizar o cluster para uma versão compatível ao solicitar o suporte, a menos que esteja dentro do período de cortesia de 30 dias após a versão ter sido preterida.

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

O que acontece quando 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.

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

Se um cluster não tiver suporte para mais de três versões secundárias e apresentar riscos de segurança, o Azure contatará você proativamente. Eles aconselham você a atualizar seu cluster. Se você não executar outras ações, o Azure reservará o direito de atualizar automaticamente o cluster em seu nome.

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 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 pools de nós, visite a documentação sobre Atualizar pools de nós.

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

A política de distorção 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 a atualização do cluster?

Se você atualizar um cluster AKS com suporte, as versões secundárias do Kubernetes não poderão ser ignoradas. A política de distorção de versão dos painéis de controle do Kubernetes não dá suporte a ignorar a versão secundária. Por exemplo, as atualizações entre:

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

Para atualizações de versão do painel de controle, você pode acessar até três versões secundárias para versões com suporte da comunidade de forma sequencial.

Para fazer a atualização das versões 1.27.x a >1.29.x:

1. Atualização das versões 1.27.x a >1.28.x.
2. Atualização das versões 1.28.x a >1.29.x.

Observe que, a partir da versão 1.28 em diante, as versões do agentpool podem ser até três versões mais antigas em relação às versões do control plane, conforme a política de desvio de versão. Se sua versão estiver muito atrás da versão mínima com suporte, talvez seja necessário fazer mais de uma operação de atualização do plano de controle para chegar à versão mínima com suporte. Por exemplo, se a versão atual do seu plano de controle for 1.23.x e você pretende atualizar para uma versão mínima suportada de 1.27.x por exemplo. Talvez seja necessário atualizar sequencialmente 4 vezes a partir 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. No exemplo anterior, você pode atualizar a versão do agentpool duas vezes, uma vez de 1.23.x para 1.25.x, quando a versão do painel de controle está em 1.25.x. E, em seguida, de 1.25.x a 1.27.x, quando a versão do painel de controle está em 1.27.x. Ao atualizar no local, como painel de controle e pool de agentes juntos, as mesmas regras aplicáveis à atualização do painel de controle se aplicam.

Se estiver executando uma atualização de uma versão sem suporte , a atualização será feita sem qualquer garantia de funcionalidade e será excluída dos contratos de nível de serviço e da garantia limitada. Os clusters que executam versão sem suporte têm a flexibilidade de desacoplar atualizações do plano de controle com atualizações do pool de nós. No entanto, se sua versão estiver desatualizada, recomendamos recriar 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 à Plataforma.

Estou usando uma versão preterida recentemente que não tem mais suporte na plataforma. Ainda posso adicionar novos pools de nós? Ou devo atualizar?

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

Próximas etapas

Para obter informações sobre como fazer upgrade do seu cluster, consulte:

• Atualizar um cluster do Serviço de Kubernetes do Azure (AKS)
• Upgrade de vários clusters do AKS por meio do Gerenciador de Frota de Kubernetes do Azure