Cinco migraciones que están transformando los equipos de infraestructura en 2026

El networking en 2026 no está impulsado por una sola tendencia — sino por plazos. Se retiró un controlador de ingreso ampliamente usado. Una importante biblioteca TLS cambió sus valores predeterminados. Un método de proxy de hace una década finalmente tiene tracción en producción. Un service mesh reemplazó su API de extensibilidad. Y la agotación de IPv4 pasó de ser un tema de conversación a un proyecto de migración real en organizaciones con mandatos federales. Ninguno de estos es especulativo — ya están obligando a los equipos de infraestructura y plataformas a actuar. Aquí te mostramos en qué estado se encuentra cada uno.

1. Ingress-NGINX está retirado — Aquí está la verdadera ruta de migración a Gateway API

La afirmación principal es precisa, pero vale ser exactos sobre qué ocurrió realmente, porque la terminología ha causado confusión en los cronogramas de migración.

Lo que terminó. El controlador kubernetes/ingress-nginx, mantenido por la comunidad y gobernado por Kubernetes SIG Network, entró en mantenimiento solo por esfuerzo en marzo de 2026, y el repositorio fue archivado formalmente y puesto en modo solo lectura el 24 de marzo de 2026. La retirada fue anunciada por primera vez por el Security Response Committee el 11 de noviembre de 2025, y reforzada en un comunicado conjunto del Kubernetes Steering Committee y el Security Response Committee el 29 de enero de 2026, que estimó en aproximadamente la mitad los entornos cloud-native afectados. La causa principal no fue un solo fallo arquitectónico — fueron años de agotamiento de los mantenedores (el proyecto funcionaba con uno o dos voluntarios) combinado con deuda técnica, especialmente las anotaciones arbitrarias de “fragmentos” de configuración NGINX, que los mantenedores vieron como una vulnerabilidad de seguridad sin solución en lugar de una característica.

Lo que no terminó. Hay dos distinciones importantes que a menudo se confunden: - La API Ingress de Kubernetes en sí no está deprecada ni en proceso de eliminación — está congelada en funciones, con desarrollo activo ahora en Gateway API. - El Controlador NGINX Ingress (nginxinc/kubernetes-ingress), mantenido comercialmente y como código abierto por F5/NGINX Inc., es un código completamente diferente y no se ve afectado por esta retirada.

Las implementaciones existentes de ingress-nginx siguen en funcionamiento; nada se rompe de la noche a la mañana. Lo que se detiene son las nuevas versiones, correcciones de errores y — lo más crítico — parches CVE. Esto ya representa un riesgo real: cuatro CVEs de alta severidad se divulgaron simultáneamente el 2 de febrero de 2026, y en mayo siguió un desbordamiento de búfer en montón crítico (“NGINX Rift,” CVE-2026-42945), sin una solución upstream. En entornos con requisitos de cumplimiento, “software EOL en la ruta de solicitud L7” ya es una constatación rutinaria en auditorías SOC 2 / PCI-DSS / ISO 27001. Algunas plataformas gestionadas (Azure AKS Application Routing, algunas configuraciones de ingreso en GKE) han comprometido parches extendidos por el proveedor solo hasta noviembre de 2026 — eso es un puente, no una solución.

Dónde está Gateway API ahora mismo. La formulación original de “migrar a Gateway API v1.4” ya está desactualizada. La v1.4.0 alcanzó GA el 6 de octubre de 2025, añadiendo BackendTLSPolicy y TLSRoute en GA. Desde entonces: - v1.5 se lanzó el 27 de febrero de 2026 — la mayor versión hasta ahora, promoviendo seis funciones previamente experimentales (incluyendo ListenerSet y la graduación completa de TLSRoute) al canal Estándar/GA, e introduciendo un modelo de tren de versiones inspirado en el proceso SIG Release de Kubernetes. - v1.6 es la versión actual a mediados de 2026, con manifiestos de instalación estándar y experimental publicados en github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.0/.

La herramienta de migración real. ingress2gateway, mantenida por SIG Network, alcanzó 1.0 el 20 de marzo de 2026 — sincronizada deliberadamente con el EOL. La herramienta previa a 1.0 solo entendía tres anotaciones de ingress-nginx; la versión 1.0 soporta más de 30 anotaciones comunes (CORS, TLS de backend, coincidencia con expresiones regulares, reescrituras de rutas) y cada una cuenta con pruebas de integración a nivel de controlador que comparan el comportamiento en tiempo de ejecución, no solo la forma YAML. También introdujo una arquitectura de emisor pluggable para que puedas apuntar a extensiones específicas de la implementación:

