Presentación de OpenShift Service Mesh 3.1

Ya se lanzó Red Hat OpenShift Service Mesh 3.1 y se incluye con Red Hat OpenShift Container Platform y Red Hat OpenShift Platform Plus. Este lanzamiento, que se basa en los proyectos Istio, Envoy y Kiali, actualiza la versión de Istio a 1.26 y la de Kiali a 2.11. Además, es compatible con OpenShift Container Platform 4.16 y las versiones posteriores.

Esta es la primera versión secundaria después de Red Hat OpenShift Service Mesh 3.0, una actualización importante para unificar OpenShift Service Mesh con el proyecto de la comunidad Istio, que incorpora la instalación y la gestión mediante el operador Sail. Gracias a este cambio, se garantiza que OpenShift Service Mesh pueda ofrecer las funciones estables más recientes de Istio con el soporte de Red Hat.

Actualización a OpenShift Service Mesh 3.1

Si ejecutas OpenShift Service Mesh 2.6 o las versiones anteriores, debes actualizarte a OpenShift Service Mesh 3.0 antes de instalar la versión 3.1. Recomendamos que migres a la actualización 3.0 lo antes posible, ya que la edición 2.6 llegará al final de su vida útil el 12 de marzo de 2026. En la documentación de OpenShift Service Mesh 3.0, se proporciona una guía detallada sobre la migración, que incluye un análisis de las diferencias entre las versiones 2.6 y 3.0.  

Recientemente, también publicamos un artículo en el que se describe la forma de usar la consola de Kiali para realizar migraciones entre OpenShift Service Mesh 2.6 y 3.0.

Para ver un ejemplo de la versión 3.0 en acción, con indicadores totalmente configurados y la consola de Kiali, explora este patrón de la solución.

Compatibilidad con Kubernetes Gateway API en OpenShift Container Platform 4.19 y las versiones posteriores

Kubernetes Gateway API es la última generación de API de Ingress, equilibradores de carga y malla de servicios de Kubernetes. Istio planea convertirlo en el conjunto predeterminado de API para crear y gestionar el tráfico mediante una malla de servicios. Además, es necesario para usar el modo Ambient. Ten en cuenta que no está previsto eliminar las API estables de Istio, como VirtualService, DestinationRule y otras. En ocasiones, es posible que sea necesario utilizarlas para aprovechar las funciones que aún no se han agregado a Kubernetes Gateway API.

Si bien OpenShift Service Mesh 3.0 incluía soporte para Kubernetes Gateway API, requería que los usuarios instalaran definiciones de recursos personalizados (CRD) sin soporte para aprovechar la función. Esto cambió a partir de OpenShift Container Platform 4.19 y las versiones posteriores, porque ahora las CRD que se requieren están disponibles de forma predeterminada en OpenShift. Ya no es necesario instalarlas por separado. Las CRD de Gateway API que se incluyen con OpenShift cuentan con el soporte completo de Red Hat.

Dado que buscamos ofrecer soporte optimizado para las cargas de trabajo de inteligencia artificial generativa y los patrones de tráfico, incluimos el soporte de la versión de prueba del proyecto Gateway API Inference Extension al adaptar esta función a OpenShift Service Mesh 3.1.

Compatibilidad general con la stack doble para clústeres con arquitectura x86

Con esta versión, OpenShift Service Mesh ofrece compatibilidad general con las cargas de trabajo de stack doble IPv4 e IPv6 en los clústeres de OpenShift que ejecutan sistemas de hardware x86. Para habilitar la compatibilidad con la stack doble en OpenShift Service Mesh, debes establecer la configuración ISTIO_DUAL_STACK como true en el recurso de clientes de Istio. Esto se demuestra en la documentación upstream de Sail Operator para la stack doble, así como en la guía de la comunidad de la stack doble de Istio. Próximamente, se publicará la documentación del producto OpenShift Service Mesh.

Migración a los contenedores de UBI Micro

