Last November, the Kubernetes project announced the discontinuation of the popular ingress controller ingress-nginx. After a best-effort transition phase until March 2026, the project will no longer receive any releases, bug fixes or security updates from this point onwards. That time has now come, and so we want to take another look at the question: What comes after ingress-nginx?
Why was ingress-nginx discontinued?
ingress-nginx is an open source project. Intended as a reference implementation of the Ingress API in Kubernetes, it has been extended over the years to include more and more features and use cases to meet its popularity and changing requirements. As is so often the case in the open source world, the majority of the effort was in the hands of very few active developers.
The above-linked article on the Kubernetes website mentions one or two developers who put in this effort unpaid(!) after their working day and on weekends, despite the immense popularity of ingress-nginx.
At a certain point, this effort became too large, and an attempted implementation of a gateway controller as a successor (InGate) also failed due to a lack of participation. This left no other option but to discontinue the project after a transitional phase.
What is the official recommendation for affected users?
Many companies and individuals with countless clusters are affected by this development. The announcement contains recommendations on how to proceed: Either migrate your clusters from the Ingress API to the Gateway API, a more modern and flexible alternative API. Or you can migrate from the discontinued Ingress controller ingress-nginx to a supported project.
The Kubernetes documentation lists various alternatives for Ingress controllers and Gateway controllers. We have selected a few alternatives from these lists and compare their capabilities and limitations in this article. The alternatives covered include the following projects:
Before that, however, we should take another look at the Gateway API, which is being used more and more, but is still not familiar to everyone.
What is the Gateway API?
The Gateway API is designed as a more flexible alternative to the Ingress API. It builds on many observed scenarios and problems from the use of the Ingress API, and comes with four clear design goals:
- Role orientation: API resources model different roles in organizations
- Portability: The Gateway API is an alternative to the Ingress API, which you can continue to use
- Expressiveness: Many scenarios that can only be implemented in a roundabout way with the Ingress API are supported in the Gateway API
- Extensibility: CustomResources can extend the Gateway API in various places as required
Specifically, the Gateway API implements three types of API objects:
- GatewayClasses, which define the configuration and behavior of the instances of a gateway controller analogous to IngressClasses of the Ingress API.
- Gateways that specifically define an instance of a gateway controller.
- xRoutes, which define the routing of different types of network traffic (e.g. HTTP, UDP, TCP, GRPC).
Last summer, we presented the Gateway API in more detail on our blog. You can find the article here.
What are the alternatives?
As mentioned above, we have looked at 6 alternatives for you, all of which can also be found in the lists in the Kubernetes documentation. Aspects of our comparison were the technologies used for routing, conformity with the Gateway API specification, feasibility of a migration from ingress-nginx, and any special features of the respective solution.
All the solutions compared are open source, but some are mainly managed by a commercial vendor. You will find the results of our comparison summarized in tabular form below, or in more detail in the paragraph on the respective project.
The results at a glance
| Project | Technology | Gateway API compliance | Migration effort | Special features |
| Cilium | Envoy | v1.4.0 | Medium | strongly interwoven with CNI |
| Contour | Envoy | v1.3.0 | Medium | few new features |
| Emissary | Envoy | limited | High | No conformance report |
| Envoy Gateway | Envoy | v1.4.1 | Medium | Higher complexity |
| kgateway | Envoy | v1.4.0 | Low | Provides migration tools for ingress-nginx |
| Traefik | Custom | v1.4.0 | Low | supports ingress-nginx annotations |
Cilium
As the first project in our comparison, Cilium immediately holds a special position. It is primarily known as a container network interface (CNI) plugin and has established itself as the de facto standard in this area. The Ingress and Gateway API functionality of the project is therefore strongly interlinked with the network implementation of the cluster.
Cilium forwards incoming requests to an Envoy proxy via eBPF in the node’s kernel. This implies certain special behaviors in detail, which are worth evaluating using the documentation for Ingress and Gateway API.
We estimate the migration effort to be medium – both implementations support all common scenarios, and Cilium is compliant with v1.4.0 of the Gateway API in the Experimental Channel of the API specification.
Contour
Contour wurde ursprünglich von VMware entwickelt und ist einer der gängigen Ingress Controller in der Kubernetes-Welt. Mit CustomResourceDefinitions für umfangreichere Konfiguration ist es in diesem Bereich auch sehr flexibel und unterstützt verschiedenste Szenarien. Hierfür setzt Contour wie einige Projekte in unserem Vergleich auf Envoy, einen cloud-nativen Proxy.
For some time now, users have been observing longer implementation times for new features. For example, a report on conformity with v1.4.0 of the Gateway API is not yet available. However, security releases and software updates continue to take place regularly.
We also consider the migration effort for Contour to be medium. The Contour Ingress Controller is functional and offers extensive configuration options, and conformity with the Gateway API is ensured, at least for v1.3.0.
Emissary
Like Contour, Emissary is also based on Envoy as a proxy and enables configuration via CustomResourceDefinitions.
As the only project in our comparison, there is no official report regarding compliance with the Gateway API. The Emissary documentation at least contains information on limited support for the Gateway API specification.
This is why we estimate the migration effort here to be high.
Envoy Gateway
If you do not need the CustomResourceDefinitions and ‘outsourced’ management from Contour, Emissary or kgateway, you can also use Envoy directly. Envoy is the only project in the comparison that is already compliant with v1.4.1 of the Gateway API, and the functionality of the proxy has been sufficiently proven as a building block in the other projects mentioned.
Envoy’s configuration is somewhat more complex – there is a reason that other ingress controllers have developed CustomResourceDefinitions to keep precisely this complexity away from users. The trade-off that has to be made is therefore conformity and a lightweight, cloud-native proxy on the one hand, against possibly increased complexity in operation on the other.
Nevertheless, we estimate the migration effort to be medium.
kgateway
The CNCF project kgateway, previously developed by Solo.io under the name Gloo, is the most widely used gateway in Kubernetes for microservices and AI applications, according to the project website. It also relies on Envoy for this and offers support for v1.4.0 of the Gateway API.
The biggest advantage of kgateway in the context of the discontinuation of ingress-nginx is its migration capabilities: With its fork of the ingress2gateway tool, kgateway enables the migration from ingress-nginx, including a variety of ingress-nginx-specific annotations and configuration.
The existence of a migration tool and the widespread use of kgateway make it possible to migrate ingress-nginx with low effort.
Traefik
Our comparison concludes with Traefik, which is widely used both on Kubernetes as an Ingress controller and in Docker environments as a reverse proxy. It offers CustomResourceDefinitions, annotations and a UI for quick insights into what is happening in clusters. For once, Envoy is not used here; Traefik takes care of all processing itself.
Similar to kgateway, Traefik also provides guarantees for easy migration from ingress-nginx by automatically supporting a growing number of ingress-nginx annotations.
In combination with Traefik’s compliance with v1.4.0 of the Gateway API, we estimate the migration effort to be low in this case as well.
Where will the journey lead?
The discontinuation of ingress-nginx marks the end of a popular and widely used tool, but at the same time provides an important impetus to modernize your own infrastructure. The good news is that the Kubernetes ecosystem offers a variety of mature alternatives that serve different requirements and migration scenarios.
Anyone who wants to migrate quickly and easily is well advised to evaluate kgateway or Traefik. Both offer concrete tools and compatibility for existing ingress-nginx configurations, thus minimizing the effort for teams that are not looking for a fundamental restructuring.
Anyone already using Cilium as a CNI or planning to implement it can use its integrated gateway functionality and save themselves an additional component in the cluster.
Regardless of the solution chosen, it is worth taking the migration as an opportunity to fundamentally rethink your own Ingress architecture. The Gateway API offers more expressiveness and flexibility than the classic Ingress API and will probably be the preferred standard in Kubernetes environments in the long term.
In the end, there is no universally correct answer. The best alternative depends on the specific requirements, the existing stack and the available resources in your own team. This comparison should serve as a starting point – the final decision is up to you.
0 Comments