Guía Práctica: Sustituyendo Ingress-NGINX por Envoy Gateway (Paso a Paso)

Durante muchos años el proxy inverso del Ingress-Nginx ha sido el más utilizado en las empresas que utilizaban Kubernetes. A diferencia de Nginx-Ingress, que sí esta mantenido por una empresa, en este caso F5, Ingres-Nginx está mantenido por la comunidad, aunque realmente esa comunidad, como veremos más adelante, son muy pocas personas.

La cuestión, en marzo de este año 2026, este proyecto dirá adios, y dejará gran cantidad de entonos huérfanos de actualizaciones, nuevas versiones y parches de seguridad. Y la pregunta es acuaciante, ¿qué hacemos?

Logo de Envoy Gateway

El fin de una era: ¿Por qué migrar de Ingress-NGINX?

Durante años, el controlador Ingress-NGINX ha sido el estándar de facto para gestionar el tráfico en Kubernetes. Sin embargo, el ecosistema ha llegado a un punto de inflexión crítico. A partir de marzo de 2026, el proyecto entrará oficialmente en su fase de retiro definitivo. Esto significa que el repositorio pasará a modo de «solo lectura» y, lo más preocupante, dejará de recibir parches de seguridad, correcciones de errores y actualizaciones de compatibilidad. Mantener esta infraestructura en producción después de esa fecha supone un riesgo inasumible para cualquier entorno expuesto a internet.

Esta decisión no es arbitraria; responde a un agotamiento del modelo basado en anotaciones, que con el tiempo se volvió complejo y difícil de asegurar (como demostró la vulnerabilidad IngressNightmare en 2025). Además, la falta de una base amplia de mantenedores ha llevado a la comunidad de Kubernetes a centrar todos sus esfuerzos en soluciones más modernas, robustas y escalables. De hecho eran básicamente dos personas, las encargadas de mantener el proyecto y lo hacían en su tiempo libre. Ya no se trata de si debemos migrar, sino de hacia dónde y lo rápido que queramos hacerlo.

En este escenario, el Gateway API emerge como el sucesor natural y la alternativa más sólida. A diferencia del antiguo Ingress, Gateway API ofrece una separación clara de responsabilidades entre infraestructura y aplicaciones, soporte nativo para protocolos avanzados y una configuración estandarizada que elimina la dependencia de anotaciones propietarias. Proyectos como Envoy Gateway (el que utilizaremos en esta entrada) aprovechan este nuevo estándar para ofrecer un control de tráfico más seguro y eficiente.

Paso 1: Instalar el CRD de Gateway API

Antes de configurar MetalLB o Envoy, Kubernetes necesita conocer los «conceptos» de la Gateway API (los CRDs).

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml

Paso 2: Desplegar MetalLB

MetalLB será el encargado de darle una IP real de tu red al Gateway.

Instalar el manifiesto:

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.3/config/manifests/metallb-native.yaml

Configurar el pool de IPs (El archivo metallb.yaml):

kubectl apply -f metallb.yaml

Tiene este contenido:

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.0.150/32 
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: advertisement
  namespace: metallb-system

Paso 3: Instalar Envoy Gateway

Es el controlador que lee tus archivos de Gateway y configura los proxies Envoy automáticamente.

# Instalamos mediante el manifiesto oficial de Envoy Gateway
kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v1.1.0/install.yaml

Espera un minuto a que los pods en el namespace envoy-gateway-system estén en «Running».

Paso 4: Definir el Gateway (El archivo mi-gateway.yaml)

Aquí es donde le dices a Kubernetes que quieres un punto de entrada HTTP en el puerto 80 gestionado por Envoy.

kubectl apply -f mi-gateway.yaml

Que tiene este contenido:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy-gateway
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-red-local
  namespace: envoy-gateway-system
spec:
  gatewayClassName: envoy-gateway
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All

Verificación clave: Al aplicar esto, MetalLB debería asignarle la IP automáticamente. Compruébalo con:

kubectl get gtw gateway-red-local -n envoy-gateway-system

Deberías ver la IP 192.168.0.150 en la columna ADDRESS.

Paso 5: Desplegar el Proyecto de prueba (Podinfo)

Este es el «backend» al que queremos llegar.

Crea un archivo proyecto.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: podinfo
spec:
  selector:
    matchLabels:
      app: podinfo
  template:
    metadata:
      labels:
        app: podinfo
    spec:
      containers:
      - name: podinfo
        image: stefanprodan/podinfo
        ports:
        - containerPort: 9898
---
apiVersion: v1
kind: Service
metadata:
  name: podinfo-service
spec:
  ports:
    - port: 80
      targetPort: 9898
  selector:
    app: podinfo

Aplica el proyecto:

kubectl apply -f proyecto.yaml

Paso 6: Configurar la ruta web (HTTPRoute)

Este archivo vincula el dominio proyecto.local con el servicio anterior a través del Gateway.

Crea un archivo ruta.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: ruta-podinfo
spec:
  parentRefs:
  - name: gateway-red-local
    namespace: envoy-gateway-system
  hostnames:
  - "proyecto.local" 
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: podinfo-service
      port: 80

Aplica la ruta:

kubectl apply -f ruta.yaml

Paso 7: Configurar el DNS

Ahora podemos hacer dos cosas, o bien, si tenemos una empresa, en el DNS corporativo añadir el registro, o si lo hacemos en nuestro clúster casero, lo podemos indicar en nuestro fichero «hosts»

Puedes verificar el DNS así:

# Ejemplo para probar desde la terminal sin DNS
curl -H "Host: proyecto.local" http://192.168.0.150

Paso 8: Ver los resultados

Si todo ha ido bien, si nos vamos a nuestro navegador favorito, escribiendo «http://proyecto.local», ya deberíamos ver una imagen similar a la siguiente:

Muestra de funcionamiento de un proyecto vía Envoy Gateway

Con esto es todo por hoy, espero que esta entrada os haya sido útil a la vez que interesante. Nos leemos en la próxima.

Para saber más:

Proyecto de Gateway API en Github

Noticia de no continuación del proyecto Ingress Nginx en Kubernetes.io