En esta versión, se traslada la mayoría de los contenedores, incluidos los de clave istiod y proxy (Enovy), para que utilicen las imágenes base de UBI Micro. UBI Micro es la imagen de base universal (UBI) más pequeña de Red Hat Enterprise Linux y se obtiene al excluir un administrador de paquetes y todas sus dependencias, que normalmente se incluyen en una imagen de contenedor. La adopción de esta imagen de base permite reducir la superficie de ataque de las imágenes de contenedores que se distribuyen como parte de OpenShift Service Mesh.

Evolución hacia una malla de servicios sin sidecar: el modo Ambient de Istio

OpenShift Service Mesh 3.1 se basa en Istio 1.26 e incluye principalmente actualizaciones graduales en comparación con la versión 3.0, que se basó en Istio 1.24. Esto se debe a que la comunidad de Istio y de Red Hat se centran en la última generación del plano de datos de la malla de servicios: el modo Ambient de Istio.

Hemos visto un crecimiento constante en el uso de la malla de servicios en los últimos años, pero la necesidad de proxies de sidecar suele ser un obstáculo para la adopción debido a los recursos adicionales (en general, de memoria y CPU) que se requieren para ejecutar los contenedores sidecar junto a cada contenedor de aplicaciones. Esto complica la adopción de la malla de servicios, ya que los proxies de sidecar deben agregarse y actualizarse como parte del ciclo de vida del pod. Es por eso que las aplicaciones deben reiniciarse para introducir una actualización de la malla.

El modo Ambient de Istio tiene como objetivo abordar estas dificultades eliminando la necesidad de utilizar proxies de sidecar y dividiendo el plano de datos de Istio en dos capas separadas. Así, se podrán adoptar de manera gradual las funciones de la malla de servicios con menos complejidad para los propietarios de las aplicaciones.

Con esta arquitectura dividida, para habilitar la malla se implementa una cantidad mucho menor de proxies, lo que reduce significativamente los recursos necesarios para ejecutarla. Debido a que el modo Ambient de Istio no requiere proxies de sidecar, las aplicaciones se pueden agregar y eliminar de la malla sin necesidad de modificar o reiniciar los pods.

Estas son las dos capas separadas del modo Ambient de Istio:

• Ztunnel:  es un proxy ligero de nodo de la capa 4 (que se ejecuta como Daemonset en Kubernetes) y crea un socket de escucha dentro del espacio de nombres de red del pod de la aplicación para actualizar de forma transparente el tráfico del pod con cifrado mTLS. También se ocupa de la gestión de certificados e identidades únicamente para los pods en el nodo. Solo con Ztunnel, puedes lograr el cifrado mTLS automático, la telemetría de la capa 4 y la gestión de políticas.
• Waypoint: es un proxy opcional de Envoy, similar a una puerta de enlace, que se implementa para un conjunto de aplicaciones (y está limitado a un espacio de nombres de forma predeterminada) para proporcionar funciones de malla de la capa 7, como políticas de tráfico y seguridad de las aplicaciones, telemetría de las aplicaciones y funciones de recuperación de la malla. A diferencia de los sidecars, los proxies de Waypoint se pueden agregar según sea necesario y ajustarse independientemente de los contenedores de aplicaciones.

Para obtener más información sobre la arquitectura del modo Ambient de Istio y sus ventajas y desventajas, lee Try Istio Ambient Mode on Red Hat OpenShift.

Con OpenShift Service Mesh 3.1, el estado del modo Ambient de Istio pasa a ser una versión de prueba, con un proxy de Ztunnel que cuenta con soporte completo de Red Hat, usa OpenSSL para el cifrado y garantiza que esté diseñado para FIPS. Además, como parte de la guía de instalación, incluye documentación para comenzar a utilizar este modo en OpenShift. Esto se desarrollará en los próximos meses, a medida que nos acerquemos a la disponibilidad general.

Ten en cuenta que el modo Ambient de Istio requiere Kubernetes Gateway API, así que utilízalo en OpenShift Container Platform 4.19 o en las versiones posteriores, que incluyen los CRD de Gateway API con soporte que se instalan de forma predeterminada. Si deseas probar el modo en versiones anteriores de OpenShift, debes instalar los CRD sin soporte, como se describe en la documentación de la comunidad de Istio. Recuerda que la actualización a las CRD de Kubernetes Gateway API con soporte en OpenShift Container Platform 4.19 puede generar tiempo de inactividad.

