Matando al Sidecar: Migrando a Meshes de Servicio sin Sidecar mediante Networking Ambiental

Ejecutar un sidecar Envoy en cada pod de Kubernetes es un gran desperdicio de gasto en la nube. El networking ambiental divide el procesamiento de la capa 4 y la capa 7 a nivel de nodo, eliminando la sobrecarga del sidecar mientras mantiene el cifrado de confianza cero. Aquí tienes la visión arquitectónica completa, basada en benchmarks actuales y en la historia de versiones de Istio hasta la 1.30.

---

El Impuesto del Sidecar: Por qué el Modelo Clásico Está Rompiendo los Presupuestos en la Nube

La evolución de la arquitectura nativa en la nube ha estado marcada por el desacoplamiento: aplicaciones de servidores físicos mediante máquinas virtuales, dependencias de tiempo de ejecución mediante contenedores, y lógica de red separada del código de la aplicación mediante el service mesh. Durante años, el estándar de la industria para ese desacoplamiento ha sido el modelo de proxy sidecar—popularizado por Istio.

El modelo funciona inyectando un contenedor proxy Envoy en cada pod de la aplicación. El proxy intercepta todo el tráfico entrante y saliente, gestionando cifrado mutual TLS (mTLS), generación de telemetría, enrutamiento de tráfico y políticas de autorización. La abstracción es limpia. El costo, no.

A medida que las implementaciones de Kubernetes han escalado de decenas a miles de microservicios, un fallo acumulativo en el modelo de sidecar se ha vuelto imposible de ignorar: estás ejecutando un proceso Envoy completo por cada pod en el clúster. Esa carga se distribuye en tres vectores distintos.

1. Hinchazón de Recursos y Gasto en la Nube

Envoy es un proxy capaz, pero requiere asignación dedicada de CPU y memoria. En Kubernetes, cada contenedor en un pod debe declarar solicitudes y límites de recursos. Con 1,000 pods, gestionas 1,000 ciclos de vida de proxy Envoy.

Debido a que los picos de tráfico son impredecibles, los equipos de plataforma deben provisionar sidecars para cargas máximas. Si un sidecar requiere 0.2 vCPU y 64 MB de RAM para manejar el tráfico pico de forma segura, un clúster de 2,500 pods reserva 500 vCPU y 160 GB de memoria solo para la infraestructura de red. En muchos entornos empresariales, el plano de datos del service mesh consume más recursos de los que soporta la lógica de negocio.

2. La Pesadilla Operativa de la Gestión del Ciclo de Vida

Dado que el sidecar está co-ubicado en el mismo pod que la aplicación, sus ciclos de vida están acoplados. Parchear una CVE en Envoy o actualizar la versión del mesh requiere un reinicio progresivo de cada pod de la aplicación. Eso viola un principio básico de infraestructura: los cambios en la red no deberían causar reinicios de la aplicación.

El acoplamiento también introduce condiciones de carrera durante el inicio del pod. Si la aplicación inicia antes de que el proxy sidecar esté listo para enrutar tráfico, las solicitudes fallan, se producen bucles de fallos y los pipelines de CI/CD se detienen. Los trabajos de Kubernetes son particularmente problemáticos: un sidecar inyectado que nunca termina puede impedir que el Pod del trabajo se complete, dejándolo huérfano indefinidamente.

3. La Penalización de Cómputo “Todo o Nada”

Los sidecars tradicionales combinan la seguridad de transporte Layer 4 (L4) con el enrutamiento de aplicaciones Layer 7 (L7). Incluso si un microservicio solo necesita cifrado mTLS y no requiere reintentos HTTP, manipulación de encabezados o división de tráfico, cada paquete que pasa por el sidecar aún paga el coste del análisis completo de HTTP L7. No hay forma de optar por no hacerlo.

---

Introducción al Plano de Datos de Networking Ambiental

