{"schemaVersion":1,"id":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium","title":"Gateway API de Kubernetes: Reemplazando Ingress con Envoy Gateway y Cilium","description":"Análisis de la migración de 200+ servicios de nginx-ingress a Gateway API con Envoy Gateway y Cilium mesh. HTTPRoute, TLS passthrough, traffic splitting, y por qué el recurso Ingress siempre fue una abstracción limitada.","language":"es","datePublished":"2026-02-06","dateModified":null,"contentFormat":"text/markdown","content":"Infrastructure\n\n# Gateway API de Kubernetes: Reemplazando Ingress con Envoy Gateway y Cilium\n\n2026-02-066 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/kubernetes-gateway-api-envoy-cilium>)\n\n## Limitaciones del recurso Ingress\n\nEl recurso Ingress era intencionalmente mínimo. Manejaba ruteo HTTP (host + path -\\> backend) y terminación TLS. Todo lo demás, rate limiting, autenticación, rewriting, CORS, soporte WebSocket, gRPC, ruteo TCP/UDP, canary deployments, se empujaba a annotations específicas del controller.\n\n```yaml\n# Un Ingress de producción típico con annotations específicas del controller\napiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: api-gateway\n annotations:\n # Específico de nginx - no funciona con traefik ni otro controller\n nginx.ingress.kubernetes.io/ssl-redirect: \"true\"\n nginx.ingress.kubernetes.io/proxy-body-size: \"50m\"\n nginx.ingress.kubernetes.io/proxy-read-timeout: \"120\"\n nginx.ingress.kubernetes.io/cors-allow-origin: \"https://app.example.com\"\n nginx.ingress.kubernetes.io/rate-limit-rps: \"100\"\n nginx.ingress.kubernetes.io/configuration-snippet: |\n more_set_headers \"X-Request-ID: $req_id\";\n if ($http_upgrade = \"websocket\") {\n proxy_pass http://upstream;\n }\nspec:\n tls:\n - hosts:\n - api.example.com\n secretName: api-tls\n rules:\n - host: api.example.com\n http:\n paths:\n - path: /v1\n pathType: Prefix\n backend:\n service:\n name: api-v1\n port:\n number: 8080\n```\n\nEsto es un desastre. Las annotations son strings no validados. El ` configuration-snippet ` es config nginx cruda que se inyecta tal cual, una vulnerabilidad de seguridad si cualquier usuario no confiable puede setear annotations (CVE-2021-25742 fue exactamente esto). Y nada es portable entre controllers.\n\n## Gateway API: El Modelo de Tres Recursos\n\nLa Gateway API reemplaza el recurso Ingress con un modelo de tres capas que mapea a roles organizacionales:\n\n```\n┌─────────────────────────────────────────────────┐\n│ GatewayClass (Admin del cluster) │\n│ \"Qué implementación de controller usar\" │\n│ Se crea una vez por cluster │\n├─────────────────────────────────────────────────┤\n│ Gateway (Equipo de plataforma / SRE) │\n│ \"Dónde escuchar, config TLS, rutas permitidas\" │\n│ Uno por punto de entrada (externo, interno, etc)│\n├─────────────────────────────────────────────────┤\n│ HTTPRoute / TLSRoute / GRPCRoute (Equipo app) │\n│ \"Cómo rutear tráfico a mi servicio\" │\n│ Uno por servicio o grupo de servicios │\n└─────────────────────────────────────────────────┘\n```\n\nEsta separación es la característica más destacada. El equipo de plataforma controla el Gateway, puertos, certificados TLS, namespaces permitidos. Los equipos de app crean Routes en sus propios namespaces. Se acabó el \"necesito cluster-admin para agregar una annotation a mi Ingress.\"\n\nAcá está el equivalente en Gateway API del horror nginx-ingress de arriba:\n\n```yaml\n# GatewayClass - el admin del cluster configura esto una vez\napiVersion: gateway.networking.k8s.io/v1\nkind: GatewayClass\nmetadata:\n name: envoy\nspec:\n controllerName: gateway.envoyproxy.io/gatewayclass-controller\n---\n# Gateway - el equipo de plataforma maneja esto\napiVersion: gateway.networking.k8s.io/v1\nkind: Gateway\nmetadata:\n name: external\n namespace: gateway-infra\nspec:\n gatewayClassName: envoy\n listeners:\n - name: https\n port: 443\n protocol: HTTPS\n tls:\n mode: Terminate\n certificateRefs:\n - name: wildcard-tls\n namespace: cert-manager\n allowedRoutes:\n namespaces:\n from: Selector\n selector:\n matchLabels:\n gateway-access: \"true\"\n---\n# HTTPRoute - el equipo de app crea esto en su namespace\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n name: api-v1\n namespace: api-team\nspec:\n parentRefs:\n - name: external\n namespace: gateway-infra\n hostnames:\n - \"api.example.com\"\n rules:\n - matches:\n - path:\n type: PathPrefix\n value: /v1\n backendRefs:\n - name: api-v1\n port: 8080\n```\n\nCada campo es validado por el API server de Kubernetes. Los typos se rechazan al hacer apply, no se ignoran silenciosamente. La ruta referencia su Gateway padre explícitamente. Y el mismo HTTPRoute funciona con Envoy Gateway, Cilium, Istio o cualquier implementación conformante.\n\n## Traffic Splitting: Canary Sin Tooling\n\nAcá es donde la Gateway API provee valor inmediato. Usar Flagger + nginx-ingress para canary deployments lo que significaba correr un controller custom que manipulaba annotations para mover tráfico. Con Gateway API, el traffic splitting es nativo:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n name: api-canary\n namespace: api-team\nspec:\n parentRefs:\n - name: external\n namespace: gateway-infra\n hostnames:\n - \"api.example.com\"\n rules:\n - matches:\n - path:\n type: PathPrefix\n value: /v2\n backendRefs:\n - name: api-v2-stable\n port: 8080\n weight: 95\n - name: api-v2-canary\n port: 8080\n weight: 5\n```\n\nCinco por ciento del tráfico va al canary. Ajustás los pese es y reaplicás. Sin controllers custom, sin gimnasia de annotations.\n\n## TLS Passthrough: Lo que Ingress Nunca Hizo Bien\n\nTLS passthrough, reenviar tráfico encriptado sin terminar TLS en el gateway, fue un dolor de cabeza constante con Ingress. Gateway API lo maneja con TLSRoute y modos de listener del Gateway:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1\nkind: Gateway\nmetadata:\n name: external\n namespace: gateway-infra\nspec:\n gatewayClassName: envoy\n listeners:\n - name: https-terminate\n port: 443\n protocol: HTTPS\n tls:\n mode: Terminate\n certificateRefs:\n - name: wildcard-tls\n allowedRoutes:\n kinds:\n - kind: HTTPRoute\n - name: tls-passthrough\n port: 443\n protocol: TLS\n tls:\n mode: Passthrough\n hostname: \"vault.example.com\"\n allowedRoutes:\n kinds:\n - kind: TLSRoute\n```\n\nLos dos listeners comparten el puerto 443. El Gateway inspecciona el SNI (Server Name Indication) en el ClientHello de TLS para decidir si terminar o pasar directo. Se maneja a nivel de protocolo, sin hacks de annotations.\n\n## Cilium: Service Mesh Sin el Impuesto del Sidecar\n\nPara tráfico east-west (servicio a servicio), Cilium con Gateway API es una opción efectiva. El approach basado en eBPF de Cilium significa que no hay sidecars, la lógica de networking corre en el kernel:\n\nLa diferencia de rendimiento entre Cilium (eBPF) y meshes basados en sidecar (Istio con sidecars Envoy) es medible. En un servicio sensible a latencia manejando 50K RPS:\n\n| Métrica | Sin mesh | Istio sidecar | Cilium eBPF |\n| --- | --- | --- | --- |\n| Latencia P50 | 2.1ms | 3.4ms | 2.3ms |\n| Latencia P99 | 8.7ms | 14.2ms | 9.1ms |\n| Memoria por pod | base | +50MB (sidecar) | +0MB |\n| CPU por pod | base | +0.1 core (sidecar) | +~0 |\n\nEl overhead del sidecar es 50MB de RAM y 0.1 core de CPU por pod. En 200 servicios con 3 réplicas cada uno, son 30GB de RAM y 60 cores de CPU solo para el mesh. Cilium elimina esto completamente.\n\n## La Migración: 200 Servicios en 6 Semanas\n\nLa migración incremental funciona bien. El insight clave: Gateway API e Ingress pueden coexistir en el mismo cluster porque usan recurse es distintos.\n\nSemana 1-2: Deploy de Envoy Gateway junto a nginx-ingress. Crear GatewayClass y Gateway. Migrar 5 servicios no críticos.\n\nSemana 3-4: Migrar todos los servicios API stateless. Validar con tráfico sintético antes de cambiar DNS.\n\nSemana 5: Migrar servicios con requerimientos de WebSocket y gRPC. Estos fueron más fáciles con Gateway API porque HTTPRoute soporta nativamente upgrades WebSocket y existe GRPCRoute.\n\nSemana 6: Migrar servicios restantes, decomisionar nginx-ingress.\n\nUn hallazgo notable: se encontraron 23 recurse es Ingress con annotations rotas que nadie había notado. Typos, nombres de annotations deprecadas, annotations para el controller equivocado. Todas silenciosamente sin hacer nada. Gateway API las habría rechazado al momento de crearlas.\n\n## Lo Que le Falta a Gateway API\n\nPersisten algunos gaps:\n\n**Rate limiting no está estandarizado.** Cada implementación tiene sus propios CRDs. La propuesta GEP-1731 para policy attachment sigue evolucionando.\n\n**Autenticación/autorización a nivel gateway** es específica de implementación. No hay un filtro HTTPRoute estándar para validación JWT u OAuth2.\n\n**Ruteo TCP/UDP** funciona (TCPRoute, UDPRoute) pero sigue en el canal experimental.\n\nA pesar de estos gaps, Gateway API representa la dirección correcta. El modelo de seguridad role-based, la configuración tipada, la portabilidad entre implementaciones y las features nativas de traffic management la hacen un upgrade claro del approach de Ingress que se usó durante siete años.\n\nPara clusters que todavía corren Ingress con configuraciones pesadas en annotations, planear una migración es una inversión que vale la pena.\n\n## Preguntas frecuentes\n\n### ¿La Gateway API está lista para producción?\n\nSí. Gateway API llegó a GA (v1.0) en octubre 2023 y v1.2 es la actual a principios de 2026. Envoy Gateway, Cilium, Istio, Traefik y Kong tienen implementaciones production-grade. El spec es estable para features core (Gateway, HTTPRoute, TLSRoute).\n\n### ¿Debería migrar de nginx-ingress a Gateway API?\n\nSi se está manejando más de 20-30 servicios, sí. Solo el modelo role-based (el equipo de plataforma maneja Gateways, los equipos de app manejan Routes) justifica la migración. Si teners 3-5 servicios y nginx-ingress funciona, el costo de migración probablemente no vale la pena todavía.\n\n### ¿Envoy Gateway o Cilium para Gateway API?\n\nEnvoy Gateway si se necesita traffic management avanzado (rate limiting, autenticación, circuit breaking) y no se desea un service mesh completo. Cilium si ya lo usás para CNI/networking y se desea Gateway API integrada con observabilidad basada en eBPF y network policies.\n\n## Tips\n\n1. **Tip:** Al migrar de Ingress a Gateway API, no convertir todos los recursos de una vez. Utilizar ` parentRefs ` en HTTPRoute para vincular rutas a Gateways específicos, es posible ejecutar Ingress y Gateway API simultáneamente durante la migración.\n2. **Tip:** Para TLS passthrough (no terminación), utilizar ` TLSRoute ` con ` mode: Passthrough ` en el listener del Gateway. Este es el aspecto que las annotations de Ingress nunca manejaron de forma limpia entre controllers.\n3. **Tip:** Configurar pesos en ` backendRefs ` para traffic splitting: ` weight: 90 ` y ` weight: 10 ` proporciona un canary 90/10 sin tooling externo. El controller del Gateway maneja el ruteo ponderado nativamente.\n4. **Tip:** Con Cilium Gateway API, habilitar ` hubble ` para observabilidad L7. Se obtienen histogramas de latencia por ruta y tasas de error sin desplegar un stack de observabilidad separado.\n\n- kubernetes\n- gateway-api\n- envoy\n- cilium\n- ingress\n- service-mesh\n- httproute\n- tls\n- traffic-splitting\n- infraestructura\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)","headings":[{"level":1,"text":"Gateway API de Kubernetes: Reemplazando Ingress con Envoy Gateway y Cilium","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#title"},{"level":2,"text":"Limitaciones del recurso Ingress","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#limitaciones-del-recurso-ingress"},{"level":2,"text":"Gateway API: El Modelo de Tres Recursos","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#gateway-api-el-modelo-de-tres-recursos"},{"level":2,"text":"Traffic Splitting: Canary Sin Tooling","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#traffic-splitting-canary-sin-tooling"},{"level":2,"text":"TLS Passthrough: Lo que Ingress Nunca Hizo Bien","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#tls-passthrough-lo-que-ingress-nunca-hizo-bien"},{"level":2,"text":"Cilium: Service Mesh Sin el Impuesto del Sidecar","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#cilium-service-mesh-sin-el-impuesto-del-sidecar"},{"level":2,"text":"La Migración: 200 Servicios en 6 Semanas","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#la-migracin-200-servicios-en-6-semanas"},{"level":2,"text":"Lo Que le Falta a Gateway API","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#lo-que-le-falta-a-gateway-api"},{"level":2,"text":"Preguntas frecuentes","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#questions"},{"level":3,"text":"¿La Gateway API está lista para producción?","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#question-1"},{"level":3,"text":"¿Debería migrar de nginx-ingress a Gateway API?","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#question-2"},{"level":3,"text":"¿Envoy Gateway o Cilium para Gateway API?","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#question-3"},{"level":2,"text":"Tips","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#article-tips"}],"sections":[{"heading":"Gateway API de Kubernetes: Reemplazando Ingress con Envoy Gateway y Cilium","level":1,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium","content":"Infrastructure"},{"heading":"Gateway API de Kubernetes: Reemplazando Ingress con Envoy Gateway y Cilium","level":1,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#title","content":"2026-02-066 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/kubernetes-gateway-api-envoy-cilium>)"},{"heading":"Limitaciones del recurso Ingress","level":2,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#limitaciones-del-recurso-ingress","content":"El recurso Ingress era intencionalmente mínimo. Manejaba ruteo HTTP (host + path -\\> backend) y terminación TLS. Todo lo demás, rate limiting, autenticación, rewriting, CORS, soporte WebSocket, gRPC, ruteo TCP/UDP, canary deployments, se empujaba a annotations específicas del controller.\n\n```yaml\n# Un Ingress de producción típico con annotations específicas del controller\napiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: api-gateway\n annotations:\n # Específico de nginx - no funciona con traefik ni otro controller\n nginx.ingress.kubernetes.io/ssl-redirect: \"true\"\n nginx.ingress.kubernetes.io/proxy-body-size: \"50m\"\n nginx.ingress.kubernetes.io/proxy-read-timeout: \"120\"\n nginx.ingress.kubernetes.io/cors-allow-origin: \"https://app.example.com\"\n nginx.ingress.kubernetes.io/rate-limit-rps: \"100\"\n nginx.ingress.kubernetes.io/configuration-snippet: |\n more_set_headers \"X-Request-ID: $req_id\";\n if ($http_upgrade = \"websocket\") {\n proxy_pass http://upstream;\n }\nspec:\n tls:\n - hosts:\n - api.example.com\n secretName: api-tls\n rules:\n - host: api.example.com\n http:\n paths:\n - path: /v1\n pathType: Prefix\n backend:\n service:\n name: api-v1\n port:\n number: 8080\n```\n\nEsto es un desastre. Las annotations son strings no validados. El ` configuration-snippet ` es config nginx cruda que se inyecta tal cual, una vulnerabilidad de seguridad si cualquier usuario no confiable puede setear annotations (CVE-2021-25742 fue exactamente esto). Y nada es portable entre controllers."},{"heading":"Gateway API: El Modelo de Tres Recursos","level":2,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#gateway-api-el-modelo-de-tres-recursos","content":"La Gateway API reemplaza el recurso Ingress con un modelo de tres capas que mapea a roles organizacionales:\n\n```\n┌─────────────────────────────────────────────────┐\n│ GatewayClass (Admin del cluster) │\n│ \"Qué implementación de controller usar\" │\n│ Se crea una vez por cluster │\n├─────────────────────────────────────────────────┤\n│ Gateway (Equipo de plataforma / SRE) │\n│ \"Dónde escuchar, config TLS, rutas permitidas\" │\n│ Uno por punto de entrada (externo, interno, etc)│\n├─────────────────────────────────────────────────┤\n│ HTTPRoute / TLSRoute / GRPCRoute (Equipo app) │\n│ \"Cómo rutear tráfico a mi servicio\" │\n│ Uno por servicio o grupo de servicios │\n└─────────────────────────────────────────────────┘\n```\n\nEsta separación es la característica más destacada. El equipo de plataforma controla el Gateway, puertos, certificados TLS, namespaces permitidos. Los equipos de app crean Routes en sus propios namespaces. Se acabó el \"necesito cluster-admin para agregar una annotation a mi Ingress.\"\n\nAcá está el equivalente en Gateway API del horror nginx-ingress de arriba:\n\n```yaml\n# GatewayClass - el admin del cluster configura esto una vez\napiVersion: gateway.networking.k8s.io/v1\nkind: GatewayClass\nmetadata:\n name: envoy\nspec:\n controllerName: gateway.envoyproxy.io/gatewayclass-controller\n---\n# Gateway - el equipo de plataforma maneja esto\napiVersion: gateway.networking.k8s.io/v1\nkind: Gateway\nmetadata:\n name: external\n namespace: gateway-infra\nspec:\n gatewayClassName: envoy\n listeners:\n - name: https\n port: 443\n protocol: HTTPS\n tls:\n mode: Terminate\n certificateRefs:\n - name: wildcard-tls\n namespace: cert-manager\n allowedRoutes:\n namespaces:\n from: Selector\n selector:\n matchLabels:\n gateway-access: \"true\"\n---\n# HTTPRoute - el equipo de app crea esto en su namespace\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n name: api-v1\n namespace: api-team\nspec:\n parentRefs:\n - name: external\n namespace: gateway-infra\n hostnames:\n - \"api.example.com\"\n rules:\n - matches:\n - path:\n type: PathPrefix\n value: /v1\n backendRefs:\n - name: api-v1\n port: 8080\n```\n\nCada campo es validado por el API server de Kubernetes. Los typos se rechazan al hacer apply, no se ignoran silenciosamente. La ruta referencia su Gateway padre explícitamente. Y el mismo HTTPRoute funciona con Envoy Gateway, Cilium, Istio o cualquier implementación conformante."},{"heading":"Traffic Splitting: Canary Sin Tooling","level":2,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#traffic-splitting-canary-sin-tooling","content":"Acá es donde la Gateway API provee valor inmediato. Usar Flagger + nginx-ingress para canary deployments lo que significaba correr un controller custom que manipulaba annotations para mover tráfico. Con Gateway API, el traffic splitting es nativo:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n name: api-canary\n namespace: api-team\nspec:\n parentRefs:\n - name: external\n namespace: gateway-infra\n hostnames:\n - \"api.example.com\"\n rules:\n - matches:\n - path:\n type: PathPrefix\n value: /v2\n backendRefs:\n - name: api-v2-stable\n port: 8080\n weight: 95\n - name: api-v2-canary\n port: 8080\n weight: 5\n```\n\nCinco por ciento del tráfico va al canary. Ajustás los pese es y reaplicás. Sin controllers custom, sin gimnasia de annotations."},{"heading":"TLS Passthrough: Lo que Ingress Nunca Hizo Bien","level":2,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#tls-passthrough-lo-que-ingress-nunca-hizo-bien","content":"TLS passthrough, reenviar tráfico encriptado sin terminar TLS en el gateway, fue un dolor de cabeza constante con Ingress. Gateway API lo maneja con TLSRoute y modos de listener del Gateway:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1\nkind: Gateway\nmetadata:\n name: external\n namespace: gateway-infra\nspec:\n gatewayClassName: envoy\n listeners:\n - name: https-terminate\n port: 443\n protocol: HTTPS\n tls:\n mode: Terminate\n certificateRefs:\n - name: wildcard-tls\n allowedRoutes:\n kinds:\n - kind: HTTPRoute\n - name: tls-passthrough\n port: 443\n protocol: TLS\n tls:\n mode: Passthrough\n hostname: \"vault.example.com\"\n allowedRoutes:\n kinds:\n - kind: TLSRoute\n```\n\nLos dos listeners comparten el puerto 443. El Gateway inspecciona el SNI (Server Name Indication) en el ClientHello de TLS para decidir si terminar o pasar directo. Se maneja a nivel de protocolo, sin hacks de annotations."},{"heading":"Cilium: Service Mesh Sin el Impuesto del Sidecar","level":2,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#cilium-service-mesh-sin-el-impuesto-del-sidecar","content":"Para tráfico east-west (servicio a servicio), Cilium con Gateway API es una opción efectiva. El approach basado en eBPF de Cilium significa que no hay sidecars, la lógica de networking corre en el kernel:\n\nLa diferencia de rendimiento entre Cilium (eBPF) y meshes basados en sidecar (Istio con sidecars Envoy) es medible. En un servicio sensible a latencia manejando 50K RPS:\n\n| Métrica | Sin mesh | Istio sidecar | Cilium eBPF |\n| --- | --- | --- | --- |\n| Latencia P50 | 2.1ms | 3.4ms | 2.3ms |\n| Latencia P99 | 8.7ms | 14.2ms | 9.1ms |\n| Memoria por pod | base | +50MB (sidecar) | +0MB |\n| CPU por pod | base | +0.1 core (sidecar) | +~0 |\n\nEl overhead del sidecar es 50MB de RAM y 0.1 core de CPU por pod. En 200 servicios con 3 réplicas cada uno, son 30GB de RAM y 60 cores de CPU solo para el mesh. Cilium elimina esto completamente."},{"heading":"La Migración: 200 Servicios en 6 Semanas","level":2,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#la-migracin-200-servicios-en-6-semanas","content":"La migración incremental funciona bien. El insight clave: Gateway API e Ingress pueden coexistir en el mismo cluster porque usan recurse es distintos.\n\nSemana 1-2: Deploy de Envoy Gateway junto a nginx-ingress. Crear GatewayClass y Gateway. Migrar 5 servicios no críticos.\n\nSemana 3-4: Migrar todos los servicios API stateless. Validar con tráfico sintético antes de cambiar DNS.\n\nSemana 5: Migrar servicios con requerimientos de WebSocket y gRPC. Estos fueron más fáciles con Gateway API porque HTTPRoute soporta nativamente upgrades WebSocket y existe GRPCRoute.\n\nSemana 6: Migrar servicios restantes, decomisionar nginx-ingress.\n\nUn hallazgo notable: se encontraron 23 recurse es Ingress con annotations rotas que nadie había notado. Typos, nombres de annotations deprecadas, annotations para el controller equivocado. Todas silenciosamente sin hacer nada. Gateway API las habría rechazado al momento de crearlas."},{"heading":"Lo Que le Falta a Gateway API","level":2,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#lo-que-le-falta-a-gateway-api","content":"Persisten algunos gaps:\n\n**Rate limiting no está estandarizado.** Cada implementación tiene sus propios CRDs. La propuesta GEP-1731 para policy attachment sigue evolucionando.\n\n**Autenticación/autorización a nivel gateway** es específica de implementación. No hay un filtro HTTPRoute estándar para validación JWT u OAuth2.\n\n**Ruteo TCP/UDP** funciona (TCPRoute, UDPRoute) pero sigue en el canal experimental.\n\nA pesar de estos gaps, Gateway API representa la dirección correcta. El modelo de seguridad role-based, la configuración tipada, la portabilidad entre implementaciones y las features nativas de traffic management la hacen un upgrade claro del approach de Ingress que se usó durante siete años.\n\nPara clusters que todavía corren Ingress con configuraciones pesadas en annotations, planear una migración es una inversión que vale la pena."},{"heading":"Preguntas frecuentes","level":2,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#questions","content":""},{"heading":"¿La Gateway API está lista para producción?","level":3,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#question-1","content":"Sí. Gateway API llegó a GA (v1.0) en octubre 2023 y v1.2 es la actual a principios de 2026. Envoy Gateway, Cilium, Istio, Traefik y Kong tienen implementaciones production-grade. El spec es estable para features core (Gateway, HTTPRoute, TLSRoute)."},{"heading":"¿Debería migrar de nginx-ingress a Gateway API?","level":3,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#question-2","content":"Si se está manejando más de 20-30 servicios, sí. Solo el modelo role-based (el equipo de plataforma maneja Gateways, los equipos de app manejan Routes) justifica la migración. Si teners 3-5 servicios y nginx-ingress funciona, el costo de migración probablemente no vale la pena todavía."},{"heading":"¿Envoy Gateway o Cilium para Gateway API?","level":3,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#question-3","content":"Envoy Gateway si se necesita traffic management avanzado (rate limiting, autenticación, circuit breaking) y no se desea un service mesh completo. Cilium si ya lo usás para CNI/networking y se desea Gateway API integrada con observabilidad basada en eBPF y network policies."},{"heading":"Tips","level":2,"url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#article-tips","content":"1. **Tip:** Al migrar de Ingress a Gateway API, no convertir todos los recursos de una vez. Utilizar ` parentRefs ` en HTTPRoute para vincular rutas a Gateways específicos, es posible ejecutar Ingress y Gateway API simultáneamente durante la migración.\n2. **Tip:** Para TLS passthrough (no terminación), utilizar ` TLSRoute ` con ` mode: Passthrough ` en el listener del Gateway. Este es el aspecto que las annotations de Ingress nunca manejaron de forma limpia entre controllers.\n3. **Tip:** Configurar pesos en ` backendRefs ` para traffic splitting: ` weight: 90 ` y ` weight: 10 ` proporciona un canary 90/10 sin tooling externo. El controller del Gateway maneja el ruteo ponderado nativamente.\n4. **Tip:** Con Cilium Gateway API, habilitar ` hubble ` para observabilidad L7. Se obtienen histogramas de latencia por ruta y tasas de error sin desplegar un stack de observabilidad separado.\n\n- kubernetes\n- gateway-api\n- envoy\n- cilium\n- ingress\n- service-mesh\n- httproute\n- tls\n- traffic-splitting\n- infraestructura\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)"}],"links":[{"text":"English","url":"https://lucioduran.com/blog/kubernetes-gateway-api-envoy-cilium"},{"text":"Volver al Blog","url":"https://lucioduran.com/es/blog"}],"structuredData":[{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium#article","mainEntityOfPage":{"@type":"WebPage","@id":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium"},"headline":"Gateway API de Kubernetes: Reemplazando Ingress con Envoy Gateway y Cilium","description":"Análisis de la migración de 200+ servicios de nginx-ingress a Gateway API con Envoy Gateway y Cilium mesh. HTTPRoute, TLS passthrough, traffic splitting, y por qué el recurso Ingress siempre fue una abstracción limitada.","datePublished":"2026-02-06","author":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"publisher":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"image":"https://statics.lucioduran.com/images/lucioduran-social-card.jpg","url":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium","inLanguage":"es","isPartOf":{"@id":"https://lucioduran.com/blog#blog"},"articleSection":"Infrastructure","keywords":"kubernetes, gateway-api, envoy, cilium, ingress, service-mesh, httproute, tls, traffic-splitting, infraestructura","wordCount":1112,"timeRequired":"PT6M","workTranslation":[{"@type":"BlogPosting","inLanguage":"en","url":"https://lucioduran.com/blog/kubernetes-gateway-api-envoy-cilium"}]},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://lucioduran.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://lucioduran.com/es/blog"},{"@type":"ListItem","position":3,"name":"Gateway API de Kubernetes: Reemplazando Ingress con Envoy Gateway y Cilium","item":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium"}]},{"@type":"FAQPage","mainEntity":[{"@type":"Question","name":"¿La Gateway API está lista para producción?","acceptedAnswer":{"@type":"Answer","text":"Sí. Gateway API llegó a GA (v1.0) en octubre 2023 y v1.2 es la actual a principios de 2026. Envoy Gateway, Cilium, Istio, Traefik y Kong tienen implementaciones production-grade. El spec es estable para features core (Gateway, HTTPRoute, TLSRoute)."}},{"@type":"Question","name":"¿Debería migrar de nginx-ingress a Gateway API?","acceptedAnswer":{"@type":"Answer","text":"Si se está manejando más de 20-30 servicios, sí. Solo el modelo role-based (el equipo de plataforma maneja Gateways, los equipos de app manejan Routes) justifica la migración. Si teners 3-5 servicios y nginx-ingress funciona, el costo de migración probablemente no vale la pena todavía."}},{"@type":"Question","name":"¿Envoy Gateway o Cilium para Gateway API?","acceptedAnswer":{"@type":"Answer","text":"Envoy Gateway si se necesita traffic management avanzado (rate limiting, autenticación, circuit breaking) y no se desea un service mesh completo. Cilium si ya lo usás para CNI/networking y se desea Gateway API integrada con observabilidad basada en eBPF y network policies."}}]}]}],"contentHash":"e6037e09215fc475f23181be4a9277222d60ca124cdd92834ec7b8b5934f1b11","provenance":{"method":"Deterministic serialization of the server-rendered main element","source":"https://lucioduran.com/es/blog/kubernetes-gateway-api-envoy-cilium","hashAlgorithm":"sha256","hashScope":"JSON document fields before contentHash and provenance","sourceHTMLBytes":62374,"contentBytes":11287}}