En Kubernetes, una de las tareas más críticas es exponer de forma segura y eficiente los servicios del clúster hacia el exterior. Durante años, Ingress fue el estándar para gestionar tráfico HTTP y HTTPS como puerta de enlace que enruta solicitudes de clientes externos a los servicios correctos dentro del clúster. Aunque Ingress ha cumplido bien su propósito, presenta limitaciones en extensibilidad, consistencia entre implementaciones y soporte para escenarios avanzados de gestión de tráfico.
Para cubrir esas brechas, Kubernetes introdujo Gateway API, una alternativa de nueva generación. A diferencia de Ingress, que se centra en enrutamiento simple, Gateway API ofrece un modelo más rico y orientado a roles. Es más expresivo, flexible y neutral respecto a proveedores, lo que facilita definir comportamientos de red complejos manteniendo una experiencia consistente en diferentes entornos.
Si tu organización usa Ingress y está considerando migrar a Gateway API, esta guía te acompaña paso a paso. Verás por qué merece la pena adoptarlo, qué cambios debes considerar y cómo migrar desde tu configuración actual de Ingress a Gateway API en un clúster en ejecución. Para profundizar en los motivos de la migración consulta este recurso: artículo recomendado
Desafíos al migrar a Gateway API
• Compatibilidad de controladores no todos los controladores de Ingress ofrecen soporte completo de Gateway API, lo que puede limitar funciones o forzar la adopción de un controlador con soporte nativo.
• Curva de aprendizaje Gateway introduce nuevos recursos Gateways, Routes y Policies, además de un diseño basado en roles. Los equipos necesitan tiempo y formación para ajustar sus flujos de trabajo.
• Posibles brechas de funciones aunque Gateway API es más expresivo, algunos casos avanzados aún dependen de extensiones específicas de proveedor, reduciendo la portabilidad.
• Sobrecarga operativa durante la migración podrías ejecutar Ingress y Gateway en paralelo, aumentando la complejidad de configuración y el consumo de recursos.
Buenas prácticas para migrar a Gateway API
• Empieza en pequeño migra primero servicios no críticos para validar el flujo, ganar confianza y detectar problemas antes de mover cargas críticas.
• Aprovecha la separación de roles la gran fortaleza de Gateway API es su diseño por dominios de responsabilidad. Infraestructura gestiona Gateways y los equipos de desarrollo definen Routes, mejorando seguridad, escalabilidad y eficiencia.
• Adopta GitOps versiona Gateways y Routes en Git, habilita colaboración, auditoría y reversión rápida ante incidencias.
• Observa y monitoriza valida el enrutamiento con logs, métricas y trazas para asegurar rendimiento y detectar anomalías de forma temprana.
• Mantente actualizado la especificación evoluciona estandarizando funciones como mTLS, enrutamiento gRPC o traffic splitting. Estar al día te permite aprovechar mejoras cuando se estabilizan.
Estrategia de migración de Ingress a Gateway API
Fase de análisis y planificación inventaría objetos Ingress, controlador actual, hosts, paths, TLS, anotaciones y servicios backend. Un apoyo útil es kubectl get ingress -A -o yaml > all-ingresses.yaml. Elige un controlador compatible con Gateway API. Opciones populares incluyen NGINX Gateway Fabric, Traefik con Gateway API, HAProxy con Gateway API e Istio Gateway API.
Equivalencias conceptuales IngressClass pasa a GatewayClass. Ingress se traduce a Gateway más HTTPRoute. Revisa RBAC, ya que Gateway API introduce control de acceso más granular por recurso.
Prueba de concepto crea recursos de Gateway API en un espacio de nombres no productivo, valida enrutamiento, TLS y conectividad de servicios antes de ampliar el alcance.
Ejecución en paralelo mantén Ingress para tráfico productivo y despliega Gateway más HTTPRoute equivalentes en paralelo. Valida con dominios de pruebas como myapp.ejemplo.com.
Migración de TLS en Gateway API TLS es de primera clase. Crea secretos TLS y refiérecelos en los listeners del Gateway. Si el secreto está en otro namespace, crea un ReferenceGrant para autorizar el acceso cross-namespace.
Gestión de anotaciones específicas de proveedor en Ingress son frecuentes anotaciones como nginx.ingress.kubernetes.io. En Gateway API se sustituyen por campos nativos. Coincidencias de cabeceras con matches.headers, reescritura de rutas con filtros requestRedirect o urlRewrite, y división de tráfico con backendRefs y weight por ejemplo enviar 80 por ciento del tráfico al servicio v1 y 20 por ciento a v2.
Conmutación de tráfico productivo actualiza el DNS al balanceador del Gateway, monitoriza logs y métricas y conserva el plan de reversión a Ingress mientras ambos conviven.
Retirada de Ingress elimina los objetos Ingress y desinstala el controlador una vez confirmada la estabilidad. Conserva Gateway API como fuente de verdad para el networking de servicios.
Guía paso a paso en un clúster existente
Requisitos previos clúster Kubernetes 1.24 o superior con despliegues, servicios y pods en funcionamiento expuestos actualmente mediante Ingress.
Paso 1 Instalar los recursos de Gateway API aplica los CRDs estándar del proyecto o del controlador elegido. Ejemplo con NGINX Gateway Fabric usando kubectl kustomize https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v1.5.1 seguido de kubectl apply -f -. Verifica con kubectl get crd y filtra por gateway.
Paso 2 Instalar y configurar NGINX Gateway Fabric despliega los CRDs con kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/deploy/crds.yaml. Despliega el controlador con Service de tipo NodePort usando kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/deploy/nodeport/deploy.yaml. Comprueba pods con kubectl get pods -n nginx-gateway. Ajusta los puertos del Service con kubectl edit svc nginx-gateway -n nginx-gateway y establece nodePort 30080 para HTTP y 30081 para HTTPS.
Paso 3 Crear GatewayClass y Gateway define un GatewayClass con controllerName del controlador elegido, por ejemplo gateway.nginx.org/nginx-gateway-controller. Crea un Gateway en el namespace del controlador con gatewayClassName igual al anterior. Declara dos listeners uno HTTP en el puerto 80 y otro HTTPS en el 443 con hostname myweb.k8s.local. En el listener HTTPS define tls en modo Terminate y referencia al secreto TLS web-tls-secret del namespace de la app web-app usando certificateRefs. En allowedRoutes permite desde todos los namespaces o limita según tu política.
Paso 4 Crear HTTPRoute para HTTP y HTTPS en web-app crea un HTTPRoute con parentRefs apuntando al Gateway nginx-gateway en el namespace nginx-gateway y sectionName http o https según corresponda. Define hostnames myweb.k8s.local. En rules usa matches con PathPrefix barra y backendRefs al servicio web-service en el puerto 80.
Paso 5 Verificar el estado usa kubectl describe gateway nombre-del-gateway y kubectl describe httproute nombre-de-la-route para revisar condiciones. En el estado del HTTPRoute verifica que la condición Accepted sea True y que los listeners estén programados. Si el secreto TLS está en otro namespace, crea un ReferenceGrant en el namespace web-app que autorice al Gateway del namespace nginx-gateway a leer el Secret web-tls-secret.
Paso 6 Probar conectividad prueba HTTP con curl hacia el NodePort 30080 enviando el host myweb.k8s.local. Añade myweb.k8s.local al archivo hosts apuntando a la IP del nodo. Prueba HTTPS con curl -k a https://myweb.k8s.local:30081 y verifica que la app responde correctamente.
Paso 7 Retirar el Ingress antiguo una vez validado el comportamiento y la observabilidad, borra los Ingress del namespace de la aplicación y desinstala el controlador de Ingress. Mantén versiones en Git para rollback si fuese necesario.
Conclusión migrar de Ingress a Gateway API no es solo cambiar de herramienta, es preparar tu plataforma para el futuro. Con separación de responsabilidades, más capacidades nativas y menos dependencia de extensiones propietarias, Gateway API facilita la colaboración entre equipos mientras habilita un networking más robusto y flexible.
En Q2BSTUDIO aceleramos esta transición de forma segura y con foco en negocio. Somos una empresa de desarrollo de software y aplicaciones a medida, especialistas en inteligencia artificial, ciberseguridad, servicios cloud AWS y Azure, servicios de inteligencia de negocio y power bi, automatización de procesos, agentes IA e IA para empresas. Si necesitas diseño, implementación y operación de plataformas Kubernetes híbridas o multicloud, descubre nuestros servicios cloud en AWS y Azure o cómo integramos esta arquitectura en soluciones de aplicaciones a medida y software a medida, alineadas con tus objetivos de escalabilidad y seguridad.