Presentación de OpenShift Service Mesh 3.2 con el modo ambient de Istio

Nos complace anunciar la disponibilidad general de Red Hat OpenShift Service Mesh 3.2. Esta versión incluye la disponibilidad general del modo ambient de Istio, una nueva forma de implementar la malla de servicios sin sidecars que reduce significativamente los costos de recursos del uso de la malla de servicios. Esto proporciona una solución de baja sobrecarga para las redes de confianza cero con cifrado mTLS ligero de pod a pod y políticas de autorización basadas en las identidades de las cargas de trabajo, con la capacidad de agregar funciones más avanzadas según sea necesario.

Esta versión, que se basa en los proyectos Istio, Envoy y Kiali, actualiza la versión de Istio a 1.27 y de Kiali a 2.17, y es compatible con Red Hat OpenShift 4.18 y las versiones posteriores. 

Actualización a OpenShift Service Mesh 3.2

Si ejecutas OpenShift Service Mesh 2.6 o versiones anteriores, debes actualizar a las versiones 3.0, 3.1 y, luego, 3.2. Recomendamos migrar a OpenShift Service Mesh 3.0 de inmediato, ya que la versión 2.6 llegará al final de su vida útil (EOL) el 30 de junio de 2026 (recientelmente se extendió desde el 12 de marzo de 2026). En la documentación de OpenShift Service Mesh 3.0 encontrarás una guía detallada sobre la migración, que incluye un análisis de las diferencias entre OpenShift Service Mesh 2.6 y la versión 3.0. En esta publicación de blog, se describe el uso de la consola de Kiali para migrar entre OpenShift Service Mesh 2.6 y 3.0.

Para ver un ejemplo de OpenShift Service Mesh 3 en acción, con métricas completamente configuradas y la consola de Kiali, consulta este patrón de soluciones.

Malla de servicios sin sidecar: el modo ambient de Istio

Con esta versión, OpenShift Service Mesh es compatible con el modo ambient de Istio, que está disponible para el público en general. El modo ambient de Istio es una característica nueva e importante que habilita las funciones de la malla de servicios en las cargas de trabajo sin la necesidad de utilizar proxies de sidecar.

Con la arquitectura del plano de datos tradicional de Istio, conocida como "modo sidecar", cada pod de aplicaciones requiere un contenedor de proxy sidecar para habilitar las funciones de la malla de servicios. Si bien esto genera una arquitectura sencilla, genera una sobrecarga adicional cuando se ejecuta una malla de servicios, ya que se requiere un contenedor de proxy para cada contenedor de carga de trabajo de la aplicación. Esto también 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 de la aplicación y de la malla de servicios. Esto significa que las aplicaciones deben reiniciarse cuando se instala y actualiza la malla de servicios.

Con la arquitectura de modo ambient de Istio, el plano de datos se divide en dos niveles de proxy: los ztunnels y los waypoints, que cumplen distintas funciones. 

Proxy Ztunnel

Ztunnel es un proxy ligero de nivel de nodo compartido que intercepta el tráfico en la capa 4 y brinda seguridad (la "Z" significa "confianza cero") en forma de cifrado de seguridad de la capa de transporte mutuo (mTLS), autenticación, telemetría y políticas de autorización L4 simples basadas en las identidades de las aplicaciones. También proporciona métricas y registros básicos de la capa 4 (p. ej., TCP), los cuales, al igual que todas las métricas de la malla de servicios, se pueden visualizar mediante la consola de Kiali.

El hecho de que ztunnel esté escrito en Rust para este propósito especializado le permite lograr un alto rendimiento de proxy con una sobrecarga adicional mínima. 