La respuesta arquitectónica a estos problemas es el Modo Ambiental de Istio, anunciado en septiembre de 2022 y alcanzando disponibilidad general en Istio 1.24 el 7 de noviembre de 2024. En GA, la imagen ztunnel, los waypoints y todas las APIs relacionadas fueron marcadas como Estables por el Comité de Supervisión Técnica de Istio, señalando plena preparación para producción. La imagen de ztunnel en Docker Hub superó los 1 millón de descargas en esa fecha, con aproximadamente 63,000 descargas en la última semana antes del lanzamiento.

La idea central del plano de datos de networking ambiental es una separación clara de responsabilidades: la seguridad básica (L4) es una propiedad omnipresente e invisible de la infraestructura, mientras que el networking avanzado de aplicaciones (L7) se aplica estrictamente bajo opción voluntaria. Lograr esa separación implica eliminar por completo el proxy del pod de la aplicación y reemplazar 1,000 sidecars con dos componentes nuevos: el Ztunnel (para L4) y el Waypoint Proxy (para L7).

---

Ztunnel: Dominando la Seguridad de Transporte en el Kernel de la Capa 4

El Ztunnel (Zero Trust Tunnel) es la base del service mesh sin sidecar. Es un proxy diseñado específicamente, escrito en Rust, elegido por su seguridad en memoria, velocidad y un uso de recursos ultra bajo.

Ztunnel se despliega como un DaemonSet de Kubernetes. Una instancia en cada nodo, independientemente de cuántos pods tenga ese nodo. Según la documentación oficial de rendimiento de Istio, un solo proxy ztunnel a 1,000 solicitudes por segundo consume aproximadamente 0.06 vCPU y 12 MB de memoria en carga estable. Ese perfil de bajo uso es una restricción significativa: en alta densidad de pods, ztunnel se beneficia del multiplexing estadístico entre todos los pods del nodo, y el uso real de memoria en patrones de tráfico mixtos suele estar en el rango de 30–50 MB, dependiendo de la configuración.

Ztunnel opera estrictamente en las capas OSI 3 y 4. No analiza solicitudes HTTP, no lee cargas JSON y no realiza división de tráfico. Sus responsabilidades se limitan a:

• Establecer y terminar conexiones mTLS en nombre de los pods.
• Aplicar políticas de autorización de red L4 (por ejemplo, “El Servicio A puede acceder al Servicio B en el puerto 8080”).
• Emitir métricas de telemetría TCP básicas.

Cómo llega el tráfico a Ztunnel sin un Sidecar

El mecanismo que hace posible la interceptación transparente ha evolucionado a lo largo del ciclo de versiones 1.x. El modo predeterminado en las versiones actuales de Istio usa redirigido en el pod: el agente de red CNI de Istio entrega el espacio de nombres de red del pod al ztunnel co-ubicado, que inicia sus sockets de redirección dentro de ese espacio, mientras corre fuera del pod. La redirección de tráfico entre ztunnel y el pod de la aplicación es, por tanto, invisible para cualquier CNI principal de Kubernetes que opere en el espacio de nombres de red del nodo—Cilium, Calico, Flannel y las implementaciones internas de CNI usadas por OpenShift y Amazon EKS coexisten sin conflicto.

Un mecanismo anterior usaba reglas iptables combinadas con túneles overlay GENEVE. Esto requería marcar y redirigir tráfico en el espacio de nombres de red del nodo, lo que entraba en conflicto con una amplia gama de CNIs de terceros. El enfoque actual en-pod, introducido para lograr compatibilidad universal con CNI antes del hito Beta, resolvió esta limitación fundamental de portabilidad.

También está disponible un modo de redirección opcional basado en eBPF mediante el valor Helm redirectMode: "ebpf". Habilitarlo requiere kernel versión 4.20 o superior y elimina la necesidad de encapsulación GENEVE, ofreciendo mejoras medibles en latencia y rendimiento en comparación con la ruta iptables. La redirección eBPF es opcional; el valor predeterminado sigue siendo iptables + entrega en el espacio de nombres del pod. Los equipos de plataforma con requisitos de compatibilidad CNI o kernels más antiguos deberían mantenerse en la configuración predeterminada.

Independientemente del mecanismo de redirección, la ruta del tráfico es la misma una vez que ztunnel recibe el paquete:

