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.
Observação
Leia mais sobre nossa política de suporte para controle de versão do Kubernetes.
Para obter o histórico de lançamentos anteriores, consulte Histórico do Kubernetes.
| Versão do K8s | Disponibilidade geral do Nexus | Fim da vida útil | Disponibilidade Estendida |
|---|---|---|---|
| 1,25 | Junho de 2023 | dez. de 2023 | Até 1,31 GA |
| 1,26 | set. de 2023 | março de 2024 | Até 1,32 GA |
| 1,27* | set. de 2023 | Julho de 2024, LTS até julho de 2025 | Até 1,33 GA |
| 1.28 | nov. de 2023 | Out de 2024 | Até 1.34 GA |
* 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-2ou 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:
| Versão do Kubernetes | Pacote de Versão | Componentes | Componentes do SO | Alterações de quebra | Observações |
|---|---|---|---|---|---|
| 1.28.9 | 1 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.11.0-68 Csi-nfs v4.7.0 csi-volume v0.1.0 |
Azure Linux 2.0 | Sem alterações de falha | A partir deste pacote de versão, a conectividade de orquestração de volume é criptografada por TLS e os nós de cluster são habilitados para Azure Arc |
| 1.28.0 | 5 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.11.0-68 Csi-nfs v4.7.0 csi-volume v0.1.0 |
Azure Linux 2.0 | Sem alterações de falha | A partir deste pacote de versão, a conectividade de orquestração de volume é criptografada por TLS |
| 1.28.0 | 4 | Calico v3.27.2 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.10.0-60 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações de falha | |
| 1.27.9 | 1 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.11.0-68 Csi-nfs v4.7.0 csi-volume v0.1.0 |
Azure Linux 2.0 | Sem alterações de falha | A partir deste pacote de versão, a conectividade de orquestração de volume é criptografada por TLS e os nós de cluster são habilitados para Azure Arc |
| 1.27.3 | 5 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.11.0-68 Csi-nfs v4.7.0 csi-volume v0.1.0 |
Azure Linux 2.0 | Sem alterações de falha | A partir deste pacote de versão, a conectividade de orquestração de volume é criptografada por TLS |
| 1.27.3 | 4 | Calico v3.27.2 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.10.0-60 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações de falha | |
| 1.26.12 | 1 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.11.0-68 Csi-nfs v4.7.0 csi-volume v0.1.0 |
Azure Linux 2.0 | Sem alterações de falha | A partir deste pacote de versão, a conectividade de orquestração de volume é criptografada por TLS e os nós de cluster são habilitados para Azure Arc |
| 1.26.6 | 5 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.11.0-68 Csi-nfs v4.7.0 csi-volume v0.1.0 |
Azure Linux 2.0 | Sem alterações de falha | A partir deste pacote de versão, a conectividade de orquestração de volume é criptografada por TLS |
| 1.26.6 | 4 | Calico v3.27.2 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.10.0-60 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações de falha | |
| 1.25.11 | 5 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.11.0-68 Csi-nfs v4.7.0 csi-volume v0.1.0 |
Azure Linux 2.0 | Sem alterações de falha | A partir deste pacote de versão, a conectividade de orquestração de volume é criptografada por TLS |
| 1.25.11 | 4 | Calico v3.27.2 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.10.0-60 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações de falha | |
| 1.25.6 | 7 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.11.0-68 Csi-nfs v4.7.0 csi-volume v0.1.0 |
Azure Linux 2.0 | Sem alterações de falha | A partir deste pacote de versão, a conectividade de orquestração de volume é criptografada por TLS |
| 1.25.6 | 6 | Calico v3.27.2 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.10.0-60 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações de falha |
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:
| Nova versão secundária | Lista de Versões Compatíveis |
|---|---|
| 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 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.
Observação
Em circunstâncias excepcionais, o suporte ao serviço de Kubernetes do Nexus poderá ser encerrado de forma antecipada ou imediata se uma vulnerabilidade ou preocupação com a segurança for identificada. A Microsoft notificará proativamente os clientes se isso ocorrer e trabalhará para mitigar possíveis problemas.
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.
| Categoria do suporte | N-2 para N | Disponibilidade estendida |
|---|---|---|
| Atualizações do N-3 para uma versão suportada | Com suporte | Com suporte |
| Escala do pool de nós | Com suporte | Com suporte |
| Criação do cluster ou pool de nós | Com suporte | Com 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 bug do Kubernetes | Com suporte | Sem suporte |
| Aplicação de patches de segurança do Kubernetes | Com suporte | Sem suporte |
| Patches de segurança de imagem do nó | Com suporte | Sem suporte |
Observação
O Nexus do Operador 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 Nexus do Operador só poderá garantir suporte total enquanto essas versões estiverem sendo atendidas em upstream. Como não há mais patches sendo produzidos em upstream, o Nexus do Operador pode deixar essas versões sem patch ou criar fork. Devido a essa limitação, a disponibilidade estendida não dá suporte a nada que depende do Kubernetes upstream.
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
LTS (suporte de longo prazo)
O AKS fornece uma versão LTS (suporte de longo prazo) do Kubernetes por um período de dois anos. Há apenas uma única versão secundária do Kubernetes considerada LTS a qualquer momento.
| Suporte da comunidade | Suporte de longo prazo | |
|---|---|---|
| Quando usar | Quando você pode acompanhar upstream versões do Kubernetes | Cenários em que seus aplicativos não são compatíveis com as alterações introduzidas nas versões mais recentes do Kubernetes e você não pode fazer a transição para um ciclo de versão contínuo devido a restrições técnicas ou outros fatores |
| Versões de suporte | Três versões secundárias de GA | Uma versão do Kubernetes (atualmente 1.27) por dois anos |
A comunidade upstream mantém uma versão secundária do Kubernetes por um ano a partir do lançamento. Após esse período, a Microsoft cria e aplica atualizações de segurança à versão LTS do Kubernetes para fornecer um total de dois anos de suporte no AKS.
Importante
O Kubernetes versão 1.27 é a primeira versão de LTS com suporte do Kubernetes no serviço de Kubernetes do Nexus do Operador.
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:
- Atualização da 1.12.x ->1.13.x.
- 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.