Si bien ztunnel se ejecuta como un proxy de nivel de nodo, un DaemonSet de Kubernetes, implementa la redirección del tráfico dentro del espacio de nombres de red de cada pod. Esto significa que, desde la perspectiva del aislamiento de la red, la redirección y el cifrado del tráfico se producen dentro del pod y, por lo tanto, se mantienen el aislamiento y el cifrado del tráfico de pod a pod. En la documentación de Istio sobre la redirección del tráfico de ZTunnel, se analiza este tema con más detalle, junto con la forma en que el agente de CNI de Istio configura este redireccionamiento del tráfico.

Con el modo Ambient de Istio, si solo necesitas las funciones que ofrece ztunnel, este es el único proxy que debes ejecutar, lo que da como resultado una malla de servicios con un uso muy eficiente de los recursos.

Proxy de waypoint

Si los usuarios desean funciones de la malla de servicios en el nivel de la aplicación (capa 7), como la telemetría relacionada con HTTP o gRPC, la gestión del tráfico y las políticas de autorización, pueden incorporar proxies adicionales denominados "waypoints". Por lo general, se implementan por espacio de nombres, con un grupo de cargas de trabajo de aplicaciones estrechamente relacionadas. 

Además de las funciones que ya ofrece ztunnel, un proxy de waypoint agrega funciones como las siguientes:

• Equilibrio de carga y enrutamiento de HTTP, reintentos, tiempos de espera, interrupción de circuitos, limitación de frecuencia e inserción de errores.
• Políticas de autorización enriquecidas basadas en elementos primitivos de L7, como el tipo de solicitud o el encabezado HTTP
• Métricas HTTP, registro de acceso y rastreo

Los proxies de waypoint se gestionan de manera similar a las puertas de enlace de entrada, ya que los proxies independientes de Envoy y similares pueden tener un ciclo de vida con las cargas de trabajo de la aplicación en lugar de hacerlo con el plano de control de la malla de servicios o el ztunnel por nodo.

¿El modo ambient de Istio es adecuado para ti? ¿Cuáles son las ventajas y las desventajas? 

El modo Ambient de Istio aún está evolucionando en la comunidad de Istio y, en este momento, es ideal para las nuevas instalaciones de la malla de servicios, ya que existen algunas limitaciones al migrar o combinar con el modo sidecar (más sobre este tema a continuación).  

Se debe utilizar OpenShift 4.19 o una versión posterior para las definiciones de recursos personalizados (CRD) compatibles de la API de la puerta de enlace de Kubernetes, las cuales se recomiendan para configurar las puertas de enlace de entrada y son necesarias para configurar los proxies de waypoint de ambient. OpenShift Service Mesh 4.18 y las versiones anteriores no incluyen ni brindan soporte para estas CRD.

Estas son algunas de las ventajas y desventajas de adoptar el modo ambient:

Reducción significativa de los costos de los recursos

Dado que los sidecars ya no son necesarios, el modo ambient de Istio reduce considerablemente el consumo de recursos, tanto de memoria como de CPU, que se necesitan para adoptar las funciones de la malla de servicios, como el cifrado mTLS. Hemos visto reducciones en el uso de la memoria de más del 90 % y de la CPU en más del 50 % en comparación con el modo sidecar. Se observa una reducción aún mayor en el uso de los recursos cuando solo se utiliza ztunnel. 

Redes ligeras de confianza cero

Creemos que la principal motivación para adoptar el modo Ambient de Istio es el cifrado mTLS ligero de pod a pod A medida que las redes de confianza cero adquieren mayor prioridad, vemos que cada vez más clientes solicitan una malla de servicios para aplicar el cifrado mTLS en una gran cantidad de aplicaciones El modo Ambient de Istio con ztunnel ofrece esto, lo cual incluye la gestión de identidades y certificados, y reduce al mínimo la sobrecarga de los recursos y el impacto en las cargas de trabajo en ejecución. A medida que aumentan los requisitos, se pueden agregar waypoints para introducir políticas y telemetría en el nivel de la aplicación, como aquellos que se basan en los tipos de solicitud HTTP (por ejemplo, /GET) o en los encabezados. 

Mejora de la capacidad de ajuste 

