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 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.28 | Agosto de 2023 | Setembro 2023 | Novembro 2023 | Janeiro de 2025 | Até 1.32 GA |
| 1,29 | Dez 2023 | Fev 2024 | Março 2024 | Março 2025 | Até 1.33 GA |
| 1.30 | Abr 2024 | jun 2024 | Julho de 2024 | Julho 2025 | Até 1.34 AG |
| 1.31 | Agosto de 2024 | Outubro de 2024 | Novembro de 2024 | Novembro 2025 | Até 1.35 GA |
| 1.32 | Dez 2024 | Fev 2025 | Março 2025 | Março 2026 | Até 1.36 GA |
Versões LTS
Nota
O Azure Linux suporta apenas 1.27 LTS. Para obter mais informações sobre o 1.30 LTS com o Azure Linux, leia a seção Versões do Azure Linux AKS LTS.
| Versão K8s | Lançamento a montante | Pré-visualização do AKS | AKS GA | Fim da vida útil | LTS Fim da vida útil |
|---|---|---|---|---|---|
| 1.27 | Abr 2023 | jun 2023 | Julho 2023 | Julho de 2024 | Julho 2025 |
| 1.30 | Abr 2024 | jun 2024 | Julho de 2024 | Julho 2025 | Julho 2026 |
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:
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:
Kubernetes 1,30
| Complementos gerenciados pelo AKS | Componentes AKS | Componentes do SO | Alterações interruptivas | Notas |
|---|---|---|---|---|
| • Azure Policy 1.3.0 • Cloud-Provider-Node-Manager v1.30.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.14.0 • 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 Ingresso de Gateway de Aplicação (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 • Coletor de pod MDC Defender 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 Secrets Loja Driver 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 (Azure CNI Overlay) • 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 • Cgroups V2 • Contentor D 1.6 |
• KEDA 2.14.1 | N/A |
Kubernetes 1,29
| Complementos gerenciados pelo AKS | Componentes AKS | Componentes do SO | Alterações interruptivas | Notas |
|---|---|---|---|---|
| • Azure Policy 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 Ingresso de Gateway de Aplicação (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 • Coletor de pod MDC Defender 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 Secrets Loja Driver 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 (Azure CNI Overlay) • 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 • Cgroups V2 • Contentor D 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 |
N/A |
Kubernetes 1,28
| Complementos gerenciados pelo AKS | Componentes AKS | Componentes do SO | Alterações interruptivas | Notas |
|---|---|---|---|---|
| • Azure Policy 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 Ingresso de Gateway de Aplicação (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 Secrets Loja Driver 1.3.4-1 • MDC Defender Limpador de Arquivos Antigos 1.3.68 • Coletor de pod MDC Defender 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 (Azure CNI Overlay) • 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 • Cgroups V1 • Contentor D 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 |
N/A |
Kubernetes 1,27
| Complementos gerenciados pelo AKS | Componentes AKS | Componentes do SO | Alterações interruptivas | Notas |
|---|---|---|---|---|
| • Azure Policy 1.3.0 • Driver AzureDisk-CSI v1.28.5 • Driver AzureFile-CSI v1.28.10 • 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 Ingresso de Gateway de Aplicação (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 Secrets Loja Driver 1.3.4-1 |
• Cílio 1.13.10-1 • CNI 1.4.44 • Cluster Autoscaler 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 • Cgroups V1 • Contentor D 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. |
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 pode suportar qualquer número de patches em um determinado momento. A AKS reserva-se o direito de substituir patches se for detetada uma vulnerabilidade crítica de CVE ou de segurança. Para saber mais sobre a disponibilidade de patches e qualquer substituição ad-hoc, consulte as notas de versão da versão e visite a página de status da versão 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 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 pode suportar qualquer número de patches com base na disponibilidade de lançamento da comunidade upstream para uma determinada versão secundária. A AKS reserva-se o direito de depreciar qualquer um desses patches a qualquer momento devido a um CVE ou potencial problema de bug. Você é sempre encorajado a usar o patch mais recente para uma versão secundária.
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 pool de nós | Suportado | Suportado |
| Criação de clusters | Suportado | Não suportado |
| Instantâneo do pool de nós | Suportado | Não suportado |
| Atualização da imagem do nó | Suportado | 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.
Observe que, para atualizações de versão do plano de controle, você pode ir até 3 versões secundárias para versões suportadas pela comunidade de forma sequencial.
Para atualizar de 1.27.x ->1.29.x:
- Atualize de 1.27.x para> 1.28.x.
- Atualize de 1.28.x para> 1.29.x.
Observação A partir da versão 1.28, as versões do agentpool podem ter até 3 versões mais antigas para controlar as versões do plano por política de distorção de versão. Quando sua versão está muito atrás da versão mínima suportada, você pode ter que fazer mais de uma operação de atualização do plano de controle para chegar à versão mínima suportada. Por exemplo, se a versão atual do plano de controle for 1.23.x e você pretende atualizar para uma versão mínima suportada de 1.27.x como exemplo. Você pode ter que atualizar sequencialmente 4 vezes 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. Isso significa que, no exemplo acima, você pode atualizar a versão do agentpool duas vezes, ou seja, uma vez de 1.23.x para 1.25.x, quando a versão do plano de controle estiver em 1.25.x. E posteriormente de 1.25.x para 1.27.x , quando a versão do plano de controle está em 1.27.x. Ao atualizar in-loco, ou seja, o plano de controle e o pool de agentes juntos, aplicam-se as mesmas regras aplicáveis à atualização do plano de controle descritas acima.
Ao executar uma atualização de uma versão não suportada - a atualização é realizada sem qualquer garantia de funcionalidade e é excluída dos contratos de nível de serviço e 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 a janela de suporte da plataforma?
Não, a criação de novos clusters não é possível durante o período de Suporte da Plataforma.
Estou em uma versão recém-preterida que está fora do suporte da plataforma, ainda posso adicionar novos pools de nós? Ou terei que atualizar?
Sim, você pode adicionar pools de agentes, desde que sejam compatíveis com a versão do plano de controle.
Próximos passos
Para obter informações sobre como atualizar seu cluster, consulte:
Azure Kubernetes Service