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

  • Artigo

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.

Nota

AKS segue 12 meses de suporte para uma versão Kubernetes geralmente disponível (GA). Para ler mais sobre nossa política de suporte para versionamento do Kubernetes, leia nossas perguntas frequentes.

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

Versão K8s Lançamento a montante Pré-visualização do AKS AKS GA Fim da vida útil Suporte da plataforma
1.26 Dez 2022 fev 2023 Abr 2023 Março 2024 Até 1.30 GA
1.27* Abr 2023 jun 2023 Julho 2023 Jul 2024, LTS até jul 2025 Até 1.31 GA
1.28 Agosto de 2023 Setembro 2023 Novembro 2023 Novembro de 2024 Até 1.32 GA
1,29 Dez 2023 Fev 2024 Março 2024 Até 1.33 GA
1.30 Abr 2024 maio de 2024 jun 2024 Até 1.34 AG

* Indica que a versão é designada para Suporte de Longo Prazo

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:

Gráfico de Gantt mostrando o ciclo de vida de todas as versões do Kubernetes atualmente ativas no AKS.

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:

Versão do Kubernetes Addons gerenciados pelo AKS Componentes AKS Componentes do SO Alterações Interruptivas Notas
1.26 Política do Azure 1.3.0
Metrics-Server 0.6.3
KEDA 2.10.1
Abrir malha de serviço 1.2.3
DNS principal v1.9.4
Sobreposição VPA 0.11.0
Azure-Keyvault-SecretsProvider 1.4.1
Controlador de entrada do gateway de aplicativo (AGIC) 1.5.3
Limpador de Imagem v1.2.3
Identidade da carga de trabalho do Azure v1.0.0
MDC Defender 1.0.56
Azure Ative Directory Pod Identity 1.8.13.6
GitOps 1.7.0
KMS 0.5.0
azurefile-csi-driver 1.26.10
 Cílio 1.12.8
CNI 1.4.44
Autoscaler de cluster 1.8.5.3
 Imagem do SO Ubuntu 22.04 Cgroups V2
ContentorD 1.7
Azure Linux 2.0
Cgrupos V1
ContentorD 1.6
 azurefile-csi-driver 1.26.10 Nenhuma
1.27 Política do Azure 1.3.0
Driver AzureDisk-CSI v1.28.5
Driver AzureFile-CSI v1.28.7
blob-csi v1.22.4
csi-attacher v4.3.0
CSI-Resizer v1.8.0
CSI-Snapshotter v6.2.2
controlador de instantâneo v6.2.2
Metrics-Server 0.6.3
Keda 2.11.2
Abrir malha de serviço 1.2.3
DNS principal v1.9.4
Sobreposição VPA 0.11.0
Azure-Keyvault-SecretsProvider 1.4.1
Controlador de entrada do gateway de aplicativo (AGIC) 1.7.2
Limpador de Imagem v1.2.3
Identidade da carga de trabalho do Azure v1.0.0
MDC Defender 1.0.56
Azure Ative Directory Pod Identity 1.8.13.6
GitOps 1.7.0
azurefile-csi-driver 1.28.7
KMS 0.5.0
CSI Driver de loja secreta 1.3.4-1
 Cílio 1.13.10-1
CNI 1.4.44
Autoscaler de cluster 1.8.5.3
 Imagem do SO Ubuntu 22.04 Cgroups V2
ContainerD 1.7 para Linux e 1.6 para Windows
Azure Linux 2.0
Cgrupos V1
ContentorD 1.6
 Keda 2.11.2
