Disponível em IBM Cloud Kubernetes Service versões

O IBM Cloud Kubernetes Service suporta simultaneamente múltiplas versões do Kubernetes. Quando uma versão mais recente (n) é liberada, até duas versões anteriores (n-2) são suportadas. As versões que são anteriores em mais de duas versões à mais recente (n-3) são primeiro descontinuadas e, em seguida, não suportadas. Para continuar recebendo importantes atualizações de correção de segurança, certifique-se de que os clusters sempre executem uma versão suportada do Kubernetes. Os clusters descontinuados podem não receber atualizações de segurança. Para obter mais informações, consulte Ciclo de vida da liberação.

As datas marcadas com o símbolo (†) são tentativas e estão sujeitas a mudança. Os sistemas operacionais marcados com um asterisco (*) estão obsoletos. Migre todos os nós de trabalho que usam um sistema operacional obsoleto para uma versão mais recente do sistema operacional.

Tipos de atualização

Seu cluster Kubernetes possui três tipos de atualizações: principais, secundárias e de correção. À medida que as atualizações se tornam disponíveis, você é notificado ao visualizar informações sobre os nós do cluster mestre ou do trabalhador, assim como com os comandos ibmcloud ks cluster ls, cluster get, worker ls ou worker get.

A IBM fornece fix packs quinzenais do nó do trabalhador IBM o objetivo da empresa é corrigir as vulnerabilidades legítimas detectadas em um prazo adequado aos riscos que elas representam. Para assegurar a qualidade e a estabilidade da liberação, os fix packs podem ser atrasados

Os fix packs são aplicados à versão mais recente do kernel estável de envio de dados fornecida pela Canonical.

Para manter seus nós seguros, deve-se instalar os fix packs do nó do trabalhador o mais rápido possível É possível assinar notificações para ser alertado quando uma nova atualização estiver disponível

Atualizações principais e secundárias (1.x)

Primeiro, atualize seu nó principal e, em seguida, atualize os nós do trabalhador.

• Não é possível atualizar duas ou mais versões secundárias de um principal do Kubernetes de uma vez (n+2). Por exemplo, se o seu principal atual for a versão 1.22 e for desejado atualizar para a 1.24, você deverá atualizar primeiro para a 1.23.
• Os nós do trabalhador não podem executar uma versão primária ou secundária do Kubernetes que seja maior do que a dos principais. Além disso, seus nós do trabalhador podem ser anteriores ao mestre somente em até duas versões (n-2).
• Se você usar uma versão da CLI kubectl que não corresponda pelo menos à versão major.minor de seus clusters, poderá ter resultados inesperados. Assegure-se de manter seu cluster de Kubernetes e as versões da CLI atualizados.

Atualizações de correção (x.x.4_1510)

As mudanças nas correções estão documentadas no log de mudanças de cada versão. As correções principais são aplicadas automaticamente, mas você inicia as correções e atualizações do nó do trabalhador. Os nós do trabalhador também podem executar versões de correção que são maiores que as principais. À medida que as atualizações se tornam disponíveis, você é notificado ao visualizar informações sobre os nós do mestre e do trabalhador no console ou na CLI do IBM Cloud, assim como com os comandos a seguir: ibmcloud ks cluster ls, cluster get, worker ls ou worker get.

As correções podem ser para nós do trabalhador, mestres ou ambos.

• Patches para nós de trabalho: Verifique mensalmente se há alguma atualização disponível. O comando a ser usado depende do tipo de infraestrutura do seu cluster e do tipo de nó de trabalho.
  • Agrupamentos clássicos: use o ibmcloud ks worker update ou ibmcloud ks worker reload. Durante uma atualização ou reinicialização, o sistema operacional do nó de trabalho é reinstalado e os dados são excluídos, caso não estejam armazenados fora do nó de trabalho.
  • Processadores da instância de servidor virtual (VSI) do VPC: Use o ibmcloud ks worker replace comando. O antigo nó de trabalho é excluído e um novo é provisionado em seu lugar. Os dados são excluídos caso não sejam armazenados fora do nó de trabalho.
  • Trabalhadores de bare metal do VPC: Use o ibmcloud ks worker reload comando. O nó é recarregado no mesmo local e mantém seu endereço IP. Os dados armazenados em discos locais são excluídos caso não sejam armazenados fora do nó de trabalho.