Como hay menos proxies que gestionar y un entorno mucho más pequeño, el potencial de escalabilidad del modo Ambient de Istio es mucho mayor que el del sidecar tradicional. Si bien hemos visto a los clientes ajustar las mallas para admitir miles de cargas de trabajo utilizando las funciones de alcance y ajuste de Istio, la arquitectura del modo ambient ofrece la posibilidad de expandirse a decenas o incluso cientos de miles de cargas de trabajo con menos optimizaciones necesarias. 

Posibles características de rendimiento

Si bien hubo medidas iniciales de rendimiento en la comunidad de Istio prometedoras, todavía estamos evaluando el rendimiento del modo ambient de Istio en una configuración empresarial comparable a la de nuestros clientes. Hasta la fecha, hemos visto un rendimiento comparable al del modo sidecar, y es posible mejorarlo en futuras versiones. Las características de rendimiento serán diferentes con ztunnel solo en comparación con ztunnel y un waypoint, ya que un waypoint agregará una mayor sobrecarga según la configuración. También detectamos un cuello de botella conocido en el rendimiento que limitaba la capacidad de ajuste vertical de ztunnel, el cual llevará tiempo resolver. Creemos que la arquitectura ambiental de Istio tiene potencial para mejorar el rendimiento en futuras versiones.

Adopción más sencilla

El modo Ambient de Istio también facilita la adopción de la malla de servicios, ya que ya no es necesario modificar las cargas de trabajo para agregar contenedores sidecar. De hecho, ni siquiera es necesario reiniciarlos para agregarlos a la malla o cuando esta se actualiza. La arquitectura de dos niveles también permite que las funciones de Istio se adopten de forma gradual, sin incurrir en los costos de recursos del proxy de capa 7 cuando no se necesita. 

Niveles de compatibilidad de las funciones

Ten en cuenta que el nivel de soporte para las funciones de Istio con el modo ambient puede diferir del modo sidecar tradicional. Para obtener una lista de las funciones compatibles, consulta la tabla de soporte de funciones de Service Mesh. Las funciones avanzadas como multicluster y multimesh aún están en desarrollo, mientras que la combinación de cargas de trabajo con sidecar y el modo ambient tiene limitaciones, en particular, para el uso de proxies de waypoint con sidecars. Para conocer el punto de vista de la comunidad de Istio sobre ambient y sidecar, consulta esta página. 

Consideraciones sobre la actualización

El modo Ambient de Istio ofrece la ventaja de que el plano de datos de Istio se puede actualizar sin reiniciar los pods de carga de trabajo, lo cual se requiere con los proxies de sidecar. La desventaja es que los ztunnels son agentes compartidos de nivel de nodo que forman parte de la ruta de datos para varias aplicaciones. Por lo tanto, ztunnel debe actualizarse con cuidado. Se recomienda realizar la actualización durante un período de mantenimiento o de poco tráfico, ya que las conexiones TCP de larga duración se restablecerán en ese nodo. A partir de esta versión, tampoco se admiten las actualizaciones basadas en revisiones (canary). Esta será un área de desarrollo en futuras versiones.

Primeros pasos con el modo ambient de Istio

Para comenzar a utilizar el modo Ambient de Istio, OpenShift Service Mesh proporciona el recurso "Ztunnel" para instalar y gestionar ztunnel como un daemonset. Se instala junto con los recursos "Istio" e "IstioCNI", que deben configurarse con el perfil "ambient", incluso si algunas cargas de trabajo tienen sidecars. 

Al igual que con el modo sidecar tradicional, también es importante configurar los "selectores de descubrimiento" de Istio para garantizar que el plano de control de Istio pueda supervisar los espacios de nombres que formarán parte de la malla y nada más. En el caso del modo Ambient, se usa la etiqueta "istio.io/dataplane-mode=ambient" para indicar que se debe incluir un espacio de nombres o una carga de trabajo en la malla. Para obtener más información sobre cómo agregar cargas de trabajo, consulta la documentación de la comunidad de Istio.

