Soc Òscar Mas i avui m'agradaria explicar-vos que està passant amb l'Ingress de Kubernetes i seguidament com solucionar aquest esdeveniment. Per això em faig aquestes preguntes:
- Què està passant amb l’Ingress de Kubernetes?
- Com solucionar el EOL d’Ingress?
Què està passant amb l’Ingress de Kubernetes?
Ja fa temps (novembre del 2025) la web oficial de Kubernetes va anunciar que continuarien treballant en el projecte de Ingress fins al març del 2026 i a partir d'aquella data, no és que eliminessin el sistema de Ingress, sinó que es congelava el projecte i no sortirien més versions noves.
Ingress vs Ingress NGINX
Abans de continuar, hem d'explicar un tema que porta a molta confusió: fins ara, Kubernetes s'havia posicionat molt clarament a favor del "Ingress NGINX", que és un Ingress basat en NGINX. El que és molt important no confondre els dos termes:
- Ingress: és el sistema d'accés a Kubernetes
- Ingress NGINX: és un sistema de Ingress que permet l'accés a Kubernetes.
Com a concepte; quan parlem de "Ingress NGINX", queda molt clar que és un producte, però quan parlem de "Ingress", en comptes de fer servir "Ingress NGINX", podríem haver fet servir "Traefik" o qualsevol altre sistema de Ingress.
A conseqüència de què el seu sistema de Ingress era molt antic i portava una sèrie d'inconvenients, Kubernetes fa temps va crear el Gateway API.
L’alternativa: Gateway API
En el concepte de Gateway API ens hem d'aturar un segon, ja que també pot generar confusió. Igual que crea confusió el "Ingress" amb "Ingress NGINX".
Existeixen dos conceptes totalment diferents que són:
- Gateway API: És el nou estàndard de Kubernetes que ve a substituir el "Ingress"
- API Gateway: És aquella eina que ens serveix per protegir i protegir les nostres APIs, que estan exposades a Internet.
Models d’accés a Kubernetes
Fins aquí tenim dos conceptes ben diferenciats, que són els estàndards de Kubernetes que serveixen per permetre que el tràfic de fora del clúster de Kubernetes als sistemes de dintre del nostre clúster i són:
- Ingress
- Gateway API
Però a part d'aquests dos conceptes, existeix un tercer concepte i és que; cada fabricant crea els seus propis CRD's. Per tant, passem de tenir dos conceptes a tenir tres i a conseqüència, tenim tres formes d'accés al clúster:
- Ingress
- Gateway API
- CRD del fabricant (com podria ser Traefik)
Us deixo un esquema que em vaig fer el seu dia, per poder entendre les diferències:
Avantatges de Gateway API
Els avantatges del nou sistema que ens dona Kubernetes (Gateway API), són diversos i es veu que s'ho han pensat molt bé a l'hora d'implementar-ho. Jo no explicaré tots els avantatges, però repassarem les que crec que són més importants:
- Nou disseny de rols
- Gestió nativa de Canary i Blue/Green
- Multi Protocol: gRPC, HTTP, HTTPS, TCP i UDP
- Traffic splitting
- i moltes més funcionalitats...
Com solucionar el EOL d’Ingress?
Doncs la veritat és que la resposta és bastant senzilla: migrar a Gateway API o als CRD's del fabricant, ja sigui Traefik o qualsevol altre.
En aquest article, per seguir els standards, procedirem a explicar-vos una configuració amb l'estàndard de Gateway API mitjançant Traefik.
Començarem configurant 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
Crec que del "values" de traefik hi ha poc a explicar, el fitxer és bastant explicatiu.
Un cop creat el fitxer l'instal·larem:
$ 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 d'aquí crearem un servei i uns pods amb un deployment. Aquesta part és bastant estàndard, el que és important és la creació dels elements del Gateway API, que són els següents:
- GatewayClass
- Gateway
- HTTPRoute
Us els detallo a continuació:
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
Un cop aplicats els manifest, podrem observar el següent:
$ 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 aquest article us hagi servit d'ajuda i si més no, us hagi estat útil per acabar d'aclarir conceptes.