• Correções de mestre: as correções de mestre são aplicadas automaticamente ao longo do curso de vários dias, portanto, uma versão de correção de mestre pode aparecer como disponível antes de ser aplicada ao seu mestre. A automação de atualização também ignora clusters que estão em um estado não funcional ou têm operações atualmente em andamento. Ocasionalmente, o IBM pode desativar as atualizações automáticas para um fix pack principal específico, conforme indicado no registro de alterações, como, por exemplo, um patch necessário apenas quando um fix pack principal é atualizado de uma versão secundária para outra. Em qualquer um desses casos, é possível optar por usar com segurança o comando ibmcloud ks cluster master update você mesmo sem esperar que a automação de atualização seja aplicada.

Ciclo de vida da liberação

Cada versão suportada do IBM Cloud Kubernetes Service passa por um ciclo de vida de teste, desenvolvimento, liberação geral, suporte, descontinuação e se torna não suportada. Revise as descrições de cada fase do ciclo de vida de uma versão.

Dias e versões estimados são fornecidos para o entendimento geral. As datas reais de disponibilidade e liberação estão sujeitas a mudanças e dependem de vários fatores, como atualizações da comunidade, correções de segurança e mudanças de tecnologia entre as versões.

1. Lançamento pela comunidade: A comunidade lança a nova versão. IBM Os engenheiros começam a testar e a aperfeiçoar a versão comunitária, em preparação para o lançamento de uma versão com suporte, a IBM Cloud Kubernetes Service.

2. Ciclo de vida da versão suportada:

   Liberação de desenvolvimento.

   A liberação está em desenvolvimento e pode estar disponível como Beta para selecionar clientes. IBM oferece suporte dentro do possível para essa versão.

   Disponibilidade geral

   A liberação está geralmente disponível (GA). IBM oferece suporte completo para essa versão e indica uma data prevista para quando o suporte a essa versão será encerrado. A versão passa a ser a versão padrão utilizada durante a criação do cluster assim que houver restrições mínimas e uma taxa de adoção razoável.

   Manutenção

   A liberação inseriu suporte de manutenção conforme definido pela comunidade do Kubernetes. A IBM fornece suporte de manutenção para o Kubernetes com base na política da comunidade Caso contrário, a IBM fornecerá suporte integral

3. Versão descontinuada: a versão foi descontinuada A IBM fornece uma data prevista não suportada atualizada para a liberação. Uma contagem regressiva não suportada até essa data é fornecida pelo menos 45 dias antes que a liberação se torne não suportada IBM oferece suporte ao lançamento, em conformidade com a política da comunidade Kubernetes durante esta fase. Essa fase de suporte é a fase final antes que a versão deixe de receber suporte e tem prioridade sobre as fases de manutenção e de suporte estendido, caso haja alguma sobreposição. Pode ser que não sejam fornecidas atualizações de patches de segurança. Durante o período de descontinuação, a versão ainda recebe suporte e seu cluster continua funcional, mas você deve atualizar o plano de controle e os nós de trabalho do cluster para uma versão compatível a fim de corrigir vulnerabilidades de segurança.

