The Deprecation of the Ingress-NGINX Controller in 2026: Motivations, Alternatives, and Migration to Gateway API

Motivations Behind the Deprecation

The retirement of Ingress-NGINX stems from several longstanding challenges. Primarily, the project's flexibility, particularly through annotations allowing arbitrary NGINX configurations (like "snippets"), has led to security vulnerabilities and maintenance difficulties. With only one or two part-time maintainers, the project has struggled to keep up with evolving Kubernetes versions, NGINX updates, and security patches. Efforts to bolster support or create a replacement, such as the InGate project, ultimately failed.

Additionally, the broader Kubernetes ecosystem is transitioning towards the Gateway API as a more advanced standard for traffic management. The Ingress API itself remains feature-frozen but not deprecated, meaning no new capabilities will be added. This fragmentation in routing technologies, combined with the rise of diverse gateways (e.g., Envoy-based or cloud-native), has made maintaining Ingress-NGINX less strategic. By retiring the project, the community aims to prioritize security, reduce maintenance burdens, and encourage adoption of forward-looking APIs like Gateway API.

Post-March 2026, there will be no new releases, bug fixes, or security updates, leaving users exposed to potential risks. Users are urged to migrate promptly to avoid compatibility issues with future Kubernetes releases.

Alternatives to Ingress-NGINX

While the Ingress-NGINX controller is retiring, the Ingress API continues to be supported. Users can switch to other Ingress controllers, such as:

• NGINX Inc.'s Open Source Ingress Controller: A fork maintained by F5 NGINX, promising long-term support with updates and bug fixes beyond 2026.
• Traefik: A modern, dynamic ingress controller that supports both Ingress and Gateway API, offering ease of use and automatic configuration.
• Contour, Ambassador, or Kong: Envoy-based proxies that provide advanced features like rate limiting and authentication.
• Cloud Provider Solutions: Such as AWS Application Load Balancer (ALB) Ingress Controller, Google Cloud's GKE Ingress, or Azure's Application Gateway Ingress Controller.

For those ready to embrace the future, the recommended path is migrating to Gateway API implementations, which offer superior capabilities.

Introducing Gateway API

The Gateway API is an open-source project under the Kubernetes SIG-Network, designed as the successor to Ingress. It provides a more expressive, extensible, and role-oriented model for managing ingress and egress traffic in Kubernetes clusters. Unlike Ingress, which is limited to basic HTTP/HTTPS routing, Gateway API supports a wider range of protocols and advanced routing scenarios.

Key components include:

• GatewayClass: Defines the implementation (e.g., a specific controller like Envoy or NGINX).
• Gateway: Represents the infrastructure (e.g., load balancers) and listeners.
• HTTPRoute: Specifies HTTP-specific routing rules, attachable to Gateways.
• Other routes like TCPRoute, UDPRoute for non-HTTP traffic.

This separation allows cluster administrators to manage infrastructure (Gateways) while application developers handle routing (Routes), promoting better collaboration.

Advantages of Gateway API Over Ingress

Gateway API addresses many limitations of the Ingress API, offering several key advantages:

• Broader Protocol Support: Handles HTTP, HTTPS, gRPC, TCP, and UDP, unlike Ingress's HTTP/HTTPS focus.
• Advanced Routing Features: Includes header-based matching, weighted traffic splitting, traffic mirroring, and path rewrites/redirection out of the box, reducing reliance on vendor-specific annotations.
• Role Separation: Enhances security and operations by decoupling infrastructure management from application routing.
• Portability and Extensibility: Standardized API minimizes lock-in, with support for policies like rate limiting or authentication via extensions.
• Better Integration: Works seamlessly with service meshes like Istio and supports custom Envoy builds for enhanced performance.

These features make Gateway API more suitable for complex, modern applications, improving scalability and maintainability.

How to Replace Ingress-NGINX with Gateway API

Migrating from Ingress-NGINX to Gateway API involves several steps:

1. Install a Gateway API Controller: Choose an implementation like Kubernetes Gateway API with Cilium, Kong, Istio, or a cloud provider's offering. Install the CRDs and controller using Helm or manifests.

2. Audit Existing Ingress Resources: Identify your current Ingress configurations using kubectl get ingress --all-namespaces. Note hosts, paths, and annotations.

3. Convert to Gateway Resources:

   • Create a GatewayClass and Gateway to replace the load balancer setup.
   • Translate Ingress rules to HTTPRoutes, mapping hosts, paths, and backends.

4. Test and Roll Out: Deploy in a staging environment, verify traffic routing, then switch DNS or gradually shift traffic.

5. Remove Old Resources: Once validated, uninstall Ingress-NGINX and delete old Ingress objects.

Tools like ingress2gateway can automate conversions from Ingress to Gateway API resources. For Qovery or similar platforms, automated migrations may be available.

Examples of Gateway and HTTPRoute

Here are practical examples of using Gateway and HTTPRoute for basic routing.

Basic Gateway and HTTPRoute

This sets up a simple Gateway listening on port 80 and an HTTPRoute forwarding traffic for example.com to a service:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "example.com"
  rules:
  - backendRefs:
    - name: example-svc
      port: 80

Host-Based Routing

Route traffic to different services based on hostname:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: foo-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "foo.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: "/"
    backendRefs:
    - name: foo-svc
      port: 8080

Header-Based Routing

Route based on HTTP headers, e.g., for canary deployments:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: bar-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "bar.example.com"
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: canary
    backendRefs:
    - name: bar-svc-canary
      port: 8080
  - backendRefs:
    - name: bar-svc
      port: 8080

These examples demonstrate how HTTPRoute attaches to a Gateway and defines granular rules, merging seamlessly across multiple routes.

Conclusion

The deprecation of Ingress-NGINX in 2026 signals the end of an era but opens doors to more robust networking with Gateway API. By understanding the motivations, exploring alternatives, and leveraging Gateway API's advantages, teams can ensure secure, scalable traffic management. Start planning your migration today to stay ahead in the evolving Kubernetes landscape.