La muerte del Sidecar: Implementación de Ztunnels en Istio Ambient Mesh

¿Los proxy sidecars están consumiendo tu presupuesto de cómputo en Kubernetes? Avanza hacia un futuro sin sidecars con Ambient Mesh Ztunnels, que utilizan el protocolo HBONE para enrutamiento de confianza cero a nivel de nodo y alto rendimiento.

En el ecosistema en rápida evolución de infraestructura nativa en la nube, pocas tecnologías han experimentado un cambio tan drástico en la filosofía operativa como el service mesh. Durante años, la industria dependió en gran medida del modelo “sidecar”—un proxy dedicado inyectado en cada pod de Kubernetes. Este paradigma aportaba capacidades esenciales como TLS mutuo (mTLS), observabilidad y control granular del tráfico. Sin embargo, a medida que crecían los tamaños de clúster y la adopción empresarial, las fallas arquitectónicas del modelo sidecar se volvieron imposibles de ignorar: consumía enormes cantidades de CPU y memoria, complicaba los ciclos de vida de las aplicaciones y forzaba a los equipos de infraestructura y desarrollo a una relación incómoda y estrechamente acoplada.

La respuesta a estos problemas ha llegado. Istio Ambient Mesh, que alcanzó disponibilidad general en Istio 1.24 en noviembre de 2024 con ztunnel, waypoints y todas las APIs marcadas como Estables por el Comité de Supervisión Técnica de Istio, ahora es la configuración predeterminada para nuevos despliegues de service mesh en Kubernetes. En el centro de esta transformación está el Ztunnel (Zero Trust Tunnel)—un proxy a nivel de nodo que cambia fundamentalmente cómo aseguramos y enrutamos el tráfico en Kubernetes.

En esta guía exploramos la mecánica de Istio Ambient Mesh y el Ztunnel, los detalles del protocolo HBONE, cómo el Istio CNI maneja la redirección del tráfico y hacia dónde apunta el proyecto hasta 2026.

---

La era del Sidecar: por qué tuvo que morir

Para entender el diseño de Ambient Mesh, primero debemos comprender el dolor del modelo que reemplaza. La capa de datos tradicional del service mesh dependía de un proxy—normalmente Envoy—que se ejecutaba como un contenedor secundario dentro de cada pod de la aplicación.

Aunque esto proporcionaba un excelente aislamiento y contexto por pod, la sobrecarga que imponía era significativa:

Bloat de recursos de cómputo. Cada sidecar requiere su propia asignación básica de CPU y memoria. En un entorno de microservicios con cientos o miles de pods, estos recursos ociosos del proxy se acumulan rápidamente. Las organizaciones descubrieron que su infraestructura de service mesh consumía tanto presupuesto de cómputo como la lógica empresarial que servía.

Acoplamiento del ciclo de vida y fricción operativa. Debido a que el sidecar se inyecta físicamente en el pod, el ciclo de vida del mesh está ligado al ciclo de vida de la aplicación. Actualizar el proxy o rotar certificados generalmente requería un reinicio en serie de toda la flota de aplicaciones, forzando a los ingenieros de plataforma a coordinar actualizaciones del mesh con los desarrolladores.

El problema del “primer paquete”. Durante la inicialización del pod, ocurrían condiciones de carrera donde el contenedor de la aplicación comenzaba antes que el proxy sidecar, resultando en conexiones iniciales caídas y soluciones complejas con init-containers.

El impuesto del Layer 7. Los sidecars tradicionales procesan tanto Layer 4 (TCP/mTLS) como Layer 7 (HTTP/gRPC). Muchas aplicaciones solo necesitan la seguridad básica de mTLS, pero estaban obligadas a pagar la sobrecarga computacional del análisis completo de L7 en cada conexión.

La conclusión fue clara: el modelo sidecar no era sostenible a escala. La solución requería separar la infraestructura fundamental (seguridad e identidad) de la gestión avanzada del tráfico L7.

---

Istio Ambient Mesh: Visión general de la arquitectura

Istio Ambient Mesh aborda estos puntos problemáticos mediante una filosofía de transparencia y no intrusividad. Elimina completamente los sidecars, dividiendo la capa de datos del service mesh en dos capas distintas y escalables independientemente:

