Suporte de longo prazo para versões do Serviço Kubernetes do Azure (AKS)

A comunidade Kubernetes lança uma nova versão secundária aproximadamente a cada quatro meses, com uma janela de suporte para cada versão por um ano. No Serviço Kubernetes do Azure (AKS), essa janela de suporte é chamada de suporte da comunidade.

O AKS suporta versões do Kubernetes que estão dentro desta janela de suporte da comunidade para enviar correções de bugs e atualizações de segurança de versões da comunidade. Embora a cadência de lançamento de suporte da comunidade forneça benefícios, ela exige que você se mantenha atualizado com as versões do Kubernetes, o que pode ser difícil dependendo das dependências do seu aplicativo e do ritmo de mudança no ecossistema do Kubernetes.

Para ajudá-lo a gerenciar suas atualizações de versão do Kubernetes, o AKS fornece uma opção de suporte de longo prazo (LTS), que estende a janela de suporte para uma versão do Kubernetes para lhe dar mais tempo para planejar e testar atualizações para versões mais recentes do Kubernetes.

Tipos de suporte AKS

Após aproximadamente um ano, uma determinada versão secundária do Kubernetes sai do suporte da comunidade, tornando as correções de bugs e atualizações de segurança indisponíveis para seus clusters AKS.

O AKS oferece um ano de suporte comunitário e um ano de suporte de longo prazo para correções de segurança de backport da comunidade upstream. O grupo de trabalho LTS a montante contribui para a comunidade, alargando a janela de apoio. O LTS fornece mais tempo para planejar e testar atualizações ao longo de dois anos a partir da disponibilidade geral (GA) da versão do Kubernetes.

Suporte da comunidade Suporte de longo prazo
Quando utilizar Quando conseguires acompanhar os releases principais do Kubernetes Quando você precisa de controle sobre quando migrar de uma versão para outra
Versões suportadas Três versões secundárias mais recentes do GA Todas as versões do Kubernetes suportadas a partir da versão 1.27 são elegíveis para Suporte Long-Term (LTS).

Processo de patch LTS

LTS suporta apenas as duas versões de patch mais recentes. Isso difere do suporte da Comunidade, onde todas as versões de patch são suportadas. No entanto, AKS reserva-se o direito de descontinuar qualquer versão de patch em resposta a vulnerabilidades críticas de segurança (CVEs). Para obter mais detalhes sobre a política de suporte da comunidade, consulte Política de suporte à versão do Kubernetes.

Para identificar as versões de patch suportadas mais recentes, consulte o rastreador de versão do AKS.

Recomendamos ativar o canal de patch de atualização automática para garantir que seus clusters permaneçam up-toatualizados com os patches mais recentes.

Habilite o suporte a longo prazo

Habilitar o LTS requer mover seu cluster para a camada Premium e selecionar explicitamente o plano de suporte LTS. Pode optar por participar a qualquer momento, incluindo enquanto o seu grupo ainda estiver em apoio comunitário.

A faturação LTS Premium para um cluster só começa depois de a versão menor Kubernetes do cluster sair do suporte comunitário e entrar na janela de suporte a longo prazo. Até lá, o cluster continua a ser faturado à sua taxa de nível atual.

Nota

Aderir cedo permite-lhe garantir o seu plano de suporte LTS e a configuração do canal de patch antes do fim da vida da comunidade, sem cobranças adicionais de LTS de nível Premium até ao início da janela de suporte LTS.

Nota

É altamente recomendável habilitar o canal de atualização automática do patch para garantir que seu cluster sempre receba os patches suportados mais recentes. LTS suporta apenas as duas últimas versões de patch para cada versão secundária. Clusters que não estão nas duas versões mais recentes suportadas podem perder suporte.

Exemplo de faturação

