Migration from Ingress NGINX is becoming mandatory: EOL and vulnerabilities make the transition to Kubernetes Gateway API a matter of resilience and security.
The problem does not manifest immediately — until control over incoming traffic becomes a point of systemic risk. Ingress NGINX has long been the de facto standard for Kubernetes, but its lifecycle has ended. This means no future security patches. Against this backdrop, vulnerabilities like IngressNightmare and new CVEs highlight an important detail: the ingress controller is not an isolated component, but a point with a cluster-wide impact radius. Meanwhile, the Kubernetes Ingress API remains, but is effectively frozen in functionality. The system continues to operate, but stops evolving.
The solution in this situation is to transition to Kubernetes Gateway API. This is not a specific controller, but a specification with a set of resources. This approach removes the dependency on annotations that were previously tied to Ingress NGINX. Instead, routing is described declaratively through standard resources. This reduces vendor lock-in and makes configurations portable between implementations. The trade-off here is clear: behavior and conformance levels may differ between controllers. It is also important to consider protocol support. HTTP is covered everywhere, but TCP and UDP are not guaranteed.
A key architectural step is the choice of controller. It defines the behavior of the data plane and the available capabilities. For LLM workloads, support for extensions such as inference routing, which depend on specific implementations (e.g., via ext_proc), is important. Next comes the migration itself. It is structured as a parallel process, not a “flip of a switch.” First, a baseline is established: request rate, latency, error rate. These metrics are needed not for reporting, but as a checkpoint to understand if the system’s behavior is breaking.
Implementation begins with the installation of Gateway API CRDs and the chosen controller. The basic entities are GatewayClass, Gateway, Route, and ReferenceGrant. Unlike Ingress, where many things “worked by default,” here the relationships become explicit. For example, cross-namespace access now requires ReferenceGrant. This enhances security but adds operational complexity. An error in these relationships manifests immediately — the Route will not be accepted (Accepted: False or ResolvedRefs: False).
To accelerate migration, the Ingress2Gateway tool is used. It translates existing manifests and even some annotations into the new format. But this is only a starting point. Manual verification is mandatory because not all constructs have a direct correspondence. After generating the configuration, Gateway and Route resources are created that replicate the current logic: hosts, paths, TLS, backend services.
A critical moment is validation without production traffic. Shadow or synthetic requests are used. Responses are compared through the old and new entry points. Status codes, headers, TLS behavior, and actual request delivery to the backend are checked. This allows discrepancies to be caught before the DNS cutover. If the Gateway has an external address, testing can be conducted directly by substituting the production hostname.
Traffic switching occurs via DNS. This is not an instantaneous process. Even with a low TTL, some clients continue to use old records. During this period, the system effectively operates in split traffic mode. This creates additional load on observability. Deviations from the baseline need to be monitored: increased latency, spikes in 4xx/5xx, TLS issues. It is important that rollback remains simple — just revert the DNS.
Observability becomes a central element of migration. Ingress NGINX metrics are compared with Gateway API metrics in a unified dashboard. Many controllers provide data in Prometheus format, simplifying integration. Additionally, tracing (APM) is used to understand where degradation occurs — at the edge or within services. This approach transforms migration from a risky event into a controlled process.
The result is a stricter and more predictable routing model. Gateway API makes system behavior explicit and portable. But the cost is increased complexity and the need to better understand relationships between resources. Improvement metrics in the original data are not provided, so the effect is assessed through the stability, security, and manageability of the architecture.