• La capa de transporte seguro (Layer 4): gestionada por Ztunnel, que proporciona mTLS, identidad basada en SPIFFE, políticas de autorización L4 y observabilidad de red.
• La capa de gestión de tráfico L7: gestionada por Waypoint Proxies opcionales, desplegados solo cuando se requieren enrutamiento HTTP complejo, reintentos, RBAC por ruta, validación JWT o limitación de tasa.

Al mover mTLS a un componente de infraestructura compartida, Ambient Mesh permite a los equipos de plataforma habilitar seguridad de confianza cero a nivel de clúster sin modificar los pods de la aplicación, sin inyectar sidecars y sin forzar reinicios de aplicaciones. Enrolar una carga de trabajo es un comando:

kubectl label namespace default istio.io/dataplane-mode=ambient

Esta etiqueta activa al agente de nodo del Istio CNI para configurar la redirección en todos los pods de ese namespace—sin reinicio de pods, sin webhooks de mutación, sin init-containers.

---

Descomponiendo el Ztunnel: El proxy de confianza cero a nivel de nodo

La piedra angular de Ambient Mesh es el Ztunnel (Zero Trust Tunnel). A diferencia de los ricos en funciones Envoy sidecars del pasado, Ztunnel es una implementación optimizada y específica para Layer 4 escrita en Rust. La implementación inicial de ambient mesh usaba Envoy para ztunnel, pero el equipo de Istio encontró que el conjunto de funciones ricas de Envoy—exactamente lo que lo hace excelente para gateways y waypoints—se desperdiciaba en el rol de ztunnel solo L4, y que adaptar Envoy a los requisitos específicos de ztunnel era poco práctico. La implementación en Rust, anunciada en febrero de 2023, resolvió esto.

Arquitectura y despliegue

Ztunnel funciona como un DaemonSet en Kubernetes, lo que significa que se despliega exactamente una instancia por nodo, compartida por todas las cargas en ese nodo. Sus responsabilidades se limitan a los elementos fundamentales de confianza cero:

• TLS mutuo (mTLS): cifrado del tráfico en tránsito entre cargas usando AES-GCM, un cifrado optimizado para hardware moderno.
• Gestión de identidad SPIFFE: Ztunnel actúa como cliente de CA, solicitando y gestionando certificados X.509 de corta duración con identidades SPIFFE desde Istiod en nombre de cada carga co-ubicada. La identidad de cada carga sigue el formato spiffe://<dominio-de-confianza>/ns/<namespace>/sa/<cuenta-de-servicio>.
• Políticas de autorización L4: aplicando reglas de “quién puede hablar con quién” basadas en la identidad de carga.
• Observabilidad L4: exportando métricas TCP estándar y registros de acceso, incluyendo las identidades SPIFFE fuente y destino por conexión.

Ztunnel también se comunica con Istiod como cliente xDS, recibiendo configuraciones xDS específicas para su rol solo L4—diferentes de la configuración completa enviada a los sidecars Envoy o waypoints.

Rendimiento y eficiencia

Debido a que Ztunnel opera estrictamente en Layer 4 y está escrito en Rust, su perfil de recursos es notablemente ligero. Según los benchmarks oficiales de rendimiento de Istio, una sola instancia de Ztunnel procesando 1,000 solicitudes por segundo consume aproximadamente 0.06 vCPU y 12 MB de memoria. Una instancia típica usa entre 30 y 50 MB de memoria en reposo, con CPU mínimo.

El equipo de Ztunnel ha lanzado mejoras continuas de rendimiento en cada versión trimestral, incluyendo migración a rustls (una biblioteca TLS de alto rendimiento y centrada en la seguridad), reducción de copiado de datos en tráfico saliente, ajuste dinámico de tamaños de búfer para conexiones activas y migración a AWS-LC—una biblioteca de criptografía optimizada para hardware moderno.

Estas mejoras han tenido un impacto significativo. Comparado con el modelo sidecar, el modo ambient solo con ztunnel usa aproximadamente el 1% de la CPU y la memoria de un despliegue equivalente en producción. Incluso con proxies Waypoint desplegados para servicios que necesitan L7, la CPU total cae a alrededor del 15% y la memoria a aproximadamente el 10%.

En un clúster de 1,000 pods en 100 nodos:

