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ántica, 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: publicada aproximadamente cada tres 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 está en la versión 4.9 y 4.10 es la versión secundaria más reciente disponible con carácter general para la serie 4, debe actualizar a la versión 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, los canales de actualización de OCP 4.9 nunca incluirán 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 estable-4.10 para actualizar desde una versión secundaria anterior de Red Hat OpenShift en Azure. No se admitirán 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 (a la que llamaremos N)
- Una versión secundaria anterior (N-1)
Si está disponible en un canal de actualización estable, también se admiten las versiones secundarias más recientes (N+1, N+2) disponibles en OCP ascendente.
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 presenta hoy la versión 4.10.z, se proporciona compatibilidad con 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 la versión 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, supongamos que la lista de versiones admitidas actual es 4.10.z y 4.9.z. Cuando Red Hat OpenShift de Azure publique la versión 4.11.z, se quitará la versión 4.9.z y no 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 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 SRE de Red Hat OpenShift en Azure se reserva el derecho de agregar o quitar versiones nuevas o existentes o retrasar las próximas versiones secundarias que se han identificado para tener uno o varios problemas críticos de producción que afectan a errores o problemas de seguridad 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 | 4.13 GA |
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 en cuanto hay 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, está fuera del soporte técnico y se le pedirá que actualice para seguir recibiendo soporte técnico. La actualización de una versión anterior a una versión compatible puede ser difícil y, en algunos casos, no es posible. 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 de Azure compatible más antigua es 4.9.z y está en la versión 4.8.z o anterior, está fuera del soporte técnico.
- Cuando la actualización de 4.8.z a 4.9.z o superior se realiza correctamente, vuelve a estar 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 compatible, el clúster está "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.
- Los clústeres fuera del soporte técnico no se supervisarán.