1. El pod fuente envía un paquete TCP estándar.
2. El CNI de Istio redirige el paquete a ztunnel local.
3. Ztunnel identifica el pod fuente, obtiene su SPIFFE X.509 SVID y encapsula el tráfico usando HBONE (Entorno de Red Overlay basado en HTTP)—HTTP/2 CONNECT sobre mTLS en el puerto 15008.
4. El paquete se tuneliza hacia el ztunnel en el nodo de destino.
5. El ztunnel de destino descifra, valida políticas y entrega el paquete al pod de destino.

Para la aplicación, la red parece una conexión local simple. En realidad, el tráfico está completamente cifrado y autenticado mutuamente en la capa del nodo.

acute; Nota operativa: Los objetos NetworkPolicy existentes en los espacios de nombres inscritos en el modo ambiental deben permitir el puerto 15008 para que el tráfico HBONE llegue al ztunnel de destino. Esto es un error común durante la migración.

Gestión Criptográfica de Identidad SPIFFE

Ztunnel gestiona identidades SPIFFE para todos los pods en su nodo. Cuando un pod se inscribe en el mesh ambiental, ztunnel solicita un SVID X.509 a Istiod en nombre de la cuenta de servicio del pod. Ztunnel, por tanto, mantiene múltiples identidades distintas simultáneamente—una por cada cuenta de servicio en el nodo.

Las identidades siguen el formato canónico SPIFFE de Istio:

spiffe://<dominio-de-confianza>/ns/<namespace>/sa/<cuenta-de-servicio>

El ID SPIFFE está incrustado en el campo Subject Alternative Name del certificado X.509, integrándose directamente con la autenticación mutua TLS estándar. La CA interna de Istiod emite y rota estos certificados automáticamente; para empresas que requieren gobernanza centralizada de PKI, Istiod soporta delegación a una implementación externa de SPIRE.

Cuando un pod inicia una conexión, el seguimiento del espacio de nombres de red del CNI garantiza que ztunnel conozca la identidad exacta del pod fuente—no puede ser falsificada. El SVID seleccionado para ese pod inicia el apretón de manos mTLS, y el ztunnel de destino verifica la identidad antes de entregar el tráfico. Esto es autenticación criptográfica por carga de trabajo en la capa del nodo; el movimiento lateral por un pod comprometido permanece criptográficamente bloqueado incluso cuando ambos pods comparten el mismo host físico.

---

Waypoint Proxies: Desacoplando el Procesamiento de la Capa 7

Para la mayoría del tráfico interno este-oeste en el clúster, la cobertura L4 de ztunnel con mTLS es suficiente. Algunos servicios requieren lógica de la capa 7: enrutamiento basado en encabezados HTTP, despliegues canary, circuit breaking, limitación de tasa o extensiones WebAssembly. En un mesh tradicional, cada pod paga ese coste L7 independientemente. En el plano de datos ambiental, L7 es manejado exclusivamente por Waypoint Proxies.

Los waypoints son proxies Envoy estándar desplegados fuera de los pods de la aplicación, típicamente uno por espacio de nombres o por cuenta de servicio. Escalan independientemente de la aplicación y solo necesitan existir para los servicios que realmente requieren capacidades L7.

Cuando un servicio está configurado para usar un waypoint, la ruta completa del tráfico es:

1. El pod fuente emite un paquete.
2. El ztunnel del nodo fuente intercepta, adjunta la identidad SPIFFE de origen y encapsula en HBONE.
3. El tráfico se enruta al Waypoint Proxy asignado al servicio de destino.
4. El waypoint termina el túnel HBONE, inspecciona encabezados HTTP, aplica políticas L7 (por ejemplo, enrutar el 10% del tráfico a un canario v2), vuelve a cifrar y reenvía.
5. El tráfico llega al ztunnel del nodo de destino.
6. El ztunnel de destino entrega el paquete al pod de destino.

Haciendo que L7 sea una opción explícita, los equipos de plataforma pueden aplicar waypoints solo a los servicios que realmente necesitan lógica HTTP y dejar el resto en sobrecarga pura de L4.

