How to deal with the retirement of Kubernetes Nginx Ingress?

[scholzj]

Strimzi supports the type: ingress listener for a very long time. While it might work with any Ingress controller in theory, we have always claimed that it was designed and tested with the Kubernetes Nginx Ingress controller. And because the Ingress Controller compatibility was never there on 100%, especially with advanced features such as TLS passthrough needed, we were never able to guarantee that other Ingress controllers work.

However, that particular controller is leaving us: https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/. It seems a bit weird to keep the type: ingress listener and claim that it supports project that is retired (although technically, nothing prevents us from doing so I guess). So we need to decide how to proceed with it.

I think there are several options:

1. Deprecate the Ingress type listener and ...
   a. Either remove the logic completely and leave it in the API as ignored.
   b. Or keep the logic as is for the time being, for users who use it. But not do any changes to it.
2. Rebase it to support another Ingress controller? If so, which one is reasonably open source? E.g. Traefik? HA Proxy? Would this include any code changes or just testing? (And does anyone else than me actually test it?)

In general, the long term future is the Gateway API. We do not have direct support for it - mainly because the Gateway API HTTPSRoute and TLSRoute resources were so far not stable enough. But users can use Gateway API semi-manually through the type: cluster-ip listener and manually created Gateway API resources. They will be able to do the same with Ingress if we remove the support.

I personally would probably think that the option 1b is the way to go followed by the removal of the code logic in 2027 or something like that. (Keep in mind, that once 0.49.0 is out, the CRD API cannot be removed in v1 anymore)

[ppatierno]

From my perspective, option 1a is a no go because we are going to break users that are still using it and haven't a clear plan for moving away from Kubernetes Nginx Ingress controller yet.
Option 2 looks to me a "waste" of time, we are going to put more effort to support and test another Ingress controller when the real path to follow is the support for the Gateway API instead.
In summary, I would agree that option 1b is the way to go.

Keep in mind, that once 0.49.0 is out, the CRD API cannot be removed in v1 anymore

Now that 0.49.0 is out, just to be clear what you mean here is that we can't remove type: ingress from the API but we can remove the logic (so actually ignoring it) and then starting from 2027 or so you envisage a v2beta1 API where we can remove stuff again? Or did you mean something different?

[scholzj]

Keep in mind, that once 0.49.0 is out, the CRD API cannot be removed in v1 anymore

Now that 0.49.0 is out, just to be clear what you mean here is that we can't remove type: ingress from the API but we can remove the logic (so actually ignoring it) and then starting from 2027 or so you envisage a v2beta1 API where we can remove stuff again? Or did you mean something different?

You can always remove the logic from the code. It is the API that is hard to break (talking about the technical aspects here, rather than the philosophical discussion about backwards compatibility, semantic versioning, etc.).

But to be clear, I do not envisage any new API version in 2027. What I meant here is that the existing code can be removed in 2027 or something like that. And the API is removed whenever we do a new API version.