Informações de versão do Red Hat OpenShift on IBM Cloud
Revise as informações sobre as versões suportadas do Red Hat OpenShift para clusters Red Hat® OpenShift® on IBM Cloud®.
Visualize informações de mudanças de versão para atualizações principais, secundárias e de correção que estão disponíveis para seus clusters do Red Hat® OpenShift® on IBM Cloud®. As mudanças incluem atualizações para os componentes do Red Hat OpenShift, do Kubernetes e do IBM Cloud Provider.
A menos que indicado de outra forma nos logs de mudança, a versão do provedor IBM Cloud ativa APIs e recursos do Red Hat OpenShift que estão em beta. Os os recursos alfa do Red Hat OpenShift, que estão sujeitos a mudanças, estão desativados.
Verifique os Boletins de segurança sobre o status da IBM Cloud quanto a vulnerabilidades de segurança que afetam o Red Hat OpenShift on IBM Cloud. É possível filtrar os resultados para visualizar apenas os boletins de segurança do Serviço do Kubernetes que são relevantes para o Red Hat OpenShift on IBM Cloud. As entradas de log de mudanças que abordam outras vulnerabilidades de segurança, mas também não se referem a um boletim de segurança da IBM, são para vulnerabilidades que não são conhecidas por afetar o Red Hat OpenShift on IBM Cloud em seu uso normal. Se executar contêineres privilegiados, comandos nos trabalhadores ou código não confiável, você poderá estar em risco.
As atualizações de correção principal são aplicadas automaticamente. As atualizações de correção de nó do trabalhador podem ser aplicadas recarregando ou atualizando os nós do trabalhador. Para obter mais informações sobre versões principais, secundárias e de correção, bem como sobre as ações de preparação entre versões secundárias, consulte as informações sobre versões em Red Hat OpenShift.
Para obter mais detalhes sobre as versões do projeto “ Red Hat OpenShift ” e “ Kubernetes ”, consulte as notas de lançamento em Red Hat OpenShift.
Versões do Red Hat OpenShift disponíveis
O Red Hat OpenShift on IBM Cloud suporta as versões a seguir do Red Hat OpenShift. Note que diferentes Red Hat OpenShift versões podem suportar diferentes versões RHEL.
Todos os clusters VPC criados na versão 4.18 ou posterior podem usar nós de trabalho RHCOS. Os clusters criados nas versões 4.15, 4.16, ou 4.17 só podem usar nós de trabalho RHCOS se tiverem sido inicialmente criados com nós de trabalho RHCOS ou se tiverem sido atualizados para, pelo menos, a versão 4.18.
†Indica datas que estão tentativas e sujeitas a mudanças.*Indica os sistemas operacionais que estão obsoletos.
Clusters do VPC
| Versão | Data de liberação | Término de suporte | Sistemas operacionais | Links relacionados |
|---|---|---|---|---|
| 4.21 ( Kubernetes 1.33 ) Padrão | 13 de maio de 2026 | 22 de março de 2028† | Red Hat CoreOS RHEL 9* |
|
| 4.20 (Kubernetes 1.33) | 04 de fevereiro de 2026 | 19 de janeiro de 2028† | Red Hat CoreOS RHEL 9* |
|
| 4.19 (Kubernetes 1.32) | 3 de setembro de 2025 | 28 de julho de 2027† | Red Hat CoreOS RHEL 9* |
|
| 4.18 (Kubernetes 1.31) | 23 de maio de 2025 | 26 de maio de 2027† | Red Hat CoreOS RHEL 9* |
|
| 4.17 (Kubernetes 1.30) | 20 de novembro de 2024 | 23 de outubro de 2026† | Red Hat CoreOS, RHEL 9, RHEL 8 | |
| 4.16 ( Kubernetes 1.29 ) Obsoleto | 30 de agosto de 2024 | 26 de agosto de 2026 | Red Hat CoreOS, RHEL 9, RHEL 8 |
Classic clusters
| Versão | Data de liberação | Término de suporte | Sistemas operacionais | Links relacionados |
|---|---|---|---|---|
| 4.21 ( Kubernetes 1.33 ) Padrão | 13 de maio de 2026 | 22 de março de 2028† | RHEL 9 | |
| 4.20 (Kubernetes 1.33) | 04 de fevereiro de 2026 | 19 de janeiro de 2028† | RHEL 9 | |
| 4.19 (Kubernetes 1.32) | 3 de setembro de 2025 | 28 de julho de 2027† | RHEL 9 | |
| 4.18 (Kubernetes 1.31) | 23 de maio de 2025 | 26 de maio de 2027† | RHEL 9 | |
| 4.17 (Kubernetes 1.30) | 20 de novembro de 2024 | 23 de outubro de 2026† | RHEL 9 (padrão), RHEL 8 |
|
| 4.16 ( Kubernetes 1.29 ) Obsoleto | 30 de agosto de 2024 | 26 de agosto de 2026 | RHEL 9 (padrão), RHEL 8 |
Clusters em locais d Satellite
| Versão | Data de liberação | Término de suporte | Sistemas operacionais | Links relacionados |
|---|---|---|---|---|
| 4.21 ( Kubernetes 1.33 ) Padrão | 04 de fevereiro de 2026 | 19 de janeiro de 2028† | Red Hat CoreOS RHEL 9 |
|
| 4.20 (Kubernetes 1.33) | 04 de fevereiro de 2026 | 10 de novembro de 2027† | Red Hat CoreOS RHEL 9 |
|
| 4.19 (Kubernetes 1.32) | 3 de setembro de 2025 | 26 de maio de 2027† | Red Hat CoreOS RHEL 9 |
|
| 4.18 (Kubernetes 1.31) | 23 de maio de 2025 | 24 de março de 2027† | Red Hat CoreOS RHEL 9 |
|
| 4.17 (Kubernetes 1.30) | 20 de novembro de 2024 | 23 de outubro de 2026† | Red Hat CoreOS, RHEL 9, RHEL 8 | |
| 4.16 ( Kubernetes 1.29 ) Obsoleto | 30 de agosto de 2024 | 26 de agosto de 2026 | Red Hat CoreOS, RHEL 9, RHEL 8 |
†Indica datas que estão tentativas e sujeitas a mudanças.*Indica os sistemas operacionais que estão obsoletos.
- Versões não suportadas:
- Para obter informações sobre versões não suportadas, consulte o archive.
Ciclo de vida da liberação
Cada versão suportada do Red Hat OpenShift on IBM Cloud 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.
-
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 Red Hat OpenShift on IBM Cloud.
-
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 entrou no suporte de manutenção conforme definido pelo suporte do Red Hat. A IBM fornece suporte de manutenção para OpenShift com base na política Red Hat. Caso contrário, a IBM fornecerá suporte integral
- suporte estendido
- A liberação inseriu suporte estendido conforme definido pelo Red Hat. A IBM fornece suporte estendido para OpenShift com base na política Red Hat. Caso contrário, a IBM fornecerá suporte integral
-
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 fornece suporte mínimo para a liberação em alinhamento com o suporte Red Hat. 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,
-
Versão sem suporte: Esta versão não tem suporte. 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
NotReadyou um Ingress não saudável. -
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.
A IBM fornece pacotes de correção de nó do trabalhador bi-semanal. IBM o objetivo da empresa é corrigir as vulnerabilidades legítimas detectadas em um prazo adequado aos riscos que elas representam. Para garantir a qualidade e a estabilidade da liberação, os pacotes de correção podem ser atrasados.
Para Red Hat OpenShift, os pacotes de correção são aplicados na mais recente liberação menor e patch para o sistema operacional direcionado.
- Para RHEL8 que é 8.9.
Para manter seus nós seguros, deve-se instalar os fix packs do nó do trabalhador o mais rápido possível Você pode se inscrever em notificações para serem alertadas quando uma nova atualização estiver disponível.
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.