# Instalación
ngo install github.com/kubernetes-sigs/ingress2gateway@v1.0.0

# Conversión en modo simulación de todo en un namespace, anotaciones de ingress-nginx
ingress2gateway print --providers ingress-nginx --namespace production > gwapi.yaml

# Apuntar a extensiones de una implementación específica (por ejemplo Envoy Gateway)
ingress2gateway print --providers ingress-nginx --emitter envoy-gateway > envoy-gwapi.yaml

La herramienta advertirá sobre cualquier cosa que no pueda traducir fielmente (por ejemplo, nginx.ingress.kubernetes.io/proxy-body-size no tiene equivalente directo en Gateway API) en lugar de omitir silenciosamente el comportamiento — revisa siempre sus advertencias antes de la migración definitiva, y valida en un clúster no productivo primero. Siete o más implementaciones (Cilium, Contour, Envoy Gateway, GKE Gateway, Istio, y otros) ya cumplen con el canal Estándar actual, por lo que hay una verdadera elección de proveedor en el otro extremo de la migración.

2. TLS Post-Cuántico pasó de borrador a predeterminado

Este tema resiste bien el marco de “recoger ahora, descifrar después” — el tráfico cifrado con intercambio de claves clásico hoy puede ser capturado y almacenado, y luego descifrado retroactivamente cuando exista una computadora cuántica criptográficamente relevante. Lo que cambió es que la solución ya no es una simple configuración experimental.

OpenSSL 3.5 (lanzado en abril de 2025) fue el punto de inflexión: hizo que un grupo de intercambio híbrido — combinando X25519 de curva elíptica clásica con ML-KEM-768, un esquema post-cuántico estandarizado por NIST — fuera la clave predeterminada en TLS 1.3, no una opción opt-in. El nombre registrado en IANA es X25519MLKEM768 (código 0x11ec); una alternativa orientada a FIPS, SecP256r1MLKEM768 (código 0x11eb), combina ML-KEM-768 con la curva P-256. Debido a que es híbrido, la sesión permanece segura mientras cualquiera de las dos mitades se mantenga — una ruptura de ML-KEM o una futura ruptura de X25519 por sí sola no son suficientes para comprometer la clave de sesión. Esta construcción está especificada en el borrador draft-ietf-tls-hybrid-design del IETF.

Las preocupaciones prácticas para quienes terminan TLS en el borde:

• El overhead es insignificante para el intercambio en sí. El intercambio híbrido funciona en el mismo orden de magnitud que X25519 clásico — decenas de miles de operaciones por segundo en un solo núcleo — por lo que el costo de CPU no es un cuello de botella.
• El tamaño de la carga útil es el verdadero costo. Las claves públicas ML-KEM-768 rondan las 1.2 KB, lo que aumenta el tamaño de ClientHello/ServerHello. Si el grupo preferido por un servidor requiere una clave compartida que el cliente no envió previamente, obtienes un HelloRetryRequest y una ronda adicional. Chrome y Firefox evitan esto precomputando claves compartidas para X25519MLKEM768 y X25519 simple; no todos los clientes lo hacen. Observa la latencia de handshake P99 después de habilitar la preferencia PQC — ahí aparecería una regresión.
• La adopción ya es amplia. Chrome (v131, noviembre de 2024) y Firefox (v135, febrero de 2025) soportan el esquema híbrido; el JDK lo agregó en versiones early-access en 2026; y cualquier compilación de NGINX o HAProxy contra OpenSSL 3.5+ lo hereda.

La presión de cumplimiento es real y tiene fecha: la suite CNSA 2.0 de EE. UU. establece una fecha límite para sistemas de seguridad nacional, y la hoja de ruta PQC coordinada en la UE apunta a sectores de alto riesgo en un cronograma similar. Para un proxy Layer-7, la migración práctica es más cercana a “recompilar contra OpenSSL 3.5+ y monitorear” que a un reemplazo completo — lo cual es mucho menor que la percepción de “hacer tu infraestructura cuánticamente resistente” suele implicar.

3. MASQUE y CONNECT-UDP: El estándar es más antiguo de lo que piensas, las implementaciones son nuevas

Vale la pena corregir de entrada: CONNECT-UDP no es un concepto emergente — es un estándar terminado, RFC 9298, desde agosto de 2022. Lo que realmente es nuevo en 2026 es la implementación a escala de producción y las extensiones que se le añaden.

