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 menores aproximadamente de quatro em 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]

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

• Versões principais: introduza alterações de API incompatíveis ou quebre a compatibilidade com versões anteriores.
• Versões menores: Adicionar novas funcionalidades. As APIs estáveis geralmente mantêm-se compatíveis, mas APIs e funcionalidades obsoletas podem ser removidas de acordo com a Política de Depreciação do Kubernetes.
• Versões de patch: Incluem correções de bugs compatíveis com versões anteriores.

Use sempre a versão de patch mais recente para a sua versão secundária atual. Quando um patch posterior estiver disponível para a sua versão menor, atualize o mais rápido possível para garantir que o cluster está totalmente atualizado e suportado.

Calendário de lançamentos do AKS Kubernetes e próximas versões

Verifique o calendário de lançamentos do AKS Kubernetes para os próximos lançamentos de versões. Para ver atualizações em tempo real do status de lançamento da região e das notas de versão, visite a página de status de lançamento 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

Precisas de ativar suporte a longo prazo (LTS) para obter apoio prolongado. Para mais informações, consulte Permitir apoio a longo prazo.

Cronograma de lançamentos do AKS Kubernetes gráfico de Gantt

O seguinte gráfico de Gantt mostra as versões atuais:

Alterações disruptivas 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.36

Kubernetes 1.35

Kubernetes 1.34

Kubernetes 1.33

Kubernetes 1,32

Kubernetes 1,31

Kubernetes 1,30

Versão menor de alias no AKS

Você pode criar um cluster AKS sem especificar uma versão de patch. Ao criar um cluster sem designar um patch, o cluster executa o patch GA mais recente da versão menor. Se deseja atualizar a sua versão do patch na mesma versão menor, use autoupgrade.

Para ver em que patch você está, execute o az aks show --resource-group myResourceGroup --name myAKSCluster comando. No resultado, 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 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 versão mais recente de GA (N).
• As duas versões menores anteriores (N-1 e N-2).
  • Cada versão secundária suportada pode suportar qualquer número de patches em um determinado momento. A AKS reserva-se o direito de descontinuar patches se for detetada uma vulnerabilidade de segurança ou CVE crítica. Para saber mais sobre a disponibilidade de patches e qualquer descontinuação ad-hoc, consulte as notas de versão e visite a página de status de lançamento 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 Kubernetes no AKS é conhecida como N-3. Para obter mais informações, consulte a política de suporte da plataforma.

A janela suportada para as versões menores do Kubernetes no AKS é conhecida como N-2, onde N se refere à versão mais recente, significando que duas versões menores 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 menores suportadas é a 1.29, 1.28 e 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 menor. A AKS reserva-se o direito de descontinuar qualquer um desses patches a qualquer momento devido a um CVE ou potencial problema de erro. Encorajamo-lo a usar o patch mais recente para uma versão menor.

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 à plataforma aplica-se a clusters numa versão N-3 (onde N é a versão menor mais recente suportada do AKS GA), antes de o cluster passar para N-4. Por exemplo, o Kubernetes v1.26 é considerado suporte de plataforma quando a v1.29 é a versão mais recente do GA. Digamos que estás a usar uma versão N-2 . No momento em que essa versão se torna N-3, também termina o seu suporte oficial, e entra na política de suporte da plataforma.

O AKS baseia-se nas versões e patches do Kubernetes, que é um projeto open-source que só suporta uma janela deslizante de três versões menores. 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 na origem, o AKS pode deixar essas versões sem correções ou criar uma derivação. Devido a essa limitação, o suporte à plataforma não oferece suporte para nada que dependa do Kubernetes upstream.

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

Versões suportadas kubectl

Podes usar uma kubectl versão que seja uma versão menor, mais antiga ou mais recente do que a tua versão kube-apiserver. Para mais informações, consulte a política de suporte Kubernetes para kubectl.

Por exemplo, se o seu kube-apiserver estiver em 1.28, então pode 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 baseado na sua ferramenta preferida:

az aks install-cli

Install-AzAksKubectl -Version latest

Suporte de Longo Prazo (LTS)

O AKS oferece um ano de suporte comunitário e um ano de suporte de longo prazo (LTS), incluindo correções de segurança retroportadas da comunidade upstream. O nosso grupo de trabalho LTS upstream contribui esforços para a comunidade para proporcionar aos nossos clientes um período de suporte mais longo.

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

Processo de lançamento e descontinuação

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

Para novas versões secundárias do Kubernetes:

• O AKS anuncia novas datas de lançamento da versão e a 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 Assistente do Azure para alertá-lo se uma nova versão pode causar problemas em seu cluster devido a APIs obsoletas. O Assistente do Azure também te alerta se ficares 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.

  Note

  Para visualizar ou alterar os administradores das suas subscrições, consulte gerir subscrições 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 correção 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, já não será possível criar clusters ou pools de nós assim que a versão for obsoleta/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.