Cílio 1.13.10-1
azurefile-csi-driver 1.28.7
Driver AzureDisk-CSI v1.28.5
blob-csi v1.22.4
csi-attacher v4.3.0
CSI-Resizer v1.8.0
CSI-Snapshotter v6.2.2
controlador de instantâneo v6.2.2		 Devido ao status de certificação FIPS do Ubuntu 22.04, mudaremos os nós FIPS do AKS de 18.04 para 20.04 a partir do 1.27.
1.28 Política do Azure 1.3.0
azurefile-csi-driver 1.29.2
csi-node-driver-registrar v2.9.0
CSI-LivenessProbe 2.11.0
AzureDisk-CSI-Linux v1.29.2
azuredisk-csi-windows v1.29.2
CSI-Provisioner v3.6.2
csi-attacher v4.5.0
CSI-Resizer v1.9.3
CSI-Snapshotter v6.2.2
controlador de instantâneo v6.2.2
Metrics-Server 0.6.3
KEDA 2.11.2
Abrir malha de serviço 1.2.7
DNS principal v1.9.4
Sobreposição VPA 0.13.0
Azure-Keyvault-SecretsProvider 1.4.1
Controlador de entrada do gateway de aplicativo (AGIC) 1.7.2
Limpador de Imagem v1.2.3
Identidade da carga de trabalho do Azure v1.2.0
MDC Defender Security Publisher 1.0.68
CSI Driver de loja secreta 1.3.4-1
MDC Defender Limpador de Arquivos Antigos 1.3.68
MDC Defender Pod Coletor 1.0.78
Coletor de baixo nível MDC Defender 1.3.81
Azure Ative Directory Pod Identity 1.8.13.6
GitOps 1.8.1		 Cílio 1.13.10-1
CNI v1.4.43.1 (Padrão)/v1.5.11 (Sobreposição CNI do Azure)
Autoscaler de cluster 1.27.3
Operador Tigera 1.28.13		 Imagem do SO Ubuntu 22.04 Cgroups V2
ContainerD 1.7.5 para Linux e 1.7.1 para Windows
Azure Linux 2.0
Cgrupos V1
ContentorD 1.6
 azurefile-csi-driver 1.29.2
CSI-Resizer v1.9.3
csi-attacher v4.4.2
CSI-Provisioner v4.4.2
blob-csi v1.23.2
Driver AzureFile-CSI v1.29.2
driver azuredisk-csi v1.29.2
CSI-LivenessProbe v2.11.0
csi-node-driver-registrar v2.9.0		 Nenhuma
1,29 Política do Azure 1.3.0
CSI-Provisioner v4.0.0
csi-attacher v4.5.0
CSI-Snapshotter v6.3.3
controlador de instantâneo v6.3.3
Metrics-Server 0.6.3
KEDA 2.11.2
Abrir malha de serviço 1.2.7
DNS principal v1.9.4
Sobreposição VPA 0.13.0
Azure-Keyvault-SecretsProvider 1.4.1
Controlador de entrada do gateway de aplicativo (AGIC) 1.7.2
Limpador de Imagem v1.2.3
Identidade da carga de trabalho do Azure v1.2.0
MDC Defender Security Publisher 1.0.68
MDC Defender Limpador de Arquivos Antigos 1.3.68
MDC Defender Pod Coletor 1.0.78
Coletor de baixo nível MDC Defender 1.3.81
Azure Ative Directory Pod Identity 1.8.13.6
GitOps 1.8.1
CSI Driver de loja secreta 1.3.4-1
azurefile-csi-driver 1.29.3
 Cílio 1.13.5
CNI v1.4.43.1 (Padrão)/v1.5.11 (Sobreposição CNI do Azure)
Autoscaler de cluster 1.27.3
Operador Tigera 1.30.7
 Imagem do SO Ubuntu 22.04 Cgroups V2
ContainerD 1.7.5 para Linux e 1.7.1 para Windows
Azure Linux 2.0
Cgrupos V1
ContentorD 1.6
 Operador Tigera 1.30.7
CSI-Provisioner v4.0.0
csi-attacher v4.5.0
CSI-Snapshotter v6.3.3
controlador de instantâneo v6.3.3		 Nenhuma

Alias versão secundária

Nota

A versão secundária do Alias requer a CLI do Azure versão 2.37 ou superior, bem como a versão da API 20220401 ou superior. Use az upgrade para instalar a versão mais recente da CLI.

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 também suporta um máximo de dois patches estáveis.

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.

