Versões do Kubernetes com suporte no serviço de Kubernetes do Nexus do Operador do Azure

Este documento fornece uma visão geral do esquema de controle de versão usado para o serviço de Kubernetes do Nexus do Operador, incluindo as versões do Kubernetes com suporte. Ele explica as diferenças entre as versões principais, secundárias e de patch, e fornece diretrizes sobre como atualizar versões do Kubernetes e como é a experiência de atualização. O documento também aborda o ciclo de vida de suporte de versão e o EOL (fim da vida útil) para cada versão secundária do Kubernetes.

A comunidade Kubernetes libera versões secundárias aproximadamente a cada três meses. A partir da versão 1.19, a comunidade do Kubernetes aumentou a janela de suporte para cada versão de nove meses para um ano.

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.24.7
  1.25.4

Cada número na versão indica compatibilidade geral com a versão anterior:

• Os números de versões principais mudam quando alterações interruptivas na API podem ser introduzidas
• Os números de versões secundárias são alterados quando são feitas atualizações de funcionalidade que são compatíveis com versões secundárias anteriores.
• Os números de versões de patch são alterados quando são feitas correções de bugs compatíveis com versões anteriores.

É altamente recomendável manter-se atualizado com os patches disponíveis mais recentes. Por exemplo, se o cluster de produção estiver em 1.25.4, 1.25.6 será a versão de patch mais recente disponível para a série 1.25. Você deve atualizar para a 1.25.6 assim que possível a fim de garantir que o cluster tenha suporte e correção total. Mais detalhes sobre como atualizar o cluster podem ser encontrados na documentação Como atualizar versões do Kubernetes.

Calendário de versões do Kubernetes do Nexus

Veja os lançamentos de versões futuras no calendário de versões do Kubernetes do Nexus.

Para obter o histórico de lançamentos anteriores, consulte Histórico do Kubernetes.

* Indica que a versão é designada para Suporte de Longo Prazo

Componentes da versão do serviço de Kubernetes do Nexus

Uma versão do serviço de Kubernetes do Nexus do Operador é feita de 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 Nexus do Operador. Esses pacotes são fornecidos pelo AKS do Azure, incluindo todas as versões de patch compatíveis com o Nexus do Operador. Para obter mais informações sobre as versões do AKS do Azure, consulte Versões do Kubernetes com suporte do AKS
• O Pacote de Versão, que encapsula os recursos (complementos) e a imagem do sistema operacional usada por nós no cluster do Kubernetes do Nexus do Operador, como um único número. Por exemplo, 2. A combinação desses valores é representada na API como a única kubernetesVersion. Por exemplo, 1.25.4-2 ou a notação "v" com suporte alternativo: v1.25.4-2.

Pacotes de versão

Ao estender a versão do Kubernetes para incluir um valor secundário para a versão do patch, o pacote de versão, o serviço do Kubernetes do Nexus do Operador pode considerar os casos em que a implantação é modificada para incluir atualizações adicionais relacionadas ao Sistema Operacional. Essas atualizações podem incluir, mas não se limitam a: imagens atualizadas do sistema operacional, versões de patch para recursos (complementos) e assim por diante. Os pacotes de versão são sempre compatíveis com pacotes de versões anteriores na mesma versão do patch, por exemplo, 1.25.4-2 é compatível com versões anteriores com 1.25.4-1.

As alterações na configuração de um cluster do Kubernetes do Nexus do Operador implantado só devem ser aplicadas em uma atualização de versão secundária do Kubernetes, não durante uma atualização de versão do patch. Exemplos de alterações de configuração que podem ser aplicadas durante a atualização de versão secundária incluem:

• Alteração da configuração do kube-proxy de usar os iptables para ipvs
• Alteração da CNI de um produto para outro

Quando seguimos esses princípios, fica mais fácil prever e gerenciar o processo de movimentação entre diferentes versões de clusters do Kubernetes oferecidas pelo serviço de Kubernetes do Nexus do Operador.

Podemos atualizar facilmente de qualquer pequena atualização em uma versão do Kubernetes para qualquer pequena atualização na próxima versão, proporcionando flexibilidade. Por exemplo, uma atualização de 1.24.1-x para 1.25.4-x seria permitida, independentemente da presença de uma versão intermediária 1.24.2-x.

