4.15 información sobre la versión y acciones de actualización
Esta versión está obsoleta. Actualice su clúster a una versión compatible lo antes posible.
Revise la información sobre la versión 4.15 de Red Hat OpenShift on IBM Cloud. Esta versión se basa en la versión Kubernetes 1.28.
¿Busca información general sobre cómo actualizar clústeres o información sobre una versión diferente? Consulte Red Hat Red Hat OpenShift en IBM Cloud y las notas del release de la versión 4.15.
Red Hat OpenShift on IBM Cloud es un producto certificado Kubernetes para la versión 1.28 en el marco del programa de certificación de conformidad de software CNCF Kubernetes. 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
En la tabla siguiente figura el calendario previsto para el lanzamiento de la versión 4.15. 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.15 / 1.28 | 24 de abril de 2024 | 8 de enero de 2026† |
Preparación para la actualización
Revise los cambios que podría tener que realizar al actualizar un clúster a la versión 4.15. Esta información resume las actualizaciones que probablemente tengan un impacto en las aplicaciones desplegadas cuando se actualice.
La gráfica Helm de copia de seguridad y restauración está soportada en los clústeres Red Hat OpenShift on IBM Cloud 4.15. Sin embargo, sólo se da soporte a los puntos finales directos de COS. Por ejemplo: s3.direct.us.cloud-object-storage.appdomain.cloud
.
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.
Tipo | Descripción |
---|---|
No soportado: caído en desuso y eliminado de las características de OpenShift | Para obtener más información, revise las características OpenShift versión 4.15 en desuso y eliminadas y Preparación de la actualización a OpenShift Container Platform 4.15 para ver las posibles acciones necesarias. |
Problemas conocidos de OpenShift | Para obtener más información, revise los problemas conocidos de OpenShift versión 4.15 para ver las posibles acciones necesarias. |
La actualización requiere la moneda de la versión del clúster de OpenShift | Una actualización del nodo maestro del clúster se cancela cuando el estado de la versión del clúster OpenShift indica que ya hay una actualización en curso. Ver Por que OpenShift mostrar que la versión del clúster no está actualizada para detalles. |
La actualización requiere resolución a condiciones actualizables de la versión de clúster de OpenShift | Upgradeable Ahora se cancelará una actualización de maestro de clúster si la condición de estado de la versión del clúster ( OpenShift ) indica que el clúster no se puede actualizar. Consulte ¿Por qué veo un mensaje de Cannot complete cluster master upgrade ? para obtener más detalles. |
Cambios en las pasarelas VPE al crear o actualizar un clúster VPC a la versión 4.15 | Hay cambios importantes en los gateways VPE utilizados para los clusters VPC cuando se crea un cluster 4.15 o se actualiza a 4.15. Estos cambios podrían requerir la adopción de medidas. Para revisar los cambios y determinar las acciones necesarias, consulte la información sobre la creación de gateways VPE. |
Comprobación del estado de su clúster en Upgradeable
Ejecute el siguiente comando para comprobar el estado Upgradeable
de su clúster.
oc get clusterversion version -o json | jq '.status.conditions[] | select(.type == "Upgradeable")'
Salida de ejemplo donde el estado de Upgradeable
es False
.
{
"lastTransitionTime": "2023-10-04T15:55:54Z",
"message": "Kubernetes 1.27 and therefore OpenShift 4.15 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/6958395 for details and instructions.",
"reason": "AdminAckRequired",
"status": "False",
"type": "Upgradeable"
}
Si el estado de Upgradeable
es False
, la información de condición proporciona instrucciones que deben seguirse antes de la actualización. Para obtener más información, consulte Proporcionar el acuse de recibo del administrador.
Cambios importantes de red para clústeres de VPC creados en la versión 4.15
A partir de la versión 4.15, Red Hat OpenShift on IBM Cloud ha introducido una nueva característica de seguridad para los clústeres de VPC denominada Secure by Default Cluster VPC Networking.
En un nivel alto, la postura de seguridad para los clústeres de VPC de Red Hat OpenShift on IBM Cloud ha cambiado de permitir todo el tráfico de salida y, a continuación, proporcionar a los usuarios mecanismos para bloquear selectivamente el tráfico según sea necesario a bloquear ahora todo el tráfico que no es crucial para la funcionalidad del clúster y proporcionar a los usuarios mecanismos para permitir selectivamente el tráfico según sea necesario.
Al suministrar un nuevo clúster de VPC de Red Hat OpenShift on IBM Cloud en la versión 4.15 o posterior, el comportamiento de suministro predeterminado es permitir sólo el tráfico necesario para que funcione el clúster. Todos los demás accesos están bloqueados. Para implementar Secure by Default Networking, hay cambios en los valores predeterminados de los grupos de seguridad de VPC, así como nuevos puntos finales privados virtuales (VPE) para los servicios comunes de IBM.
Algunas notas clave para Secure by Default Networking son:
-
Sólo se aplica a clústeres de VPC. Los clústeres clásicos no se ven afectados.
-
No afecta a los clústeres existentes. Los clústeres existentes en la VPC seguirán funcionando como lo hacen hoy.
-
Sólo se aplica a los clústeres Red Hat OpenShift on IBM Cloud recién suministrados en la versión 4.15. Las configuraciones de grupo de seguridad para los clústeres Red Hat OpenShift on IBM Cloud existentes que se han actualizado a la versión 4.15, incluidas las personalizaciones que ha realizado, no se modifican.
-
El comportamiento predeterminado para los clústeres creados en la versión 4.15 y posteriores es habilitar la protección de tráfico de salida segura por omisión. Sin embargo, los nuevos parámetros de la interfaz de usuario, la CLI, la API y Terraform le permiten inhabilitar esta característica. También puede habilitar e inhabilitar la protección del tráfico de salida después de crear un clúster.
-
Si la VPC utiliza un programa de resolución de DNS personalizado, el suministro de un clúster de la nueva versión 4.15 añade automáticamente reglas que permiten el tráfico a través de las direcciones IP del programa de resolución en el grupo de seguridad gestionado por IKS (
kube-<clusterID>
).
Para obtener una visión general de la red de VPC de clúster segura por omisión, incluidos los grupos de seguridad, las reglas y los VPE que se crean de forma predeterminada, consulte Descripción de la red de VPC de clúster segura por omisión.
¿Qué conexiones están permitidas?
En los clústeres de VPC con la protección de tráfico de salida segura por omisión habilitada, se permiten las conexiones siguientes.
- Acceso a los registros internos de IBM
*.icr.io
para extraer las imágenes de contenedor necesarias a través de una pasarela VPE. - Acceso al maestro de clúster y a las API de Red Hat OpenShift on IBM Cloud a través de pasarelas VPE.
- Acceso a otros servicios esenciales de IBM como, por ejemplo, el registro y la supervisión a través de la red privada de IBM.
- Accediendo a IBM Cloud DNS.
¿Qué conexiones están bloqueadas?
Revise los ejemplos siguientes de conexiones que están bloqueadas de forma predeterminada. Tenga en cuenta que puede habilitar de forma selectiva el tráfico de salida a estos u otros orígenes externos que necesita la app.
- Extracción de imágenes de registros públicos como, por ejemplo, quay.io y Docker Hub.
- Acceso a Red Hat Marketplace y OperatorHub.
- Acceso a cualquier servicio a través de la red pública.
Cambios en la comunicación de copia de seguridad de trabajador a maestro
Los trabajadores de clúster de VPC utilizan la red privada para comunicarse con el maestro de clúster. Anteriormente, para los clústeres de VPC que tenían el punto final de servicio público habilitado, si la red privada estaba bloqueada o no estaba disponible, los trabajadores del clúster podían volver a utilizar la red pública para comunicarse con el maestro del clúster.
En clústeres con protección de tráfico de salida segura por omisión, volver a la red pública no es una opción porque el tráfico de salida público de los trabajadores del clúster está bloqueado. Es posible que desee inhabilitar la protección
del tráfico de salida para permitir esta opción de copia de seguridad de red pública, sin embargo, existe una alternativa mejor. En su lugar, si hay un problema temporal con la conexión de trabajador a maestro a través de la red privada,
entonces, en ese momento, puede añadir una regla de grupo de seguridad temporal al grupo de seguridad kube-clusterID
para permitir el tráfico de salida al puerto apiserver
maestro del clúster. De esta forma, solo
se permite el tráfico para apiserver
en lugar de todo el tráfico. Más adelante, cuando se resuelva el problema, puede eliminar la regla temporal.
Permitir el tráfico de salida después de crear un clúster 4.15
Si ha creado un clúster de la versión 4.15 con la protección de tráfico de salida habilitada, es posible que las apps o los servicios experimenten un tiempo de inactividad debido a las dependencias que requieren conexiones de red externas. Revise las opciones siguientes para habilitar el tráfico de salida de forma selectiva o para permitir todo el tráfico de salida.
Para obtener más información, consulte Gestión de la protección del tráfico de salida en clústeres de VPC.
Información sobre la creación de pasarelas VPE
Cuando se crea un clúster VPC o se actualiza a la versión 4.15, se crean los siguientes gateways VPE si no existen.
VPE Nombre(s) DNS | Servicio | Versiones |
---|---|---|
s3.direct.<region>.cloud-object-storage.appdomain.cloud y *.s3.direct.<region>.cloud-object-storage.appdomain.cloud |
Cloud Object Storage | Versión 4.15 y posteriores |
config.direct.cloud-object-storage.cloud.ibm.com |
Cloud Object Storage Configuración | Versión 4.15 y posteriores |
<region>.private.iaas.cloud.ibm.com |
Infraestructura de VPC | Versión 4.15 y posteriores |
icr.io y " *.icr.io * |
Container Registry | Versión 4.14 y posteriores |
api.<region>.containers.cloud.ibm.com * |
Red Hat OpenShift on IBM Cloud | Versión 4.14 y posteriores |
- Para los clusters actualizados a ' 4.15, estos VPE Gateways ya deberían existir puesto que se habrían creado cuando el cluster estaba en ' 4.14.
Estas puertas de enlace VPE son compartidas por todos los recursos de la VPC y, cuando se crean por primera vez, cambian las direcciones IP asociadas a estos servicios, además de restringir el acceso a los mismos.
Si alguno de los recursos de la VPC utiliza alguno de estos servicios en los que aún no existe el Gateway VPE, debe realizar las acciones que se describen a continuación tanto antes como posiblemente durante la actualización para garantizar que los recursos sigan teniendo acceso.
Los pasos a seguir son diferentes según se trate de crear un nuevo clúster 4.15 o de actualizar el maestro de un clúster 4.14 existente.
- Los nuevos clusters 4.15 obtienen las configuraciones Secure by Default descritas anteriormente.
- Los clusters 4.14 existentes actualizados siguen utilizando el antiguo modelo de grupos de seguridad.
Pasarelas VPE creadas al actualizar a la versión 4.15
Se crean tres nuevos Gateways VPE para 4.15 si no existen ya en la VPC. Además, se añade una dirección IP por zona a cada puerta de enlace VPE para cada zona que tenga trabajadores de clúster. Estas direcciones IP se toman de una de las subredes VPC existentes en esa zona.
Las pasarelas VPE se colocan en el grupo de seguridad existente " kube-<vpcID>
", que por defecto permite todo el tráfico. A menos que haya modificado este grupo de seguridad, no necesita añadir ninguna regla para
permitir el acceso entrante a estos nuevos gateways VPE.
Si ha modificado el grupo de seguridad " kube-<vpcID>
", debe asegurarse de que todos los recursos de la VPC que utilizan estos servicios tienen permitido el acceso entrante a este grupo de seguridad. Además, asegúrese
de que no haya ACL de red en las subredes, grupos de seguridad en los propios recursos o rutas VPC personalizadas que bloqueen el acceso a estas nuevas puertas de enlace VPE.
Nueva configuración del gateway VPE al crear un nuevo cluster 4.15
Se crean cinco nuevos gateways VPE si aún no existen en la VPC. Además, se añade una dirección IP por zona a cada VPE Gateway para cada zona que tenga cluster workers. Estas direcciones IP se toman de una de las subredes VPC existentes en esa zona.
Las pasarelas VPE se colocan en un nuevo grupo de seguridad kube-vpegw-<vpcID>
, que sólo permite el tráfico entrante a estas nuevas pasarelas VPE desde el grupo de seguridad de trabajadores de clúster kube-<clusterID>
.
Antes de crear su clúster, para cualquier recurso en su VPC que acceda a cualquiera de estos puntos finales, asegúrese de que no haya ACL de red en las subredes, grupos de seguridad en los propios recursos o rutas VPC personalizadas que bloqueen el acceso a estas nuevas puertas de enlace VPE.
Mientras se actualiza su clúster, esté atento a la creación del grupo de seguridad " kube-vpegw-<vpcID>
". Una vez creado, añada las reglas de entrada necesarias para permitir que todos sus recursos que no sean
cluster workers accedan a los nuevos gateways VPE que se están creando. Tenga en cuenta que todos los trabajadores del clúster en la VPC ya pueden acceder a estas puertas de enlace VPE a través de reglas de grupo de seguridad que se añaden
automáticamente al crear el clúster.
Para obtener más información sobre un caso de uso similar, consulte Solución de problemas de aplicaciones VPC.
Problemas comunes y resolución de problemas
- Después de habilitar la protección del tráfico de salida en mi clúster 4.15, mi app ya no funciona.
- Cuando intento crear un clúster de la versión 4.15, veo un error de cuota.
- Cuando actualizo mi clúster para proteger de forma predeterminada, mi app nodeport ya no funciona.
- ¿Por qué veo anomalías de DNS después de añadir un programa de resolución de DNS personalizado?.
- Después de crear un clúster de la versión 4.15, las aplicaciones que se ejecutan en otros clústeres de mi VPC fallan.