4.22 Información sobre versiones y acciones de actualización
Consulta la información sobre la versión 4.22 de Red Hat OpenShift on IBM Cloud. Esta versión se basa en la versión Kubernetes 1.35.
¿Busca información general sobre cómo actualizar clústeres o información sobre una versión diferente? Consulte Red Hat Red Hat OpenShift para obtener información sobre las versiones de IBM Cloud y las notas de la versión 4.22.
Red Hat OpenShift on IBM Cloud Es un producto certificado Kubernetes para la versión 1.35 en el marco del programa de certificación de conformidad de software Kubernetes de la CNCF. Kubernetes® es una marca registrada de The Linux Foundation en Estados Unidos y otros países, y se utiliza en virtud de una licencia de The Linux Foundation.
Calendario de releases
La siguiente tabla incluye el calendario de lanzamientos previsto para la versión 4.22. Puede utilizar esta información con fines de planificación, por ejemplo, para estimar el momento en general en el que la versión puede dejar de estar soportada.
Las fechas que están marcadas con el símbolo † son provisionales y están sujetas a cambios.
| ¿Está soportada? | Versión de Red Hat OpenShift / Kubernetes | Fecha del release | Fecha no soportada |
|---|---|---|---|
| Soportado | 4.22 / 1.35 | 28 de septiembre de 2026 | 30 de junio de 2028† |
Preparación para la actualización
Revisa los cambios que quizá tengas que realizar al actualizar un clúster a la versión 4.22. Esta información resume las actualizaciones que probablemente tengan un impacto en las aplicaciones desplegadas cuando se actualice.
Los requisitos de dimensionamiento de la ubicación Satellite para alojar clústeres de la versión 4.22 Red Hat OpenShift on IBM Cloud ahora son los mismos independientemente de si la ubicación está basada en RHEL non-CoreOS o en RHEL CoreOS. Los requisitos para los nodos de ubicación deben ajustarse ahora a los de las ubicaciones de CoreOS-enabled.
Portworx Aún no es compatible con clústeres de Red Hat OpenShift on IBM Cloud versión 4.22. No actualices tu clúster a la versión 4.22 si tienes instalado Portworx.
A partir de la versión 4.22, el plano de control del clúster se aloja en el puerto 443 en lugar de en un puerto de nodo asignado dinámicamente (rango 20000-32767). El tráfico se enruta mediante un sistema de enrutamiento basado en nombres de
host a través de cuatro nombres de host creados específicamente para este fin: <cluster>.api.<region-domain>, <cluster>.oauth.<region-domain>, <cluster>.tunnel.<region-domain>,
y <cluster>.ignition.private.<region-domain>. Los nombres de .oauth. host y .api. están disponibles tanto en los puntos de conexión públicos como en los privados del servicio; los nombres
de .ignition.private. host y .tunnel. son exclusivamente privados. Este cambio afecta no solo al tráfico de cliente kubectl,oc sino también al tráfico entre los trabajadores y el plano de
control (API de kubelet, Konnectivity e ignition de RHCOS). Este cambio está disponible a partir de ahora en las siguientes regiones: Montreal (ca-mon), Chennai (in-che) y Mumbai (in-mum). Próximamente
se añadirá compatibilidad con otras regiones. Para obtener más información, consulta Plano de control del clúster accesible a través del puerto 443.
Antes de actualizar el nodo maestro
En la tabla siguiente se muestran las acciones que debe llevar a cabo antes de actualizar el nodo maestro del clúster.
En el caso de los clústeres que ejecutan la versión 4.22 o posterior, puede utilizar el comando oc adm upgrade status para comprobar el estado de actualización del maestro del clúster durante una actualización de la versión del
maestro. Para obtener más información, consulta Cómo consultar el estado de la actualización del clúster con el comando oc adm upgrade status.
| Tipo | Descripción |
|---|---|
| Puerto 443 para el plano de control del clúster | El plano de control del clúster ahora se sirve a través del puerto 443 en lugar de un puerto de nodo asignado dinámicamente (rango 20000-32767). Se utilizan cuatro nombres de host: <cluster>.api.<region-domain>,
<cluster>.oauth.<region-domain>, <cluster>.tunnel.<region-domain>, y <cluster>.ignition.private.<region-domain>. Los nombres de .ignition.private. host y .tunnel. son de uso exclusivamente privado. Esto afecta kubectl a oc los clientes, a la consola web oc login y al tráfico entre los trabajadores y el plano de control (kubelet,
Konnectivity e RHCOS Ignition). Acción necesaria: Actualiza cualquier regla de cortafuegos, grupo de seguridad o lista de permisos de salida que haga referencia al antiguo puerto de plano de control de número alto
para permitir el tráfico de salida HTTPS en el puerto 443 hacia los cuatro nombres de host. Si utilizas el punto de conexión del servicio público, descarga un nuevo archivo kubeconfig ejecutando ibmcloud ks cluster config o actualiza manualmente el puerto de tu archivo kubeconfig actual a 443. Si utilizas listas de permitidos basadas en direcciones IP, actualízalas para que utilicen los rangos de IP actuales de Akamai IPP, ya que los registros DNS de
los puntos finales del servicio público ahora se resuelven en direcciones front-end de Akamai IP Protect. Para obtener más información, consulta Introducción a las redes para clústeres ROKS y Plano de control del clúster accesible a través del puerto 443. |
| Preparación para actualizar OpenShift | Para obtener más información, consulta el documento Preparación para la actualización a OpenShift Container Platform 4.22 para conocer las posibles acciones necesarias. Las acciones de preparación para la actualización relacionadas con la copia de seguridad de etcd, la selección de versiones y la eliminación de SDN no se aplican a los clústeres de Red Hat OpenShift on IBM Cloud, ya que las acciones de copia de seguridad de etcd y de selección de versiones se gestionan automáticamente, y se utiliza Calico en lugar de SDN. |
| Funcionalidades de OpenShift obsoletas y eliminadas | Para obtener más información, consulta la versión de OpenShift Container Platform 4.22 sobre las funciones obsoletas y eliminadas para conocer las posibles medidas que debas tomar. |
| La actualización no requiere la aprobación del administrador | En esta versión no se han eliminado API. |
| Problemas conocidos de OpenShift | Para obtener más información, consulta la lista de problemas conocidos de la versión OpenShift Container Platform 4.22 para ver las posibles medidas que hay que tomar. |
| La actualización requiere que el clúster de OpenShift esté actualizado a la última versión | La actualización del nodo maestro del clúster se cancelará si el estado de la versión del clúster de OpenShift indica que ya se está realizando una actualización. Consulta ¿Por qué OpenShift indica que la versión del clúster no está actualizada? para obtener más detalles. |
| La actualización requiere que se cumplan las condiciones de actualización de la versión del clúster de OpenShift | La actualización del nodo maestro del clúster se cancelará si la condición de estado OpenShift (Actualizable) de la versión del clúster indica que el clúster no es actualizable. Para determinar si el clúster se puede actualizar, consulta Comprobación del estado de actualización de tu clúster. |
Comprobación del estado Upgradeable de su clúster
Ejecuta el siguiente comando para comprobar el estado Upgradeable de tu clúster.
oc get clusterversion version -o json | jq '.status.conditions[] | select(.type == "Upgradeable")'
Ejemplo de resultado cuando el estado Upgradeable es False.
{
"lastTransitionTime": "2024-11-17T19:29:34Z",
"message": "Cluster operator operator-lifecycle-manager should not be upgraded between minor versions: ClusterServiceVersions blocking cluster upgrade: default/test is incompatible with OpenShift minor versions greater than 4.16",
"reason": "IncompatibleOperatorsInstalled",
"status": "False",
"type": "Upgradeable"
}
Si el estado Upgradeable es False, la información sobre el estado proporciona instrucciones que deben seguirse antes de realizar la actualización.