Once upon a time, in a Kubernetes cluster not so far away, there was a brave little team.
Their applications hummed along happily, shielded from the dark web by their trusty old guardian, Sir Ingress-NGINX. He was a flexible and powerful knight, but let’s be honest, he was also held together by the digital equivalent of duct tape and hope—a collection of YAML files and ancient, inscrutable annotations.
Life was good. Until it wasn’t.
It started like any other Friday afternoon. Dev-Ops-Gary was about to deploy his script:
“if (smokeTest == true) { deployToProd() }” when a security alert screeched across their screens.
A new CVE, something with a dramatic name like 🚨“IngressNightmare,” 🚨 was on the loose .
It was a classic “unauthenticated RCE to full cluster takeover” situation
The kind of thing that makes a SRE wake up in a cold sweat .
Panic ensued.
The team huddled, frantically Googling for a patch.
“Surely the community will save us!” they cried.
But instead of a shiny new release, they found a digital tombstone on the official Kubernetes blog .
The retirement of Ingress NGINX... best-effort maintenance until March 2026... no bugfixes, and no updates to resolve any security vulnerabilities .
The room fell silent. Gary’s coffee went cold. The project that powered
“billions of requests”
was being put out to pasture, a victim of its own flexibility becoming
“insurmountable technical debt” and maintainer burnout .
Their knight in shining armor was officially retiring, and they were about to be left defending the castle with a cardboard sword.
This kicked off the Five Stages of Cloud Grief.
Denial: “It says existing deployments will still function! We’ll just... function harder!”
Anger: “Who decided this?! ‘Yesterday’s flexibility has become today’s insurmountable technical debt?’ That’s just poetry for ‘we’re abandoning us!’”
Bargaining: “Maybe we can just write our own patches? How hard can it be?” (A quick look at the codebase answered that question. Very hard.)
Depression: This was punctuated by the realization that their entire infrastructure was a museum of annotations. It was cloud-native archaeology.
Acceptance: It came in the form of a single, terrifying whisper: “We have to migrate to Gateway API.”
The migration path was clear, but it was like swapping out the engine of a car while it was speeding down the highway .
The official docs promised a brighter future, but the present was a mess of kubectl get commands and existential dread.
Their journey looked something like this:
Realizing a single Ingress resource now needed a Gateway, HTTPRoute, and GatewayClass. It felt like needing three tools to do one job.
“Ah, that’s hot.” – probably while applying a BackendTLSPolicy
Finding and replacing dozens of nginx.ingress.kubernetes.io annotations with proper Gateway API fields. So long, rewrite-target, my old friend.
“One does not simply” replace a snippet annotation.
Moving TLS termination from the Ingress spec to the Gateway listener and discovering their cert-manager setup needed a full rework.
Their “simple” canary deployment, which relied on a cryptic annotation, now needed a proper HTTPRoute with header-based matching and weighted backendRefs.
when traffic splitting actually worked better.
Their Slack channels were a war zone. #platform-team-alerts was a sea of red. #dev-chatter was filled with confused emojis.
It was the cloud-native version of a zombie apocalypse.
don’t drink so apple juice is my favourite
After a week that felt like a month, the last kubectl apply command was run.
The last HTTPRoute was Accepted. A beautiful, green, 200 OK appeared from their new Gateway API setup.
They had done it. The migration was complete.
The new system was not only more secure but also more expressive, with clear role-based boundaries between infrastructure and app teams .
They had finally entered the modern era of Kubernetes networking.
The moral of our story? Don’t be like Gary’s team. The retirement clock is ticking until March 2026 . Your future self will thank you for starting the migration now.
Check if you’re affected:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginxStart your migration: Read the official migration guide and explore controllers like Istio, Envoy, or NGINX Gateway Fabric .
Don’t let your cluster become a horror story. Upgrade today
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.