Het einde van een tijdperk: van ingress-nginx naar de Gateway API

De Kubernetes ingress-nginx controller is jarenlang de gouden standaard geweest voor het afhandelen van inkomend verkeer in een Kubernetes cluster. Een project op Github met meer dan 19500 sterren. Echter, de ontwikkeling rondom de originele Ingress-resource loopt tegen zijn grenzen aan. De community verschuift de focus volledig naar de Gateway API, wat directe gevolgen heeft voor de ondersteuning van de huidige nginx-controller. Sinds maart 2026 is de actieve ontwikkeling gestopt aan deze ingress-controller.

Waarom stopt de ondersteuning?

De belangrijkste reden voor het End-of-Life (EOL) raken van de traditionele ingress-nginx is de architectonische beperking van de Ingress-resource zelf. Ingress is "bevroren" in ontwikkeling om plaats te maken voor een toekomstbestendiger model.

• Geen nieuwe patches: zodra de ondersteuning stopt, worden er geen updates meer uitgebracht.

• CVE Risico's: toekomstige kwetsbaarheden (Common Vulnerabilities and Exposures) worden niet meer gepatched. Voor productie-omgevingen is dit een onacceptabel security-risico.

• Beperkte functionaliteit: nieuwe netwerkstandaarden worden enkel nog ontwikkeld binnen de Gateway API.

Bestaande installaties en gebruiken in Helm charts zullen niet veranderen of stoppen met werken.

De opvolger: Gateway API

De Gateway API is niet zomaar "Ingress v2", maar een volledige herziening van hoe we verkeer routeren. Het biedt een rol gebaseerde aanpak waarbij infrastructuur (GatewayClass), toegangspunten (Gateway) en routing (HTTPRoute) van elkaar zijn gescheiden.

Grote providers die de Gateway API ondersteunen

Als je nu wilt overstappen, zijn er verschillende volwassen implementaties beschikbaar:

Hoe eenvoudig is de overstap?

De complexiteit van de migratie hangt sterk af van hoe "standaard" de huidige configuratie is:

1. Standaard Ingress: gebruik je alleen basisfuncties zoals hostnames en paden? Dan is de overstap naar een andere controller of de Gateway API relatief eenvoudig. De logica blijft immers hetzelfde.

1. De "Annotatie-val": ingress-nginx leunt zwaar op specifieke annotaties (zoals nginx.ingress.kubernetes.io/rewrite-target). Deze zijn niet direct overdraagbaar. Als je omgeving vol staat met nginx-specifieke annotaties, zal de configuratie handmatig vertaald moeten worden naar de nieuwe standaarden binnen de Gateway API.

Advies: begin vandaag nog met het inventariseren van je Ingress-resources. Hoe minder specifiek je annotaties zijn, hoe soepeler de weg naar de Gateway API zal verlopen. Beide installaties kunnen naast elkaar gedraaid worden en omgevingen kunnen gefaseerd gemigreerd worden.