Ciclo de vida del soporte técnico de Red Hat OpenShift en Azure 4

Red Hat publica versiones secundarias de Red Hat OpenShift Container Platform (OCP) aproximadamente cada cuatro meses. Estas versiones incluyen nuevas características y mejoras. Las versiones de revisión son más frecuentes (normalmente semanales) y solo están previstas para correcciones de errores críticos en una versión secundaria. Estas versiones de revisión pueden incluir correcciones para vulnerabilidades de seguridad o errores importantes.

Red Hat OpenShift en Azure se crea a partir de versiones específicas de OCP. En este artículo se describen las versiones de OCP que se admiten en Red Hat OpenShift en Azure y se detallan las actualizaciones, las caídas en desuso y la directiva de soporte técnico.

Versiones de Red Hat OpenShift

Red Hat OpenShift Container Platform usa el control de versiones semántico. El control de versiones semántico utiliza diferentes niveles de número de versión para especificar diferentes niveles de control de versiones. En la tabla siguiente se muestran las distintas partes de un número de versión semántico, en este caso, con el número de versión de ejemplo 4.10.3.

Versión principal (x) Versión secundaria (y) Revisión (z)
4 10 3

Cada número en la versión indica compatibilidad general con la versión anterior:

  • Versión principal: no se han planeado versiones principales en este momento. Las versiones principales cambian cuando cambia una API incompatible o la compatibilidad con versiones anteriores deja de funcionar.
  • Versión secundaria: publicado aproximadamente cada cuatro meses. Las actualizaciones de versiones secundarias pueden incluir adiciones de características, mejoras, caídas en desuso, eliminaciones, correcciones de errores, mejoras de seguridad y otras actualizaciones.
  • Revisiones: normalmente se publican cada semana, o según sea necesario. Las actualizaciones de versiones de revisión pueden incluir correcciones de errores, mejoras de seguridad y otras actualizaciones.

Los clientes deben tratar de ejecutar la última versión secundaria de su versión principal. Por ejemplo, si el clúster de producción ejecuta la versión 4.9 y 4.10 es la última versión secundaria disponible con carácter general para la serie 4, debe actualizar a 4.10 tan pronto como pueda.

Canales de actualización

Los canales de actualización están vinculados a una versión secundaria de Red Hat OpenShift Container Platform (OCP). Por ejemplo, la actualización de OCP 4.9 nunca incluyen una actualización a una versión 4.10. Los canales de actualización controlan solo la selección de versión y no afectan a la versión del clúster.

Red Hat OpenShift 4 en Azure admite solo canales estables. Por ejemplo: stable-4.9.

Puede usar el canal stable-4.10 para actualizar desde una versión secundaria anterior de Red Hat OpenShift en Azure. No se admiten los clústeres actualizados con canales rápidos, de versión preliminar y candidatos.

Si cambia a un canal que no incluye la versión actual, se muestra una alerta y no se recomienda ninguna actualización. Sin embargo, puede volver a cambiar de forma segura al canal original en cualquier momento.

Directiva de compatibilidad de la versión de Red Hat OpenShift Container Platform

Red Hat OpenShift en Azure admite dos versiones secundarias de disponibilidad general (GA) de Red Hat OpenShift Container Platform:

  • La versión secundaria con disponibilidad general (GA) más reciente publicada en Red Hat OpenShift en Azure (denominada N)

  • Una versión secundaria anterior (N-1)

Si está disponible en un canal de actualización estable, también se pueden admitir las versiones secundarias más recientes (N+1, N+2) disponibles en las versiones de OCP anteriores.

Las actualizaciones de revisión críticas se aplican automáticamente a los clústeres por parte de los ingenieros de confiabilidad de sitios de Red Hat OpenShift en Azure. Los clientes que deseen instalar las actualizaciones de revisión con anterioridad pueden hacerlo libremente.

Por ejemplo, si Red Hat OpenShift en Azure publica 4.10.z hoy, se proporciona soporte técnico para las siguientes versiones:

Nueva versión secundaria Lista de versiones admitidas
4.10.z 4.10.z, 4.9.z

Nota:

La tabla anterior es simplemente un ejemplo para ilustrar la compatibilidad con el ciclo de vida; no está pensado como una lista de versiones admitidas actualmente.

"z" representa las versiones de revisión. Si está disponible en un canal de actualización estable, los clientes también pueden actualizar a 4.9.z.

Cuando se publica una nueva versión secundaria, la versión secundaria más antigua cae en desuso y se quita. Por ejemplo, pongamos que la lista de versiones admitidas actual es 4.10.z y 4.9.z. Cuando Red Hat OpenShift en Azure publique 4.11.z, se quitará la versión 4.9.z y dejará de ser compatible en un plazo de 30 días.

Nota:

Tenga en cuenta que si los clientes ejecutan una versión incompatible de Red Hat OpenShift, se les podría pedir que actualicen al solicitar soporte técnico para el clúster. Los clústeres que ejecutan versiones de Red Hat OpenShift no compatibles no están incluidos en el contrato de nivel de servicio de Red Hat OpenShift en Azure.

Proceso de publicación y desuso

Puede consultar las próximas publicaciones de versiones y las que se quedarán obsoletas en el calendario de publicación de Red Hat OpenShift en Azure.