MASQUE (Multiplexed Application Substrate over QUIC Encryption) es una familia de especificaciones, no un solo RFC. La cadena de dependencia: RFC 9000 (transporte QUIC) → RFC 9221 (datagramas no confiables en QUIC) → RFC 9114 (HTTP/3, que adapta el método Extended CONNECT) → RFC 9297 (Datagramas HTTP y el Protocolo Capsule — mecanismo para transportar datos multiplexados dentro de una conexión HTTP) → RFC 9298 (CONNECT-UDP en sí) → RFC 9484 (CONNECT-IP, octubre de 2023, extendiendo el modelo a túnel IP completo). Un cliente abre una solicitud Extended CONNECT con :protocol: connect-udp, y el proxy reenvía datagramas UDP al destino, envueltos como Datagramas HTTP en una conexión QUIC ya cifrada. Como corre en el puerto 443 junto a HTTPS normal, el tráfico tunelizado — WebRTC, juegos, WireGuard, lo que sea — es estructuralmente indistinguible de la navegación normal para cualquier middlebox que no haya roto TLS.

Esto no es teórico: MASQUE ya soporta Apple iCloud Private Relay y la flota WARP de Cloudflare, y es una opción activa en productos Zero Trust empresariales.

Dónde sigue avanzando el estándar: - draft-ietf-masque-connect-udp-listen (actualmente borrador -13, publicado el 30 de junio de 2026) extiende CONNECT-UDP a UDP iniciado por el servidor — útil para protocolos peer-to-peer como WebRTC que CONNECT-UDP solo no soporta claramente, dando a los proxies MASQUE una vía para reemplazar relays STUN/TURN. - draft-ietf-httpbis-connect-tcp propone una alternativa basada en plantillas a la conexión clásica para TCP, abordando brechas como la imposibilidad de hospedar múltiples servicios proxy distintos tras un solo servidor HTTP. - Las implementaciones de código abierto maduran rápidamente: masque-go (basado en quic-go) ofrece soporte para RFC 9298, y herramientas de tunelización general como gost tienen solicitudes abiertas para agregar soporte MASQUE específicamente para transportar protocolos como WireGuard a través de HTTP/3.

Para los equipos de infraestructura, la conclusión práctica es menos “adoptar un protocolo de vanguardia” y más “presupuestar que los firewalls empresariales construidos en torno a la suposición de ‘bloquear puertos UDP no estándar’ se vuelven menos efectivos por diseño” — lo cual afecta en ambos sentidos, dependiendo de si tú construyes el túnel o intentas verlo.

4. Extensibilidad de proxy: WasmPlugin está siendo reemplazado, no solo popularizado

Aquí es donde la formulación original necesita mayor corrección — no porque la tecnología sea incorrecta, sino porque “filtros Wasm intercambiables” describe 2021–2025, no el estado actual, y el panorama cambió muy recientemente.

Istio introdujo la extensibilidad Wasm con el CRD WasmPlugin en Istio 1.12 (2021), reemplazando los parches EnvoyFilter más frágiles para agregar lógica personalizada al plano de datos Envoy. La mecánica principal sigue siendo precisa: un plugin es un módulo WebAssembly sandboxed (compilado desde Rust, Go/TinyGo, C++, o AssemblyScript usando el SDK Proxy-Wasm), distribuido vía un registro OCI, y el Servicio de Descubrimiento de Configuración de Extensiones (ECDS) de Envoy carga en caliente una nueva versión sin reiniciar el proxy ni perder conexiones — actualiza una etiqueta OCI y Envoy obtiene y reemplaza el módulo en vivo.

Lo que ha cambiado es la superficie de API sobre esa mecánica. Istio 1.30 introdujo la API TrafficExtension, que unifica la extensibilidad Wasm y Lua bajo un mismo recurso y ahora es el mecanismo de extensibilidad recomendado — WasmPlugin aún funciona (Istio convierte internamente los recursos existentes en WasmPlugin en TrafficExtension antes de generar la configuración de Envoy), pero el trabajo nuevo debe dirigirse a la nueva API:

apiVersion: extensions.istio.io/v1alpha1
kind: TrafficExtension
metadata:
  name: basic-auth-gateway
spec:
  targetRefs:
    - kind: Gateway
      group: gateway.networking.k8s.io
      name: bookinfo-gateway
  phase: AUTHN
  wasm:
    url: oci://ghcr.io/istio-ecosystem/wasm-extensions/basic_auth:1.12.0
    pluginConfig:
      basic_auth_rules:
        - prefix: "/productpage"
          request_methods: ["GET", "POST"]