Cuando se agrega una nueva carga de trabajo a la malla, el agente de CNI de Istio trabajará con el proxy ztunnel local del nodo para configurar la redirección del tráfico, de modo que todo el tráfico se intercepte y se actualice para usar mTLS utilizando el protocolo de túnel HBONE de Istio. Ztunnel también se encarga de obtener y gestionar los certificados para todos los pods en el mismo nodo.

Si se deseas un proxy de waypoint, se puede agregar de la misma manera que se agregaría una puerta de enlace de entrada o salida utilizando el recurso "Gateway" de Kubernetes de la API de puerta de enlace de Kubernetes, que se incluye con OpenShift 4.19 y versiones posteriores Para obtener más información sobre la instalación de los waypoints haz clic aquí, y el uso de los waypoints para las funciones L7 haz clic aquí.

Para obtener un procedimiento detallado sobre cómo comenzar a utilizar el modo ambient de Istio, consulta la documentación de OpenShift Service Mesh.

Si ya uso la malla de servicios, ¿puedo migrar al modo ambient?

Si bien el modo ambient es ideal para los usuarios nuevos de la malla de servicios, también se puede incorporar a las implementaciones actuales de la malla y combinarse con las cargas de trabajo del modo sidecar con ciertas advertencias. También anticipamos que el modo sidecar seguirá siendo el caso práctico preferido cuando se necesite el conjunto completo de funciones de un proxy Envoy exclusivo por pod. 

Para incorporar el modo ambient a una malla actual, esta (Istio e Istio CNI) debe actualizarse con el perfil "ambient" y todas las cargas de trabajo con sidecars deben reiniciarse para que puedan comunicarse con ztunnels mediante el protocolo de túnel HBONE. 

Una limitación actual de esta coexistencia es que el tráfico entre los proxies de sidecar y las cargas de trabajo de ambient generalmente omitirá los proxies de waypoint, por lo que las políticas de la capa 7 no se aplicarán a la carga de trabajo ambiental.

Dadas estas limitaciones, recomendamos que los espacios de nombres y los grupos de aplicaciones utilicen el modo ambient o el modo sidecar, y no mezclen modos dentro de cargas de trabajo de aplicaciones estrechamente acopladas. También es importante evitar mezclar las etiquetas de los pods de los modos sidecar y ambient.

Kiali con el entorno de Istio

Kiali, la consola para Istio que se incluye con OpenShift Service Mesh, ofrece muchas funciones para configurar, visualizar y validar el modo ambient de Istio. Dado que las cargas de trabajo pueden encontrarse en varios estados posibles (en malla con ztunnel, en malla con waypoints, en modo sidecar o sin formar parte de la malla), Kiali se vuelve aún más importante para comprender el estado de tu malla y solucionar los problemas cuando las aplicaciones distribuidas no se están comportando como se esperaba.

Kiali proporciona confirmaciones claras en todos los niveles de que el modo ambient se configuró correctamente. Esto comienza con la ejecución del plano de control de Istio con el perfil ambient habilitado y con los espacios de nombres y las cargas de trabajo etiquetados, de modo que ztunnel o waypoint registren el tráfico de las cargas de trabajo como se espera. Por último, en el pod, puedes comprobar que el tráfico se protege con el protocolo HBONE de Istio, en lugar del protocolo TCP sin cifrar.

Kiali también proporciona registros correlacionados entre ztunnel y waypoint para que puedas comprender y solucionar los problemas sobre cómo se mueve el tráfico desde la carga de trabajo a través de cada proxy.

Si bien los proxies de waypoint son similares a otros proxies, Kiali tiene una pestaña específica para mostrar qué servicios y cargas de trabajo se han inscrito. 