Modelo de Extensión: WasmPlugin y API TrafficExtension

Una restricción importante a entender antes de migrar: el API EnvoyFilter no es compatible con los proxies waypoint. EnvoyFilter sigue en estado Alpha tras años de uso en producción en modo sidecar, principalmente porque su acoplamiento estrecho con la estructura interna de Envoy xDS lo hace frágil en actualizaciones. Los mantenedores no lo han portado deliberadamente al modo ambiental.

Las extensiones para waypoints deben usar plugins WebAssembly (Wasm). En Wasm, la lógica personalizada de autenticación, telemetría especializada o transformación de solicitudes/respuestas puede cargarse dinámicamente en el waypoint en tiempo de ejecución sin reconstruir el binario del proxy. La API WasmPlugin es el mecanismo actual; TrafficExtension, una API unificada que soporta tanto Wasm como Lua para sidecars, gateways y waypoints, se lanzó en estado Alpha en Istio 1.30 (mayo de 2026) y es el camino a seguir.

Los equipos con inversiones fuertes en EnvoyFilter deben considerar la migración a Wasm como un elemento prioritario en su plan de adopción ambiental.

---

Optimización del Proxy a Nivel de Nodo: El Impacto Económico

La aritmética de migrar de sidecars por pod a ztunnels por nodo es sencilla, y los números se mantienen en la práctica. La documentación de Istio y los primeros adoptantes reportan consistentemente ahorros del 70% a 90% o más en la sobrecarga de cómputo del plano de datos del mesh.

Considera un clúster con 50 nodos de trabajo ejecutando 2,500 pods de microservicios.

Modelo Sidecar:

• 2,500 proxies Envoy, cada uno provisionado para carga máxima.
• A 0.2 vCPU reservadas por sidecar: 500 vCPU consumidas por el plano de datos.

Modelo Ambiental:

• 50 instancias de ztunnel (una por nodo) con aproximadamente 0.06–1 vCPU cada una, dependiendo de la densidad de tráfico, beneficiándose del multiplexing estadístico entre todos los pods del nodo.
• Waypoints desplegados para el 10–20% de los servicios que requieren lógica L7; con 10 instancias de waypoint, aproximadamente 1 vCPU cada una.
• Sobrecarga total del plano de datos del mesh: aproximadamente 60–100 vCPU.

Eso representa una reducción del 80–88% en el cómputo dedicado a la infraestructura de red. En entornos en la nube donde las horas de vCPU se traducen directamente en gastos, los ahorros a escala empresarial son sustanciales.

La historia de latencia también es fuerte. Los benchmarks oficiales de rendimiento de Istio (medidos en el CNCF Community Infrastructure Lab a 1,000 RPS, carga útil de 1 KB, HTTP/1.1, TLS mutuo habilitado) muestran que las dos saltos de ztunnel en un camino L4 ambiental añaden 0.17 ms en P90 y 0.20 ms en P99 sobre la latencia base del plano de datos. Una comparación revisada por pares encontró que Istio Ambient solo aumentó la latencia en un 8% a 3,200 RPS—el mejor resultado entre todas las implementaciones de mesh probadas—mientras que el modo sidecar tradicional produjo un aumento del 166% en la misma carga y no pudo cumplir con el objetivo de 12,800 RPS.

El uso de HTTP/2 en HBONE como marco del túnel introduce aproximadamente un 12% adicional de latencia sobre una conexión TLS sin procesar en escenarios de conexión única, un overhead que el proyecto Istio está monitoreando activamente para reducir. Para cargas de trabajo con múltiples conexiones a escala, las ganancias de multiplexing estadístico del proxy compartido en el nodo dominan, y el perfil de latencia neto es mejor que en modo sidecar para casi todas las formas de tráfico de producción realista.

---

Redefiniendo la Seguridad: Respuesta a la Objeción del Proxy Compartido

Una preocupación común al adoptar un mesh sin sidecar es la intuición de que un sidecar—aislado dentro del espacio de nombres de red del pod—es más seguro que un ztunnel compartido que atiende múltiples pods en el mismo nodo. En la práctica, el modo ambiental mantiene, y en varias formas mejora, la postura de confianza cero del clúster.

