Versões do Kubernetes com suporte no AKS (Serviço de Kubernetes do Azure)
A comunidade do Kubernetes libera versões secundárias aproximadamente a cada quatro meses.
As versões secundárias incluem novos recursos e aprimoramentos. As versões de patch são mais frequentes (às vezes, semanais) e são destinadas a correções de bugs críticas em dentro de uma versão secundária. As versões de patch incluem correções para vulnerabilidades de segurança ou bugs principais.
Versões do Kubernetes
O Kubernetes usa o esquema de controle de versão Controle de Versão 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 são alteradas quando as atualizações de API incompatíveis ou a compatibilidade com versões anteriores podem ser interrompidas.
- As versões secundárias são alteradas quando são feitas atualizações de funcionalidade que são compatíveis com versões anteriores.
- As versões de patch são alteradas quando são feitas correções de bugs compatíveis com versões anteriores.
Tenha como objetivo executar a última versão do patch da versão secundária que está sendo executada. Por exemplo, se o seu cluster de produção estiver na versão 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 1.29.2 o mais rápido possível para garantir que seu cluster esteja totalmente corrigido e tenha suporte.
Calendário de versão do AKS Kubernetes
Exibir lançamentos de versões futuras no calendário de lançamento do AKS Kubernetes. Para visualizar as atualizações em tempo real do status da versão da região e das notas sobre a versão, visite a página da Web status de versão do AKS. Para saber mais sobre a página da Web de status da versão, confira Rastreador de versão do AKS.
Observação
O AKS segue 12 meses de suporte para uma versão de disponibilidade geral (GA) do Kubernetes. Para ler mais sobre nossa política de suporte para controle de versão do Kubernetes, leia nossas perguntas frequentes.
Para obter o histórico de lançamentos anteriores, consulte Histórico do Kubernetes.
| Versão do K8s | Versão de upstream | Visualização prévia AKS | AKS GA | Fim da vida útil | Suporte a plataforma |
|---|---|---|---|---|---|
| 1.28 | Agosto de 2023 | Setembro de 2023 | nov. de 2023 | Janeiro de 2025 | Até 1,32 GA |
| 1.29 | dez. de 2023 | fev. de 2024 | Março de 2024 | Março de 2025 | Até 1,33 GA |
| 1.30 | Abril de 2024 | Junho de 2024 | Julho de 2024 | Julho de 2025 | Até 1.34 GA |
| 1.31 | Ago de 2024 | Out de 2024 | Novembro de 2024 | Novembro de 2025 | Até 1.35 GA |
| 1,32 | Dez 2024 | Fevereiro de 2025 | Março de 2025 | Mar 2026 | Até 1,36 GA |
Versões LTS
| Versão do K8s | Versão de upstream | Visualização prévia AKS | AKS GA | Fim da vida útil | Fim da vida útil do LTS |
|---|---|---|---|---|---|
| 1.27 | Abril de 2023 | Junho de 2023 | Julho de 2023 | Julho de 2024 | Julho de 2025 |
| 1.30 | Abril de 2024 | Junho de 2024 | Julho de 2024 | Julho de 2025 | Jul 2026 |
Gráfico de Gantt da programação de versões do Kubernetes do AKS
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 da falha | Observações |
|---|---|---|---|---|
| • 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 • Métricas-Servidor 0.6.3 • KEDA 2.14.0 • Malha de serviço aberta 1.2.7 • DNS principal V1.9.4 • Sobreposição VPA 0.13.0 • Azure-Keyvault-SecretsProvider 1.4.1 • Controlador de entrada de Gateway de Aplicativo (AGIC) 1.7.2 • Limpador de imagens v1.2.3 • Identidade da carga de trabalho do Azure v1.2.0 • Publicador de segurança do MDC Defender 1.0.68 • Limpador de arquivos antigos do MDC Defender 1.3.68 • Coletor de pods do MDC Defender 1.0.78 • Coletor de Baixo Nível MDC Defender 1.3.81 • Identidade do Pod do Azure Active Directory 1.8.13.6 • GitOps 1.8.1 • CSI Secrets Store Driver 1.3.4-1 • azurefile-csi-driver 1.29.3 |
• Cilium 1.13.5 • CNI v1.4.43.1 (padrão)/v1.5.11 (sobreposição CNI do Azure) • Escalonador Automático de Cluster 1.27.3 • Tigera-Operador 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 • ContainerD 1.6 |
• KEDA 2.14.1 | N/D |
Kubernetes 1.29
| Complementos gerenciados pelo AKS | Componentes AKS | Componentes do SO | Alterações da falha | Observações |
|---|---|---|---|---|
| • 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 • Métricas-Servidor 0.6.3 • KEDA 2.11.2 • Malha de serviço aberta 1.2.7 • DNS principal V1.9.4 • Sobreposição VPA 0.13.0 • Azure-Keyvault-SecretsProvider 1.4.1 • Controlador de entrada de Gateway de Aplicativo (AGIC) 1.7.2 • Limpador de imagens v1.2.3 • Identidade da carga de trabalho do Azure v1.2.0 • Publicador de segurança do MDC Defender 1.0.68 • Limpador de arquivos antigos do MDC Defender 1.3.68 • Coletor de pods do MDC Defender 1.0.78 • Coletor de Baixo Nível MDC Defender 1.3.81 • Identidade do Pod do Azure Active Directory 1.8.13.6 • GitOps 1.8.1 • CSI Secrets Store Driver 1.3.4-1 • azurefile-csi-driver 1.29.3 |
• Cilium 1.13.5 • CNI v1.4.43.1 (padrão)/v1.5.11 (sobreposição CNI do Azure) • Escalonador Automático de Cluster 1.27.3 • Tigera-Operador 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 • ContainerD 1.6 |
• Tigera-Operador 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/D |
Kubernetes 1.28
| Complementos gerenciados pelo AKS | Componentes AKS | Componentes do SO | Alterações da falha | Observações |
|---|---|---|---|---|
| • 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 • snapshot-controller v6.2.2 • Métricas-Servidor 0.6.3 • KEDA 2.11.2 • Malha de serviço aberta 1.2.7 • DNS principal V1.9.4 • Sobreposição VPA 0.13.0 • Azure-Keyvault-SecretsProvider 1.4.1 • Controlador de entrada de Gateway de Aplicativo (AGIC) 1.7.2 • Limpador de imagens v1.2.3 • Identidade da carga de trabalho do Azure v1.2.0 • Publicador de segurança do MDC Defender 1.0.68 • CSI Secrets Store Driver 1.3.4-1 • Limpador de arquivos antigos do MDC Defender 1.3.68 • Coletor de pods do MDC Defender 1.0.78 • Coletor de Baixo Nível MDC Defender 1.3.81 • Identidade do Pod do Azure Active Directory 1.8.13.6 • GitOps 1.8.1 |
• Cilium 1.13.10-1 • CNI v1.4.43.1 (padrão)/v1.5.11 (sobreposição CNI do Azure) • Escalonador Automático de Cluster 1.27.3 • Tigera-Operator 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 • ContainerD 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 • azurefile-csi driver v1.29.2 • azuredisk-csi driver v1.29.2 • csi-livenessprobe v2.11.0 • csi-node-driver-registrar v2.9.0 |
N/D |
Kubernetes 1.27
| Complementos gerenciados pelo AKS | Componentes AKS | Componentes do SO | Alterações da falha | Observações |
|---|---|---|---|---|
| • Azure Policy 1.3.0 • azuredisk-csi driver v1.28.5 • azurefile-csi driver v1.28.10 • blob-csi v1.22.4 • csi-attacher v4.3.0 • csi-resizer v1.8.0 • csi-snapshotter v6.2.2 • snapshot-controller v6.2.2 • Métricas-Servidor 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 de Gateway de Aplicativo (AGIC) 1.7.2 • Limpador de imagens v1.2.3 • Identidade da carga de trabalho do Azure v1.0.0 • MDC Defender 1.0.56 • Identidade do Pod do Azure Active Directory 1.8.13.6 • GitOps 1.7.0 • azurefile-csi-driver 1.28.7 • KMS 0.5.0 • CSI Secrets Store Driver 1.3.4-1 |
• Cilium 1.13.10-1 • CNI 1.4.44 • Escalonador Automático 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 • Cgroups V1 • ContainerD 1.6 |
• KEDA 2.11.2 • Cilium 1.13.10-1 • azurefile-csi-driver 1.28.7 • azuredisk-csi driver v1.28.5 • blob-csi v1.22.4 • csi-attacher v4.3.0 • csi-resizer v1.8.0 • csi-snapshotter v6.2.2 • snapshot-controller v6.2.2 |
Devido ao status de certificação FIPS do Ubuntu 22.04, mudaremos os nós AKS FIPS de 18.04 para 20.04 de 1.27 em diante. |
Versão secundária do alias
Observação
A versão secundária do alias requer a CLI do Azure versão 2.37 ou superior, bem como a versão 20220401 ou superior da API. 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 da 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 em disponibilidade geral mais recente, seu cluster será criado com a versão 1.29.2. Se quiser atualizar a versão do patch na mesma versão secundária, use a atualização automática.
Para visualizar em qual patch você está, execute o comando az aks show --resource-group myResourceGroup --name myAKSCluster. A propriedade currentKubernetesVersion 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 de versão do Kubernetes
O AKS define uma versão em disponibilidade geral (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 é compatível com três versões secundárias GA do Kubernetes:
- A última versão secundária do GA lançada no AKS (à qual nos referimos como N).
- Duas versões secundárias anteriores.
- Cada versão secundária com suporte pode ser compatível com qualquer número de patches em um determinado momento. O AKS se reserva o direito de preterir patches se uma CVE ou vulnerabilidade críticas forem detectadas. Para se manter ciente da disponibilidade do patch e de qualquer substituição ad hoc, confira as notas de versão dessa versão e acesse a página da web do status de versões do AKS.
O AKS também pode dar suporte a versões prévias, que estão explicitamente rotuladas e sujeitas aos termos e às condições da versão prévia.
O AKS fornece suporte de plataforma somente para uma versão secundária do Kubernetes da GA 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.
Observação
O AKS usa práticas de implantação segura que envolvem a implantação gradual de região. Isso significa que pode levar até dez dias úteis para que um novo lançamento ou uma nova versão fique disponível em todas as regiões.
A janela de versões secundárias do Kubernetes com suporte no AKS é conhecida como "N-2", em que N se refere à versão mais recente, significando que as duas versões secundárias anteriores também têm suporte.
Por exemplo, no dia em que o AKS apresenta a versão 1.29, o suporte é fornecido para as seguintes versões:
| Nova versão secundária | Lista de versões secundárias com suporte |
|---|---|
| 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 om suporte seja:
1.29
1.28
1.27
Quando o AKS lançar a versão 1.30, todas as versões 1.27 perderão o suporte 30 dias depois.
O AKS pode dar suporte a qualquer número de patches com base na disponibilidade de versões da comunidade upstream para uma determinada versão secundária. O AKS se reserva o direito de preterir quaisquer patches a qualquer momento devido a uma CVE ou a uma possível preocupação com bugs. Você é sempre incentivado a usar o patch mais recente para uma versão secundária.
A política de suporte da plataforma
A política de suporte à plataforma é um plano de suporte reduzido para determinadas versões do Kubernetes sem suporte. Durante o suporte à plataforma, os clientes só recebem suporte da Microsoft para problemas relacionados à plataforma AKS/Azure. Não há suporte para qualquer problema relacionado à funcionalidade e aos componentes do Kubernetes.
A política de suporte da plataforma se aplica a clusters em uma versão n-3 (em que n é a última versão secundária suportada do AKS da GA), antes que o cluster caia para n-4. Por exemplo, o Kubernetes v1.26 é considerado suporte à plataforma quando a v1.29 é a versão GA mais recente. No entanto, durante a versão GA v1.30, a v1.26 será atualizada automaticamente para a v1.27. Se você estiver executando uma versão n-2, no momento em que ela se tornar n-3, ela também será preterida e você entrará na política de suporte da plataforma.
O AKS depende das versões e dos patches do Kubernetes, que é um projeto de código aberto que dá suporte apenas para 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 em upstream. Como não há mais patches sendo produzidos em upstream, o AKS pode deixar essas versões sem patch ou bifurcá-las. Devido a essa limitação, o suporte à plataforma não dá suporte a nada que dependa do upstream do Kubernetes.
Essa tabela descreve as diretrizes de suporte para o Suporte da Comunidade em comparação com o suporte da Plataforma.
| Categoria do suporte | Suporte da Comunidade (N-2) | Suporte da Plataforma (N-3) |
|---|---|---|
| Atualizações do N-3 para uma versão suportada | Com suporte | Com suporte |
| Disponibilidade da plataforma (Azure) | Com suporte | Com suporte |
| Escala do pool de nós | Com suporte | Com suporte |
| Disponibilidade da VM | Com suporte | Com suporte |
| Problemas relacionados ao armazenamento e à rede | Com suporte | Com suporte, exceto para correções de bugs e componentes desativados |
| Iniciar/parar | Com suporte | Com suporte |
| Girar certificados | Com suporte | Com suporte |
| SLA de infraestrutura | Com suporte | Com suporte |
| Plano de controle do SLA | Com suporte | Com suporte |
| SLA da Plataforma (AKS) | Com suporte | Sem suporte |
| Componentes do Kubernetes (incluindo Complementos) | Com suporte | Sem suporte |
| Atualizações de componentes | Com suporte | Sem suporte |
| Hotfixes de componentes | Com suporte | Sem suporte |
| Aplicação de correções de bugs | Com suporte | Sem suporte |
| Aplicação de patches de segurança | Com suporte | Sem suporte |
| Suporte à API do Kubernetes | Com suporte | Incompatível |
| Criação do pool de nós | Com suporte | Com suporte |
| Criação do cluster | Com suporte | Sem suporte |
| Instantâneo do pool de nós | Com suporte | Sem suporte |
| Atualização da imagem do nó | Com suporte | Com suporte |
Observação
A tabela acima está sujeita a alterações e descreve cenários de suporte comuns. Quaisquer cenários relacionados à funcionalidade e aos componentes do Kubernetes não são compatíveis com o N-3. Para obter mais suporte, consulte Suporte e solução de problemas para o AKS.
Versõeskubectl compatíveis
Você pode usar uma versão secundária mais antiga ou mais recente de kubectl em relação à sua versão do kube-apiserver, consistente com a política de suporte do Kubernetes para o kubectl.
Por exemplo, se o seu Kube-apiserver estiver na versão 1.28, você poderá usar as versões 1.27 a 1.29 do kubectl com o Kube-apiserver em questão.
Para instalar ou atualizar kubectl para a versão mais recente, execute:
az aks install-cli
LTS (suporte de longo prazo)
O AKS fornece um ano de suporte à comunidade e um ano de suporte de longo prazo (LTS) para apoiar correções de segurança de porta da comunidade upstream no nosso repositório público. Nosso grupo de trabalho LTS upstream contribui com esforços de volta para a comunidade a fim de fornecer aos nossos clientes uma janela de suporte mais longa.
Para obter mais detalhes sobre o LTS, consulte Suporte de longo prazo para o AKS (Serviço de Kubernetes do Azure).
Processo de liberação e de deprecação
Você pode consultar lançamentos de versões e deprecações futuras no Calendário de lançamento do AKS Kubernetes.
Para novas versões secundárias do Kubernetes:
- A AKS publica um comunicado com a data planejada de um novo lançamento de versão e a respectiva deprecação da versão antiga nas Notas sobre a versão do AKS pelo menos 30 dias antes da remoção.
- O AKS usa o Assistente do Azure para alertar você se uma nova versão pode causar problemas no cluster devido a APIs preteridas. O Assistente do Azure também alerta se você não tiver suporte
- O AKS publica uma notificação de integridade do serviço disponível para todos os usuários com acesso ao portal e do AKS e envia um email para os administradores de assinatura com as datas de remoção da versão planejada.
Observação
Para descobrir quem são os administradores da sua assinatura ou alterá-lo, confira Gerenciar assinaturas do Azure.
- Você tem 30 dias desde a remoção da versão até a atualização para uma versão secundária com suporte 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 no Azure à medida que se tornam disponíveis. Depois de disponíveis, os patches têm um ciclo de vida mínimo de dois meses.
- Em geral, o AKS não comunica de maneira ampla o lançamento das novas versões de patch. No entanto, o AKS monitora e valida constantemente os patches de CVE disponíveis para dar suporte a eles em AKS em tempo hábil. Se for encontrado um patch crítico ou se for necessária uma ação do usuário, o AKS o notificará para fazer upgrade para o patch recém-disponível.
- Você tem 30 dias após a remoção de uma versão de patch do AKS para fazer a atualização para um patch compatível e continuar recebendo suporte. No entanto, não será mais possível criar clusters ou pools de nós depois que a versão for preterida/removida.
Exceções de política de versões com suporte
O AKS reserva o direito de adicionar ou remover versões novas/existentes com um ou mais bugs críticos que afetam a produção ou problemas de segurança sem aviso prévio.
As versões de patch específicas podem ser ignoradas ou ter a distribuição acelerada, dependendo da severidade do bug ou do problema de segurança.
Versões de CLI e portal do Azure
Ao implantar um cluster do AKS com o portal do Azure, a CLI do Azure, o Azure PowerShell, o cluster usa como padrão a versão secundária N-1 e o último patch. Por exemplo, se o AKS der suporte às versões 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á a 1.28.7.
Para descobrir quais versões estão disponíveis atualmente para sua assinatura e região, use o comando az aks get-versions. 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
Perguntas frequentes
Como a Microsoft me notificará sobre as 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, no GitHub e em e-mails para administradores de assinatura que possuem clusters que ficarão sem suporte. O AKS também usa o Assistente do Azure para alertá-lo no portal do Azure se você estiver sem suporte e informá-lo sobre APIs obsoletas que podem afetar seu aplicativo ou processo de desenvolvimento.
Com que frequência devo esperar para atualizar as versões do kubernetes para manter o suporte?
A partir do Kubernetes 1.19, a comunidade de código aberto expandiu o suporte para um ano. O AKS confirma a habilitação de patches e o suporte correspondentes aos compromissos upstream. Para os clusters do AKS da versão 1.19 e superior, você pode atualizar, no mínimo, uma vez por ano para permanecer em uma versão compatível.
O que acontece quando você atualiza um cluster do Kubernetes com uma versão secundária sem suporte?
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 atualização da versão n-3 para a n-2 tiver êxito, você voltará para nossas políticas de suporte. Por exemplo:
- Se a versão mais antiga do AKS com suporte for 1.27 e você estiver na versão 1.26 ou anterior, estará fora do suporte.
- Ao fazer com sucesso a atualização da versão 1.26 para a versão 1.27 ou superior, você estará novamente dentro das nossas políticas de suporte.
Não há suporte para fazer downgrade.
O que significa "fora do suporte"?
'Fora do suporte' significa que:
- A versão que você está executando está fora da lista de versões compatíveis.
- Você precisará atualizar o cluster para uma versão compatível ao solicitar o suporte, a menos que esteja dentro do período de cortesia de 30 dias após a versão ter sido preterida.
Além disso, o AKS não torna nenhum tempo de execução nem outras garantias para clusters fora da lista de versões com suporte.
O que acontece quando você escala um cluster do Kubernetes com uma versão secundária sem suporte?
Para as versões secundárias sem suporte do AKS, a redução ou a escala horizontal deve continuar funcionando. Como não há garantias de qualidade de serviço, recomendamos a atualização para colocar seu cluster de volta ao suporte.
Você pode permanecer em uma versão do Kubernetes para sempre?
Se um cluster tiver estado sem suporte por mais de três (3) versões secundárias e tiver sido considerado com riscos de segurança, o Azure entrará em contato com você de maneira proativa para atualização do cluster. Se você não executar outras ações, o Azure reservará o direito de atualizar automaticamente o cluster em seu nome.
O que acontece se você escala um cluster do Kubernetes com uma versão secundária sem suporte?
Para as versões secundárias sem suporte do AKS, a redução ou a escala horizontal deve continuar funcionando. Como não há garantias de qualidade de serviço, recomendamos a atualização para colocar seu cluster de volta ao suporte.
A qual versão do plano de controle dá suporte quando o pool do nó não está em uma das versões com suporte do AKS?
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 pools de nós, visite a documentação sobre como Atualizar pools de nós.
Qual é a diferença permitida nas versões entre o painel de controle e o pool de nós?
A política de distorção de versão agora permite uma diferença de até três versões entre o plano de controle e os pools de agentes. O AKS segue essa alteração de política de versão distorcida a partir da versão 1.28 em diante.
Posso ignorar várias versões do AKS durante a atualização do cluster?
Ao atualizar um cluster do AKS com suporte, as versões secundárias do Kubernetes não podem ser ignoradas. A política de distorção de versão dos painéis de controle do Kubernetes não dá suporte a ignorar a versão secundária. Por exemplo, as atualizações entre:
- 1.28.x a >1.29.x: permitidas.
- 1.27.x a >1.28.x: permitidas.
- 1.27.x a >1.29.x: não permitidas.
Observe que, para atualizações de versão do plano de controle, você pode adquirir até 3 versões secundárias para versões com suporte da comunidade de forma sequencial.
Para fazer a atualização das versões 1.27.x a >1.29.x:
- Atualização das versões 1.27.x a >1.28.x.
- Atualização das versões 1.28.x a >1.29.x.
Observação: a partir da versão 1.28 em diante, as versões do agentpool podem ser 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 estiver muito atrasada em relação à versão mínima suportada, talvez seja necessário 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 seu plano de controle for 1.23.x e você pretende atualizar para uma versão mínima suportada de 1.27.x por 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 estiver em1.27.x. Ao atualizar no local, ou seja, o plano de controle e o pool de agentes juntos, as mesmas regras aplicáveis à atualização do plano de controle escritas acima se aplicam.
Ao realizar uma atualização de uma versão sem suporte, a atualização é realizada sem nenhuma garantia de funcionalidade e é excluída do contrato de nível de serviço e da garantia limitada. Os clusters que executam versão sem suporte têm a flexibilidade de desacoplar atualizações do plano de controle com atualizações do pool de nós. No entanto, se a sua versão está muito desatualizada, é recomendável recriar 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 usando uma versão recentemente obsoleta que não tem mais suporte na plataforma. Ainda posso adicionar novos pools de nós? Ou precisarei fazer a atualização?
Sim, você pode adicionar pools de agentes, desde que eles sejam compatíveis com a versão do plano de controle.
Próximas etapas
Para obter informações sobre como fazer upgrade do seu cluster, consulte:
Azure Kubernetes Service