Modelo	Número de proxies	Sobrecarga de CPU	Sobrecarga de memoria
Sidecar (Envoy por pod)	1,000	~100 vCPU	~128 GB
Ambient solo L4 (DaemonSet Ztunnel)	100	~6–7 vCPU	~1.2–5 GB
Ambient con Waypoints (20% de servicios)	100 + algunos waypoints	~15–20 vCPU	~13–15 GB

La reducción en solicitudes de recursos asignados—antes de medir uso real—representa una disminución del 90% para ambient solo L4 y aproximadamente 80% cuando se despliegan waypoints para un subconjunto de servicios.

En términos de latencia, los benchmarks oficiales de Istio 1.23 muestran que dos saltos de ztunnel (cliente y servidor) añaden aproximadamente 0.17 ms en el percentil 90 y 0.20 ms en el percentil 99 respecto a la línea base para tráfico HTTP/1.1 a 1,000 solicitudes por segundo con mTLS habilitado.

Preservando la identidad por carga de trabajo

Una preocupación común sobre proxies a nivel de nodo es que colapsan la identidad por pod en una “identidad de nodo”. Ztunnel evita esto explícitamente. Aunque se comparte entre todos los pods en un nodo, gestiona certificados en nombre de cada carga individual.

Cuando el Pod A en el Nodo 1 se comunica con el Pod B en el Nodo 2:

1. El Ztunnel en el Nodo 1 solicita un certificado X.509 único para la cuenta de servicio del Pod A desde Istiod, presentando la identidad SPIFFE del Pod A.
2. Istiod verifica que el Ztunnel esté autorizado a actuar en nombre del Pod A (a través de RBAC de Kubernetes en la cuenta de servicio del pod).
3. El apretón de manos mTLS usa el certificado SPIFFE específico del Pod A. El Ztunnel de destino en el Nodo 2 valida esta identidad exacta contra la política de autorización L4 del Pod B.

El resultado es una identidad estricta y criptográfica de confianza cero a nivel de carga de trabajo—sin la sobrecarga de proxies por pod.

---

El protocolo HBONE: túnel seguro basado en estándares

Para transportar de forma segura el tráfico TCP en bruto entre nodos sin exponer complejidad a las aplicaciones, Istio Ambient Mesh usa HBONE (HTTP-Based Overlay Network Environment)—un protocolo de túnel específico de Istio construido a partir de tres estándares abiertos:

• HTTP CONNECT (RFC 7540) para establecer la conexión del túnel
• HTTP/2 para multiplexar múltiples flujos de conexión de aplicaciones sobre un solo túnel seguro y transportar metadatos de flujo
• mTLS para cifrar y autenticar mutuamente el túnel

Por convención, los proxies Ztunnel y otros que soportan HBONE escuchan en puerto TCP 15008. Esto tiene una implicación práctica para los operadores: si tienen objetos NetworkPolicy existentes que restringen puertos entrantes en pods inscritos en ambient, deben agregar una excepción explícita permitiendo el puerto 15008 o el tráfico HBONE será bloqueado.

¿Por qué no usar solo mTLS en crudo?

Usar HTTP/2 CONNECT como portador en lugar de una conexión mTLS en crudo ofrece ventajas técnicas específicas. La multiplexación HTTP/2 permite que una sola conexión mTLS entre dos instancias de Ztunnel transporte tráfico para muchas conexiones pod a pod diferentes, reduciendo sustancialmente la sobrecarga de conexiones a escala. La solicitud HTTP CONNECT también lleva la IP y el puerto del destino en el encabezado :authority, y la identidad SPIFFE del carga de trabajo origen se transmite en el certificado TLS del cliente durante el apretón de manos.

HBONE también es interoperable: proxies Envoy en modo sidecar pueden hablar HBONE, lo que permite la coexistencia de cargas de trabajo ambient y sidecar en el mismo clúster durante una migración gradual.

Flujo de paquetes HBONE

Cuando el Pod A envía una conexión TCP en texto plano a un servicio:

1. Intercepción: El CNI de Istio redirige el tráfico saliente del namespace del Pod A al Ztunnel local antes de que llegue a las tablas de enrutamiento estándar.
2. Encapsulación: El Ztunnel local envuelve el flujo TCP dentro de una solicitud HTTP/2 CONNECT que lleva la IP:puerto de destino en :authority.
3. Apretón de manos mTLS: El Ztunnel local inicia una conexión mTLS con el Ztunnel del nodo destino en el puerto 15008, presentando el certificado SPIFFE del Pod A.
4. Desencapsulación: El Ztunnel de destino verifica la identidad del Pod A contra la política de autorización L4 del Pod B, desempaqueta el sobre HTTP/2 y entrega el flujo TCP original al Pod B.