4. Versão não compatível: A versão não é compatível. IBM oferece suporte apenas para ajudá-lo a atualizar para uma versão compatível. Os clusters sem suporte não recebem atualizações de segurança nem de patches e não contam com o suporte da IBM Cloud. Embora seu cluster e seus aplicativos possam continuar em execução por algum tempo, você não poderá mais criar, recarregar ou realizar outras ações corretivas no plano de controle do cluster ou nos nós de trabalho quando ocorrer um problema. Ainda é possível excluir os nós do trabalhador ou o cluster ou atualizar o cluster para a próxima versão. Revise os potenciais impactos e atualize o cluster imediatamente para continuar recebendo atualizações importantes de segurança e suporte. Se o plano de controle do cluster estiver duas ou mais versões atrás da versão mais antiga compatível, não será mais possível aplicar atualizações, e será necessário excluir o cluster e criar um novo.

   Os clusters que executam uma versão sem suporte acabarão falhando porque os certificados do cluster expiram. As falhas podem incluir, mas não se limitam a, um plano de controle de cluster indisponível, nós de trabalho NotReady ou um Ingress não saudável.

5. Arquivado: Esta versão não tem suporte e não há caminho de atualização disponível. IBM não oferece suporte e se reserva o direito de desativar os planos de controle dos clusters arquivados.

IBM Cloud Kubernetes Service não expandiu sua inclinação suportada entre o nó central e os componentes do plano de controle em uma versão secundária. A defasagem suportada permanece n-2.. Para obter mais informações, consulte Alterações no desvio suportado entre as versões do plano de controle e do nó para obter informações Kubernetes da comunidade.

Se você esperar o cluster ficar duas ou mais versões secundárias atrás da versão mais antiga suportada, não será possível atualizá-lo. Em vez disso, crie um novo cluster, implemente seus apps no novo cluster e exclua o cluster não suportado. Para evitar esse problema, atualize os clusters obsoletos para uma versão compatível antes de atualizar para a versão mais recente. Se os nós de trabalho estiverem executando uma versão duas ou mais versões atrás do plano de controle, é possível que seus pods apresentem falhas, entrando em um estado como “ MatchNodeSelector ”, “ CrashLoopBackOff ” ou “ ContainerCreating ”, até que você atualize os nós de trabalho para a mesma versão do plano de controle. Embora as versões sem suporte não sejam atendidas pelo Suporte da IBM Cloud, o IBM Technology Expert Labs oferece serviços que podem ajudá-lo a resolver problemas com essas versões. Selecione “Estabelecer parceria com os Laboratórios de Especialistas em Tecnologia d IBM ” no catálogo IBM Cloud para começar a utilizar os serviços deles. Depois de atualizar de uma versão descontinuada para uma suportada, seu cluster pode continuar as operações normais e continuar recebendo suporte. Você pode verificar se o seu cluster é do tipo “ não compatível ” analisando o campo “ Estado ” na saída do comando “ ibmcloud ks cluster ls ” ou no arquivo “ IBM Cloud Kubernetes Service console ”.

Preparando-se para a atualização

A atualização de um cluster de uma versão mais antiga para uma nova versão poderá ter um impacto nos apps implementados. Para obter uma lista completa das alterações, consulte os registros de alterações Kubernetes da comunidade, os registros de IBM alterações de versão e os Kubernetes avisos úteis.

Para ações que você deve executar antes e depois de atualizar o seu cluster, consulte os links de informações da versão em Versões do IBM Cloud® Kubernetes Service disponíveis.

Archive

Os clusters não suportados não são fornecidos com atualizações de segurança e correção e não têm o Suporte IBM Cloud. Embora o cluster e os aplicativos possam continuar em execução por um tempo, não será mais possível criar, recarregar ou realizar outras ações corretivas no mestre do cluster ou nos nós do trabalhador quando ocorrer um problema. Ainda é possível excluir os nós do trabalhador ou o cluster ou atualizar o cluster para a próxima versão. Revise os potenciais impactos e atualize o cluster imediatamente para continuar recebendo atualizações importantes de segurança e suporte. Se o seu cluster mestre for duas ou mais versões atrás da versão suportada mais antiga, você deverá fazer um novo cluster e implementar seus apps nele.