También recomendamos experimentar con el modo Ambient de Istio en clústeres que aún no tengan instalado OpenShift Service Mesh para reducir la probabilidad de interferir con las implementaciones actuales de la malla de servicios. En el futuro, proporcionaremos documentación sobre la ejecución de un plano de datos de este modo junto con un plano de datos del modo sidecar, así como orientación para migrar las aplicaciones del modo sidecar al modo Ambient.

Ten presente que, desde la versión 1.26 de Istio, no todas las funciones del modo sidecar son compatibles con el modo Ambient y algunas permanecen en la etapa "Alpha" en la versión upstream de Istio. Es posible que el modo Ambient no sea adecuado para todos los casos prácticos de la malla de servicios. Las limitaciones más notables son las configuraciones de varios clústeres de red y la interoperabilidad entre los planos de datos de los modos Ambient y sidecar. Estas y otras funciones se encuentran en desarrollo en la comunidad de Istio.

Actualizaciones de Kiali

Kiali es la consola para la malla de servicios de Istio que se incluye con OpenShift Service Mesh. La versión 2.11 incluye muchas actualizaciones y mejoras (como el modo Ambient de Istio).

Actualizaciones de la página de la malla

La página de la malla sigue recibiendo mejoras en su función de panel principal para supervisar el estado de la infraestructura de Istio, que abarca el propio plano de control, los elementos del plano de datos y los complementos de determinación del estado interno de los sistemas, como Prometheus y Tempo. Esta versión incluye varias actualizaciones, por ejemplo, las puertas de enlace de Istio y los elementos del plano de datos del modo Ambient: Ztunnel y Waypoint. Desde la página de la malla, puedes examinar los elementos para acceder a la información más importante sobre el estado, incluidos los indicadores y las instantáneas de configuración relevantes para cada elemento.

Rendimiento y capacidad de ajuste con mallas grandes

Una preocupación común con Kiali es el rendimiento a medida que aumenta la cantidad de cargas de trabajo en la malla de servicios. En el pasado, la consola tenía dificultades para mantener la capacidad de respuesta con las mallas muy grandes. Ahora, en las preguntas frecuentes hay una nueva sección sobre el rendimiento que brinda orientación para usar Kiali con implementaciones de mallas de servicios grandes. Esta versión incorpora actualizaciones para aumentar el rendimiento, como las que sirven para gestionar mejor las mallas de gran tamaño.

Por ejemplo, una función predeterminada de Kiali es intentar renderizar una página de inmediato y actualizar automáticamente la mayoría de las páginas según la configuración en el menú desplegable Refresh Interval. En el caso de las mallas muy grandes, hasta el renderizado inicial puede ser lento, lo cual retrasa la posibilidad de usar de la consola. En la actualidad, Kiali ofrece una configuración de actualización Manual, que solo actualiza una página cuando se hace clic manualmente en el botón Refresh. Esto se puede configurar con el parámetro spec.kiali_feature_flags.ui_defaults.refresh_interval: manual en la CRD de Kiali. 

Ahora también puedes deshabilitar las validaciones para mejorar el rendimiento y la capacidad de respuesta con las mallas grandes. Para ello, debes establecer a 0 la configuración spec.external_services.istio.validation_reconcile_interval del operador.

Comienza a utilizar OpenShift Service Mesh

Si es la primera vez que utilizas OpenShift Service Mesh, comienza con nuestra introducción y las instrucciones de instalación del día 1. Para ver un ejemplo práctico completo, explora el patrón de la solución Optimizing Traffic and Observability with OpenShift Service Mesh 3.

Si ya utilizas OpenShift Service Mesh 3.0, accede a ladocumentación para conocer los diferentes enfoques para actualizar el operador de OpenShift Service Mesh 3, los planos de control y el recurso de la interfaz de redes de contenedores (CNI) de Istio, y los proxies que conforman el plano de datos.

Si utilizas OpenShift Service Mesh 2.6 o una versión anterior, descubre las diferencias entre OpenShift Service Mesh 2 y 3 en nuestra extensa documentación sobre la migración. También hay una publicación del blog en la que se describe el procedimiento con Kiali.