Desde la perspectiva del Pod A: envió una conexión TCP normal. Desde la perspectiva de la red: el tráfico atravesó un túnel HBONE multiplexado, cifrado con mTLS y con autenticación de identidad.

---

Redirección de tráfico: Istio CNI, iptables, GENEVE y eBPF

Lograr que el tráfico de un pod de aplicación llegue al Ztunnel a nivel de nodo sin modificar la aplicación es un reto de ingeniería importante. Istio lo resuelve mediante el agente de nodo Istio CNI, que monitorea eventos del ciclo de vida de los pods y configura reglas de redirección dinámicamente.

Mecanismo predeterminado: iptables + GENEVE

En la configuración predeterminada, el CNI de Istio usa una combinación de reglas iptables y túneles de sobreposición GENEVE (Encapsulación de red virtualizada genérica) para conectar los espacios de nombres de red del pod con el Ztunnel. El pod Ztunnel expone las interfaces pistioin y pistioout, conectadas a las interfaces istioin y istioout del nodo a través de estos túneles. El tráfico recibido en el túnel entrante se dirige al puerto ztunnel 15008 (HBONE) o 15006 (texto plano); el tráfico saliente de los pods se dirige al puerto 15001.

TPROXY (proxy transparente en Linux) marca los paquetes entrantes de los túneles y los enruta a los puertos de entrada y salida de ztunnel, preservando la IP y puerto origen reales para que la política de upstream vea las direcciones reales de carga.

La alternativa eBPF

Istio ha añadido un modo opcional de redirección de tráfico basada en eBPF. Cuando se habilita, un programa eBPF se compila en el componente CNI de Istio y se adjunta a los hooks de control de tráfico (TC) ingress y egress en las interfaces de red relevantes. El CNI monitorea eventos de pods y adjunta o desacopla este programa eBPF cuando los pods se mueven a modo ambient o fuera de él.

El programa eBPF opera en espacio kernel y puede redirigir paquetes directamente al Ztunnel, evitando la sobrecarga de la traversa de cadenas iptables y eliminando la encapsulación GENEVE. El Ztunnel realiza una búsqueda de conexión en el mapa del programa eBPF para determinar la redirección correcta para cada paquete.

Ventajas del modo eBPF:

• Eficiencia a nivel kernel: evita cambios de contexto entre kernel y espacio usuario.
• Sin sobrecarga GENEVE: los paquetes se redirigen en kernel sin paso de encapsulación.
• Programabilidad flexible: los programas eBPF pueden actualizarse sin recargar módulos del kernel y pueden incorporar contexto adicional del paquete para enrutamiento personalizado.
• Transparente para la aplicación: el pod no tiene visibilidad de la redirección que ocurre debajo.

El modo eBPF actualmente requiere habilitación explícita sobre el modo ambient, dado que requiere compatibilidad con CNI. La ruta predeterminada iptables + GENEVE es compatible con todos los plugins CNI de Kubernetes, incluyendo Cilium, Calico, OpenShift SDN y Amazon VPC CNI.

---

Desacoplando Layer 7: Waypoint Proxies

Si Ztunnel maneja la seguridad en Layer 4, ¿qué pasa con funciones avanzadas de Layer 7 como enrutamiento basado en encabezados HTTP, división de tráfico, circuit breaking, RBAC por ruta, validación JWT y trazabilidad distribuida?

Ambient Mesh introduce Waypoint Proxies para gestionar estos aspectos. Un Waypoint es una instancia estándar de Envoy desplegada de forma independiente—por namespace, por servicio o por cuenta de servicio—no como sidecar. Los Waypoints tienen su propia identidad SPIFFE (waypoint-sa) y se despliegan usando recursos de la API Gateway de Kubernetes, convirtiéndolos en infraestructura de red de primera clase en lugar de un parche sobre despliegues de aplicaciones.

La arquitectura es estrictamente opcional. Ztunnel detecta automáticamente cuando un destino tiene un proxy Waypoint configurado y enruta el tráfico a través de él mediante un túnel HBONE antes de entregarlo al destino. La política de autorización L4 continúa aplicándose en la capa de Ztunnel; la política de autorización L7 se aplica en el Waypoint.