Versão de componentes e alterações interruptivas

Observe as seguintes alterações importantes que devem ser feitas antes de atualizar para qualquer uma das versões secundárias disponíveis:

Recursos do pacote de versão

Como atualizar versões do Kubernetes

Para obter mais informações sobre como atualizar seu cluster, consulte Atualizar um cluster do Serviço de Kubernetes do Nexus do Operador do Azure.

Política de suporte de versão do Kubernetes

O Nexus do Operador é compatível com três versões secundárias do Kubernetes:

• A versão secundária de GA mais recente lançada no Nexus do Operador (que chamamos de 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 mais recentes, enquanto os patches anteriores ficam sob política de disponibilidade estendida durante o tempo de vida da versão secundária.

O serviço de Kubernetes do Nexus do Operador fornece uma duração padronizada do suporte para cada versão secundária do Kubernetes lançada. As versões aderem a duas linhas do tempo diferentes, refletindo:

• Duração do suporte – por quanto tempo uma versão é mantida ativamente. No final do período com suporte, a versão é "Fim da vida útil".
• Disponibilidade estendida – quanto tempo uma versão pode ser selecionada para implantação após "Fim da vida útil".

A janela com suporte das versões do Kubernetes no Nexus do Operador é 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 Nexus do Operador introduz 1.17. a hoje, o suporte é fornecido para as seguintes versões:

Quando uma nova versão secundária é introduzida, a versão secundária e as versões de patch mais antigas com suporte são removidas do suporte. Por exemplo, se a lista atual de versões compatíveis for:

1.17.a
1.17.b
1.16.c
1.16.d
1.15.e
1.15.f

Quando o Nexus do Operador lança 1.18.*, todas as versões 1.15.* ficam sem suporte.

Linha do tempo de suporte

O serviço de Kubernetes do Nexus do Operador fornece suporte por 12 meses a partir da versão inicial de GA do AKS de uma versão secundária normalmente. Essa linha do tempo segue o tempo do AKS do Azure, que inclui um Suporte de Longo Prazo declarado versão 1.27.

Versões com suporte:

• Pode ser implantado como novos clusters do Kubernetes do Nexus do Operador.
• Pode ser o destino de atualizações de versões anteriores. Limitado por caminhos de atualização normais.
• Pode ter patches extras ou Pacotes de Versão na versão secundária.

EOL (fim da vida útil)

EOL (fim da vida útil) significa que não são produzidos mais pacotes versão ou patch. É possível que o cluster que você configurou não possa mais ser atualizado porque as versões mais recentes com suporte não estão mais disponíveis. Nesse caso, a única maneira de atualizar é recriar completamente o cluster do Kubernetes do Nexus usando a versão mais recente com suporte. Atualizações sem suporte por meio da Extended availability podem ser utilizadas para retornar a uma versão com suporte.

Política de disponibilidade estendida

Durante o período de disponibilidade estendida para versões do Kubernetes sem suporte (ou seja, versões do Kubernetes em EOL), os usuários não recebem patches de segurança ou correções de bugs. Para obter informações detalhadas sobre categorias de suporte, consulte a tabela a seguir.

Clusters Kubernetes Nexus abandonados

Após o término do período de disponibilidade estendida, a versão do K8s é completamente removida do Nexus. Neste ponto, todos os clusters Kubernetes Nexus existentes que são baseados nessa versão do K8s serão considerados abandonados. A única operação com suporte em clusters abandonados é a exclusão. É importante ressaltar que, depois que um cluster for abandonado, a atualização para uma versão posterior do K8s não funcionará.

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 seu Kube-apiserver estiver em 1,17, você poderá usar as versões 1,16 a 1,18 de kubectl com esse Kube-apiserver.

Para instalar ou atualizar kubectl para a versão mais recente, execute:

az aks install-cli

Install-AzAksKubectl -Version latest

LTS (suporte de longo prazo)

A comunidade do 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 AKS (Serviço de Kubernetes do Azure), essa janela de suporte é chamada de “suporte da Comunidade”.

O AKS dá suporte a versões do Kubernetes que estão dentro dessa janela do suporte da Comunidade para enviar por push correções de bugs e atualizações de segurança de versões da comunidade.

Embora a inovação proporcionada por esse ciclo de lançamentos traga grandes benefícios para você, ela desafia você a se manter atualizado com os lançamentos do Kubernetes, o que pode ser mais difícil dependendo do 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 ficam em risco, pois correções de bugs e atualizações de segurança ficam indisponíveis.

O AKS fornece um ano de suporte da Comunidade e um ano de LTS (suporte de longo prazo) para dar suporte a correções de segurança da comunidade upstream em nosso repositório público. Nosso grupo de trabalho upstream LTS contribui com esforços de volta para a comunidade para fornecer aos nossos clientes uma janela de suporte mais longa.

O LTS pretende fornecer um longo período de tempo para planejar e testar atualizações durante um período de dois anos a partir da Disponibilidade Geral da versão designada do Kubernetes.

Migrar do LTS para a próxima versão do LTS

Clusters Kubernetes Nexus não dão suporte a atualizações diretas entre versões LTS. Para transitar de uma versão LTS para a próxima, você tem duas opções: criar um novo cluster com a versão LTS desejada e mover suas cargas de trabalho para este novo cluster, ou realizar uma série de atualizações intermediárias através das versões com suporte antes de alcançar a próxima versão LTS.

Perguntas frequentes

Como a Microsoft me notificará sobre as novas versões do Kubernetes?

Este documento é atualizado periodicamente com datas planejadas das novas versões do Kubernetes.

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 Nexus do Operador confirma a habilitação de patches e o suporte correspondentes aos compromissos upstream. Para os clusters do Nexus do Operador da versão 1.19 e superiores, você pode atualizar, no mínimo, uma vez por ano para permanecer em uma versão com suporte.

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 anterior, estará fora da janela de suporte. Ao atualizar da versão N-3 para N-2, você estará de volta à nossa janela de suporte. Por exemplo:

• Se a versão mais antiga do AKS com suporte for 1.25.x e você estiver na 1.24.x ou anterior, estará fora do suporte.
• A atualização com sucesso da 1.24.x para a 1.25.x ou superior traz você de volta para nossa janela de suporte.
• Não há suporte para "atualizações que ignoram o nível". Para atualizar da 1.23.x para a 1.25.x, você deve atualizar primeiro para a 1.24.xe depois para a 1.25.x.

Não há suporte para fazer downgrade.

O que acontece se eu não atualizar meu cluster?

Se você não atualizar o cluster, continuará recebendo suporte para a versão do Kubernetes em execução até o final do período de suporte. Depois disso, você não receberá mais suporte para o cluster. Você precisa atualizar seu cluster para uma versão com suporte 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 atualizar seu cluster para uma versão com suporte ou pools de agentes de expansão. Você precisa recriar seu cluster usando uma versão com suporte para continuar recebendo suporte.

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.
• Ao solicitar suporte, você receberá uma solicitação para atualizar o cluster para uma versão com suporte.

Além disso, o Nexus do Operador 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 um usuário escalar um cluster do Kubernetes com uma versão secundária sem suporte?

Para as versões secundárias sem suporte do Nexus do Operador, 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.

Posso ignorar várias versões do Kubernetes durante a atualização do cluster?

Quando você atualiza um cluster do Kubernetes do Nexus do Operador 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.12.x ->1.13.x: permitido.
• 1.13.x ->1.14.x: permitido.
• 1.12.x ->1.14.x: não permitido.

Para fazer a atualização da 1.12.x ->1.14.x:

1. Atualização da 1.12.x ->1.13.x.
2. Atualização da 1.13.x ->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 criar um novo cluster com a versão mais recente com suporte.

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 na N-4, você poderá usar a disponibilidade estendida para primeiro atualizar de N-4 para N-3 e, em seguida, continuar com a atualização para uma versão com suporte (N-2).

Estou em uma janela de disponibilidade estendida, ainda posso adicionar novos pools de nós? Ou precisarei fazer a atualização?

Sim, você tem permissão para adicionar pools de nós ao cluster.