Nota

O AKS usa práticas de implantação seguras que envolvem a implantação gradual da região. Isso significa que pode levar até 10 dias úteis para que uma nova versão ou uma nova versão esteja disponível em todas as regiões.

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:

Nova versão secundária Lista de versões secundárias suportadas
1,29 1.29, 1.28, 1.27

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 também suporta um máximo de duas versões de patch de uma determinada versão secundária. Por exemplo, dadas as seguintes versões suportadas:

Current Supported Version List
------------------------------
1.29.2, 1.29.1, 1.28.7, 1.28.6, 1.27.11, 1.27.10

Se o AKS for lançado 1.29.3 e 1.28.8o , as versões de patch mais antigas forem preteridas e removidas, e a lista de versões suportadas se tornará:

New Supported Version List
----------------------
1.29.3, 1.29.2, 1.28.8, 1.28.7, 1.27.11, 1.27.10

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.

Categoria de suporte Apoio Comunitário (N-2) Suporte à plataforma (N-3)
Atualizações do N-3 para uma versão suportada Suportado Suportado
Disponibilidade da plataforma (Azure) Suportado Suportado
Dimensionamento do pool de nós Suportado Suportado
Disponibilidade da VM Suportado Suportado
Armazenamento, problemas relacionados à rede Suportado Suportado, exceto para correções de bugs e componentes retirados
Iniciar/parar Suportado Suportado
Rodar certificados Suportado Suportado
SLA de infraestrutura Suportado Suportado
SLA do Plano de Controle Suportado Suportado
SLA da plataforma (AKS) Suportado Não suportado
Componentes do Kubernetes (incluindo Add-ons) Suportado Não suportado
Atualizações de componentes Suportado Não suportado
Hotfixes de componentes Suportado Não suportado
Aplicação de correções de bugs Suportado Não suportado
Aplicação de patches de segurança Suportado Não suportado
Suporte à API do Kubernetes Suportado Não suportado
Criação de cluster ou pool de nós Suportado Não suportado
Instantâneo do pool de nós Suportado Não suportado
Atualização da imagem do nó Suportado Não suportado

Nota

A tabela acima está sujeita a alterações e descreve cenários de suporte comuns. Quaisquer cenários relacionados à funcionalidade e componentes do Kubernetes não são suportados para o N-3. Para obter mais suporte, consulte Suporte e solução de problemas para AKS.

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

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.

Para saber quais versões estão atualmente disponíveis para sua assinatura e região, use o az aks get-versions comando. O exemplo a seguir lista as versões disponíveis do Kubernetes para a região EastUS :

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

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.

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.

Ignorar várias versões só pode ser feito ao atualizar de uma versão não suportada de volta para a versão mínima suportada. Por exemplo, você pode atualizar de um 1.25.x sem suporte para um 1.27.x suportado se 1.27 for a versão secundária mínima suportada.

Ao executar uma atualização de uma versão não suportada que ignora duas ou mais versões secundárias, a atualização é executada sem qualquer garantia de funcionalidade e é excluída dos contratos de nível de serviço e da 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 sua janela de suporte de 30 dias?

N.º Depois que uma versão for preterida/removida, você não poderá criar um cluster com essa versão. À medida que a alteração for implementada, você começará a ver a versão antiga removida da sua lista de versões. Este processo pode demorar até duas semanas a partir do anúncio, progressivamente por região.

Estou em uma versão recém-preterida, ainda posso adicionar novos pools de nós? Ou terei que atualizar?

N.º Você não tem permissão para adicionar pools de nós da versão preterida ao cluster. A criação ou atualização de pools de nós até a versão do plano de controle de versão não suportada é permitida, independentemente da diferença de versão entre o pool de nós e o plano de controle. Apenas pequenas atualizações de alias são permitidas.

Com que frequência você atualiza patches?

Os adesivos têm um ciclo de vida mínimo de dois meses. Para se manter atualizado quando novos patches são lançados, siga as notas de versão do AKS.

Próximos passos

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