Un patrón de despliegue práctico: enrutar el 80% de los servicios solo a través de Ztunnel (mTLS, SPIFFE, política L4), y desplegar Waypoints solo para el 20% de los servicios que realmente necesitan enrutamiento HTTP, división de tráfico o RBAC L7 detallado. Este despliegue selectivo elimina el “impuesto Layer 7” en el tráfico que no lo requiere.

Una limitación actual a tener en cuenta: los Waypoints aplican políticas usando la identidad de carga de trabajo original (no la propia identidad del waypoint), pero la API EnvoyFilter—ampliamente usada en modo sidecar para personalización de Envoy—no es compatible en modo ambient. Las extensiones deben usar plugins WebAssembly.

---

Hacia dónde va Ambient Mesh: hoja de ruta 2025–2026

El proyecto Istio publicó una hoja de ruta clara para 2025–2026 con tres temas principales.

Paridad de migración de sidecar a ambient. El proyecto invierte en herramientas para evaluar la preparación para la migración, interoperabilidad segura para revertir entre namespaces de sidecar y ambient en el mismo clúster, y documentación exhaustiva. Cerrar las brechas de funciones más importantes—especialmente gestión de tráfico multi-clúster y extensibilidad—es el foco central.

Mesh ambient multi-clúster. La compatibilidad multi-clúster se lanzó como alpha en Istio 1.27 (agosto de 2025), con contribuciones de Microsoft. Extiende la arquitectura modular de ambient para ofrecer conectividad segura, descubrimiento y balanceo de carga entre clústeres—una de las capacidades más solicitadas por usuarios empresariales de ambient. Esto sienta las bases para configuraciones activas-activa en regiones o proveedores de nube.

API Gateway y madurez en extensibilidad. En KubeCon Europa 2026, el proyecto Istio anunció Ambient Multicluster Beta, Gateway API Inference Extension Beta y soporte experimental para Agentgateway—señalando la evolución del service mesh más allá del networking de microservicios hacia una plataforma de gestión de tráfico para cargas de trabajo de inferencia AI. El Sail Operator (lanzado en 2025) ofrece una forma simplificada de gestionar despliegues de Istio mediante el patrón de operador de Kubernetes.

---

Despliegue práctico: habilitar Ambient Mesh

Para equipos que evalúan o migran a Ambient Mesh, la recomendación es una adopción gradual, namespace por namespace.

Instalar perfil Ambient:

istioctl install --set profile=ambient

Inscribir un namespace:

kubectl label namespace mi-aplicacion istio.io/dataplane-mode=ambient

Desplegar un proxy Waypoint para funciones L7 en un namespace específico:

istioctl waypoint apply -n mi-aplicacion --enroll-namespace

Verificar que Ztunnel procesa conexiones (buscar identidades SPIFFE en los registros de acceso):

kubectl logs -n istio-system daemonset/ztunnel -f

Verás líneas de registro que incluyen los campos src.identity y dst.identity con los URIs SPIFFE de las cargas fuente y destino—confirmando que se preserva la identidad por carga de trabajo a nivel de nodo.

Revertir si es necesario (sin reinicios de pods):

kubectl label namespace mi-aplicacion istio.io/dataplane-mode- --overwrite

---

Conclusión: El Sidecar está muerto, larga vida al Mesh

El service mesh ahora es un requisito fundamental para operar de forma segura en entornos nativos en la nube—pero la deuda arquitectónica del modelo sidecar amenazaba con hacer que muchas organizaciones se resistieran a adoptarlo. La sobrecarga de cómputo era real, la complejidad operativa también, y el acoplamiento del ciclo de vida, igualmente.

Istio Ambient Mesh, ahora completamente en producción desde Istio 1.24, resuelve estos problemas a nivel arquitectónico. Al separar la seguridad en Layer 4 (ztunnel, que funciona como DaemonSet en Rust consumiendo aproximadamente 0.06 vCPU y 12 MB por nodo a 1,000 RPS) del manejo de tráfico en Layer 7 (waypoints, opt-in por servicio), el proyecto ha cumplido la promesa original del service mesh—seguridad de confianza cero robusta, observabilidad profunda y control granular—sin la sobrecarga debilitante.

