Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Importante
Atualizações iniciadas pela plataforma do AKS. A partir de 1º de junho de 2027, o AKS atualiza automaticamente qualquer cluster que permaneça em uma versão sem suporte do Kubernetes após o término do período de carência de suporte da plataforma de 60 dias. Uma atualização iniciada pela plataforma não segue a janela de manutenção, não para para o uso preterido da API e pode substituir um Pod Disruption Budget (PDB) que bloqueia um drain de nó, portanto, as cargas de trabalho podem ser interrompidas. Antes do mês do upgrade, substitua as APIs removidas da versão do Kubernetes de destino e atualize complementos autogerenciados incompatíveis. Mantenha seus clusters em uma versão do Kubernetes com suporte para evitar uma atualização iniciada pela plataforma. Para obter mais informações, consulte Preparar para atualizações iniciadas pela plataforma no AKS.
A comunidade do Kubernetes lança uma nova versão secundária aproximadamente a cada quatro meses e cada versão tem uma janela de suporte de um ano. No AKS (Serviço de Kubernetes do Azure), essa janela de suporte é chamada de suporte da comunidade.
Para versões do Kubernetes no suporte da comunidade, o AKS fornece correções de bugs e atualizações de segurança das versões da comunidade. Pode ser difícil manter-se atualizado com a cadência de versão do Kubernetes quando seus aplicativos têm dependências complexas.
O LTS (suporte a longo prazo) estende a janela de suporte para que você tenha mais tempo para planejar e testar atualizações para versões mais recentes do Kubernetes.
Tipos de suporte do AKS
Após aproximadamente um ano, uma determinada versão secundária do Kubernetes sai do suporte da comunidade, e correções de bugs e atualizações de segurança não estão disponíveis para seus clusters do AKS.
O AKS fornece um ano de suporte à comunidade, seguido por mais um ano de suporte a longo prazo. Juntos, o suporte da comunidade e os períodos de LTS fornecem aproximadamente 24 meses de suporte total da GA (disponibilidade geral) da versão do Kubernetes. Durante o ano lts, o AKS faz backports de correções de segurança da comunidade upstream. O grupo de trabalho LTS upstream contribui para a comunidade, estendendo a janela de suporte.
| Suporte da comunidade | Suporte de longo prazo | |
|---|---|---|
| Quando usar | Quando você pode acompanhar os lançamentos upstream do Kubernetes | Quando você precisa de controle sobre quando migrar de uma versão para outra |
| Versões com suporte | Três versões secundárias mais recentes em GA | Todas as versões do Kubernetes com suporte são qualificadas para LTS. Consulte o calendário de lançamento do AKS LTS. |
Processo de patch de suporte de longo prazo
O LTS dá suporte apenas às duas versões de patch mais recentes. O suporte à comunidade pode incluir qualquer número de patches atualmente oferecidos. No entanto, o AKS reserva-se o direito de preterir qualquer versão de patch em resposta a vulnerabilidades críticas de segurança (CVEs). Para obter mais informações sobre a política de suporte à comunidade, consulte a política de suporte à versão do Kubernetes.
Para identificar as versões de patch com suporte mais recentes, consulte o rastreador de versão do AKS.
Habilitar o suporte de longo prazo
Habilitar o LTS requer mover o cluster para a camada Premium e selecionar explicitamente o plano de suporte do LTS. Você pode optar por participar a qualquer momento, inclusive enquanto o cluster ainda estiver em suporte da comunidade.
O LTS está disponível no nível Premium. Para obter as taxas atuais, consulte os preços do AKS.
Observação
Habilite o canal de atualização automática de patch para manter o cluster nos patches mais recentes com suporte. O LTS dá suporte apenas às duas versões de patch mais recentes para cada versão secundária. Clusters que não executam uma dessas versões de patch podem perder o suporte.
Habilitar o LTS em um novo cluster
Crie um cluster com LTS habilitado usando o comando az aks create. O AKS usa a versão do Kubernetes com suporte padrão e o patch mais recente disponível na região.
az aks create \
--resource-group <resource-group-name> \
--name <cluster-name> \
--tier premium \
--k8s-support-plan AKSLongTermSupport \
--auto-upgrade-channel patch \
--generate-ssh-keys
O comando usa os seguintes valores de parâmetro específicos do LTS:
-
--tier premiumdefine a camada de gerenciamento de cluster como Premium, o que é necessário para LTS. -
--k8s-support-plan AKSLongTermSupportregistra o cluster no LTS e fornece um ano adicional de correções de segurança. -
--auto-upgrade-channel patchatualiza automaticamente o cluster para versões de patch com suporte, mantendo a mesma versão secundária.
Habilitar o LTS em um cluster existente
Habilite o LTS em um cluster existente usando o comando az aks update.
az aks update --resource-group <resource-group-name> --name <cluster-name> --tier premium --k8s-support-plan AKSLongTermSupport --auto-upgrade-channel patch
O comando usa os seguintes valores de parâmetro específicos do LTS:
-
--tier premiummova o cluster para a camada de gerenciamento de cluster Premium, que é necessária para LTS. -
--k8s-support-plan AKSLongTermSupportregistra o cluster no LTS e fornece um ano adicional de correções de segurança. -
--auto-upgrade-channel patchatualiza automaticamente o cluster para versões de patch com suporte, mantendo a mesma versão secundária.
Dica
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
Para executar uma atualização in-loco para a versão mais recente do LTS, especifique uma versão lts mais alta oferecida pelo AKS como o destino de atualização. Um cluster LTS pode ignorar versões secundárias quando a atualização atende aos requisitos de descompasso entre versões e verificações de validação. Para obter mais informações, consulte as regras de atualização de versão do Kubernetes.
Durante uma atualização completa no local, o AKS atualiza primeiro o plano de controle e, em seguida, atualiza cada pool de nós sequencialmente. Teste suas cargas de trabalho em relação a APIs preteridas e outras alterações incompatíveis entre as versões atuais e de destino antes de atualizar.
Liste as versões que o AKS oferece como destinos de atualização para seu cluster usando o
az aks get-upgradescomando.az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output tableAtualize para uma versão lts oferecida usando o
az aks upgradecomando.az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version <lts-kubernetes-version>Observação
Todas as versões do Kubernetes do AKS com suporte são compatíveis com LTS. Para obter o calendário lts mais recente, consulte o calendário de lançamento do Kubernetes do AKS. Para exibir as versões lts disponíveis e seus patches por região, consulte o rastreador de versão do AKS.
Desabilitar o suporte a longo prazo em um cluster existente
Para desabilitar o LTS em um cluster existente, mova o cluster para a camada Gratuito ou Standard e selecione explicitamente o KubernetesOfficial plano de suporte.
Você pode desabilitar o LTS enquanto a versão do Kubernetes do cluster ainda estiver em suporte da comunidade. Depois que essa versão sair do suporte da comunidade, atualize o cluster para uma versão com suporte da comunidade antes de desabilitar o LTS. Verifique o calendário de lançamento do Kubernetes do AKS para determinar o status de suporte da sua versão.
Se a versão atual estiver fora do suporte da comunidade, liste os destinos de atualização disponíveis usando o
az aks get-upgradescomando.az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output tableSe necessário, atualize o cluster para uma versão oferecida que esteja no suporte da comunidade usando o
az aks upgradecomando.az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version <community-supported-kubernetes-version>Desabilite o LTS usando o
az aks updatecomando. O exemplo a seguir move o cluster para a camada Gratuita e seleciona oKubernetesOfficialplano de suporte.az aks update --resource-group <resource-group-name> --name <cluster-name> --tier free --k8s-support-plan KubernetesOfficialO valor
--tier freemove o cluster para a camada de gerenciamento de cluster gratuito, e--k8s-support-plan KubernetesOfficialalterna o cluster de LTS para o plano de suporte padrão do Kubernetes do AKS.
Considerações sobre o add-on e o ciclo de vida da funcionalidade
O LTS estende o suporte para a versão do Kubernetes, mas complementos e recursos podem ter ciclos de vida de suporte separados. Antes de mover um cluster para LTS, examine o ciclo de vida e a compatibilidade de versão do Kubernetes de cada complemento e recurso que o cluster usa.
A tabela a seguir resume as considerações atuais sobre o ciclo de vida:
| Complemento ou recurso | Considerações sobre o ciclo de vida |
|---|---|
| Calicó | Confirme se sua versão do Calico dá suporte à versão do Kubernetes de destino e examine os termos de suporte do Tigera para uso além do suporte à comunidade do Kubernetes. |
| Serviço de Gerenciamento de Chaves (KMS) | A experiência KMS existente agora é designada como legada. Para o Kubernetes 1.33 e posterior, examine a nova experiência de criptografia de dados KMS e as diretrizes de migração aplicáveis. Tanto a nova experiência quanto seu fluxo de trabalho de migração estão em versão prévia. |
| Dapr | A extensão Dapr gerenciada usa uma janela de suporte contínua que inclui as versões atual e anterior do Dapr. Mantenha a extensão dentro da janela de versão com suporte. |
| AGIC (Controlador de Ingress do Application Gateway) | O AGIC permanece disponível. Comece a transição para o Application Gateway for Containers. |
| Open Service Mesh (OSM) | O suporte do AKS para o complemento do OSM gerenciado termina em 30 de setembro de 2027. Migre para o complemento Istio antes dessa data. |
| Microsoft Entra identidade gerenciada por pod | O suporte para o complemento gerenciado terminou em setembro de 2025. Migre para ID de carga de trabalho do Microsoft Entra. |
| Computação confidencial do Azure SGX (ACC SGX) | Confirme se o ACC SGX dá suporte à versão do Kubernetes de destino antes de mover o cluster para além do suporte da comunidade. |
Planejar a próxima atualização do LTS
O AKS torna as versões consecutivas do Kubernetes elegíveis para LTS e publica uma data de fim de vida de LTS separada para cada versão. Use o calendário de lançamento do AKS LTS e o rastreador de lançamentos do AKS para escolher uma versão de destino oferecida e planejar sua migração antes que a versão atual atinja a data de fim de vida útil do LTS da versão atual.
Se você não atualizar, o AKS atualizará o cluster para você após o período de carência de 60 dias que segue a data de fim de vida do LTS, por meio de uma atualização iniciada pela plataforma. O cluster permanece na faixa LTS e passa para a próxima versão do LTS com suporte. As atualizações iniciadas pela plataforma não seguem sua janela de manutenção, portanto, atualizar em sua própria agenda é a única maneira de manter o controle do momento da atualização.
Perguntas frequentes
Posso criar um novo cluster do AKS com uma versão lts após o término do suporte da comunidade?
Sim, você pode criar um novo cluster do AKS usando uma versão LTS após o término do período de suporte da comunidade se você habilitar o LTS. O suporte a LTS continua somente até o final do ciclo de vida dessa versão. Em seguida, você deve atualizar para a próxima versão LTS com suporte. Para obter mais informações, consulte o calendário de lançamento do Kubernetes do AKS.
Posso habilitar e desabilitar o LTS em uma versão com suporte do AKS após o término do suporte da comunidade?
Sim, você pode habilitar o plano de suporte do LTS em qualquer versão com suporte do AKS mesmo após o término do período de suporte da comunidade. No entanto, depois que o período de suporte da comunidade for encerrado, você não poderá desabilitar o LTS para essa versão.
Um cluster AKS com suporte da comunidade se torna automaticamente elegível para LTS após o fim da vida útil?
Não. Você deve habilitar explicitamente o LTS e mover o cluster para a camada Premium.
Uma atualização iniciada pela plataforma registra meu cluster no LTS?
Não. O AKS nunca inscreve um cluster no LTS em seu nome e nunca altera seu nível de cobrança. Uma atualização iniciada pela plataforma mantém o cluster em sua camada de suporte atual: um cluster de suporte da comunidade se move para a versão secundária da comunidade com suporte mais baixa e um cluster LTS passa para a versão LTS aplicável.
O que acontece se a versão LTS do meu cluster atingir o fim da vida útil e eu não atualizar?
O AKS atualiza o cluster para a próxima versão LTS com suporte após o período de carência de 60 dias que segue a data de fim da vida útil do LTS. O cluster não é rebaixado para uma versão com suporte da comunidade. Para localizar o mês da sua versão, consulte o calendário de lançamento do AKS LTS. Para obter mais informações, consulte atualizações iniciadas pela plataforma.
Todas as versões do AKS são qualificadas para suporte a longo prazo?
Sim. Todas as versões do Kubernetes com suporte são qualificadas para LTS.
Quais são os modelos de preços do LTS?
O LTS é oferecido na camada Premium. Para obter as taxas atuais, consulte os preços do tipo Premium.
Habilitar o LTS interrompe cargas de trabalho?
Não. É uma alteração somente de configuração; ela não reinstala a imagem dos nós nem interrompe cargas de trabalho, portanto, nenhum tempo de inatividade é esperado.