Migreren van Ingress-NGINX na het stoppen in 2026

Ingress-NGINX is op 24 maart 2026 gestopt. Bestaande installaties blijven draaien en juist dat maakt het ongemakkelijk: niets dwingt een migratie af totdat een onbeveiligd lek of een incompatibele platformwijziging dat wel doet. Kubernetes is duidelijk dat er geen fixes of securityreleases meer komen. Ik behandel doorgebruik als een tijdelijk en bewust risico.

Bewijs eerst of je het werkelijk gebruikt

Begin bij de controller en niet bij Ingress-objecten. De Kubernetes-stuurgroep adviseert pods op te zoeken met het ingress-nginx application label. Ik controleer daarnaast Helm-releases, GitOps-repositories, cluster-add-ons, admission policies, DNS-records en cloudloadbalancers. Oude clusters en previewomgevingen worden makkelijk vergeten.

Per cluster maak ik een inventaris van controller-image en chart, publieke IP’s, namespaces, ingress classes, certificaten, DNS-namen en eigenaars. Daarna exporteer ik iedere Ingress en verzamel ik annotations. Die lijst met annotations is de echte migratiebacklog.

kubectl get pods --all-namespaces   --selector app.kubernetes.io/name=ingress-nginx

kubectl get ingress --all-namespaces   -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,CLASS:.spec.ingressClassName,HOSTS:.spec.rules[*].host'

kubectl get ingress --all-namespaces -o yaml > ingress-inventory.yaml

Vertaal gedrag, niet alleen YAML

Ik deel annotations in op routing, beveiliging, transport, capaciteit, observability en controller-specifieke extensies. Rewrites, regex-paden, authenticatie, snippets, body limits, timeouts, forwarded headers, CORS, canaries en client-IP-verwerking krijgen allemaal een expliciete nieuwe plek of worden bewust verwijderd.

Sommig gedrag hoort in HTTPRoute, ander gedrag in Gateway- of controllerpolicy. Een deel kan beter naar de applicatie. Een conversietool is handig voor een eerste versie, maar kent de productreden achter een annotation niet.

• Uploads: maximale bodygrootte en request-timeout
• WebSockets: upgrades, idle timeout en draining
• Authenticatie: identity headers en foutredirects
• Client-IP: vertrouwde hops en eigenaarschap van forwarded headers
• Rewrites: exacte semantiek van pad en querystring

Kies een implementatie, niet alleen Gateway API

Gateway API definieert resources; een controller implementeert ze. Ik vergelijk conformiteit, ondersteunde features, cloudintegratie, operationele volwassenheid, securityproces, upgradebeleid, metrics, statusconditions en teamervaring. Conformiteit betekent niet dat alle extensies en operationele eigenschappen gelijk zijn.

De kandidaat installeer ik eerst buiten productie en test ik met één representatieve route: TLS, redirects, een gewone API, een grote upload, WebSocket en foutpad. Die route wordt daarna ook compatibiliteitstest voor controller-updates.

Bouw een parallel pad

Ik laat de nieuwe Gateway naast Ingress-NGINX bestaan met een apart adres. Dezelfde backend ontvangt eerst alleen testverkeer. Certificaten, headers, timeouts en bron-IP’s worden vergeleken voordat DNS verandert. Zo blijft rollback een routingkeuze en geen spoedige herinstallatie.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: portfolio
spec:
  parentRefs:
    - name: public-web
  hostnames:
    - jeffsmind.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: portfolio
          port: 80

Vergelijk verkeer voordat DNS wijzigt

Ik replay geschoonde productie-requests of mirror veilig verkeer en vergelijk status, headers, redirects, stabiele body-hashes, upstreamkeuze, latency en foutpercentage. Ook misvormde requests en dependency failures horen erbij. Voor WebSockets kijk ik naar duur en reconnects tijdens rolling updates.

DNS TTL verlaag ik vooraf, maar bestaande verbindingen en resolvercaches leven langer dan de ideale TTL. Hosts gaan in kleine groepen over. De oude controller en configuratie blijven deploybaar tot de observatieperiode voorbij is. Daarna verwijder ik loadbalancer, RBAC, webhooks en charts van het oude pad.

Praktische checklist

• Inventariseer controllers, Ingresses, annotations, DNS en eigenaars
• Kies een controller op conformiteit en beheerbaarheid
• Test uploads, WebSockets, auth, rewrites en client-IP's
• Draai beide paden en vergelijk responses
• Zet hosts geleidelijk om met geoefende rollback
• Verwijder oude rechten en infrastructuur