Dependendo da gravidade da falha ou do problema de segurança, versões específicas de patches podem ser ignoradas ou a implementação acelerada.

Portal do Azure e versões da CLI

Se implementar um cluster AKS usando o portal Azure, CLI do Azure ou Azure PowerShell, o cluster passa a usar por defeito a versão menor N-1 e o patch mais recente.

Para saber que versões estão atualmente disponíveis para a sua subscrição e região, use o comando baseado na 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 mais frequentes (FAQ)

Como a Microsoft me notifica sobre 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 e-mail para administradores de assinatura com clusters próximos do fim do suporte. O AKS também usa o Assistente do Azure 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?

A partir do Kubernetes 1.19, a comunidade de código aberto expandiu o suporte para um ano. A AKS compromete-se a fornecer patches e suporte que estejam em conformidade com os 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 a tua versão deixar de suportar conforme a lista de versões Kubernetes suportadas, precisas de atualizar. Podes atualizar de versões não suportadas para versões suportadas. Por exemplo:

• Se a versão secundária suportada mais baixa do AKS for 1.33 e estiveres a usar a 1.32 ou uma versão anterior, estás fora de suporte.
• Se conseguires atualizar com sucesso da versão 1.32 para a 1.33 ou superior, estás de volta dentro das políticas de suporte.

Rebaixamentos ou retrocessos para uma versão não suportada não são suportados. Além disso, quanto mais longe a versão do cluster estiver da versão mais suportada, maior a probabilidade de problemas de atualização. Nesse caso, a criação de um novo cluster e a migração da carga de trabalho seriam uma abordagem melhor.

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

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

Se um cluster estiver sem suporte para mais de três versões secundárias e acarretar riscos de segurança, o Azure entrará em contato proativamente com você. Eles aconselham você a atualizar seu 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 dimensionar um cluster de Kubernetes com uma versão secundária que não é suportada?

Para versões secundárias não suportadas pelo AKS, o escalonamento 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 controlo e todos os pools de nós devem permanecer dentro da janela de desvio da versão suportada. A partir da versão 1.28 do Kubernetes, o plano de controlo pode estar até três versões secundárias à frente dos grupos de nós. Para mais detalhes, consulte as regras de atualização da versão Kubernetes.

Qual é a diferença permitida nas versões entre o plano de controlo e os agrupamentos de nós?

A política de desfasamento de versões agora permite um desfasamento de até três versões entre o plano de gestão 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 saltar várias versões do AKS durante uma atualização do cluster?

Sim, em alguns casos podes saltar versões menores. No entanto, se atualizares o plano de controlo independentemente dos pools de nós, deves cumprir as políticas de desvio da versão Kubernetes. A política de desvio da versão Kubernetes suporta atualmente apenas N-3, pelo que o plano de controlo e os pools de agentes devem estar dentro de N-3 um do outro.

• LTS: Uma versão com o plano de Suporte Long-Term AKS ativado. Ver versões LTS.
• LTS não suportado: Uma versão compatível com LTS que já ultrapassou a data de fim de vida útil do LTS na tabela de versões LTS .
• Versão não LTS suportada: Uma versão que não é LTS, mas que continua listada como suportada no calendário de versões do Kubernetes no AKS.
• Não suportado não LTS: Uma versão que não é LTS e que já não está listada como suportada no calendário de lançamentos do AKS Kubernetes.

Examples:

• Se o teu cluster estiver em 1.29 LTS e quiseres passar para 1.32 LTS, podes saltar várias versões menores desde que a 1.32 LTS ainda seja oferecida pelo AKS e a atualização satisfaça os testes de desfasamento e validação de versões.
• Se o seu cluster estiver em 1.28 não-LTS, pode migrar para o AKS LTS 1.30 LTS usando o caminho de recuperação não suportado, desde que a versão alvo esteja listada pelo AKS, satisfaça verificações de validação e execute uma atualização completa do cluster em vez de control-plane-only.
• Se o teu cluster estiver numa versão não suportada de LTS 1.33 e quiseres migrar para a não suportada LTS 1.35, não podes saltar diretamente da 1.33 para a 1.35. Tem de atualizar uma versão menor de cada vez, como 1.33 para 1.34, e depois 1.34 para 1.35.

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

Para escolher o caminho correto, verifique os alvos disponíveis executando az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>. Reveja a tabela anterior e depois 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 à plataforma.

Estou numa versão recentemente descontinuada que já não tem suporte de plataforma. Ainda posso adicionar novos conjuntos de nós ou devo fazer uma atualização?

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

Conteúdo relacionado

Para informações sobre atualizações do cluster AKS, veja:

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