El protocolo HBONE, que combina HTTP/2, HTTP CONNECT y mTLS en el puerto 15008, ofrece un túnel basado en estándares, multiplexado, autenticado por identidad y transparente para las aplicaciones. El Istio CNI gestiona la interceptación de tráfico de forma transparente mediante iptables y GENEVE por defecto, con una ruta rápida basada en eBPF disponible para entornos donde la eficiencia a nivel kernel y la reducción de sobrecarga de encapsulación son prioritarios.

Para los equipos de ingeniería de plataformas en 2026, el cálculo es sencillo: modo ambient es la configuración predeterminada para nuevos despliegues de service mesh en Kubernetes. Los sidecars siguen disponibles y soportados para cargas con requisitos técnicos específicos que el modo ambient aún no puede cubrir—pero para la gran mayoría del tráfico microservicio empresarial, la era de pagar el impuesto del sidecar ha terminado.

---

Registro de cambios

Las siguientes correcciones y adiciones se hicieron al borrador original, basadas en investigación web de fuentes:

Corregido — Marco de lanzamiento GA: La descripción original indicaba que Ambient Mesh había alcanzado “disponibilidad general completa y madurez robusta para 2026.” Corregido: Ambient Mesh GA fue lanzado en Istio 1.24, 7 de noviembre de 2024, con ztunnel, waypoints y todas las APIs marcadas como Estables por el TOC de Istio.

Corregido — Benchmark de memoria de Ztunnel: La declaración original decía “menos de 15 MB de memoria.” La documentación oficial de rendimiento de Istio reporta 12 MB a 1,000 RPS para el proxy ztunnel; el uso típico en reposo es de 30–50 MB. La cifra de 15 MB era no atribuida y no concordaba con datos oficiales.

Corregido — eBPF como mecanismo predeterminado: La descripción original sugería que la redirección eBPF era el mecanismo predeterminado en 2026. Corregido: iptables + GENEVE es el predeterminado; la redirección basada en eBPF es un modo opcional dentro del CNI de Istio. La ruta eBPF elimina la necesidad de encapsulación GENEVE, pero requiere compatibilidad con CNI.

Corregido — Descripción del protocolo HBONE: La descripción original indicaba que HBONE usaba “HTTP/2 CONNECT (o HTTP/3 en iteraciones más recientes).” No hay documentación pública de una variante HTTP/3 de HBONE en Istio. Corregido: HBONE combina HTTP CONNECT, HTTP/2 y mTLS—los tres estándares abiertos juntos.

Corregido — Origen de Ztunnel: La original no mencionaba que ztunnel fue inicialmente implementado en Envoy antes de la reescritura en Rust. La transición Envoy-a-Rust (anunciada en febrero de 2023) es significativa arquitectónicamente y se añadió por precisión.

Añadido — Detalles de identidad SPIFFE: Se añadieron detalles sobre cómo Ztunnel transporta la identidad por carga de trabajo SPIFFE (spiffe://<dominio-de-confianza>/ns/<namespace>/sa/<cuenta-de-servicio>) en los certificados mTLS y cómo Istiod valida el derecho del Ztunnel a actuar en nombre de cada carga.

Añadido — Puerto 15008 y implicaciones en NetworkPolicy: Se añadió que la existencia de NetworkPolicy debe permitir el puerto 15008 entrante en pods inscritos en ambient.

Añadido — Limitaciones de Waypoints: Se añadió que la API EnvoyFilter no es compatible en modo ambient, y que las extensiones deben usar plugins WebAssembly.

Añadido — Hoja de ruta 2025–2026: Se añadió cobertura de la fase alpha de multi-clúster en Istio 1.27 (agosto 2025), las inversiones en herramientas de migración en Istio 1.28–1.29, y los anuncios en KubeCon Europa 2026.

Añadido — Benchmarks de latencia: Se añadieron datos oficiales de P90/P99 de los benchmarks de Istio 1.23 (0.17 ms / 0.20 ms para dos saltos de ztunnel a 1,000 RPS con mTLS).

Eliminado — Reclamo de reducción de recursos “del 80-80%”: La declaración original citaba “más del 70-80%” de reducción de recursos basada en datos de benchmark atribuidos a “lanzamientos de Istio 2026.” Sustituido por cifras documentadas: reducción del 99% en CPU y memoria en modo ambient solo L4 (datos de Solo.io), con reducción del 85% en CPU y 90% en memoria cuando se añaden waypoints para aproximadamente el 20% de los servicios.