We’re currently working on a proper strategy relating to the upcoming retirement of the ingress-nginx project, which is scheduled for March 2026. While we are very much aware of the deadline, we have not yet finalized our long-term replacement strategy. Currently, new developments regarding this topic seem to emerge frequently. Which is why we are investigating in multiple directions and would like to share our findings so far.

Adopting a Different «Pure» Ingress Controller

There are options to provide an installation of a different Ingress controller and allow customers to switch current Ingress resources to that new controller. While this might read like an appealing solution, it still requires some migration work (and a DNS change as the new controller would use a different public IPv4 address). The ingress-nginx project allows configuration via specific annotations on the Ingress resource itself. These annotations will not be supported by the new, alternative Ingress controller. Some projects came up with help in this regard. For example, HAProxy provides a migration helper website which allows to check if there is a HAProxy specific annotation available for an ingress-nginx one. The Traefik project built something like a compatibility layer, which allows to use some ingress-nginx annotations directly (they translate internally).

We tested the compatibility of the current in-use ingress-nginx annotations on our clusters with some of these options and think that most customers would still need to put some work into rewriting their configuration to keep the same functionality. Furthermore, most of the controllers introduced specific CRDs to outsource «annotation configuration» into controller specific types. For example, with Traefik customers might need to create a «Middleware resource» to achieve configuration which was possible by annotations with ingress-nginx. Additionally, some features (for example «modsecurity») most probably won’t have a replacement available in any controller.

To sum it up, migrating to another Ingress controller requires a lot of resources and might involve more than a pure rewriting of annotations. Moreover, as GatewayAPI defines the future of Ingress definition (see below), we feel that a change to a gateway controller will be inevitable in the future. In the worst case, this would mean 2 migrations. The first one to the new alternative Ingress controller and the second one to a GatewayAPI based controller.

Migrating to a GatewayAPI Based Controller

GatewayAPI went GA in 2023 and is the official successor of the Ingress API in Kubernetes. It provides all the features of the Ingress resource and allows to configure gateway controller specific features in a common, more expressive way instead of relying on annotations. This introduces new resources and splits up the Ingress configuration amongst them. For simple use cases, splitting up the configuration into multiple resources might feel «too much», but it certainly allows for more configuration use-cases than the Ingress based API did. Also, almost every of the available controllers in the open source space does have an implementation for Gateway API nowadays. To make it short, it seems that GatewayAPI is the future.

However, GatewayAPI also introduced different personas/roles when defining how traffic should be routed in the cluster. In particular, GatewayAPI differentiates between «Infrastructure providers», «Cluster Operators» and «Developers». Without going much into the details of this, it changes the responsibilities of TLS certificate management currently. When working with Ingress resources, developers can manage hostnames, path configurations, various other specific configurations and also TLS certificates. In the current GatewayAPI stable version, the management of TLS certificates is part of the «Cluster Operator» role. This is quite a change in the operational experience of developers as it stops self-provisioning of LetsEncrypt certificates for example. Sure there are existing solutions like wildcard certificates or the merge of the «Cluster Operator» and «Developer» roles into one, but all of them are just workarounds and do have drawbacks assigned to them. To really improve the situation a proposal was created. In this proposal, a new resource called «ListenerSet», would allow developers to self-manage TLS certificates. As the «ListenerSet» resource is still marked as experimental, there is currently no broad adoption of that feature, but we feel that once gateway controllers and projects like cert-manager support the «ListenerSet» resource it will greatly improve the operational workflow for developers. However, we currently can’t estimate when this will be.

We also had a look into the gateway controller ecosystem, but choosing the «right» controller doesn’t seem to be an easy task either as there are varying implementation levels.

Summary

With all the current developments in regards to ingress-nginx, we feel that we still need a bit more time to make a proper strategy decision. As written above, GatewayAPI is the future, but we don’t feel it is ready yet to provide the same operational experience as developers are used to. We will continue to maintain our current ingress-nginx deployments, ensuring we are always running the latest possible versions to mitigate security risks and maintain stability until a migration path is chosen.

Should you have any questions or concerns from your side regarding this topic, please feel free to contact us.