Versões do Kubernetes suportadas no serviço Kubernetes do Azure Operator Nexus
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 como é a experiência de atualização. O documento também abrange o ciclo de vida de suporte de versão e o fim da vida útil (EOL) para cada versão secundária do 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 incluem novos recursos e 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 versões 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.
Nota
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 | Disponibilidade estendida |
|---|---|---|---|
| 1,25 | jun 2023 | Dez 2023 | Até 1.31 GA |
| 1.26 | Setembro 2023 | Março 2024 | Até 1.32 GA |
| 1.27* | Setembro 2023 | Jul 2024, LTS até jul 2025 | Até 1.33 GA |
| 1.28 | Novembro 2023 | Outubro de 2024 | Até 1.34 AG |
* Indica que a versão é designada para Suporte de Longo Prazo
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
- O Version Bundle, que encapsula os recursos (complementos) e a imagem do sistema operacional usada pelos nós no cluster Operator Nexus Kubernetes, 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-2ou a notação "v" suportada alternativamente:v1.25.4-2.
Pacotes de versões
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 Operator Nexus Kubernetes pode levar em conta 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 estão limitadas a: imagens atualizadas do sistema operacional, versões de patches para recursos (complementos) e assim por diante. Os pacotes de versão são sempre compatíveis com pacotes de versões anteriores dentro da mesma versão de 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 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
- Mudança da CNI de um produto para outro
Quando seguimos esses princípios, torna-se mais fácil prever e gerenciar o processo de movimentação entre diferentes versões de clusters Kubernetes oferecidos pelo serviço Operator Nexus Kubernetes.
Podemos facilmente atualizar de qualquer pequena atualização em uma versão do Kubernetes para qualquer pequena atualização na próxima versão, dando-lhe 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 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:
| Versão do Kubernetes | Pacote de versões | Componentes | Componentes do SO | Alterações Interruptivas | Notas |
|---|---|---|---|---|---|
| 1.25.6 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.5.1 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.25.6 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.25.6 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.25.6 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | Os nós de cluster são habilitados para o Azure Arc |
| 1.25.6 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 CSI-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.25.11 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.25.11 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | Os nós de cluster são habilitados para o Azure Arc |
| 1.25.11 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 CSI-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.26.3 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.5.1 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.26.3 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.26.3 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.26.3 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | Os nós de cluster são habilitados para o Azure Arc |
| 1.26.3 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 CSI-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.26.6 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.26.6 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | Os nós de cluster são habilitados para o Azure Arc |
| 1.26.6 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 CSI-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.27.1 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.5.1 |
Azure Linux 2.0 | Cgroupv2 | Os passos para desativar o cgroupv2 podem ser encontrados aqui |
| 1.27.1 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | Os passos para desativar o cgroupv2 podem ser encontrados aqui |
| 1.27.1 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | Os passos para desativar o cgroupv2 podem ser encontrados aqui |
| 1.27.1 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | Os nós de cluster são habilitados para o Azure Arc |
| 1.27.1 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 CSI-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.27.3 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | Os passos para desativar o cgroupv2 podem ser encontrados aqui |
| 1.27.3 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | Os nós de cluster são habilitados para o Azure Arc |
| 1.27.3 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 CSI-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.28.0 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | |
| 1.28.0 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 |
Azure Linux 2.0 | Sem alterações significativas | Os nós de cluster são habilitados para o Azure Arc |
| 1.28.0 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 SRUV-DP v3.7.0-48 CSI-nfs v4.6.0 |
Azure Linux 2.0 | Sem alterações significativas |
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 é "Fim da vida útil".
- Disponibilidade estendida – Por quanto tempo uma versão pode ser selecionada para implantação após o "Fim da vida útil".
A janela suportada de versões do Kubernetes no Operator Nexus é conhecida como "N-2": (N (última versão) - 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 secundária | 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.
Nota
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. A Microsoft notificará proativamente os clientes se isso ocorrer e trabalhará para mitigar possíveis problemas.
Fim da vida útil (EOL)
Fim da vida útil (EOL) significa que não são produzidos mais pacotes de patch ou versão. É possível que o cluster que você configurou não possa mais 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 (ou seja, versões EOL do Kubernetes), 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 do pool de nós | Suportado | Suportado |
| Criação de cluster ou pool de nós | Suportado | Suportado |
| Componentes do Kubernetes (incluindo Add-ons) | 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 |
Nota
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 nada de depender do kubernetes upstream.
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 kubectl com esse kube-apiserver.
Para instalar ou atualizar kubectl para a versão mais recente, execute:
az aks install-cli
Suporte de Longo Prazo (LTS)
O Serviço Kubernetes do Azure (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 em qualquer momento.
| Apoio à Comunidade | Apoio a Longo Prazo | |
|---|---|---|
| Quando utilizar | Quando você pode acompanhar as versões upstream 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 secundárias do GA | Uma versão do Kubernetes (atualmente 1.27) por dois anos |
A comunidade upstream mantém uma versão menor 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
Kubernetes versão 1.27 é a primeira versão LTS suportada do Kubernetes no serviço Operator Nexus Kubernetes.
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?
Começando com o 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 atualizar seu cluster 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 distorção de versão dos planos de controle do Kubernetes não suporta pular versões secundárias. Por exemplo, upgrades 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 e, em seguida, prosseguir 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 terei que atualizar?
Sim, você tem permissão para adicionar pools de nós ao cluster.