Para las nuevas versiones secundarias de Red Hat OpenShift Container Platform:

  • El equipo de ingenieros de confiabilidad de sitios de Red Hat OpenShift en Azure publica un anuncio previo con la fecha planificada de la nueva publicación de una versión y el respectivo desuso de una versión antigua en las notas de la versión de Red Hat OpenShift en Azure al menos 30 días antes de la eliminación.
  • Este equipo publica una notificación de estado del servicio disponible para todos los clientes con Red Hat OpenShift en Azure y acceso al portal, y envía un correo electrónico a los administradores de suscripciones con las fechas de eliminación de versión planeadas.
  • Los clientes tienen 30 días a partir de la eliminación de una versión para actualizar a una versión secundaria compatible para seguir recibiendo soporte técnico.

Para las nuevas versiones de revisión de Red Hat OpenShift Container Platform:

  • Debido a la naturaleza urgente de las versiones de revisión, se pueden introducir en el servicio por parte del equipo de ingenieros de confiabilidad de sitios de Red Hat OpenShift en Azure a medida que estén disponibles.
  • En general, este equipo no realiza grandes comunicaciones para la instalación de nuevas versiones de revisión. Sin embargo, supervisa y valida constantemente las revisiones de CVE disponibles para admitirlas de manera puntual. Si se requiere una acción del cliente, el equipo enviará una notificación sobre la actualización.

Excepciones de directiva de versiones admitidas

El equipo de ingenieros de confiabilidad de sitios de Red Hat OpenShift en Azure se reserva el derecho de agregar o eliminar versiones nuevas o existentes, o aplazar próximas versiones secundarias, donde se hayan identificado uno o varios problemas de seguridad o errores críticos que afecten a la producción sin previo aviso.

Las versiones de revisión específicas se pueden omitir, o su implantación puede verse acelerada en función de la gravedad del error o el problema de seguridad.

Versiones de Azure Portal y CLI

Al implementar un clúster de Red Hat OpenShift en Azure en el portal o con la CLI de Azure, el valor predeterminado del clúster es la última versión secundaria (N) y la revisión crítica más reciente. Por ejemplo, si Red Hat OpenShift en Azure admite 4.10.z y 4.9.z, la versión predeterminada para las nuevas instalaciones es 4.10.z. Los clientes que quieran usar la última versión secundaria de OCP anterior (N+1, N+2) pueden actualizar su clúster en cualquier momento a cualquier versión disponible en los canales de actualización estables.

Calendario de versiones de Red Hat OpenShift en Azure

Consulte la siguiente guía para ver el historial anterior de versiones (precedentes) de OpenShift Container Platform.

Versión de OCP Versión anterior Disponibilidad general de Red Hat OpenShift en Azure Fin de la vida útil
4.4. Mayo de 2020 Julio de 2020 4.6 Disponibilidad general
4.5 Julio de 2020 Noviembre de 2020 4.7 GA
4.6 Octubre de 2020 Febrero de 2021 4.8 GA
4.7 Febrero de 2021 15 de julio de 2021 4.9 GA
4.8 Julio de 2021 15 de septiembre de 2021 4.10 GA
4,9 Noviembre de 2021 1 de febrero de 2022 4.11 GA
4.10 Marzo de 2022 21 de junio de 2022 4.12 GA
4.11 Agosto de 2022 2 de marzo de 2023 10 de febrero de 2024
4,12 Enero de 2023 19 de agosto de 2023 17 de julio de 2024
4.13 Mayo de 2023 15 de diciembre de 2023 17 de noviembre de 2024

Importante

A partir de la versión 4.12 de ARO, el ciclo de vida de soporte técnico para las nuevas versiones se establecerá en 14 meses a partir del día de la disponibilidad general. Esto significa que la fecha de finalización para admitir cada versión ya no dependerá de la versión anterior (como se muestra en la tabla anterior para la versión 4.12). Esto no afecta a la compatibilidad con la versión anterior; Se seguirán admitiendo dos versiones secundarias (GA) con carácter general de Red Hat OpenShift Container Platform, como se explicó anteriormente.

Preguntas más frecuentes

¿Qué ocurre cuando un cliente actualiza un clúster de OpenShift con una versión secundaria que no es compatible?

Red Hat OpenShift en Azure admite la instalación de dos versiones secundarias en el momento de la instalación. Se admite una versión tan pronto como esté disponible una ruta de actualización a esa versión. Si está ejecutando una versión más allá de la fecha de EOL anterior, quedará fuera del soporte técnico y se le pedirá que actualice la versión para seguir recibiéndolo. Puede que resulte difícil y, en algunos casos, imposible actualizar una versión anterior a una versión compatible. Se recomienda mantener el clúster con la versión más reciente de OpenShift para evitar posibles problemas de actualización.

Por ejemplo:

  • Si la versión de Red Hat OpenShift en Azure admitida más antigua es la 4.9.z y la suya es la 4.8.z o anterior, está fuera del soporte técnico.
  • Si la actualización de 4.8.z a 4.9.z se realiza correctamente, estará de nuevo dentro de nuestras directivas de soporte técnico.

No se admite la reversión del clúster a una versión anterior. Solo se admite la actualización a una versión más reciente.

¿Qué significa "fuera de soporte técnico"?

Si el clúster de ARO ejecuta una versión de OpenShift que no está en la lista de versiones admitidas o usa una configuración de clúster no admitida, dicho clúster queda “fuera del soporte técnico”. Como resultado:

  • Al abrir una incidencia de soporte técnico para el clúster, se le pedirá que actualice el clúster a una versión compatible antes de recibir soporte técnico, a menos que esté dentro del período de gracia de 30 días después de que finalice el soporte técnico de la versión.
  • Las garantías de tiempo de ejecución o contrato de nivel de servicio para clústeres fuera del soporte técnico quedan anuladas.
  • Los clústeres fuera del soporte técnico se revisarán dentro de lo posible.
  • Estos clústeres no se supervisarán.