El aislamiento criptográfico se mantiene. Ztunnel mantiene identidades X.509 SVID distintas para cada cuenta de servicio en el nodo. El mecanismo de redirección en-pod garantiza que ztunnel conozca la identidad exacta del pod fuente antes de seleccionar el certificado correspondiente para el apretón de manos mTLS. No hay situación en la que el pod A pueda usar la identidad del pod B, incluso cuando ambos residen en el mismo host físico.

Se elimina la superficie de ataque de la API de administración de Envoy. En modo sidecar, un contenedor de aplicación comprometido tiene acceso localhost a la API de administración de Envoy—un vector de escalada bien conocido. En modo ambiental, el proxy ya no está co-ubicado en el pod. Una aplicación comprometida no tiene un proxy local para atacar.

La seguridad en memoria de Rust elimina toda una clase de vulnerabilidades. Ztunnel está escrito en Rust, que elimina desbordamientos de búfer y errores de uso después de liberar en el nivel del lenguaje. El proyecto Istio seleccionó explícitamente Rust por esta razón: el proxy que mantiene todo el material criptográfico en el nodo debe ser seguro en memoria.

La integración existente con NetworkPolicy permanece sin cambios. Ztunnel cifra y autentica el tráfico en la capa del mesh. La política de red estándar de Kubernetes sigue operando en la capa CNI, aplicando controles de frontera de red sin conflicto. Calico, Cilium y otros CNIs que ofrecen inspección profunda de paquetes continúan funcionando junto a ztunnel en lugar de ser reemplazados.

---

Migración: Cómo se Ve el Cambio Operacional

El camino de migración en Istio modo ambiental está diseñado para ser no disruptivo. Llevar un espacio de nombres al mesh ambiental requiere una sola etiqueta:

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

El CNI de Istio detecta la etiqueta, configura la redirección en-pod para todos los pods nuevos en ese espacio, y comienza a enrutar tráfico a través del ztunnel del nodo. Los pods de la aplicación no se reinician. Las conexiones TCP no se interrumpen. La actualización a mTLS estricto es instantánea y transparente.

Actualizar el mesh en sí mismo se desacopla completamente del ciclo de vida de la aplicación. Para desplegar una nueva versión de ztunnel, los operadores actualizan el DaemonSet—nodo por nodo, con semántica de actualización progresiva estándar—mientras los pods de la aplicación permanecen completamente intactos. Los waypoints son despliegues normales de Kubernetes y se actualizan como cualquier otro Deployment. La infraestructura de red ya no está bajo control del desarrollador.

Migración desde Modo Sidecar

La hoja de ruta declarada del proyecto Istio para 2025–2026 prioriza la migración de sidecar a ambiental: herramientas para evaluar la preparación, interoperabilidad segura para rollback entre namespaces sidecar y ambiental en el mismo clúster, y documentación completa son tareas en curso. El modo sidecar no está en desuso—los mantenedores han comprometido soporte continuo—pero la inversión operativa ahora se centra claramente en la vía ambiental.

Los elementos clave de la lista de verificación previa a la migración para equipos con despliegues sidecar existentes:

• Auditar el uso de EnvoyFilter. Cualquier filtro debe reescribirse como plugins Wasm antes de desactivar la inyección de sidecar. La API TrafficExtension (Istio 1.30 Alpha) es el objetivo futuro.
• Validar compatibilidad CNI. La redirección en-pod actual funciona con todos los CNIs principales, incluyendo Cilium y Calico, pero verificar con las versiones específicas en tu entorno.
• Verificar uso de VirtualService. VirtualService en modo ambiental está en Alpha y no puede combinarse con recursos Gateway API. Los servicios que dependen de VirtualService para gestión de tráfico deben migrar a HTTPRoute (Gateway API) antes o durante la transición ambiental.
• Actualizar NetworkPolicy para el puerto 15008. El tráfico HBONE debe permitirse entrante en el puerto 15008 para todos los pods inscritos en modo ambiental.

---