Por último, los gráficos de topología para el modo ambient se ven diferentes en comparación con el modo sidecar. Como ahora hay dos niveles de proxy, es posible que se notifiquen dos conjuntos independientes de telemetría por carga de trabajo: las métricas de nivel 4 (TCP) de ztunnels, que se muestran con bordes azules, y las métricas de nivel 7 (HTTP), que se muestran con bordes verdes cuando se configuró un waypoint. Kiali ofrece la posibilidad de seleccionar el tipo de tráfico que se muestra.

Como es probable que los proxies de waypoint representen grupos de cargas de trabajo estrechamente acopladas (que quizás formen una aplicación distribuida común), la vista de waypoint proporcionará una descripción general de nivel superior de tu malla en lo que podría ser una malla muy grande.

Para obtener más información sobre todas las funciones de Kiali para el modo ambient, consulta la documentación de la comunidad de Kiali.

Actualizaciones de Istio 1.27

Esta versión incluye todas las actualizaciones que se indican en las notas sobre los cambios de Istio 1.27. Estos son algunos de los aspectos más destacados.

Extensiones de inferencia de la API de Gateway (GIE)

Esta versión es compatible con las extensiones de inferencia de la API de Gateway Para brindar un mejor soporte a los clientes con Red Hat OpenShift AI 3, incorporamos a esta versión la implementación de la API disponible para el público en general (versión 1.0). Ten en cuenta que esta función solo es compatible con Red Hat OpenShift AI 3 y se considera una versión de prueba de OpenShift Service Mesh 3.2. 

Varios clústeres con modo ambient

En esta versión, se incorpora el soporte inicial para el modo ambient de Istio en una topología de varios clústeres principales. Debido a que esta función aún se encuentra en desarrollo upstream, la designamos como “versión preliminar para desarrolladores” de OpenShift Service Mesh 3.2. 

Compatibilidad con nftables en el modo sidecar

En la preparación de Red Hat Enterprise Linux (RHEL) 10, Red Hat aportó soporte para nftables al proyecto Istio, con soporte para el modo sidecar introducido en Istio 1.27 El nftable framework es el sucesor moderno de iptables, la función de Linux que Istio utiliza para configurar las reglas de redirección de la red Su objetivo es proporcionar un mejor rendimiento, capacidad de mantenimiento y una gestión de reglas más flexible para la redirección del tráfico hacia y desde el sidecar Envoy. A partir de RHEL 10, nftables será la herramienta predeterminada para gestionar las reglas de red. El soporte para Red Hat Enterprise Linux 10 estará disponible en una versión futura de OpenShift.

Cert-Manager Istio-CSR está disponible para el público en general

El operador cert-manager es compatible con OpenShift Service Mesh, pero se requiere el agente istio-csr para que cert-manager firme, entregue y renueve los certificados para las cargas de trabajo. Con el lanzamiento de la versión 1.18 del operador cert-manager, este agente ya está disponible para el público en general y se puede utilizar con todas las versiones compatibles de OpenShift Service Mesh. Para obtener más información sobre el funcionamiento conjunto de cert-manager y OpenShift Service Mesh para lograr la confianza cero, lee este blog. Para conocer el procedimiento que describe el uso de cert-manager con OpenShift Service Mesh, consulta la documentación.

Primeros pasos con OpenShift Service Mesh

Para obtener más información sobre Red Hat OpenShift Service Mesh, lee esta publicación de blog y la continuación sobre multicluster service mesh. 

Para comenzar a utilizar la malla de servicios, primero debes instalar el operador Red Hat OpenShift Service Mesh 3. Si es la primera vez que utilizas la malla de servicios, deberías considerar el modo ambient de Istio. Proporcionará una arquitectura de malla de servicios con un uso mucho más eficiente de los recursos que el modo sidecar tradicional. Para comenzar a utilizar el modo ambient de Istio, lee la documentación aquí. 

Para ver un ejemplo completo del uso de OpenShift Service Mesh con la supervisión de las cargas de trabajo de los usuarios de OpenShift, el rastreo distribuido y Kiali, consulta este patrón de solución.