TrafficExtension también formaliza Lua como una opción de primera clase, más ligera — scripts en línea sin paso de distribución de módulos, solo HTTP (Capa 7), y con una huella de memoria significativamente menor que Wasm (aproximadamente 20–26 MiB independientemente de la concurrencia, versus ~110–290 MiB de Wasm dependiendo de la carga). La recomendación práctica: usa Lua para manipulación sencilla de encabezados, registro o enrutamiento condicional, y reserva Wasm para extensiones que necesitan pruebas reales, versionado y portabilidad entre versiones de Envoy — flujos de autenticación personalizados, lógica compleja de limitación de tasa, transformación de carga útil.

Una nota editorial importante: este tema se superpone sustancialmente con contenido ya cubierto en artículos anteriores del blog sobre extensibilidad de proxy y malla ambient de Istio. La perspectiva realmente nueva y que aún no se ha publicado aquí es específicamente la API TrafficExtension y su reemplazo de WasmPlugin — vale la pena comenzar con ese enfoque en lugar de reintroducir Wasm en proxies como un concepto novedoso.

5. Clústeres Kubernetes solo IPv6: NAT64/DNS64 pasa de ejercicio de laboratorio a requisito de producción

El agotamiento dual-stack descrito aquí es preciso y, en al menos un caso bien documentado, ya no es opcional. ESnet — la red de ciencia del Departamento de Energía de EE. UU. — publicó su propia transición a Kubernetes solo IPv6 usando Cilium, impulsada por un mandato federal para eliminar IPv4. Su mayor obstáculo práctico no fue la capa de red en sí — sino direcciones IPv4 codificadas en el código de la aplicación que solo surgieron cuando IPv4 desapareció realmente. Usaron IPAM Multi-pool de Cilium para asignar a cada namespace su propio prefijo /64, lo que les dio una micro-segmentación limpia sin necesidad de mascaramiento.

El mecanismo principal no ha cambiado conceptualmente, pero las herramientas sí:

• NAT64 realiza traducción con estado entre pods solo IPv6 y la internet IPv4, usando el prefijo conocido 64:ff9b::/96 (RFC 6052). Jool sigue siendo la implementación de kernel NAT64 de código abierto más común y en producción.
• DNS64 sintetiza registros AAAA para dominios que solo publican registros A, anteponiendo la dirección IPv4 con el prefijo NAT64 — así un cliente solo IPv6 puede resolver y acceder a un servicio solo IPv4 de forma transparente. CoreDNS tiene un plugin DNS64; Unbound y BIND también son opciones comunes.
• Una opción más reciente a seguir: kubernetes-sigs/nat64, un proyecto experimental que explora un agente NAT64 en clúster basado en eBPF — buscando evitar la sobrecarga operativa de montar un gateway NAT64/DNS64 externo separado, que actualmente es el patrón más común (aunque más torpe).

# Ejemplo: resolutor compatible con DNS64 como complemento de clúster
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dns64
  namespace: network-services
spec:
  replicas: 3
  selector:
    matchLabels: { app: dns64 }
  template:
    metadata:
      labels: { app: dns64 }
    spec:
      containers:
        - name: unbound
          image: mvance/unbound:latest
          ports:
            - containerPort: 53
              protocol: UDP
            - containerPort: 53
              protocol: TCP

Una advertencia específica para entornos en la nube: en EKS, el endpoint de la API del clúster solo es accesible por IPv4, incluso en un clúster solo IPv6 — por lo que “solo IPv6” en la práctica aún significa “solo IPv6 para tráfico pod a pod y pod a internet,” con un mecanismo de transición NAT64/DNS64 en la frontera, no una eliminación completa de IPv4 del stack. Esa nuance importa para quienes escriben guías de migración “go IPv6-only” — los pods pueden ser solo IPv6; el plano de control generalmente no.

El hilo conductor

Ninguno de estos cinco temas es hype — cada uno está respaldado por una función externa de fuerza: un controlador retirado con fecha EOL fija, un valor predeterminado criptográfico que ya se implementó, un RFC de hace una década que finalmente ve despliegue real, una API que reemplaza a su predecesora en un service mesh importante, y un mandato federal que impulsa una migración real a producción. Esa es una buena forma de filtrar qué cubrir a continuación: no “qué es técnicamente interesante” sino “qué tiene un plazo definido”.

---

Fuentes

Fin de vida de Ingress-NGINX / Gateway API - Comités de Dirección y Respuesta de Seguridad de Kubernetes, declaración conjunta — https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/ - Historial de lanzamientos/archivos de kubernetes/ingress-nginx — https://github.com/kubernetes/ingress-nginx/releases - Anuncio de Ingress2Gateway 1.0 — https://kubernetes.io/blog/2026/03/20/ingress2gateway-1-0-release/ - Notas de la versión Gateway API v1.4 — https://kubernetes.io/blog/2025/11/06/gateway-api-v1-4/ - Notas de la versión Gateway API v1.5 — https://kubernetes.io/blog/2026/04/21/gateway-api-v1-5/ - Repositorio Gateway API (estado actual v1.6.0) — https://github.com/kubernetes-sigs/gateway-api - Seguimiento CVE de fin de vida de Ingress-NGINX — https://www.herodevs.com/blog-posts/ingress-nginx-end-of-life-2026-migration-and-support