Considere um cluster AKS a correr Kubernetes 1.35, cuja janela de suporte à comunidade termina em março de 2027. Se optar por aderir ao LTS enquanto o cluster ainda está sob suporte da comunidade:

  1. Enquanto 1,35 continua em apoio comunitário (até março de 2027), o cluster continua a ser faturado à sua taxa de nível atual (por exemplo, Standard).
  2. Assim que a versão 1.35 sai do suporte comunitário e entra na janela LTS, o cluster transita automaticamente para a faturação LTS de nível Premium.

Habilitar LTS em um novo cluster

  • Crie um novo cluster com LTS habilitado usando o az aks create comando.

    O comando a seguir cria um novo cluster AKS com LTS habilitado usando o Kubernetes versão 1.27 como exemplo. Para revisar as versões disponíveis do Kubernetes, consulte o rastreador de versões do AKS.

    az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --tier premium \
    --k8s-support-plan AKSLongTermSupport \
    --kubernetes-version 1.27 \
    --auto-upgrade-channel patch \
    --generate-ssh-keys

Habilitar LTS em um cluster existente

  • Habilite o LTS em um cluster existente usando o az aks update comando.

    az aks update --resource-group <resource-group-name> --name <cluster-name> --tier premium --k8s-support-plan AKSLongTermSupport --auto-upgrade-channel patch

Sugestão

Para ver para quais versões do Kubernetes você pode atualizar, use o rastreador de versão do AKS ou execute az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>.

Migrar para a versão LTS mais recente

A comunidade Kubernetes upstream suporta uma trajetória de atualização de duas versões menores. O processo migra os objetos em seu cluster Kubernetes como parte do processo de atualização e fornece um caminho de migração testado e credenciado.

Se quiser realizar uma migração no local, o serviço AKS migra o seu plano de controlo da versão LTS anterior para a mais recente e depois migra o seu plano de dados. Para realizar uma atualização local para a versão LTS mais recente, é necessário especificar uma versão do Kubernetes com suporte para LTS como o destino da atualização.

  • Migre para a versão LTS mais recente usando o az aks upgrade comando.

    O comando a seguir usa o Kubernetes versão 1.32.2 como uma versão de exemplo. Para revisar as versões disponíveis do Kubernetes, consulte o rastreador de versões do AKS.

    az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version 1.32.2

    Nota

    No futuro, todas as versões do AKS Kubernetes serão compatíveis com LTS. Para obter o calendário LTS mais recente, visite o Calendário de Lançamento do Kubernetes AKS. Para visualizar as versões LTS disponíveis e seus patches por região, consulte o rastreador de versões do AKS.

Desabilitar o suporte de longo prazo em um cluster existente

A desativação do LTS em um cluster existente requer mover o cluster para a camada livre ou padrão e selecionar explicitamente o plano de suporte KubernetesOfficial.

Há aproximadamente dois anos entre uma versão LTS e a seguinte. Em vez do suporte upstream para migrar mais de duas versões secundárias, há uma alta probabilidade de seu aplicativo depender de APIs do Kubernetes que foram preteridas. Recomendamos que você teste completamente seu aplicativo na versão LTS Kubernetes de destino e realize uma implantação azul/verde de uma versão para outra.

  1. Desative o LTS em um cluster existente usando o az aks update comando. O seguinte comando de exemplo move o cluster para o tier gratuito e seleciona o plano de suporte KubernetesOfficer.

    az aks update --resource-group <resource-group-name> --name <cluster-name> --tier free --k8s-support-plan KubernetesOfficial

  2. Atualize o cluster para uma versão posterior com suporte usando o az aks upgrade comando.

    O comando a seguir usa o Kubernetes versão 1.28.3 como uma versão de exemplo. Para revisar as versões disponíveis do Kubernetes, consulte o rastreador de versões do AKS.

    az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version 1.28.3

Complementos e recursos não suportados

A equipe do AKS atualmente rastreia versões de complementos onde existe suporte à comunidade Kubernetes. Quando uma versão deixa o suporte da comunidade, contamos com projetos de código aberto para complementos gerenciados para continuar esse suporte. Devido a vários fatores externos, alguns complementos e recursos podem não suportar versões do Kubernetes fora dessas janelas de suporte da comunidade upstream.