La Hoja de Ruta de Istio Ambient: 2025 y Más Allá

La superficie de funciones en modo ambiental ha crecido significativamente desde la versión 1.24 GA:

Istio 1.27 (agosto 2025): Multicluster ambiental en estado Alpha. Conectividad segura entre clústeres, descubrimiento de servicios y balanceo de carga disponibles con la arquitectura ztunnel + waypoint, permitiendo configuraciones activas y pasivas en múltiples clústeres y regiones desde un solo plano de control.

Istio 1.28 (noviembre 2025): Los waypoints ahora pueden enrutar tráfico a redes remotas en configuraciones multicluster. Políticas L7, incluyendo detección de outliers, ahora aplican a solicitudes entre redes. Se añadió soporte nativo para nftables como alternativa a iptables para gestión de reglas de red en modo ambiental.

Istio 1.29 (febrero 2026): Multicluster multirred en modo ambiental en Beta, con telemetría mejorada en clústeres distribuidos. HBONE ahora soporta encabezados de carga para transportar metadatos de pares a través de gateways east-west, permitiendo métricas L7 precisas en topologías multicluster. También se abordó el problema de tamaño de ventana HTTP/2 en HBONE para cargas de alto rendimiento.

Istio 1.30 (mayo 2026): Se parchearon cuatro CVEs, incluyendo una fuga de clave RSA en JWKS (CVE-2026-31837) y exposición no autenticada del endpoint de depuración XDS (CVE-2026-31838). La API TrafficExtension se lanzó en estado Alpha, unificando la configuración de extensiones Wasm y Lua para sidecars, gateways y waypoints. Se introdujo Agentgateway, un nuevo componente de plano de datos para enrutamiento de cargas de trabajo de inferencia AI, como experimental. La autenticación en XDS se volvió obligatoria, y los permisos del archivo de configuración de CNI se ajustaron a 0600.

KubeCon EU 2026 (Ámsterdam, marzo 2026): La CNCF anunció la Beta de multicluster de Istio ambient, la Beta de extensión de inferencia Gateway API y la integración experimental de agentgateway. La narrativa fue clara: Istio ahora se posiciona como infraestructura para cargas de trabajo de Kubernetes en la era de la IA, con el 66% de las organizaciones ejecutando IA generativa en Kubernetes según datos de CNCF.

---

Conclusión: El Futuro Es Ambiental

El proxy sidecar fue un paso necesario y realmente importante en la evolución de la red en la nube. Demostró que las arquitecturas de confianza cero eran viables a escala y enseñó a la industria cómo desacoplar la inteligencia de red del código de la aplicación. Pero la carga computacional, la fricción operativa y el acoplamiento del ciclo de vida se han convertido en problemas estructurales que no pueden resolverse solo con el modelo de sidecar.

La transición a un service mesh sin sidecar mediante un plano de datos de networking ambiental representa la madurez del concepto de service mesh. Al desplegar ztunnels en Rust, seguros en memoria, como proxies compartidos por nodo en la capa 4 y aislar los waypoints de Envoy para lógica L7 bajo demanda, las organizaciones obtienen tres beneficios: una superficie de ataque más pequeña y más defendible, un ciclo de vida del mesh verdaderamente invisible para los equipos de aplicación, y una reducción concreta del 70–90% en la sobrecarga de cómputo dedicada a la infraestructura de red.

El lanzamiento en GA del proyecto Istio en noviembre de 2024, la Beta multicluster en principios de 2026 y la hoja de ruta activa hasta la versión 1.30 indican que esto ya no es solo infraestructura experimental. Para nuevas implementaciones, el modo ambiental es la opción predeterminada. Para los equipos con despliegues en modo sidecar a gran escala, las herramientas de migración y las garantías de interoperabilidad son lo suficientemente maduras para comenzar a planear la transición ahora.

Es hora de matar al sidecar y dejar que la red sea ambiental.

---

Registro de Cambios

