About this scenario
ingress-nginx publishes the shop: the shop-api Ingress sends /api to the api Service with a rewrite-target, and shop-web sends everything else to web. Ingress NGINX was retired on March 24, 2026. It keeps working, but gets no more releases or security fixes.
The platform team runs Envoy Gateway with a Gateway called public in the infra namespace. Recreate the routes as an HTTPRoute, test them against the Gateway before moving traffic, then remove the Ingresses and ingress-nginx.
Objectives
- Find the ingress-nginx controller
- Serve /api and / for shop.example.com from the Gateway, rewrite included
- Test the Gateway before moving traffic
- Remove the Ingresses and ingress-nginx, with the shop still answering
What you'll practice
- Ingress NGINX was retired on March 24, 2026. Existing installs keep running with no more releases or security fixes, so plan the move rather than waiting for a CVE.
- Each Ingress controller reads its own annotations. Gateway API puts the same features in the spec: a
rewrite-target becomes a URLRewrite filter, a host and path become hostnames and matches. - Test the new route against the Gateway's address with
curl --resolve before moving DNS, then remove the old Ingresses so two controllers don't serve the same host. ingress2gateway converts ingress-nginx Ingresses to Gateway API resources. Review what it writes: not every annotation has an equivalent.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Flux, Argo CD) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.