Ingress NGINX is dead, long live the Gateway API

We look at the reasons for abandoning NGINX Ingress Controller, the benefits of the Gateway API, and a practical transition plan.

The world of Kubernetes is on the verge of a significant architectural transformation. Ingress has long been perceived as the standard entry point for HTTP traffic, but today the ecosystem is increasingly shifting towards the Gateway API. The catalyst for this transition was the end of support for the classic NGINX Ingress Controller: it became obvious that the old model had run into its own limitations.

This is not a reason to panic, but a good time to reconsider your network architecture. Below we will look at why Ingress is no longer suitable for the industry, why the Gateway API is better, and how to approach migration without unnecessary risk.

Introduction: Why Kubernetes is talking about change #

Ingress has long seemed like a convenient and fairly universal abstraction: host, path, backend, TLS and a minimum of entities. In 2020, the resource received the status of Generally Available (v1), but then its development practically stopped. Simplicity, which used to be an advantage, has become an architectural limitation over time.

When news broke that security updates for the classic NGINX Ingress Controller would be discontinued, it became clear that talk of a replacement was no longer theoretical. For many teams, this became a signal: it was time not to patch up the old scheme, but to rethink it.

How we lived with Ingress and what went wrong #

Ingress had several systemic problems that were compensated for over the years by workarounds.

• “Bag of annotations.” There weren’t enough basic Ingress fields, so vendors put a significant part of the configuration into annotations like nginx.ingress.kubernetes.io/.... As a result, manifests became long, difficult to read, and implementation dependent.
• Monolithicity. Infrastructure settings and applied routing logic were mixed in one entity. This prevented the normal division of responsibilities between the platform team and the developers.
• Security issues. For flexibility we had to use snippets and extensions, including Lua. It is precisely such mechanisms that often become the source of critical vulnerabilities and complicate controller maintenance.

The bottom line is simple: Ingress turned out to be too tight a model for modern networking, security, and teamwork requirements.

Anatomy of a Gateway API: divide and conquer #

The Gateway API is built on decomposition and explicit separation of roles. Instead of one overloaded entity, separate objects with a clear area of ​​responsibilities appear.

• GatewayClass defines the implementation type of the balancer and corresponds to the infrastructure level.
• Gateway describes a specific entry point: IP addresses, ports, listeners, access policies.
• HTTPRoute is responsible for application routing and can be managed separately from the infrastructure part.

This approach helps to distribute responsibilities between teams. For example, a wildcard certificate can be kept in a secure infrastructure namespace and used at the Gateway level without copying the secret to each application namespace.

An additional advantage of the Gateway API is that it is an open specification with conformance tests. The architecture is not built around a specific controller, but around a standard that is supported by various implementations, including Cilium, Istio and Envoy-based solutions.

Where to migrate today #

The choice of a specific Gateway API implementation depends on the infrastructure, performance requirements, and the network stack already in use.

• Cilium is well suited for those who rely on eBPF and want the most native integration with a Linux network.
• Envoy-based solutions like Istio, Traefik or Gloo are interesting where flexible routing and a developed service mesh ecosystem are important.
• F5 NGINX Plus could be an intermediate option for those who want to stay in the familiar NGINX ecosystem but move to a supported commercial product.

When choosing, it is important to look not only at the marketing description, but also at the actual support for the desired Gateway API version. The specification evolves quickly, and implementations often take a while to catch up.

Migration practice: tools and pitfalls #

Migration doesn’t have to be a leap into the abyss. The community offers a utility called ingress2gateway that helps automatically convert existing manifests, but you shouldn’t rely on it entirely.

Main risks during the transition:

• Problems with namespace. Automatic conversion may attempt to create Gateway directly in the application namespace, although architecturally such a resource is often more appropriate at the infrastructure level.
• Non-portable annotations. A significant portion of NGINX Ingress specific settings do not have a direct equivalent and require manual revision through Filters and other HTTPRoute mechanisms.
• Compatibility errors. Before using manifests, it is useful to check them through kubectl apply --server-side --dry-run=server in order to get a response from controller webhooks in advance and not break the working environment.

A practical migration strategy is to run Gateway API alongside existing Ingress on another IP address or port. That lets you move services one at a time, validate behavior, and reduce the risk of a wide outage.

Looking ahead with Shturval #

The transition to the Gateway API is not a fad — it is a step toward a more secure, scalable network architecture. Roles are separated, configuration becomes more predictable, and dependence on vendor-specific annotations drops.

In the Shturval platform, Gateway API object management is available from release 2.14 — see Gateway API.

The migration path still requires manual review of manifests and architectural discipline, but the result is usually worth it: the network becomes cleaner, clearer, and more secure.