Planning the Ingress NGINX migration before maintenance ends

The Kubernetes Steering and Security Response Committees have issued a joint warning about Ingress NGINX. Maintenance ends in March, and operators need to begin migration now. Existing deployments will continue to function after retirement. That makes an ordinary availability check insufficient evidence that the ingress layer remains suitable for production.

I would treat this as scheduled infrastructure replacement with application owners involved from the beginning. A controller can remain healthy while its maintenance arrangements have become unacceptable. Waiting for an availability alarm would miss the change that the committees are asking operators to address. The work needs an explicit owner and a completion condition that includes removing the retired controller.

My interest in Kubernetes comes from its reconciliation model and API machinery. After eight years with it, including Talos clusters with Cilium and GitOps, I value the way controllers recover declared state after interruptions. This announcement concerns a different limit. Reconciliation cannot provide future security fixes for an implementation whose maintainers have stopped producing them. I would make maintenance status part of the cluster inventory alongside the desired configuration.

The controller is the migration unit

The original retirement announcement explains the distinction between Ingress and an Ingress controller. Ingress describes routing to workloads. A running controller implements that description. Ingress NGINX is one implementation, and the retirement applies to that project. Operators can consider another Ingress controller or move to Gateway API.

The original announcement also explains why a seemingly straightforward controller swap needs investigation. Ingress NGINX gained adoption through broad functionality and configuration flexibility. The project specifically identifies snippets annotations, which permit arbitrary NGINX configuration directives, as an example of flexibility that became a security concern. A migration therefore has to examine the behavior expressed outside the basic routing objects.

I would begin with an inventory of the controller deployments and the configuration they consume. The committees provide a pod selector that detects typical installations. For a named context, the discovery command is:

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

The context name is illustrative. The statement specifies cluster administrator permissions and says the selector works in most cases. I would preserve that qualification in an inventory procedure. An empty result needs comparison with the actual deployment configuration before anyone signs off that a cluster is unaffected.

Discovery should produce a migration work list. For each installation, I would record the owners of the routes and identify configuration that depends on Ingress NGINX behavior. Snippets deserve individual review because they can express instructions that a replacement will not accept in the same form. The committees explicitly warn that none of the available alternatives is a direct drop-in replacement. A list of matching Kubernetes objects does not establish behavioral equivalence.

Why additional maintainers no longer settle the question

The November announcement describes years of insufficient maintainership. It says development depended on one or two people working outside their normal working hours. It also records the unsuccessful attempt to develop InGate with the Gateway API community. InGate did not mature into a replacement and is also being retired.

January's statement goes further than a renewed request for volunteers. The committees describe accumulated technical debt and design decisions that worsen security flaws. They say continuing maintenance is no longer reasonable even if resources become available. That changes how I would evaluate a proposal to postpone migration while waiting for a rescue effort. The project is explaining a design and sustainability decision, with an announced end to updates.

I would avoid treating the continued availability of installation artifacts as a support commitment. November's announcement says Helm charts and container images will remain available, and repositories will become read-only after retirement. Those arrangements let people inspect and reproduce existing installations. They do not create a process for reviewing a newly discovered vulnerability or delivering a corrected release.

This distinction matters in GitOps. A declared installation can remain reproducible after its upstream project retires. A review that only verifies that the configuration still converges would leave the maintenance question unanswered. I would add the retirement deadline to the migration issue and require evidence that production no longer depends on the retired implementation.

Choosing the next API and implementation

Gateway API has an established stable base. Its v1.0 announcement records the graduation of Gateway, GatewayClass, and HTTPRoute to v1. It also distinguishes stable APIs in the Standard channel from functionality developed through the Experimental channel. I would use that distinction when evaluating a replacement. Stable resource definitions do not establish that every required behavior has the same maturity or implementation support.

The API decision and controller decision need separate evidence. The retirement announcements recommend Gateway API and also allow for other Ingress controllers. I would first identify the application's required behavior, then check the selected implementation against it. Choosing a supported controller that meets current requirements can be a reasonable scope. Moving to Gateway API can also be appropriate, provided the migration accounts for the API and implementation changes together.

I would make the acceptance criteria specific to the routes being moved. A translated configuration needs tests derived from the application's expected requests and responses. Controller-specific configuration deserves tests that show why it exists. Where a snippet has no known owner or documented requirement, I would investigate its purpose before reproducing it in a new implementation.

I would also retain a record of each deliberate behavior change. A migration may expose configuration that should be removed, but that decision needs application review. Otherwise an intentional simplification and an accidental loss of behavior can look identical in the resulting manifests. The review should explain which expectations the replacement preserves and which expectations the owners have agreed to change.

The committees' warning makes engineering time part of the immediate decision. As of January 29, the announced March retirement leaves a short preparation period. I would use that period to establish the affected inventory, choose an implementation against documented requirements, and validate the changed routes before scheduling production cutover. Completion should include checking that the old controller has been removed from the declared configuration as well as from the running cluster.