Platform engineering

After the ingress-NGINX retirement, what your migration plan owes production

After the ingress-NGINX retirement, what your migration plan owes production

The status of the controller

As of March 2026, the Kubernetes SIG Network stopped maintaining ingress-nginx. That is the controller a lot of clusters have been running for years. A CNCF blog post published July 9 walks operators through the state of play. The headline for anyone still on it is short: unpatched CVEs, and no more feature work.

The post names two operational risks explicitly. New security issues will not receive upstream fixes. Feature updates and community support have stopped. If your ingress plane is a piece of infrastructure you have not touched in a while, this is the reason to pull it up in this quarter's planning doc.

What it means at 3am

An ingress controller sits between the internet and your services. When it drops a request, you find out from your users. When it takes a CVE and no one is patching, you find out from a scanner or from a report. Neither is a good discovery path.

The controller also carries the exact set of annotations, TLS defaults and rewrite rules your workloads rely on. Nothing about a retirement changes the version you have in production today, so the immediate blast radius is zero. The risk is on the calendar, not on the pager. That is the kind of risk teams reliably defer until a scanner flags an unpatched CVE.

The two paths CNCF lays out

The post frames the choice as a fork.

Path A is a lateral swap to another Ingress controller. The example named is Contour, described in the post as Envoy-based. This keeps you on the Ingress API and mostly moves the problem of who is patching.

Path B is modernization to the Gateway API, described in the post as the upstream-backed successor to Ingress. The CNCF post points at ingress2gateway to automate the translation, and recommends an incremental rollout: run the new plane in parallel and move non-critical workloads first.

The stopgap version is a mix. Adopt Contour to buy time on maintained code, then schedule the Gateway API move on your own calendar rather than under duress.

What to verify before the cutover

Ingress annotations do not port cleanly between controllers. The affinity, timeout and rewrite rules your services depend on are dialect, and each controller speaks its own. A migration that treats the manifests as one-to-one produces quiet regressions on the traffic paths that carry the most annotations, which is to say the paths that matter most.

A short list of things to check before you flip DNS or change the IngressClass:

  • Health-check semantics. Idle timeouts and slow-start behavior vary across implementations.
  • TLS behavior. Certificate reload, SNI handling and default cipher policies are all controller-specific.
  • Rewrite and canonicalization rules. Trailing slashes and path prefixes are the classic source of a silent 404 after a swap.

Rollback path: keep the old controller running in the cluster on a different IngressClass until the new one has held a production week without a page. Cutover by class, not by cluster.

The wider shape

The specific news is the retirement. The shape is familiar. A workhorse project ends its maintenance window, and the community points at both a like-for-like replacement and a longer-term API. In this case the CNCF post treats the Gateway API as the destination and Contour as the shorter road to a maintained plane. The reasoning offered is straightforward: the Gateway API is the upstream-backed successor to Ingress, so anything you build against it should still be there when the next controller cycles out.

None of that changes if you do nothing this week. It changes when the next CVE lands on a controller no one is fixing.

Source: CNCF (cncf.io)

Related
Platform engineering

etcd v3.7 adds a streaming range API and drops the legacy v2 store

SIG etcd shipped v3.7.0 with a RangeStream API that chunks large read responses instead of buffering them, plus faster lease handling under load and the removal of the legacy v2 backing store. Kubernetes will expose the feature in v1.37 behind a gate.

July 9, 2026
Platform engineering

Flipkart's chaos platform runs 90% of fault injection in staging, ships five fixes back to LitmusChaos

Flipkart's central reliability engineering team won the CNCF End User Case Study contest for a multi-tenant chaos engineering platform on Kubernetes that runs roughly 90% of its experiments in staging clusters and contributed five fixes upstream to LitmusChaos. The next step on the roadmap is to wire chaos testing into the CI/CD pipeline as a mandatory phase.

June 18, 2026
Platform engineering

Sandboxing your agent isn't the hard part, keeping it cheap is

A CNCF post from Solo.io's Lin Sun argues Kubernetes' agent-sandbox project delivers the isolation piece of hosting AI agents, while a sibling project, agent-substrate, is aimed at the resource-efficiency gap a per-agent pod leaves behind.

July 7, 2026

Turn this into your pipeline. Build it on Buddy.

Start free