TLS Post-Cuántico - OpenSSL Corporation, visión general de preparación post-cuántica — https://openssl-corporation.org/post-quantum.html - OpenSSL 3.5, valores predeterminados híbridos PQC — https://faisalyahya.com/access-control/openssl-3-5-entering-the-post-quantum-era/ - Patrones de despliegue TLS post-cuántico en producción — https://www.systemshardening.com/articles/network/tls-post-quantum-hybrid-deployment/ - Criptografía post-cuántica en Kubernetes — https://kubernetes.io/blog/2025/07/18/pqc-in-k8s/

MASQUE / CONNECT-UDP - Explicación del protocolo MASQUE — https://http.dev/masque - Arquitectura MASQUE y cadena de dependencias RFC — https://instatunnel.substack.com/p/masque-the-http3-tunneling-protocol - draft-ietf-masque-connect-udp-listen — https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp-listen/

Extensibilidad de proxy - Introducción a la API TrafficExtension de Istio — https://istio.io/latest/blog/2026/traffic-extension-api/ - Conceptos de extensibilidad en Istio (Wasm vs. Lua) — https://istio.io/latest/docs/concepts/extensibility/ - Referencia a WasmPlugin — https://istio.io/latest/docs/reference/config/proxy_extensions/wasm-plugin/

Clústeres solo IPv6 / NAT64 - Cilium networking nativo IPv6 (estudio de caso ESnet) — https://cilium.io/use-cases/ipv6/ - kubernetes-sigs/nat64 (agente NAT64 eBPF en clúster) — https://github.com/kubernetes-sigs/nat64 - Restricciones de red IPv6 en EKS — https://aws.github.io/aws-eks-best-practices/networking/ipv6/

---

Registro de cambios

Removido: bloques de metadatos SEO, palabras clave, y el marco de “visión editorial” del borrador original — nada de eso es contenido del artículo.

Corregido: - “Gateway API v1.4” actualizado en todo el texto — v1.4 era el estado en el anuncio original de fin de vida de ingress-nginx, pero la API ha avanzado a través de v1.5 (27 de febrero de 2026) hasta v1.6 (actual). El artículo ahora refleja la versión actual y cita las funciones específicas añadidas en cada lanzamiento. - Aclarado que la EOL de ingress-nginx fue impulsada principalmente por agotamiento de mantenedores y deuda técnica acumulada (específicamente la mecánica de anotaciones “snippets”), no por una única “restricción de seguridad arquitectónica” como insinuaba el borrador. - Distinción explícita entre el proyecto kubernetes/ingress-nginx retirado y el controlador comercialmente mantenido nginxinc/kubernetes-ingress — estos a menudo se confunden y se malinterpretan. - Corrección en el marco de MASQUE/CONNECT-UDP: CONNECT-UDP ha sido un estándar terminado (RFC 9298) desde agosto de 2022, no un mecanismo emergente — se enmarca la sección en las noticias reales de 2026, que son despliegue a escala y borradores de extensiones activas, no la novedad del protocolo base. - Añadidos los puntos de código exactos de IANA para los grupos híbridos PQC (X25519MLKEM768 = 0x11ec, SecP256r1MLKEM768 = 0x11eb) y el borrador específico del IETF (draft-ietf-tls-hybrid-design) que define la construcción híbrida.

Marcado para juicio editorial: La sección 4 (extensibilidad de proxy / WasmPlugin) se superpone sustancialmente con cobertura previa sobre Proxy-Wasm y proxies de borde basados en WASI en este blog. Se mantiene en este artículo pero se reformula específicamente en torno a la API TrafficExtension de Istio 1.30, que es realmente nueva y reemplaza a WasmPlugin — se recomienda comenzar con ese enfoque si se incluye esa sección, o eliminarla en favor de un sexto tema menos cubierto si se prefiere evitar la superposición.

Agregado: ejemplos concretos en CLI/YAML para ingress2gateway, TrafficExtension, y una implementación de DNS64; identificadores específicos de CVE y fechas para el riesgo de seguridad de fin de vida de ingress-nginx; el caso de migración real de ESnet/Cilium; la advertencia de EKS IPv4-only en el plano de control.