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,26 | Dezembro de 2022 | Fevereiro de 2023 | Abril de 2023 | Março de 2024 | Até 1,30 GA |
| 1,27* | Abril de 2023 | Junho de 2023 | Julho de 2023 | Julho de 2024, LTS até julho de 2025 | Até 1,31 GA |
| 1.28 | Agosto de 2023 | Setembro de 2023 | nov. de 2023 | Novembro de 2024 | Até 1,32 GA |
| 1.29 | dez. de 2023 | fev. de 2024 | Março de 2024 | Até 1,33 GA | |
| 1.30 | Abril de 2024 | Maio de 2024 | Junho de 2024 | Até 1.34 GA |
* Indica que a versão é designada para Suporte de Longo Prazo
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:
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:
| Versão do Kubernetes | Complementos gerenciados do AKS | Componentes do AKS | Componentes do SO | Alterações de quebra | Observações |
|---|---|---|---|---|---|
| 1,26 | Política do Azure 1.3.0 Servidor de Métricas 0.6.3 KEDA 2.10.1 Malha de Serviço Aberto 1.2.3 DNS Principal V1.9.4 Sobreposição VPA 0.11.0 Azure-Keyvault-SecretsProvider 1.4.1 AGIC (Controlador de Entrada do Gateway de Aplicativo) 1.5.3 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 KMS 0.5.0 azurefile-csi-driver 1.26.10 |
Cilium 1.12.8 CNI 1.4.44 Dimensionamento automático do cluster 1.8.5.3 |
Imagem do SO Ubuntu 22.04 Cgroups V2 ContainerD 1.7 Azure Linux 2.0 Cgroups V1 ContainerD 1.6 |
azurefile-csi-driver 1.26.10 | Nenhum |
| 1.27 | Política do Azure 1.3.0 azuredisk-csi driver v1.28.5 azurefile-csi driver v1.28.7 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 Servidor de Métricas 0.6.3 Keda 2.11.2 Malha de Serviço Aberto 1.2.3 DNS Principal V1.9.4 Sobreposição VPA 0.11.0 Azure-Keyvault-SecretsProvider 1.4.1 AGIC (Controlador de Entrada do Gateway de Aplicativo) 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 Driver de armazenamento de Segredos da CSI 1.3.4-1 |
Cilium 1.13.10-1 CNI 1.4.44 Dimensionamento automático do 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. |
| 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 snapshot-controller v6.2.2 Servidor de Métricas 0.6.3 KEDA 2.11.2 Open Service Mesh 1.2.7 DNS Principal V1.9.4 Sobreposição da VPA 0.13.0 Azure-Keyvault-SecretsProvider 1.4.1 AGIC (Controlador de Entrada do Gateway de Aplicativo) 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 Driver de armazenamento de Segredos da CSI 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 Nível Baixo do 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 da CNI do Azure) Dimensionador 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 |
Nenhum |
| 1.29 | Política do Azure 1.3.0 csi-provisioner v4.0.0 csi-attacher v4.5.0 csi-snapshotter v6.3.3 snapshot-controller v6.3.3 Servidor de Métricas 0.6.3 KEDA 2.11.2 Open Service Mesh 1.2.7 DNS Principal V1.9.4 Sobreposição da VPA 0.13.0 Azure-Keyvault-SecretsProvider 1.4.1 AGIC (Controlador de Entrada do Gateway de Aplicativo) 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 1.3.81 Identidade do pod do Azure Active Directory 1.8.13.6 GitOps 1.8.1 Driver de armazenamento de Segredos da CSI 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 da CNI do Azure) Dimensionador Automático de Cluster 1.27.3 Tigera-Operator 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 V1 ContainerD 1.6 |
Tigera-Operator 1.30.7 csi-provisioner v4.0.0 csi-attacher v4.5.0 csi-snapshotter v6.3.3 snapshot-controller v6.3.3 |
Nenhum |
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 também dá suporte a um máximo de dois patches estáveis.
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 também dá suporte para um máximo de duas versões de patch de uma versão secundária. Por exemplo, dadas as seguintes versões com suporte:
Current Supported Version List
------------------------------
1.29.2, 1.29.1, 1.28.7, 1.28.6, 1.27.11, 1.27.10
Se AKS versões 1.29.3 e 1.28.8 as versões mais antigas do patch forem preteridas e removidas, e a lista de versões com suporte se tornar:
New Supported Version List
----------------------
1.29.3, 1.29.2, 1.28.8, 1.28.7, 1.27.11, 1.27.10
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 | Sem suporte |
| Criação do cluster ou pool de nós | Com suporte | Sem suporte |
| Instantâneo do pool de nós | Com suporte | Sem suporte |
| Atualização da imagem do nó | Com suporte | Sem 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.
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.
Ignorar várias versões só pode ser feito ao atualizar de uma versão sem suporte de volta para a versão mínima com suporte. Por exemplo, você pode fazer a atualização de um cluster 1.25.x sem suporte para um cluster 1.27.x com suporte se 1.27 for a versão secundária mínima com suporte.
Ao executar uma atualização de uma versão incompatível que ignora duas ou mais versões secundárias, a atualização é executada sem garantia de funcionalidade e é excluída dos contratos de nível de serviço e da garantia limitada. Os clusters que executam uma versão incompatível têm a flexibilidade de desacoplar atualizações do painel de controle com atualizações de 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 sua janela de suporte de 30 dias?
Não. 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 implantada, você começará a ver a versão antiga removida da sua lista de versões. Esse processo pode levar até duas semanas a partir do comunicado, progressivamente por região.
Estou em uma versão reprovada, ainda posso adicionar novos pools de nós? Ou precisarei fazer a atualização? Ou precisarei fazer a atualização?
Não. Você não tem permissão para adicionar pools de nós da versão obsoleta ao seu cluster. É permitida a criação ou atualização de pools de nós na versão do plano de controle da versão incompatível, independentemente da diferença de versão entre o pool de nós e o plano de controle. Somente atualizações secundárias de alias são permitidas.
Qual é a frequência de atualização dos patches?
Os patches têm um ciclo de vida mínimo de dois meses. Para se manter atualizado quando novos patches forem lançados, siga as Notas sobre a versão do AKS.
Próximas etapas
Para obter informações sobre como fazer upgrade do seu cluster, consulte: