EOL Ingress Kubernetes: alternativas y migración a Gateway API

Soy Òscar Mas y hoy me gustaría explicaros qué está pasando con el Ingress de Kubernetes y seguidamente cómo solucionar este evento. Por eso me hago estas preguntas:

• ¿Qué está pasando con el Ingress de Kubernetes?
  
• ¿Cómo solucionar el EOL de Ingress?

¿Qué está pasando con el Ingress de Kubernetes?

Hace tiempo (noviembre de 2025) la web oficial de Kubernetes anunció que continuarían trabajando en el proyecto de Ingress hasta marzo de 2026 y a partir de esa fecha, no es que eliminaran el sistema de Ingress, sino que se congelaba el proyecto y no saldrían más versiones nuevas.

Ingress vs Ingress NGINX

Antes de continuar, debemos explicar un tema que lleva a mucha confusión: hasta ahora, Kubernetes se había posicionado muy claramente a favor de “Ingress NGINX”, que es un Ingress basado en NGINX. Es muy importante no confundir los dos términos:

• Ingress: es el sistema de acceso a Kubernetes
• Ingress NGINX: es un sistema de Ingress que permite el acceso a Kubernetes
  

Como concepto; cuando hablamos de “Ingress NGINX”, queda muy claro que es un producto, pero cuando hablamos de “Ingress”, en lugar de usar “Ingress NGINX”, podríamos haber usado “Traefik” o cualquier otro sistema de Ingress.

Como consecuencia de que su sistema de Ingress era muy antiguo y tenía una serie de inconvenientes, Kubernetes creó hace tiempo el Gateway API. 

La alternativa: Gateway API

En el concepto de Gateway API debemos detenernos un segundo, ya que también puede generar confusión. Igual que genera confusión “Ingress” con “Ingress NGINX”. 

Existen dos conceptos totalmente diferentes que son:

• Gateway API: es el nuevo estándar de Kubernetes que viene a sustituir el “Ingress”
• API Gateway: es aquella herramienta que nos sirve para proteger nuestras APIs, que están expuestas a Internet.
  

Modelos de acceso a Kubernetes

Hasta aquí tenemos dos conceptos bien diferenciados, que son los estándares de Kubernetes que sirven para permitir que el tráfico de fuera del clúster de Kubernetes a los sistemas dentro de nuestro clúster, y son:

• Ingress
• Gateway API

Pero aparte de estos dos conceptos, existe un tercer concepto y es que cada fabricante crea sus propios CRD’s. Por lo tanto, pasamos de tener dos conceptos a tener tres y, en consecuencia, tenemos tres formas de acceso al clúster:

• Ingress
• Gateway API
• CRD del fabricante (como podría ser Traefik)

Os dejo un esquema que me hice en su día para poder entender las diferencias:

Ventajas de Gateway API

Las ventajas del nuevo sistema que nos da Kubernetes (Gateway API) son diversas y se ve que lo han pensado muy bien a la hora de implementarlo. No explicaré todas las ventajas, pero repasaremos las que creo que son más importantes:

• Nuevo diseño de roles
• Gestión nativa de Canary y Blue/Green
• Multi Protocolo: gRPC, HTTP, HTTPS, TCP y UDP
• Traffic splitting
• y muchas más funcionalidades...
  

¿Cómo solucionar el EOL de Ingress?

Pues la verdad es que la respuesta es bastante sencilla: migrar a Gateway API o a los CRD’s del fabricante, ya sea Traefik o cualquier otro.

En este artículo, para seguir los estándares, procederemos a explicaros una configuración con el estándar de Gateway API mediante Traefik.

Comenzaremos configurando el “values” de traefik:

ingressClass:
  enabled: false
gateway:
  enabled: false
gatewayClass:
  enabled: false
providers:
  kubernetesCRD:
    enabled: trueIngressRoute
  kubernetesIngress:
    enabled: false
  kubernetesGateway:
    enabled: true
  kubernetesIngressNginx:
    enabled: false

Creo que del “values” de traefik hay poco que explicar, el fichero es bastante explicativo.

Una vez creado el fichero lo instalaremos:

$ helm repo add traefik https://traefik.github.io/charts && helm repo update

helm upgrade --install \
traefik traefik/traefik \
--create-namespace \
--namespace traefik \
--version=38.0.1 \
-f values-traefik.yaml

A partir de aquí crearemos un servicio y unos pods con un deployment. Esta parte es bastante estándar, lo importante es la creación de los elementos del Gateway API, que son los siguientes:

• GatewayClass
• Gateway
• HTTPRoute

Os los detallo a continuación:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: traefik
  labels:
    app.kubernetes.io/name: traefik-gateway
    app.kubernetes.io/component: gateway-class
spec:
  controllerName: traefik.io/gateway-controller

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-api
  namespace: test1
  labels:
    app.kubernetes.io/name: traefik-gateway
    app.kubernetes.io/component: gateway
spec:
  gatewayClassName: traefik
    listeners:
    - name: http
      protocol: HTTP
      port: 8000
      allowedRoutes:
        namespaces:
          from: Same

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: test-httproute
  namespace: test1
spec:
  parentRefs:
    - name: gateway-api
      sectionName: http
      kind: Gateway
  hostnames:
    - test1.ilba.cat
  rules:
     - matches:
        - path:
            type: PathPrefix
            value: /
       backendRefs:
        - name: app-ilba-service
          namespace: test1
          port: 8080

Una vez aplicados los manifest, podremos observar lo siguiente:

$ k get gatewayclass
NAME      CONTROLLER                      ACCEPTED   AGE
traefik   traefik.io/gateway-controller   True       147m

$ k get gateway -A
NAMESPACE   NAME          CLASS     ADDRESS        PROGRAMMED   AGE
test1       gateway-api   traefik   172.26.0.101   True         147m

$ k get httproute -A
NAMESPACE   NAME             HOSTNAMES            AGE
test1       test-httproute   ["test1.ilba.cat"]   16m

Espero que este artículo os haya servido de ayuda y, como mínimo, os haya sido útil para acabar de aclarar conceptos.