A tabela a seguir fornece uma lista de complementos e recursos que não são suportados e os motivos pelos quais eles não são suportados:

Complemento / Recurso Razão pela qual não é suportado
Calico Requer um acordo do Calico Enterprise além do suporte da comunidade.
Serviço de Gestão de Chaves (KMS) O KMSv2 substitui o KMS durante este ciclo LTS.
Dapr As extensões AKS não são suportadas.
Controlador de Entrada do Gateway de Aplicação A migração para o App Gateway for Containers acontece durante o período LTS.
Open Service Mesh (Malha de Serviço Aberta) O OSM foi preterido.
Identidade do AAD Pod Substituído por Identidade do Trabalho.

Nota

Não é possível mover o cluster para suporte de longo prazo se algum desses complementos ou recursos estiver habilitado.

Embora esses complementos gerenciados pelo AKS não sejam suportados pela Microsoft, você pode instalar suas versões de código aberto em seu cluster se quiser usá-los após o suporte da comunidade.

Como decidimos a próxima versão LTS

As versões do Kubernetes LTS estão disponíveis por dois anos a partir do GA, e marcamos uma versão superior do Kubernetes como LTS com base nos seguintes critérios:

  • Esse tempo decorreu suficiente para que os clientes migrassem da versão LTS anterior para a versão LTS atual.
  • A versão anterior completou uma janela de suporte de dois anos.

Leia as notas de versão do AKS para se manter informado sobre quando você pode planejar sua migração.

Perguntas mais frequentes

Posso criar um novo cluster AKS com uma versão LTS após o fim do suporte da comunidade?

Sim, você pode criar um novo cluster AKS usando uma versão LTS mesmo após o término do período de suporte da comunidade, desde que tenha optado pelo LTS. No entanto, isso só é válido até o final do ciclo de vida da versão LTS. Depois disso, você deve atualizar para a próxima versão LTS suportada. Para obter mais detalhes, consulte o Calendário de Lançamento do Kubernetes do AKS.

Posso ativar e desativar o LTS em uma versão suportada pelo AKS após o término do suporte da comunidade?

Sim, você pode ativar o plano de suporte LTS em qualquer versão suportada pelo AKS, mesmo após o término do período de suporte da comunidade. No entanto, uma vez terminado o período de suporte da comunidade, não é possível desativar o LTS para essa versão.

Um cluster AKS suportado pela comunidade torna-se automaticamente elegível para LTS após o fim da vida útil?

Não. Tens de ativar explicitamente o LTS e mover o cluster para o nível Premium. A faturação LTS de nível premium aplica-se assim que a versão sai do suporte comunitário. Consulte os preços do escalão Premium para mais informações.

Todas as versões do AKS suportarão Long-Term Support (LTS)?

Sim, o AKS garante que todas as versões do Kubernetes suportadas sejam elegíveis para Suporte Long-Term (LTS). Você pode optar pelo LTS para qualquer versão suportada disponível hoje.

Qual é o modelo de preços para LTS?

O LTS é oferecido no nível Premium. A faturação LTS de nível premium para um cluster começa quando a sua versão menor Kubernetes sai do suporte comunitário e o cluster entra na janela de suporte LTS. Clusters que optam por LTS ainda dentro do suporte comunitário não são cobrados à tarifa LTS Premium durante o período de suporte comunitário. Para as tarifas atuais, consulte preços do nível Premium.

Quando começa a faturação LTS se eu optar por participar durante o suporte comunitário?

A faturação do nível Premium do LTS começa quando a versão secundária do Kubernetes do seu cluster é descontinuada do suporte comunitário. Se optar por aderir mais cedo, o seu cluster mantém a faturação por nível atual durante todo o período de suporte comunitário e transita automaticamente para a faturação LTS Premium quando o suporte da comunidade termina.

A habilitação do LTS interromperá as cargas de trabalho?

Não. É uma mudança apenas de configuração; não reconfigura nós nem interrompe cargas de trabalho, portanto, nenhum tempo de inatividade é esperado.

  • Last updated on