Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este documento fornece uma visão geral do esquema de controle de versão usado para o serviço Operator Nexus Kubernetes, incluindo as versões suportadas do Kubernetes. Ele explica as diferenças entre as versões principal, secundária e de patch, e fornece orientação sobre como atualizar as versões do Kubernetes e o que esperar da experiência de atualização. Ele também cobre o ciclo de vida de suporte de versão, incluindo o fim do suporte para cada pacote de versão. Os recursos, anteriormente conhecidos como Add-ons, são componentes de software incluídos em cada pacote de versão. A versão dos componentes e as alterações de quebra articulam as versões de recursos incluídas nos pacotes de versões. Para obter informações mais detalhadas sobre recursos, consulte Recursos de cluster do Nexus Kubernetes.
A comunidade do Kubernetes lança versões secundárias a cada três meses. A partir da versão 1.19, a comunidade Kubernetes aumentou a janela de suporte para cada versão de nove meses para um ano.
As versões secundárias podem incluir novos recursos e/ou 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.24.7
1.25.4
Cada número na versão indica compatibilidade geral com a versão anterior:
- Os números de versão principais mudam quando alterações significativas na API podem ser introduzidas
- Os números de versão secundária mudam quando são feitas atualizações de funcionalidade que são compatíveis com lançamentos anteriores das outras versões secundárias.
- Os números de versão do patch mudam quando correções de bugs compatíveis com versões anteriores são feitas.
Recomendamos vivamente que se mantenha atualizado com os patches mais recentes disponíveis. Por exemplo, se o cluster de produção estiver ativado 1.25.4e 1.25.6 for a versão de patch mais recente disponível para a série 1.25 . Você deve atualizar para o 1.25.6 mais rápido possível para garantir que seu cluster seja totalmente corrigido e suportado. Mais detalhes sobre como atualizar seu cluster podem ser encontrados na documentação Atualizando versões do Kubernetes.
Calendário de lançamento do Nexus Kubernetes
Veja os próximos lançamentos de versões no calendário de lançamentos do Nexus Kubernetes.
Observação
Leia mais sobre nossa política de suporte para versionamento do Kubernetes.
Para obter o histórico de lançamentos anteriores, consulte Histórico do Kubernetes.
| Versão K8s | Nexo GA | Fim da vida útil | LTS Fim da vida útil | Disponibilidade estendida |
|---|---|---|---|---|
| 1.27 | Setembro 2023 | Julho de 2024 | Julho 2025 | NA |
| 1.28 | Novembro 2023 | Janeiro de 2025 | NA | Até ao final de outubro de 2025 |
| 1.29 | Agosto de 2024 | Março 2025 | NA | Até final de fevereiro de 2026 |
| 1.30 | Outubro de 2024 | Julho 2025 | Julho 2026 | NA |
| 1.31 | Março 2025 | Novembro 2025 | Novembro 2026 | NA |
| 1.32 | Abr 2025 | Março 2026 | Março 2027 | NA |
| 1.33 | Julho 2025 | jun 2026 | jun 2027 | NA |
Observação
A partir da versão 1.30 do Kubernetes, todas as versões do Nexus Kubernetes serão compatíveis com LTS.
Componentes da versão de serviço do Nexus Kubernetes
Uma versão do serviço Operator Nexus Kubernetes é composta por dois componentes discretos que são combinados em uma única representação:
- A versão do Kubernetes. Por exemplo, 1.25.4 é a versão do Kubernetes que você implanta no Operator Nexus. Esses pacotes são fornecidos pelo Azure AKS, incluindo todas as versões de patch suportadas pelo Operator Nexus. Para obter mais informações sobre as versões do Azure AKS, consulte Versões do Kubernetes suportadas pelo AKS
- Um número de pacote de versão que encapsula a versão, os recursos e a imagem do sistema operacional (SO) do Kubernetes usados pelos nós no cluster Kubernetes do Operator Nexus, como um único número. Por exemplo, 2.†
A combinação desses valores é representada na API como o único kubernetesVersion. Por exemplo, 1.25.4-2 ou a notação alternativamente suportada v : v1.25.4-2.
† A partir de abril de 2025, os incrementos do pacote de versões foram alterados para incluir versionamento de versão em vez de numeração sequencial para fornecer distinção de lançamento para lançamento em um piscar de olhos. Continue lendo para obter mais informações sobre essa mudança.
Pacotes de versões
Um pacote de versão é um valor secundário adicionado à versão do Kubernetes. Os pacotes de versão levam em conta os casos em que a versão do Kubernetes não é alterada, mas o sistema operacional e/ou os recursos são atualizados com uma versão do Nexus. Essas atualizações podem incluir, mas não estão limitadas a: imagens atualizadas do sistema operacional, versões de patches para Recursos e a introdução de novos Recursos da plataforma.
Antes de abril de 2025, os números do pacote de versão eram incrementados a partir de e variavam dependendo de quanto tempo uma determinada versão do 1 patch do Kubernetes estava disponível no Nexus. Após abril de 2025, todos os pacotes de versão na mesma versão são numerados com o mesmo identificador de versão, por exemplo -4.4.0 ou -4.5.0. O gráfico abaixo detalha quais pacotes de versão estão na mesma série.
Os pacotes de versão dão aos usuários a capacidade de planejar e gerenciar o processo de atualização de seus clusters Kubernetes oferecidos pelo serviço Operator Nexus Kubernetes.
Todas as atualizações de cluster do Nexus seguem a política de distorção de versões padrão do Kubernetes. Em alguns casos, mais de uma atualização pode ser necessária para trazer um cluster para a versão desejada do Kubernetes. Pular qualquer versão do pacote de versão é aceito, no entanto, você não pode fazer o downgrade para uma série de pacotes de versão anterior.
As alterações na configuração de um cluster Kubernetes do Operator Nexus implantado só devem ser aplicadas dentro de uma atualização de versão secundária do Kubernetes, não durante uma atualização de versão de patch. Exemplos de alterações de configuração que podem ser aplicadas durante a atualização da versão secundária incluem:
- Alterando a configuração do kube-proxy de usar o iptables para ipvs.
- Alterar a interface de rede de contêiner (CNI) de um produto para outro.
Escolhendo um pacote de versão para um cenário de atualização
Permitimos a atualização de qualquer versão de patch em uma versão secundária do Kubernetes para qualquer versão de patch na próxima versão secundária do Kubernetes, dando-lhe flexibilidade. Por exemplo, uma atualização de 1.31.1-x.x.x para 1.32.x-x.x.x seria permitida, independentemente da presença de uma versão intermediária 1.31.2-x.x.x.
Quando novos pacotes de versão são lançados, todas as versões de patch do Kubernetes nesse lançamento do pacote de versão usam as mesmas versões do sistema operativo e das funcionalidades; apenas o código do Kubernetes difere entre elas. Vejamos alguns exemplos de rotas de atualização que podem ser desejáveis:
Atualização da versão do Kubernetes
Para corrigir ou atualizar a versão secundária do Kubernetes, selecione uma versão disponível do Kubernetes da mesma série de pacotes de versão. Por exemplo, se 1.32.1-4.4.0 é o seu pacote de versão atual, e 1.33.1-4.4.0 é o pacote de versão 1.33.x mais recente, então você deve escolher 1.33.1-4.4.0.
Atualização da versão do SO e do componente
Para corrigir ou atualizar componentes do sistema operacional ou da plataforma mantendo a mesma versão do Kubernetes, selecione um pacote de versão dentro da mesma versão secundária do Kubernetes do cluster, mas com um número de versão posterior. Por exemplo, se 1.32.1-4.4.0 for o seu pacote de versão atual e 1.32.1-4.5.0 for o pacote de versão 1.32.1 mais recente, escolha o pacote 1.32.1-4.5.0.
Atualização das versões do Kubernetes, do sistema operativo e dos componentes
Para corrigir ou atualizar a versão do Kubernetes, a versão do sistema operacional e os componentes da plataforma juntos, selecione a versão de lançamento mais recente para a versão secundária subsequente do Kubernetes. Por exemplo, se 1.32.1-4.4.0 for o seu pacote de versão atual e o pacote de versão mais recente para a versão secundária subsequente do Kubernetes for 1.33.2-4.5.0, selecione 1.33.2-4.5.0 para atualizar todos os componentes.
Nos dois primeiros casos, talvez seja necessário aceitar uma versão atualizada do Kubernetes ou uma versão do componente se um pacote de versão contendo as atualizações desejadas não tiver sido lançado. Neste caso, qualquer versão secundária subsequente do Kubernetes funciona, mas o pacote de versão com a versão de lançamento mais recente é a versão mais up-toe segura dessa versão secundária do Kubernetes. A recomendação é escolher a versão de lançamento mais recente para um determinado pacote de versão.
Versão dos componentes e alterações significativas
Observe as seguintes alterações importantes a serem feitas antes de atualizar para qualquer uma das versões secundárias disponíveis:
- A versão azure-arc-k8sagents refere-se à versão deste recurso fornecida com o pacote de versão. O agente Kubernetes habilitado para Arc está configurado para atualizar automaticamente para a versão mais recente do agente sempre que estiver disponível.
- A partir da 4.6.0, a versão ipam-cni-plugin reflete a versão interna do aplicativo (4.6.0-32) versus a versão do gráfico (1.0.10). Para a versão 4.6.0, ambos são mostrados por uma questão de transição.
Atenção
Os usuários não devem atualizar um pacote de versão do Nexus AKS da versão 4.3.0 ou anterior para um pacote de versão 4.6.0 ou posterior sem primeiro atualizar para o pacote de versão 4.4.0 ou 4.5.0. Há um bug externo do etcd que afeta as atualizações da versão etcd v3.5 para v3.6. Há uma alta probabilidade de que uma atualização do Nexus Kubernetes v4.3.0 ou anterior para a v4.6.0 ou posterior falhe devido a esse problema etcd. Detalhes do bug etcd podem ser encontrados aqui Como evitar uma falha comum ao atualizar etcd v3.5 para v3.6.
Para mitigar esse possível problema de atualização, os usuários são aconselhados a executar uma atualização em duas etapas. O cluster deve primeiro ser atualizado para um pacote de versão que é produzido nos lançamentos 4.4 ou 4.5. Em seguida, ele pode ser atualizado para um novo pacote de versão a partir de 4.6 ou 4.7. Aqui está um resumo simplificado do caminho de atualização recomendado: 
Por exemplo, um usuário tem um cluster que está atualmente no pacote de versão v1.30.8-4.3.0 e deseja atualizar para uma versão do Kubernetes disponível na versão 4.7 (v1.31 para n+1). O usuário deve primeiro atualizar o cluster para o pacote de versão v1.31.10-4.5.0. Em seguida, o usuário pode executar uma atualização subsequente para o pacote de versão v1.31.12-4.7.0. O caminho de atualização neste cenário é: 
Informações sobre o pacote da versão atual
A partir da versão 4.8.0, os recursos que possuem tanto uma versão da aplicação quanto uma versão do gráfico têm ambas listadas na tabela de referência. O formato é app version/chart version. Esta atualização permite mapear as versões dos gráficos para as versões dos aplicativos. Os utilizadores podem ver as versões dos gráficos das funcionalidades no output dos comandos 'create' e 'update' do Nexus Kubernetes. Os links externos para as notas de versão dos recursos são baseados na versão do aplicativo, quando disponível.
azure-arc-k8sagent é uma exceção. O manifesto do gráfico tem as versões invertidas, de modo que a versão do aplicativo aparece na versão do gráfico e vice-versa. Para fins de consistência, a tabela de referência reflete as versões onde devem ser exibidas.
Se um recurso tiver o mesmo valor para as versões do aplicativo e do gráfico, isso indica que a versão do gráfico é a única versão disponível.
OS Image, coredns image, etcd image, kube-vip image, e pause image basta ter o identificador de versão da imagem.
Para ajudar na legibilidade, os dois pacotes de versão mais recentes estão incluídos na seção da versão atual. As versões mais antigas estão listadas na seção Informações do pacote de versões mais antigas.
| Versão do Kubernetes | Identificador de versão | Imagem do SO | azure-arc-k8sagents | azure-arc-servers | calico | cloud-provider-kubevirt | imagem coredns | csi-nfs | csi-volume | imagem etcd | ipam-cni-plugin | imagem kube-vip | metallb | metrics-server | multus | node-local-dns | Pausar imagem | sriov-dp |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| v1.30.13 v1.30.14 v1.31.12 v1.31.13 v1.32.8 v1.32.9 v1.33.4 v1.33.5 |
4.8.0 | Azure Linux 3.0.20250910 | 1.30.1/1.0 | v1.2.5/v1.2.5 | v3.29.2/v1.8.0 | 0.5.1-1.3.0.20250702/v1.0.8 | v1.12.1-4 | v4.12.1/4.8.0-26 | 4.8.0-26/4.8.0-26 | v3.6.3-2 | 4.8.0-143/v1.0.12 | v1.0.0-2 | v0.14.9-3/v1.3.4 | v0.8.0-2/v1.0.7 | v4.0.2/v1.4.5 | 1.26.0-3/v1.2.3 | 3.10-5 | v3.7.0/v1.1.8 |
| v1.30.13 v1.30.14 v1.31.11 v1.31.12 v1.32.7 v1.32.8 v1.33.3 v1.33.4 |
4.7.0 | Azure Linux 3.0.20250729 | 1.29.3/1.0 | v1.2.4/v1.2.4 | v3.29.2/v1.8.0 | 0.5.1-1.3.0.20250602/v1.0.7 | v1.11.4-4 | v4.11.0/4.7.0-30 | 4.7.0-30/4.7.0-30 | v3.6.3-1 | 4.7.0-141/v1.0.11 | V0.9.2-2 | v0.14.9-2/v1.3.3 | v0.8.0-1/v1.0.6 | v4.0.2/v1.4.4 | 1.26.0-2/v1.2.2 | 3.10-4 | v3.7.0/v1.1.7 |
Informações sobre o pacote de versões mais antigas
Importante
O suporte à versão 1.27 LTS termina no final de 2025. O usuário deve atualizar seus clusters Nexus Kubernetes para pelo menos um pacote de versão 1.30 LTS. Se possível, atualize os clusters para a versão mais recente do Kubernetes. Estar na versão mais recente garante que novos recursos e atualizações de segurança estejam disponíveis.
| Versão do Kubernetes | Identificador de versão | Imagem do SO | azure-arc-k8sagents | azure-arc-servers | calico | cloud-provider-kubevirt | imagem coredns | csi-nfs | csi-volume | imagem etcd | ipam-cni-plugin | imagem kube-vip | metallb | metrics-server | multus | node-local-dns | Pausar imagem | sriov-dp |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| v1.33.2 v1.33.1 v1.32.6 v1.32.5 v1.31.10 v1.31.9 v1.30.14 v1.30.13 |
4.6.0 | Azure Linux 3.0.20250702-3.0 | 1.28.0 | v1.2.3 | v3.29.2 | 1.0.7 | v1.10.1-1 | v4.11.0 | 4.6.0-32 | v3.6.3-1 | 1.0.10/4.6.0-32 | V0.9.2-2 | v0.14.9-1 | v0.7.2-7 | v4.0.2 | 1.26.0-1 | 3.10-4 | v3.7.0 |
| v1.33.2 v1.33.1 v1.32.6 v1.32.5 v1.31.10 v1.31.9 v1.30.14 v1.30.13 |
4.5.0 | Azure Linux 3.0.20250702-3.0 | 1.27.0 | v1.2.2 | v3.29.2 | 1.0.7 | v1.10.1-1 | v4.11.0 | 4.5.0-48 | v3.5.21-2 | v1.0.9 | v0.8.9 | v0.14.9-1 | v0.7.2-7 | v4.0.2 | 1.26.0-1 | 3.10-3 | v3.7.0 |
| v1.32.4 v1.32.1 v1.31.8 v1.31.7 v1.30.12 v1.30.9 |
4.4.0 | Azure Linux 3.0.20250429-3.0 | 1.26.0 | v1.2.1 | v3.29.2 | 1.0.6 | v1.10.1-1 | v4.11.0 | 4.4.0-49 | v3.5.21-1 | v1.0.8 | v0.8.9 | v0.14.9-1 | v0.7.2 | v4.0.2 | 1.25.0-2 | 3.10-3 | v3.7.0 |
| v1.32.1 v1.31.5 v1.31.4 v1.30.9 v1.30.8 v1.29.13 v1.29.12 |
4.3.0 | v1.30.x e mais recente: Azure Linux 3.0.20250311-3.0 1.29.x e mais antigo: Azure Linux 2.0.20250304-2.0 |
1.24.4 | v1.2.0 | v3.29.2 | 1.0.5 | v1.9.4-4 | v4.11.0 | 4.3.0-45 | v3.5.15-1 | v1.0.7 | v0.8.5 | v0.14.5-9 | v0.7.2 | v4.0.2 | 1.23.1-1 | 3.1 | v3.7.0 |
| v1.31.4 v1.31.3 v1.30.8 v1.30.7 v1.29.12 v1.29.11 |
4.2.0 | v1.30.x e mais recente: Azure Linux 3.0.20250206-3.0 1.29.x e mais antigo: Azure Linux 2.0.20250207-2.0 |
1.23.3 | v1.1.0 | v3.29.1 | v1.0.4 | v1.9.4-4 | v4.10.0 | v1.0.13 | v3.5.15-1 | v1.0.5 | v0.8.5 | v0.14.5-7 | v0.7.2 | v4.0.2 | 1.23.1-1 | 3.1 | v3.7.0 |
| v1.31.3 | 1 | Azure Linux 3.0.20241005-3.0 | 1.22.4 | v1.1.0 | v3.29.1 | v1.0.4 | v1.9.4-4 | v4.9.0 | v1.0.11 | v3.5.15-1 | v1.0.5 | v0.8.5 | v0.14.5-7 | v0.7.2 | v4.0.2 | 1.23.1 | 3.1 | v3.7.0 |
| v1.30.7 | 1 | Azure Linux 3.0.20241005-3.0 | 1.22.4 | v1.1.0 | v3.29.1 | v1.0.4 | v1.9.4-4 | v4.9.0 | v1.0.11 | v3.5.15-1 | v1.0.5 | v0.8.5 | v0.14.5-7 | v0.7.2 | v4.0.2 | 1.23.1 | 3.1 | v3.7.0 |
| v1.30.5 | 2 | Azure Linux 3.0.20241005-3.0 | 1.22.4 | v1.1.0 | v3.29.1 | v1.0.4 | v1.9.4-4 | v4.9.0 | v1.0.11 | v3.5.15-1 | v1.0.5 | v0.8.5 | v0.14.5-7 | v0.7.2 | v4.0.2 | 1.23.1 | 3.1 | v3.7.0 |
| v1.30.5 | 1 | Azure Linux 3.0.20241005-3.0 | 1.21.10 | v1.1.0 | v3.28.2 | v1.0.3 | v1.9.4-hotfix.20240704 | v4.9.0 | v1.0.11 | v3.5.15 | v1.0.5 | v0.8.1 | v0.14.5-7 | v0.7.2 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.7.0 |
| v1.30.3 | 2 | Azure Linux 3.0.20241005-3.0 | 1.21.10 | v1.1.0 | v3.28.2 | v1.0.3 | v1.9.4-hotfix.20240704 | v4.9.0 | v1.0.11 | v3.5.15 | v1.0.5 | v0.8.1 | v0.14.5-7 | v0.7.2 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.7.0 |
| v1.30.3 | 1 | Azure Linux 3.0.20240824-3.0 | 1.21.10 | v1.1.0 | v3.27.4 | v1.0.3 | v1.9.4-hotfix.20240704 | v4.9.0 | v1.0.10 | v3.5.15 | v1.0.5 | v0.8.1 | v0.14.5-3 | v0.7.2 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.7.0 |
| v1.29.11 | 1 | Azure Linux 2.0.20241006-2.0 | 1.22.4 | v1.1.0 | v3.29.1 | v1.0.4 | v1.9.4-4 | v4.9.0 | v1.0.11 | v3.5.15-1 | v1.0.5 | v0.8.5 | v0.14.5-7 | v0.7.2 | v4.0.2 | 1.23.1 | 3.1 | v3.7.0 |
| v1.29.9 | 2 | Azure Linux 2.0.20241006-2.0 | 1.22.4 | v1.1.0 | v3.29.1 | v1.0.4 | v1.9.4-4 | v4.9.0 | v1.0.11 | v3.5.15-1 | v1.0.5 | v0.8.5 | v0.14.5-7 | v0.7.2 | v4.0.2 | 1.23.1 | 3.1 | v3.7.0 |
| v1.29.9 | 1 | Azure Linux 2.0.20241006-2.0 | 1.21.10 | v1.1.0 | v3.28.2 | v1.0.3 | v1.9.4-hotfix.20240704 | v4.9.0 | v1.0.11 | v3.5.15 | v1.0.5 | v0.8.1 | v0.14.5-7 | v0.7.2 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.7.0 |
| v1.29.7 | 4 | Azure Linux 2.0.20241006-2.0 | 1.21.10 | v1.1.0 | v3.28.2 | v1.0.3 | v1.9.4-hotfix.20240704 | v4.9.0 | v1.0.11 | v3.5.15 | v1.0.5 | v0.8.1 | v0.14.5-7 | v0.7.2 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.7.0 |
| v1.29.7 | 3 | Azure Linux 2.0.20240731-2.0 | 1.21.10 | v1.1.0 | v3.27.4 | v1.0.3 | v1.9.4-hotfix.20240704 | v4.9.0 | v1.0.10 | v3.5.15 | v1.0.5 | v0.8.1 | v0.14.5-3 | v0.7.2 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.7.0 |
| v1.29.7 | 2 | Azure Linux 2.0.20240731-2.0 | 1.21.10 | v1.1.0 | v3.27.4 | v1.0.3 | v1.9.4-hotfix.20240520 | v4.8.0 | v1.0.9 | v3.5.15 | v1.0.4 | v0.8.1 | v0.14.5-3 | v0.7.1 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.5.1 |
| v1.29.7 | 1 | Azure Linux 2.0.20240731-2.0 | 1.21.10 | v1.1.0 | v3.27.4 | v1.0.3 | v1.9.4-hotfix.20240520 | v4.8.0 | v1.0.9 | v3.5.15 | v1.0.4 | v0.8.1 | v0.14.5-3 | v0.7.1 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.5.1 |
| v1.29.6 | 4 | Azure Linux 2.0.20240731-2.0 | 1.21.10 | v1.1.0 | v3.27.4 | v1.0.3 | v1.9.4-hotfix.20240704 | v4.9.0 | v1.0.10 | v3.5.15 | v1.0.5 | v0.8.1 | v0.14.5-3 | v0.7.2 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.7.0 |
| v1.29.6 | 3 | Azure Linux 2.0.20240731-2.0 | 1.21.10 | v1.1.0 | v3.27.4 | v1.0.3 | v1.9.4-hotfix.20240520 | v4.8.0 | v1.0.9 | v3.5.15 | v1.0.4 | v0.8.1 | v0.14.5-3 | v0.7.1 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.5.1 |
| v1.29.6 | 2 | Azure Linux 2.0.20240731-2.0 | 1.21.10 | v1.1.0 | v3.27.4 | v1.0.3 | v1.9.4-hotfix.20240520 | v4.8.0 | v1.0.9 | v3.5.15 | v1.0.4 | v0.8.1 | v0.14.5-3 | v0.7.1 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.5.1 |
| v1.29.6 | 1 | Azure Linux 2.0.20240425-2.0 | 1.21.10 | v1.1.0 | v3.27.4 | v1.0.3 | v1.9.4-hotfix.20240520 | v4.7.0 | v1.0.8 | v3.5.15 | v1.0.4 | v0.8.1 | v0.14.5-3 | v0.7.1 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.5.1 |
| v1.29.4 | 1 | Azure Linux 2.0.20240425-2.0 | 1.21.10 | v1.1.0 | v3.27.4 | v1.0.3 | v1.9.4-hotfix.20240520 | v4.7.0 | v1.0.8 | v3.5.15 | v1.0.4 | v0.8.1 | v0.14.5-3 | v0.7.1 | v4.0.2 | 1.23.1 | 3.9-hotfix-20230808 | v3.5.1 |
Recursos do pacote de versões
| Característica | Pacote de versões |
|---|---|
| A conectividade de orquestração de volumes é criptografada por TLS | A partir de 1.28.9-1, 1.28.0-5, 1.27.9-1, 1.27.3-5, 1.26.12-1, 1.26.6-5, 1.25.11-5 e 1.25.6-7 |
| Os nós de cluster são habilitados para o Azure Arc | A partir de 1.25.6-4, 1.25.11-2, 1.26.3-4, 1.26.6-2, 1.27.1-4, 1.27.3-2 e 1.28.0-2 |
| Os volumes compartilhados do Nexus têm seu atributo de capacidade imposto como um limite de tamanho de volume | A partir de v1.27.13-3, v1.27.9-5, v1.28.11-4, v1.28.12-3, v1.29.6-4, v1.29.7-3, v1.30.3-1 |
Atualizando versões do Kubernetes
Para obter mais informações sobre como atualizar seu cluster, consulte Atualizar um cluster do Serviço Nexus Kubernetes do Operador do Azure.
Política de suporte da versão do Kubernetes
O Operator Nexus suporta três versões secundárias do Kubernetes:
- A última versão secundária do GA lançada no Operator Nexus (que chamamos de N).
- Duas versões secundárias anteriores.
- Cada versão secundária suportada também suporta um máximo de dois patches estáveis mais recentes, enquanto os patches anteriores estão sob política de disponibilidade estendida durante o tempo de vida da versão secundária.
O serviço Nexus Kubernetes do operador fornece uma duração padronizada de suporte para cada versão secundária do Kubernetes lançada. As versões aderem a duas linhas temporais diferentes, refletindo:
- Duração do suporte – Por quanto tempo uma versão é mantida ativamente. No final do período suportado, a versão é considerada
End of Support. - Disponibilidade estendida – Por quanto tempo uma versão pode ser selecionada para implantação após
End of Support.
A janela suportada das versões do Kubernetes no Operator Nexus é conhecida como N-2: (N (versão mais recente) - 2 (versões secundárias)), e .letter é representativa das versões de patch.
Por exemplo, se o Operator Nexus introduzir 1.17.a hoje, o suporte é fornecido para as seguintes versões:
| Nova versão menor | Lista de versões suportadas |
|---|---|
| 1.17.a | 1.17.a, 1.17.b, 1.16.c, 1.16.d, 1.15.e, 1.15.f |
Quando uma nova versão secundária é introduzida, a versão secundária mais antiga suportada e as versões de patch estão fora de suporte. Por exemplo, a lista de versões suportadas atual é:
1.17.a
1.17.b
1.16.c
1.16.d
1.15.e
1.15.f
Quando o Operator Nexus lança 1.18.*, todas as versões 1.15.* deixam de ser suportadas.
Linha cronológica de suporte
O serviço Nexus Kubernetes do operador fornece suporte por 12 meses a partir da versão inicial do AKS GA de uma versão secundária normalmente. Esta linha do tempo segue o tempo do Azure AKS, que inclui uma versão 1.27 declarada de Suporte de Longo Prazo.
Versões suportadas:
- Pode ser implantado como novos clusters Operator Nexus Kubernetes.
- Pode ser alvo de atualizações de versões anteriores. Limitado por caminhos de atualização normais.
- Pode ter patches extras ou pacotes de versão dentro da versão secundária.
Observação
Em circunstâncias excecionais, o suporte ao serviço Nexus Kubernetes pode ser encerrado antecipadamente ou imediatamente se uma vulnerabilidade ou problema de segurança for identificado. Se essa situação ocorrer, a Microsoft notificará proativamente os clientes e trabalhará para mitigar possíveis problemas.
Fim do suporte
End of Support significa que não são produzidos mais pacotes de patch ou versão. É possível que o cluster não possa ser atualizado porque as versões suportadas mais recentes não estão mais disponíveis. Nesse caso, a única maneira de atualizar é recriar completamente o cluster Nexus Kubernetes usando a versão mais recente suportada. Atualizações sem suporte podem Extended availability ser utilizadas para retornar a uma versão suportada.
Política de disponibilidade estendida
Durante o período de disponibilidade estendido para versões do Kubernetes sem suporte, os usuários não recebem patches de segurança ou correções de bugs. Para obter informações detalhadas sobre as categorias de suporte, consulte a tabela a seguir.
| Categoria de suporte | N-2 a N | Disponibilidade estendida |
|---|---|---|
| Atualizações do N-3 para uma versão suportada | Suportado | Suportado |
| Dimensionamento de grupos de nós | Suportado | Suportado |
| Criação de cluster ou pool de nós | Suportado | Suportado |
| Componentes do Kubernetes (incluindo recursos) | Suportado | Não suportado |
| Atualizações de componentes | Suportado | Não suportado |
| Hotfixes de componentes | Suportado | Não suportado |
| Aplicando correções de bugs do Kubernetes | Suportado | Não suportado |
| Aplicando patches de segurança do Kubernetes | Suportado | Não suportado |
| Patches de segurança de imagem de nó | Suportado | Não suportado |
Observação
O Operator Nexus 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 operador Nexus 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 Operator Nexus pode deixar essas versões sem patches ou bifurcação. Devido a essa limitação, a disponibilidade estendida não suporta a dependência de nada relacionado ao Kubernetes upstream.
Clusters Nexus Kubernetes abandonados
Após o final do período de disponibilidade estendido, a versão K8s é removida do Nexus. Neste ponto, todos os clusters Nexus Kubernetes existentes que são baseados nesta versão K8s são abandonados. A única operação suportada em clusters abandonados é a exclusão. É importante ressaltar que, uma vez que um cluster é abandonado, a atualização para uma versão posterior do K8s não é possível.
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.17, então você pode usar as versões 1.16 a 1.18 do com esse kubectl.
Para instalar ou atualizar kubectl para a versão mais recente, execute:
az aks install-cli
Suporte de Longo Prazo (LTS)
A comunidade Kubernetes lança uma nova versão secundária aproximadamente a cada quatro meses, com uma janela de suporte para cada versão por um ano. No Serviço Kubernetes do Azure (AKS), essa janela de suporte é chamada de "Suporte da comunidade".
O AKS suporta versões do Kubernetes que estão dentro desta janela de suporte da Comunidade, para enviar correções de bugs e atualizações de segurança de versões da comunidade.
As inovações fornecidas com esta cadência de lançamento fornecem os recursos mais recentes do Kubernetes e segurança atualizada. No entanto, pode ser um desafio manter-se atualizado com base no número de clusters que você precisa manter.
Tipos de suporte
Após aproximadamente um ano, a versão do Kubernetes sai do suporte da Comunidade e seus clusters AKS estão agora em risco, pois correções de bugs e atualizações de segurança ficam indisponíveis.
O AKS fornece um ano de suporte comunitário 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. O nosso grupo de trabalho LTS upstream contribui esforços para a comunidade para proporcionar aos nossos clientes um período de suporte mais longo.
O LTS fornece um longo período de tempo para planejar e testar atualizações durante um período de dois anos a partir da disponibilidade geral de uma versão do Kubernetes.
| Suporte da Comunidade | Apoio a Longo Prazo | |
|---|---|---|
| Quando utilizar | Quando conseguires acompanhar os releases principais do Kubernetes | Cenários em que seus aplicativos não são compatíveis com as alterações introduzidas em versões mais recentes do Kubernetes e você não pode fazer a transição para um ciclo de lançamento contínuo devido a restrições técnicas ou outros fatores |
| Versões de suporte | Três versões menores do GA | Uma versão do Kubernetes por dois anos |
Importante
Kubernetes versão 1.27 é a primeira versão LTS suportada do Kubernetes no serviço Operator Nexus Kubernetes. A próxima versão LTS após a 1.27 é a 1.30, que iniciará seu suporte LTS em outubro de 2024. Da versão 1.30 do Kubernetes em diante, todas as versões do Nexus Kubernetes são compatíveis com LTS.
Migrar do LTS para a próxima versão do LTS
Os clusters Nexus Kubernetes não suportam atualizações diretas entre versões LTS. Para fazer a transição de uma versão LTS para a seguinte, você tem duas opções:
- Crie um novo cluster com a versão LTS desejada e mova suas cargas de trabalho para esse novo cluster.
- Execute uma série de atualizações intermediárias através das versões suportadas antes de chegar à próxima versão LTS.
FAQ
Como a Microsoft me notifica sobre novas versões do Kubernetes?
Este documento é atualizado periodicamente com as datas planejadas das novas versões do Kubernetes.
Com que frequência devo esperar atualizar as versões do Kubernetes para permanecer no suporte?
A partir do Kubernetes 1.19, a comunidade de código aberto expandiu o suporte para um ano. O operador Nexus compromete-se a permitir patches e suporte que correspondam aos compromissos upstream. Para clusters Nexus do operador 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, você está fora da janela de suporte. Quando você atualiza da versão N-3 para N-2, você está de volta à nossa janela de suporte. Por exemplo:
- Se a versão mais antiga suportada do AKS for 1.25.x e você estiver na 1.24.x ou mais antiga, você está fora do suporte.
- A atualização bem-sucedida de 1.24.x para 1.25.x ou superior traz você de volta à nossa janela de suporte.
- "Atualizações de nível de pulo" não são suportadas. Para atualizar de 1.23.x para 1.25.x, você deve atualizar primeiro para 1.24.x e depois para 1.25.x.
Não há suporte para downgrades.
O que acontece se eu não atualizar meu cluster?
Se você não atualizar seu cluster, continuará a receber suporte para a versão do Kubernetes que está executando até o final do período de suporte. Depois disso, você não receberá mais suporte para seu cluster. Você precisa atualizar seu cluster para uma versão suportada para continuar recebendo suporte.
O que acontece se eu não atualizar meu cluster antes do final do período de disponibilidade estendida?
Se você não atualizar seu cluster antes do final do período de disponibilidade estendida, não poderá mais atualizá-lo para uma versão suportada ou pools de agentes de expansão. Você precisa recriar seu cluster usando uma versão suportada para continuar recebendo suporte.
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.
Além disso, o Operator Nexus não faz nenhum tempo de execução ou outras garantias para clusters fora da lista de versões suportadas.
O que acontece quando um usuário dimensiona um cluster do Kubernetes com uma versão secundária que não é suportada?
Para versões secundárias não suportadas pelo Operator Nexus, 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.
Posso ignorar várias versões do Kubernetes durante a atualização do cluster?
Quando você atualiza um cluster Kubernetes do Operator Nexus suportado, as versões secundárias do Kubernetes não podem ser ignoradas. A política de desvio de versão dos planos de controle do Kubernetes não suporta a passagem de versões secundárias. Por exemplo, atualizações entre:
- 1.12.x ->1.13.x: permitido.
- 1.13.x ->1.14.x: permitido.
- 1.12.x ->1.14.x: não permitido.
Para atualizar de 1.12.x ->1.14.x:
- Atualize de 1.12.x para> 1.13.x.
- Atualize de 1.13.x para> 1.14.x.
Posso criar um novo cluster durante sua janela de disponibilidade estendida?
Sim, você pode criar um novo cluster 1.xx.x durante sua janela de disponibilidade estendida. No entanto, recomendamos que você crie um novo cluster com a versão suportada mais recente.
Posso atualizar um cluster para uma versão mais recente durante sua janela de disponibilidade estendida?
Sim, você pode atualizar um cluster N-3 para N-2 durante sua janela de disponibilidade estendida. Se o cluster estiver atualmente em N-4, você poderá usar a disponibilidade estendida para primeiro atualizar de N-4 para N-3. Quando a atualização do N-3 for concluída, prossiga com a atualização para uma versão suportada (N-2).
Estou em uma janela de disponibilidade estendida, ainda posso adicionar novos pools de nós ou preciso atualizar?
Sim, você tem permissão para adicionar pools de nós ao cluster.