Gateway API in plaats van ingress-nginx: verkeer en TLS op orde
Sinds maart 2026 krijgt ingress-nginx geen releases, bugfixes of securityfixes meer. Je cluster blijft draaien, maar elke nieuwe kwetsbaarheid in de controller die al je verkeer afhandelt, blijft open. Wij migreren naar de Gateway API met een onderhouden implementatie, richten TLS in met cert-manager en zetten Cloudflare en Varnish op de juiste plek in de keten.
- Inventaris van je Ingress-resources en annotaties
- Gateway API met een onderhouden implementatie, parallel getest
- cert-manager, Cloudflare Full (strict) en Varnish in één ontwerp
Wat is er met ingress-nginx gebeurd, en wat is de Gateway API?
ingress-nginx was jarenlang de standaard ingress-controller in Kubernetes: één project dat Ingress-resources vertaalde naar een nginx-configuratie. In november 2025 kondigden SIG Network en het Security Response Committee van Kubernetes aan dat het project met pensioen zou gaan. Tot maart 2026 was er nog best-effort onderhoud. Daarna stopten releases, bugfixes en securityupdates. Bestaande installaties blijven werken en de artefacten blijven downloadbaar.
In januari 2026 volgde een statement van de Steering Committee en het Security Response Committee, met een duidelijke boodschap: wie na de pensionering op ingress-nginx blijft, laat zichzelf en zijn gebruikers kwetsbaar voor aanvallen. Ook meldden ze dat geen enkel alternatief een directe drop-in vervanging is. Het geplande opvolgproject InGate is eveneens gestopt.
De aanbevolen opvolger is de Gateway API. Dat is geen controller, maar een set Kubernetes-resources die Ingress vervangt: GatewayClass, Gateway, HTTPRoute en verwante types. Verschillende projecten implementeren die API. Let op de naamverwarring: de door F5 onderhouden NGINX Ingress Controller is een ander project dan de community-versie die stopt.
Ingress versus Gateway API: wat verandert er
Het grootste verschil: functies die eerst in annotaties zaten, zijn nu velden in de API. Dat maakt configuratie draagbaar tussen implementaties.
| Onderwerp | Ingress (met ingress-nginx) | Gateway API |
|---|---|---|
| Rolverdeling | Eén resource voor alles, per applicatie | Platformteam beheert GatewayClass en Gateway, applicaties hangen er HTTPRoutes aan |
| Routering op header of methode | Via controller-specifieke annotaties | Standaard matches in HTTPRoute |
| Verkeer splitsen voor canary | Via canary-annotaties van ingress-nginx | Gewichten per backendRef in HTTPRoute |
| Redirects en header-aanpassingen | Annotaties zoals ssl-redirect en configuration-snippet | Filters zoals RequestRedirect, RequestHeaderModifier en URLRewrite |
| TLS naar de backend | Annotaties, per controller verschillend | BackendTLSPolicy, sinds v1.4 in het Standard-kanaal |
| Routes over namespaces heen | Niet standaard geregeld | Expliciet toegestaan via allowedRoutes en ReferenceGrant |
| TLS per team op een gedeelde Gateway | Per Ingress een eigen tls-blok | ListenerSet, sinds v1.5 in het Standard-kanaal |
Plan een vrijblijvend gesprek over je project
Een half uur via video met de mensen die het werk ook echt doen. Kies hieronder een moment dat jou past.
- Direct met het vaste team, geen tussenlagen
- Concrete feedback op je huidige situatie of plannen
- Eerlijk advies, ook als het antwoord "niet doen" is
- Indicatie van kosten en tijdlijn
Plan een gratis Tech Check
Vrijblijvend jouw uitdagingen bespreken
Of bel direct: 0591-239 299
Gateway API-implementaties: welke past bij jouw cluster
Alle implementaties spreken dezelfde API, maar verschillen in architectuur, extra features en hoe ze extensies regelen.
Envoy Gateway
Envoy-proxy aangestuurd via Gateway API, als zelfstandig project binnen het Envoy-ecosysteem. Een pragmatische standaard als je nog geen service mesh draait en een breed ondersteunde implementatie wilt.
Lees verder →NGINX Gateway Fabric
Implementatie van F5 op basis van nginx. Prettig als je team nginx kent en het gedrag zo dicht mogelijk bij de oude situatie wilt houden.
Lees verder →Traefik
Ondersteunt zowel Ingress als Gateway API. Lage drempel bij kleinere clusters en bekend van k3s, waar het standaard wordt meegeleverd.
Lees verder →Cilium
Als je Cilium al als CNI gebruikt, kan het ook de Gateway API afhandelen. Eén component minder, met NetworkPolicies en observability uit dezelfde hoek.
Lees verder →Istio
Logische keuze als je al een service mesh met Istio draait of mTLS tussen services nodig hebt. Voor een enkele webshop vaak meer dan nodig.
Lees verder →Load balancer van je cloud
GKE, EKS en AKS bieden eigen Gateway API-integraties met hun load balancers. Minder onderhoud, wel meer binding aan die aanbieder.
Lees verder →De migratie van ingress-nginx naar de Gateway API, stap voor stap
We beginnen met een inventaris. Alle Ingress-resources in alle namespaces, met hun annotaties. Bij Magento- en Laravel-platformen zien we vaak proxy-body-size voor uploads, proxy-read-timeout voor lange exports, ssl-redirect, eigen headers via configuration-snippet en soms canary-annotaties. Elk van die annotaties moet een equivalent krijgen, of bewust vervallen. configuration-snippet is precies het soort vrij nginx-blok dat in de Gateway API geen één-op-één vervanging heeft.
Voor de eerste vertaling gebruiken we ingress2gateway. Versie 1.0 kwam in maart 2026 uit en ondersteunt ruim dertig veelgebruikte ingress-nginx-annotaties, met waarschuwingen voor wat het niet kan vertalen. Het resultaat is een startpunt, geen eindproduct. We controleren elke gegenereerde HTTPRoute en schrijven de rest met de hand of met de policy-resources van de gekozen implementatie.
Daarna draaien beide naast elkaar. De nieuwe Gateway krijgt een eigen load balancer en een eigen IP. We testen met een hosts-entry of een tijdelijke hostnaam: checkout, betaal-callbacks, admin, API's, uploads en redirects. Pas als alles klopt, verlagen we de TTL en zetten we DNS of de Cloudflare-origin om. ingress-nginx blijft tot na de overstap staan als terugvaloptie, en wordt daarna opgeruimd.
De laatste stap is de GitOps-repository. Ingress-templates in je Helm-charts worden HTTPRoute-templates, de Gateway komt in de platform-laag. Argo CD rolt het daarna uit zoals de rest. In ons artikel over het einde van ingress-nginx staat de volledige checklist.
Een HTTPRoute voor Magento: hoe het eruitziet
Het platform beheert één Gateway, bijvoorbeeld met de naam web in de namespace gateway, met listeners voor HTTP op poort 80 en HTTPS op 443. De HTTPS-listener verwijst naar een TLS-secret dat cert-manager vult. allowedRoutes bepaalt welke namespaces routes aan deze Gateway mogen hangen.
De applicatie levert de HTTPRoute. In de kern: parentRefs wijst naar de Gateway web, hostnames bevat www.jouwshop.nl, en één rule met een PathPrefix-match op / en een backendRef naar de Varnish-service op poort 80. Een tweede rule stuurt /admin_beheer direct naar de PHP-service, buiten Varnish om, eventueel met een header-match of beperking op bron-IP via de policy van je implementatie.
Een aparte HTTPRoute op de HTTP-listener doet alleen een RequestRedirect-filter met scheme https en statusCode 301. Zo staat de redirect naar HTTPS in de API zelf, niet in een annotatie. Grote uploads en lange timeouts zijn niet in elke implementatie hetzelfde geregeld. HTTPRoute heeft een timeouts-veld voor requests; body-limieten zitten bij de meeste implementaties in een eigen policy-resource. Dat leggen we per implementatie vast.
TLS met cert-manager en Let's Encrypt
cert-manager vraagt certificaten aan en vernieuwt ze automatisch. Je definieert een ClusterIssuer voor Let's Encrypt met ACME, en cert-manager regelt de validatie. Met Gateway API-ondersteuning ingeschakeld, zet je een annotatie op de Gateway en maakt cert-manager per listener het Certificate aan. Je hoeft dan geen losse Certificate-resources te onderhouden.
Er zijn twee validatiemethoden. HTTP-01 werkt via een tijdelijk pad op je domein en vraagt dat Let's Encrypt je origin kan bereiken. DNS-01 werkt via een TXT-record bij je DNS-provider en is nodig voor wildcard-certificaten. Draait Cloudflare voor je shop, dan kiezen we meestal DNS-01 met een Cloudflare API-token dat alleen DNS mag wijzigen voor die zone. Dat token staat als secret in het cluster, bij voorkeur via External Secrets.
Certificaten worden korter geldig. Let's Encrypt heeft aangekondigd dat het standaardprofiel op 10 februari 2027 naar 64 dagen gaat en op 16 februari 2028 naar 45 dagen. Met cert-manager is dat geen probleem zolang vernieuwen automatisch gaat en je bewaakt dat het lukt. Daarom hoort een alert op certificaten die binnen 14 dagen verlopen in elke monitoring-set.
Gebruik je één gedeelde Gateway voor meerdere teams of shops, dan is ListenerSet relevant: daarmee voegen teams eigen listeners en certificaten toe zonder de centrale Gateway te wijzigen. ListenerSet is in Gateway API v1.5 naar het Standard-kanaal gegaan. Of jouw implementatie en cert-manager-versie het al ondersteunen, controleren we per project.
Cloudflare ervoor, Varnish erachter: de complete keten
Bij een Magento-shop loopt een request door vier lagen. Elke laag heeft een eigen taak, en de volgorde bepaalt wat je cachet en wie je vertrouwt.
De Gateway termineert TLS en stuurt het verkeer via HTTP naar Varnish. Magento moet dan wel weten dat de bezoeker HTTPS gebruikt. Daarvoor zet de Gateway de header X-Forwarded-Proto, en Magento leest die via de offloader-header-instelling. Bij Laravel regel je hetzelfde met TrustProxies. Het echte bezoekers-IP komt van Cloudflare in CF-Connecting-IP; de Gateway en Varnish moeten die doorgeven, anders zie je in logs en rate limits alleen Cloudflare-adressen.
Magento stuurt purges naar Varnish. In Kubernetes wijst http_cache_hosts in env.php naar de Varnish-service. Bij meerdere Varnish-pods moet een purge alle pods bereiken. Dat lossen we op met een headless service en een kleine purge-proxy, of door Varnish bewust op één of twee pods te houden. Meer over Varnish-configuratie voor Magento staat in onze aparte handleiding.
Tot slot: laat de origin alleen verkeer van Cloudflare accepteren. Dat kan met een IP-allowlist op de load balancer, met Authenticated Origin Pulls of met Cloudflare Tunnel. Anders omzeilt een aanvaller je WAF door direct je load balancer-IP aan te spreken.
| Laag | Taak | TLS | Waar het vaak misgaat |
|---|---|---|---|
| Cloudflare | DNS, CDN voor statische bestanden, WAF, botbescherming | Edge-certificaat van Cloudflare; SSL-modus Full (strict) naar de origin | Flexible-modus, waardoor het verkeer naar de origin onversleuteld gaat |
| Gateway (Gateway API) | TLS-terminatie, routering per host en pad, redirects | Let's Encrypt via cert-manager of Cloudflare Origin CA-certificaat | Origin bereikbaar voor iedereen in plaats van alleen voor Cloudflare |
| Varnish | Full page cache voor HTML | Geen; verkeer binnen het cluster | Purges die niet aankomen omdat Magento het verkeerde adres kent |
| nginx en PHP-FPM | Magento of Laravel uitvoeren | Geen, of mTLS via een service mesh | Applicatie denkt dat het verzoek via HTTP binnenkwam en maakt foute redirects |
Checklist voor een veilige overstap
Voorbereiden
- Inventaris van alle Ingress-resources, annotaties en IngressClasses
- Gateway API-CRD's installeren in de versie die je implementatie ondersteunt
- Implementatie kiezen en via Helm en Argo CD uitrollen
- cert-manager met Gateway API-ondersteuning en een ClusterIssuer
Vertalen
- ingress2gateway draaien en de output regel voor regel controleren
- Annotaties zonder equivalent bewust oplossen of laten vervallen
- Redirects, headers, timeouts en uploadlimieten per route vastleggen
- HTTPRoutes in de Helm-charts of Kustomize-overlays van de applicatie
Testen
- Nieuwe Gateway parallel met eigen IP, testen via tijdelijke hostnaam
- Checkout, betaal-callbacks, admin, API's, uploads en websockets
- Echte bezoekers-IP's in logs en rate limiting
- Varnish-purges vanuit Magento na een productwijziging
Overschakelen
- DNS-TTL vooraf verlagen of de Cloudflare-origin omzetten
- Monitoring op 4xx, 5xx en latency per route tijdens de overstap
- ingress-nginx laten staan als terugvaloptie, daarna verwijderen
- Origin afschermen zodat alleen Cloudflare er nog bij kan
Onze aanpak van een Gateway API-migratie
Vijf stappen. Het vaste team dat je platform beheert, doet ook de overstap.
- 1
Inventaris en risico
We lezen alle Ingress-resources en annotaties uit en markeren wat niet één-op-één over kan. Je krijgt een lijst met keuzes, geen verrassingen.
- 2
Implementatie kiezen
Op basis van je cloud, CNI en eisen: Envoy Gateway, NGINX Gateway Fabric, Traefik, Cilium of de integratie van je aanbieder.
- 3
Bouwen als code
Gateway, HTTPRoutes, cert-manager en policies in je GitOps-repository, uitgerold met Argo CD.
- 4
Parallel testen
Nieuwe Gateway naast de oude, met eigen IP. We testen alle kritieke routes voordat er één bezoeker overgaat.
- 5
Overstap en opruimen
Gecontroleerd overschakelen met monitoring, terugvaloptie tot alles stabiel is, daarna ingress-nginx verwijderen.
Wat je opgeleverd krijgt
- Inventaris van alle Ingress-resources en annotaties met per regel de vertaling
- Gekozen Gateway API-implementatie, uitgerold via Helm en Argo CD
- Gateway en HTTPRoutes in je Helm-charts of Kustomize-overlays
- cert-manager met ClusterIssuer voor Let's Encrypt, HTTP-01 of DNS-01
- Ontwerp van de keten Cloudflare, Gateway, Varnish en PHP, inclusief headers en echte IP's
- Afgeschermde origin, alleen bereikbaar via Cloudflare
- Testrapport van kritieke routes voor en na de overstap
- Alerts op certificaten, 5xx en latency per route
Waarom Coding.nl voor ingress en Gateway API
We kennen wat erachter draait
Varnish-purges, Magento-offloader-headers, Laravel TrustProxies. De Gateway is maar één schakel, en wij kennen de hele keten.
Geen big bang
Parallel testen met een eigen IP en een terugvaloptie. Je checkout merkt niets van de overstap.
Geen tussenlagen
Je spreekt direct met de mensen die de migratie uitvoeren. Geen projectmanager die vragen doorgeeft.
Security en performance samen
We kijken naar Cloudflare, TLS en caching in één ontwerp, met metingen van echte bezoekers als RUMvision Gold Partner.
Verder lezen
- ›ingress-nginx stopt: zo migreer je naar de Gateway API
- ›Cloudflare SSL/TLS: Full (strict), origin certificate en HSTS
- ›Varnish configureren voor Magento 2 — stap voor stap
- ›Magento 2 Full Page Cache configureren: Varnish, Redis en de built-in FPC
- ›Cloudflare Pro instellen voor je webshop: stappenplan
- ›CDN configuratie voor e-commerce — Cloudflare vs Fastly vs CloudFront
- ›Canary- en blue-green deploys met Argo Rollouts
- ›Magento 2 op Kubernetes: de architectuur per component
- ›Webshop beveiligen tegen bots: carding, credential stuffing en scraping
Veelgestelde vragen
Draait je cluster nog op ingress-nginx?
Plan een gesprek. We lezen je Ingress-resources en annotaties uit en vertellen eerlijk hoeveel werk de overstap naar de Gateway API is, en welke implementatie bij je cluster past.