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.
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 dentro de uma versão menor. 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 secundárias.
- 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 menor que você está executando. 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 oferece 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.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 | Abril de 2025 | Março 2026 | Até 1,36 GA |
Versões LTS
Observação
O Azure Linux oferece suporte apenas à versão 1.27 LTS. Para obter mais informações sobre o 1.30 LTS com o Azure Linux, leia a seção Versões do AKS LTS do Azure Linux .
| 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.28 | Agosto de 2023 | Setembro de 2023 | nov. de 2023 | Janeiro de 2025 | Fevereiro de 2026 |
| 1.30 | Abril de 2024 | Junho de 2024 | Julho de 2024 | Julho de 2025 | julho 2026 |
Gráfico de Gantt do cronograma de versões do AKS Kubernetes
Se você preferir ver essas informações visualmente, aqui está um gráfico de Gantt com todas as versões atuais exibidas:
Alterações interruptivas dos componentes do AKS por versão
Observe as seguintes alterações importantes antes de atualizar para qualquer uma das versões secundárias disponíveis:
Kubernetes 1.32
| Complementos gerenciados pelo AKS | Componentes AKS | Componentes do SO | Alterações interruptivas | Observações |
|---|---|---|---|---|
| • Azure Policy 1.8.0 • Métricas-Servidor 0.6.3 • Operador de roteamento de aplicativo v0.2.3 • KEDA 2.14.1 • Open Service Mesh v1.2.9 • DNS principal V1.9.4 • Sobreposição VPA 1.0.0 • Azure-Keyvault-SecretsProvider v1.4.5 • Controlador de entrada de Gateway de Aplicativo (AGIC) 1.7.2 • Limpador de Imagens v1.3.1 • Identidade da carga de trabalho do Azure v1.3.0 • Coletor de Nível Baixo do MDC Defender 2.0.186 • open-policy-agent-gatekeeper v3.17.1 • Retina v0.0.17 |
• Cilium v1.17.0 • Dimensionador automático de cluster v1.30.6-aks • Tigera-Operator v1.34.7 |
• Imagem do Sistema Operacional Ubuntu 22.04 Cgroups V2 • ContainerD 1.7.23-ubuntu22.04u1 para Linux e v1.6.35+azure para Windows • Azure Linux 3.0 • Cgroups V2 • ContainerD 1.7.13-3.azl |
• Calico v1.34.7 | Não aplicável |
Kubernetes 1.31
| Complementos gerenciados pelo AKS | Componentes AKS | Componentes do SO | Alterações interruptivas | Observações |
|---|---|---|---|---|
| • Azure Policy 1.8.0 • Métricas-Servidor 0.6.3 • Operador de roteamento de aplicativo v0.2.3 • KEDA 2.14.1 • Open Service Mesh v1.2.9 • DNS principal V1.9.4 • Sobreposição VPA 1.0.0 • Azure-Keyvault-SecretsProvider v1.4.5 • Controlador de entrada de Gateway de Aplicativo (AGIC) 1.7.2 • Limpador de Imagens v1.3.1 • Identidade da carga de trabalho do Azure v1.3.0 • Coletor de Nível Baixo do MDC Defender 2.0.186 • open-policy-agent-gatekeeper v3.17.1 • Retina v0.0.17 |
• Cilium v1.16.6 • Dimensionador automático de cluster v1.30.6-aks • Tigera-Operator v1.30.11 |
• Imagem do Sistema Operacional Ubuntu 22.04 Cgroups V2 • ContainerD 1.7.23-ubuntu22.04u1 para Linux e v1.6.35+azure para Windows • Azure Linux 3.0 • Cgroups V2 • ContainerD 1.7.13-3.azl |
• Calico 1.30.11 | Não aplicável |
Kubernetes 1.30
| Complementos gerenciados pelo AKS | Componentes AKS | Componentes do SO | Alterações interruptivas | Observações |
|---|---|---|---|---|
| • Azure Policy 1.3.0 • Operador de roteamento de aplicativo v0.2.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 • MDC Defender Security Publisher 1.0.68 • Limpador de arquivos antigos do MDC Defender 1.3.68 • Coletor de pods do MDC Defender 1.0.78 • Coletor de Nível Baixo do MDC Defender 2.0.186 • Identidade do Pod do Azure Active Directory 1.8.13.6 • GitOps 1.8.1 • Driver de Repositório de Segredos do CSI 1.3.4-1 • azurefile-csi-driver 1.29.3 |
• Cilium v1.14.9 • CNI v1.4.43.1 (padrão)/v1.5.11 (Sobreposição CNI do Azure) • Escalonador Automático de Grupos 1.27.3 • Tigera-Operador 1.30.7 |
• Imagem do Sistema Operacional 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 | Não aplicável |
Kubernetes 1.29
| Complementos gerenciados pelo AKS | Componentes AKS | Componentes do SO | Alterações interruptivas | Observações |
|---|---|---|---|---|
| • Azure Policy 1.3.0 • csi-provisioner v4.0.0 • Operador de roteamento de aplicativo v0.2.1 • csi-attacher v4.5.0 • csi-snapshotter v6.3.3 • snapshot-controller 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 • MDC Defender Security Publisher 1.0.68 • Limpador de arquivos antigos do MDC Defender 1.3.68 • Coletor de pods do MDC Defender 1.0.78 • Coletor de Nível Baixo do MDC Defender 2.0.186 • Identidade do Pod do Azure Active Directory 1.8.13.6 • GitOps 1.8.1 • Driver de Repositório de Segredos do CSI 1.3.4-1 • azurefile-csi-driver 1.29.3 |
• Cilium v1.14.9 • CNI v1.4.43.1 (padrão)/v1.5.11 (Sobreposição CNI do Azure) • Escalonador Automático de Grupos 1.27.3 • Tigera-Operador 1.30.7 |
• Imagem do Sistema Operacional 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 • snapshot-controller v6.3.3 |
Não aplicável |
Versão secundária do alias
Observação
A versão menor do Alias requer a CLI do Azure versão 2.37 ou superior e 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 menor. Por exemplo, se você criar um cluster com 1.29 e 1.29.2 for o patch em GA mais recente disponível, seu cluster será criado com 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 versão secundária em GA mais recente lançada no AKS (à qual nos referimos como N).
- Duas versões menores anteriores.
- Cada versão menor com suporte pode suportar qualquer número de patches ao mesmo tempo. O AKS se reserva o direito de preterir patches se uma CVE ou vulnerabilidade críticas forem detectadas. Para saber mais sobre a disponibilidade de patch e qualquer substituição ad hoc, consulte as notas de versão da versão e visite a página da Web de status de versão 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 em GA do Kubernetes após as versões regulares com suporte. 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 menor | 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 com 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 encorajado a usar o patch mais recente para uma versão menor.
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 em GA do AKS com suporte), 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 v1.30-GA, a v1.26 deverá ser atualizada automaticamente para 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 de suporte | Suporte da Comunidade (N-2) | Suporte da Plataforma (N-3) |
|---|---|---|
| Atualizações do N-3 para uma versão suportada | Suportado | Suportado |
| Disponibilidade da plataforma (Azure) | Suportado | Suportado |
| Escala do pool de nós | Suportado | Suportado |
| Disponibilidade da VM | Suportado | Suportado |
| Problemas relacionados ao armazenamento e à rede | Suportado | Com suporte, exceto para correções de bugs e componentes desativados |
| Iniciar/parar | Suportado | Suportado |
| Girar certificados | Suportado | Suportado |
| SLA de infraestrutura | Suportado | Suportado |
| Plano de controle do SLA | Suportado | Suportado |
| SLA da Plataforma (AKS) | Suportado | Sem suporte |
| Componentes do Kubernetes (incluindo Complementos) | Suportado | Sem suporte |
| Atualizações de componentes | Suportado | Sem suporte |
| Hotfixes de componentes | Suportado | Sem suporte |
| Aplicação de correções de bugs | Suportado | Sem suporte |
| Aplicação de patches de segurança | Suportado | Sem suporte |
| Suporte à API do Kubernetes | Suportado | Sem suporte |
| Criação do pool de nós | Suportado | Suportado |
| Criação do cluster | Suportado | Sem suporte |
| Instantâneo do pool de nós | Suportado | Sem suporte |
| Atualização da imagem do nó | Suportado | Suportado |
Observação
A tabela está sujeita a alterações e descreve cenários comuns de suporte. 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 suportadas
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 LTS (Suporte de Longo Prazo) para apoiar correções de segurança de porta da comunidade upstream em nosso repositório público. Nosso grupo de trabalho upstream LTS contribui com esforços para a comunidade para fornecer aos nossos clientes uma janela de suporte mais longa.
Para obter mais informações sobre LTS, consulte suporte de longo prazo para o AKS (Serviço de Kubernetes do Azure).
Processo de liberação e de desativação
Você pode consultar lançamentos de versões e descontinuações futuras no Calendário de lançamento do AKS Kubernetes.
Para novas versões secundárias do Kubernetes:
- O AKS anuncia a data de lançamento planejada de uma nova versão e a substituição da versão antiga nas Notas de 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
Se você implantar um cluster do AKS com o portal do Azure, a CLI do Azure, o Azure PowerShell, o cluster usará como padrão a versão secundária N-1 e o patch mais recente. 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 anuncia novas datas de lançamento da versão do Kubernetes em nossa documentação, no GitHub e por email para administradores de assinatura com clusters próximos ao fim do 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 precisa atualizar. Se a atualização da versão n-3 para n-2 for bem-sucedida, você estará de volta em 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.
- Se você atualizar com êxito de 1.26 para 1.27 ou superior, retornará às nossas políticas de suporte.
Não há suporte para fazer downgrade.
O que significa "fora de 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 oferece garantias de funcionamento nem outras garantias para clusters fora da lista de versões suportadas.
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 não tiver suporte para mais de três versões secundárias e apresentar riscos de segurança, o Azure entrará em contato proativamente com você. Eles aconselharão você a atualizar seu 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.
Qual versão é compatível com o plano de controle se o pool de nós não estiver em uma das versões de AKS compatíveis?
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 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?
Se você atualizar um cluster AKS com suporte, as versões secundárias do Kubernetes não poderão 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 ->1.28.x: permitido.
- 1.27.x a >1.29.x: não permitidas.
Para atualizações de versão do painel de controle, você pode acessar até três 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é três versões mais antigas para versões do plano de controle por política de distorção de versão. Se sua versão estiver muito atrás da versão mínima com suporte, talvez seja necessário fazer mais de uma operação de atualização do plano de controle para chegar à versão mínima com suporte. 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. 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 painel 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 o painel de controle in-loco e o pool de agentes juntos, as mesmas regras aplicáveis à atualização do plano de controle se aplicam.
Ao executar uma atualização de uma versão não suportada, a atualização é feita sem qualquer garantia de funcionalidade e é excluída dos acordos 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 sua versão estiver desatualizada, recomendamos 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 à Plataforma.
Estou usando uma versão preterida recentemente que não tem mais suporte na plataforma. Ainda posso adicionar novos pools de nós? Ou devo atualizar?
Sim, você pode adicionar pools de agentes desde que eles sejam compatíveis com a versão do painel de controle.
Próximas etapas
Para obter informações sobre como fazer upgrade do seu cluster, consulte:
Colaborar conosco no GitHub
A fonte deste conteúdo pode ser encontrada no GitHub, onde você também pode criar e revisar problemas e solicitações de pull. Para obter mais informações, confira o nosso guia para colaboradores.
Azure Kubernetes Service