#	Sección	Cambio
1	En toda la documentación	Se eliminó el encabezado de metadatos (subtítulo/ bloque de descripción).
2	Introducción	Se corrigió el marco de GA: modo ambiental alcanzó GA en Istio 1.24 el 7 de noviembre de 2024 con ztunnel, waypoints y todas las APIs marcadas como Estables por el TOC de Istio—no “para 2026” como algunos borradores anteriores sugerían. Se añadió el hito de descargas en Docker Hub (más de 1M, ~63k/semana en GA).
3	Impuesto del Sidecar §2	Se añadió el problema de trabajos de Kubernetes / pods huérfanos como un modo de fallo de ciclo de vida concreto, basado en el anuncio oficial de modo ambiental de CNCF.
4	Ztunnel §recursos	Se corrigió la referencia a memoria: los docs oficiales de rendimiento de Istio reportan 12 MB a 1,000 RPS y uso típico en reposo/mezclado de 30–50 MB. Se eliminó la figura no atribuida de “menos de 15 MB”. Se añadió la cifra precisa de vCPU de 0.06 por instancia de ztunnel, según la documentación oficial de rendimiento de Istio.
5	Intercepción de tráfico	Se corrigió y expandió la sección del mecanismo de redirección. Se reemplazó la descripción vaga de “plugin CNI o eBPF” por una descripción precisa: el modo predeterminado es entrega en el espacio de nombres del pod (iptables); eBPF es una alternativa opcional que requiere kernel ≥4.20; el modo overlay GENEVE anterior fue una implementación previa, no la configuración predeterminada actual. Fuentes: blog de Istio enero 2024 y docs preliminares de 1.29.
6	HBONE	Se añadió el puerto de HBONE (15008) y la implicación práctica en NetworkPolicy de que los pods inscritos en modo ambiental deben permitir entrada en 15008.
7	SPIFFE	Se añadió el formato explícito de ID SPIFFE spiffe://<dominio-de-confianza>/ns/<namespace>/sa/<cuenta-de-servicio>, el mecanismo SVID X.509, y el modelo de certificados por cuenta de servicio de Istiod. Fuentes: docs de integración de Istio SPIRE y documentación del marco SPIFFE.
8	Limitaciones de Waypoints §	Se añadió que EnvoyFilter no es compatible con proxies waypoint (según docs oficiales). Las extensiones deben usar plugins WebAssembly (Wasm). En Wasm, la lógica personalizada puede cargarse dinámicamente sin reconstruir el proxy. La API WasmPlugin es el mecanismo actual; TrafficExtension será el camino a seguir, lanzado en Istio 1.30 (mayo 2026). Los equipos con inversiones en EnvoyFilter deben priorizar la migración a Wasm.
9	Benchmarks	Se reemplazaron las afirmaciones de latencia ilustrativa por datos oficiales: P90 = 0.17 ms, P99 = 0.20 ms en 1,000 RPS con 2 saltos de ztunnel y mTLS. Se añadió comparación revisada por pares (arXiv:2411.02267): solo un 8% de aumento en latencia a 3,200 RPS con Istio Ambient, frente a un 166% en modo sidecar tradicional. Se añadió la cifra de overhead de HTTP/2 en HBONE (~12%) en escenarios de conexión única, extraída de issue #1476 en GitHub.
10	Ahorros en cómputo	Se ajustó el ejemplo a 0.2 vCPU por sidecar (siguiendo la guía de rendimiento de Istio) en lugar de 0.5. La estimación de ahorro del 80–88% coincide con declaraciones oficiales de Istio “puede superar el 90%” y la afirmación de Solo.io “90% o más”.
11	Sección: Hoja de ruta 2025–2026	Nueva sección documentando Istio 1.27 (multicluster Alpha, agosto 2025), 1.28 (políticas L7, nftables, noviembre 2025), 1.29 (multicluster Beta, febrero 2026), 1.30 (cuatro CVEs, TrafficExtension Alpha, agentgateway experimental, mayo 2026), y anuncios en KubeCon EU 2026. Todas fuentes oficiales de blogs y comunicados CNCF.
12	Lista de verificación de migración	Se añadió lista concreta: auditoría de EnvoyFilter, compatibilidad CNI, migración de VirtualService, permisos en NetworkPolicy para puerto 15008.