En Kubernetes, una de las tareas más críticas es exponer los servicios del clúster hacia el exterior. Durante años, Ingress ha sido el estándar para manejar tráfico HTTP y HTTPS como puerta de enlace que enruta solicitudes hacia los servicios correctos dentro del clúster. Aunque Ingress ha cumplido su función, presenta limitaciones en extensibilidad, consistencia entre implementaciones y soporte para escenarios avanzados de gestión de tráfico.
Para resolver estas brechas, surge Gateway API como la evolución natural de Ingress. A diferencia de Ingress, que se centra en enrutamiento simple, Gateway API ofrece un modelo más expresivo, flexible y orientado a roles, con comportamiento consistente entre proveedores y entornos. Si tu organización depende hoy de Ingress y está valorando migrar, esta guía te explica por qué merece la pena, qué debes tener en cuenta y cómo ejecutar la migración paso a paso sin interrumpir tu clúster en producción.
En Q2BSTUDIO acompañamos a empresas en esta transición con arquitectura moderna, automatización y seguridad extremo a extremo. Somos una empresa de desarrollo de software con foco en aplicaciones a medida y software a medida, especialistas en inteligencia artificial, ciberseguridad, agentes IA, servicios inteligencia de negocio y power bi, además de servicios cloud aws y azure. Descubre cómo optimizamos tu plataforma con nuestros servicios cloud en Azure y AWS y cómo potenciamos tus productos digitales con desarrollo de aplicaciones a medida.
Por qué migrar a Gateway API. Gateway API mejora claramente la expresividad del enrutamiento, separa responsabilidades entre equipos, integra políticas y seguridad como primera clase y reduce el bloqueo de proveedor. Si quieres profundizar en los motivos, consulta este análisis en detalle en el siguiente enlace: Gateway API, el futuro del networking en Kubernetes.
Retos habituales al migrar. Soporte del controlador, ya que no todos los controladores de Ingress implementan completamente Gateway API; curva de aprendizaje por la introducción de recursos como Gateways, Routes y Policies; posibles huecos de funcionalidad que aún dependen de extensiones del proveedor; y sobrecarga operativa al mantener Ingress y Gateway en paralelo durante la transición.
Mejores prácticas. Comienza con servicios no críticos para validar el flujo; separa roles para que el equipo de plataforma gestione Gateways y los equipos de aplicación gestionen Routes; aplica GitOps con control de versiones y revisiones; monitoriza y observa con logs, métricas y trazas; mantente actualizado con capacidades como mTLS, enrutamiento gRPC y traffic splitting a medida que se estandarizan.
Estrategia de migración desde Ingress a Gateway API. La clave es planificar, probar y adoptar por fases.
Investigación y planificación. Audita tus Ingress actuales, controladores, hosts, paths, TLS, anotaciones y servicios backend. Extrae el inventario con kubectl get ingress -A -o yaml y documenta las dependencias. Selecciona un controlador compatible con Gateway API como NGINX Gateway Fabric, Traefik, HAProxy o Istio según tus requisitos de rendimiento, seguridad y soporte.
Mapeo de recursos. IngressClass se corresponde con GatewayClass, un Ingress típico se descompone en un Gateway más uno o varios HTTPRoute y, si aplica, políticas complementarias. Revisa RBAC y asigna permisos granulares por rol y namespace.
Prueba de concepto. Despliega Gateway API en un entorno no productivo y valida enrutamiento, TLS y conectividad de servicios antes de expandir el alcance.
Ejecución en paralelo. Mantén Ingress sirviendo tráfico de producción y crea los recursos equivalentes de Gateway y HTTPRoute en paralelo. Usa dominios de pruebas como myapp.ejemplo.com para validar comportamiento, cabeceras y reescrituras.
Migración de TLS. En Gateway API, TLS es de primera clase. Crea secretos TLS en el namespace correspondiente y refiérete a ellos desde los listeners del Gateway. Si el secreto está en un namespace diferente, autoriza el acceso con un ReferenceGrant adecuado.
Anotaciones específicas del proveedor. Lo que en Ingress resolvías con anotaciones, en Gateway API suele existir como campo nativo. Coincidencia por cabeceras mediante matches.headers, reescrituras de ruta con filters.requestRedirect y filters.urlRewrite, y distribución de tráfico con backendRefs y weight para canary o blue green.
Corte de tráfico a producción. Cambia DNS para apuntar al balanceador del Gateway, supervisa latencia, errores y logs, y conserva la posibilidad de revertir a Ingress mientras ambos conviven.
Retirada de Ingress. Cuando valides estabilidad, elimina objetos Ingress y desinstala el controlador, dejando Gateway API como la única fuente de verdad para el networking de servicios.
Guía paso a paso en un clúster en ejecución. Prerrequisitos. Kubernetes 1.24 o superior con deployments, services y pods en funcionamiento, y un Ingress operativo del que partiremos.
Paso 1 instalación de recursos de Gateway API. Instala los CRD estándar de Gateway API con kubectl kustomize seguido de kubectl apply, usando el manifiesto del proveedor que hayas elegido. Verifica con kubectl get crd y comprueba que aparezcan los recursos de gateway.
Paso 2 configurar NGINX Gateway Fabric. Aplica los CRD y el despliegue del controlador en modo NodePort si lo necesitas para pruebas en on premises. Verifica que los pods en el namespace nginx-gateway estén en estado listo. Ajusta el Service nginx-gateway para exponer los puertos NodePort 30080 para HTTP y 30081 para HTTPS. Puedes editar el Service y fijar los nodePort manualmente.
Paso 3 crear GatewayClass y Gateway. Define una GatewayClass llamada nginx cuyo controllerName apunte al controlador del proveedor. Crea un Gateway en el namespace nginx-gateway con listeners HTTP en el puerto 80 y HTTPS en el 443 para el hostname myweb.k8s.local. En el listener HTTPS, referencia el secret TLS web-tls-secret del namespace donde esté la aplicación si usas ReferenceGrant o del propio namespace del Gateway si no lo necesitas. Permite rutas desde todos los namespaces o restringe según tus políticas.
Paso 4 crear HTTPRoute. En el namespace web-app, define un HTTPRoute para myweb.k8s.local que se asocie al Gateway nginx-gateway mediante parentRefs, uno para la sección http y otro para la sección https si quieres diferenciar ambos. Crea una regla con PathPrefix barra y envía el tráfico a tu service web-service en el puerto 80. Añade más reglas si requieres cabeceras, rewrites o redirecciones.
Paso 5 verificación. Describe el Gateway para confirmar que los listeners están programados y con direcciones asignadas. Describe los HTTPRoute y verifica que el estado de los padres muestre Accepted en True. Si el secret TLS está en otro namespace y el listener falla, crea un ReferenceGrant en el namespace de la aplicación permitiendo acceso desde el Gateway al Secret especificado.
Paso 6 pruebas funcionales. Comprueba HTTP con curl -v -H Host: myweb.k8s.local https://IP_DEL_NODO:30080 barra. Para HTTPS, añade al archivo hosts la resolución de myweb.k8s.local hacia IP_DEL_NODO y prueba con curl -v -k https://myweb.k8s.local:30081 barra. Valida códigos de estado, cabeceras, latencia y trazas.
Paso 7 retirada del Ingress antiguo. Cuando valides la estabilidad del tráfico y la observabilidad, elimina el recurso Ingress y, si procede, desinstala su controlador. Mantén los manifiestos de Gateway API como fuente única bajo GitOps para auditoría y despliegue reproducible.
Consejos adicionales. Para canary o balanceo ponderado, utiliza varios backendRefs con pesos, por ejemplo 80 por ciento al servicio v1 y 20 por ciento al servicio v2. Para reescrituras de ruta, usa filtros de urlRewrite o requestRedirect en la regla correspondiente. Para seguridad avanzada, activa mTLS y políticas por namespace cuando tu controlador lo soporte. Integra dashboards con métricas y logs del plano de datos y usa alertas sobre errores 5xx y saturación de conexiones.
Beneficios para tu organización. Migrar de Ingress a Gateway API no es solo cambiar de herramienta, es preparar tu plataforma para el futuro con roles claros, más capacidades y menos bloqueo de proveedor. En Q2BSTUDIO te ayudamos a ejecutar esta transición alineada con tus objetivos de negocio, integrando prácticas de ciberseguridad, automatización, ia para empresas y analítica con power bi y servicios inteligencia de negocio. Si necesitas escalar en la nube y optimizar costes, consulta nuestros servicios cloud aws y azure. Si buscas crear productos digitales diferenciales, revisa nuestro enfoque en software a medida y aplicaciones a medida.
Conclusión. Avanza de forma incremental, documenta cada cambio, monitoriza en todo momento y utiliza GitOps para controlar el riesgo. Con Gateway API obtendrás una base más fiable, flexible y moderna para tus aplicaciones, reforzada por buenas prácticas de ciberseguridad y la incorporación de inteligencia artificial y agentes IA en tus procesos. En Q2BSTUDIO estamos listos para acompañarte de extremo a extremo en tu viaje hacia una plataforma cloud nativa de alto rendimiento.