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.

• Correções de nó do trabalhador: confira mensalmente se há alguma atualização disponível e use o comando ibmcloud ks worker update ou o comando ibmcloud ks worker reload para aplicar essas correções de segurança e sistema operacional. Durante uma atualização ou um recarregamento, a imagem da máquina do nó do trabalhador será recriada e os dados serão excluídos se não armazenados fora do nó do trabalhador.
• 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 que só é necessário caso um fix pack principal seja 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 do 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 fornece suporte de melhor esforço para a liberação.

   Disponibilidade geral

   A liberação está geralmente disponível (GA). A IBM fornece suporte integral para a liberação A IBM fornece uma data de destino provisória para a liberação não suportada. A liberação se torna a versão padrão usada durante a criação do cluster quando há restrições mínimas e uma taxa de adoção razoável para a liberação.

   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 A IBM fornece suporte mínimo para a liberação em alinhamento com a comunidade do Kubernetes Essa fase de suporte é geralmente a fase final antes que a liberação se torne não suportada e substitua as fases de manutenção e de suporte estendido, caso haja qualquer 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 é suportada e seu cluster ainda é funcional, mas pode requerer atualização para uma liberação suportada para corrigir vulnerabilidades de segurança. Por exemplo, incluindo ou recarregando os nós do trabalhador,

4. Versão sem suporte: A versão não é suportada. A IBM fornece suporte apenas para fazer upgrade para uma liberação suportada A versão não é suportada. 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 cluster mestre executar duas ou mais versões atrás da versão suportada mais antiga, não será mais possível aplicar atualizações e você deverá 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: a versão não é suportada sem caminho de upgrade. IBM não fornece suporte. A IBM reserva o direito de encerrar os planos de controle para esses clusters.

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 descontinuados para uma versão suportada que esteja uma ou duas versões abaixo da versão atual, por exemplo, 1.21 ou 1.22, e então atualize para a versão mais recente, 1.23. Se os nós do trabalhador executarem uma versão do mestre mais antiga do que a atual em duas ou mais versões, será possível que seus pods falhem, entrando em um estado como MatchNodeSelector, CrashLoopBackOff ou ContainerCreating, até que você atualize os nós do trabalhador para a mesma versão do mestre. Embora as versões sem suporte não sejam suportadas pelo suporte do IBM Cloud, o IBM Technology Expert Labs tem serviços de compilação disponíveis que podem ajudá-lo a resolver problemas com versões sem suporte. Selecione "Partner with IBM Technology Expert Labs" no catálogo IBM Cloud para começar a usar seus serviços. 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 está em modo “ não compatível ” consultando 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.