Dec 08, 2025

9 min read

Articles

Ingress NGINX Controller End-of-Life: 2026. Alternatives and Architecture.

Kubernetes Ingress API Deprecation. Azure Kubernetes Services perspective.

Big news for the Kubernetes ecosystem: Ingress NGINX will reach end-of-life in March 2026. After that, no patches, no updates, and no security fixes. For the teams running Kubernetes clusters today, this is not just a lifecycle event — it’s a signal to rethink how traffic enters your clusters.

This news was expected, as the NGINX Ingress Controller is based on the Kubernetes Ingress API, which is no longer being developed or actively maintained. The Gateway API has become the new standard.

1. Kubernetes Perspective: Ingress Controller vs Gateway API

Ingress NGINX has been the go-to controller for routing HTTP and HTTPS traffic in Kubernetes for years. It powers internet-facing clusters, local dev setups, and many tutorials.

According to the Traefik CEO, around 41% of internet-facing clusters rely on it, and it ships by default in platforms like RKE2, IBM Cloud, and Alibaba ACK.

With its retirement, several risks emerge:

Security: No future CVE fixes mean unpatched vulnerabilities for production workloads.
Compatibility: New Kubernetes versions may break legacy NGINX Ingress setups.
Operational debt: Legacy NGINX annotations and snippets are convenient but increasingly unsafe and hard to maintain.

2. Ingress Controller — overview

Overview

An Ingress Controller is a Kubernetes component that manages external access to your cluster’s services.

It acts like a traffic manager or gatekeeper, controlling how HTTP/HTTPS requests from the internet (or other networks) reach the right service inside the cluster.

How it works

Ingress Resources: You define rules in Kubernetes Ingress objects, specifying things like hostnames, paths, and TLS settings.
Controller Watches Ingress: The Ingress Controller continuously monitors these resources and translates them into actual routing rules.
Traffic Routing: When requests arrive at the cluster (usually via a LoadBalancer or NodePort), the controller inspects the request’s hostname/path and forwards it to the correct service.
Optional Features: Many controllers (like NGINX or Traefik) also handle TLS termination, authentication, rate limiting, redirects, and custom headers.

Ingress API example

One API with 2 Resources: `Ingress` and `IngressClass`. This API was set to Deprecated.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: demo.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: demo-service
            port:
              number: 80

apiVersion / kind — Declares this resource as an Ingress object.
metadata — Standard naming and annotations.
The example includes an NGINX rewrite annotation (ignored by other controllers).
ingressClassName — Specifies which Ingress Controller should handle this Ingress.
rules — Defines what host and which URL paths route to which service.
backend — Tells Kubernetes to send requests for / on demo.example.com to demo-service:80.

3. Gateway API — overview

The Kubernetes community is rallying behind Gateway API, the next-generation model for cluster ingress.

It separates concerns, enables richer routing features, and offers a vendor-neutral, extensible architecture. Teams now have two paths:

Drop-in replacement: Run a modern controller like Traefik with an Ingress NGINX Provider. Your existing annotations and resources continue to work without rewriting anything.
Modernization with Gateway API: Adopt the Gateway API for a cleaner, future-proof architecture. This requires defining GatewayClass, Gateway, and HTTPRoute resources, but it sets you up for the next decade (years?).

Overview

A Kubernetes-native API (CRDs like GatewayClass, Gateway, HTTPRoute) standardized by the Kubernetes community.
It’s not a specific implementation, but a spec that controllers can implement.
Ensures configurations are portable across different implementations
Examples of controllers implementing Gateway API: Traefik, Istio, Contour, and AGIC (Azure Gateway Ingress Controller).

Gateway API example

Gateway API is built around three core resources: GatewayClass, Gateway, and HTTPRoute—the essential building blocks for configuring modern Kubernetes traffic management.

GatewayClass

Defines the type of Gateway your controller will create. Usually provided by the controller:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
 name: traefik
spec:
 controllerName: traefik.io/gateway-controller

Gateway

Represents the actual entry point into your cluster (like a load balancer).

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gateway
spec:
  gatewayClassName: traefik
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same

HTTPRoute

Defines the routing rules for your services.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo-route
spec:
  parentRefs:
  - name: web-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: demo-service
      port: 80

4. Ingress Controller vs Gateway API

Ingress is simple but limited and vendor-fragmented. Gateway API is modular, powerful, cloud-native, and a long-term replacement.

https://medium.com/media/5d2b185e2ef172aaa1ef844dd287b652

5. NGINX Ingress Controller is dead; long live NGINX Gateway Fabric (NGF)

For on-premises or self-managed Kubernetes clusters, modern north–south traffic management no longer centers on the legacy Ingress API. The shift toward the Gateway API has produced a new generation of controllers that run seamlessly across bare metal, VMware, OpenStack, Proxmox, Nutanix, and other environments.

Below is a concise overview of the leading on-prem–friendly Gateway API implementations:

Envoy Gateway: A lightweight, vendor-neutral controller built on Envoy. Delivers first-class Gateway API support and modern features like mTLS, JWT validation, and rate limiting without introducing a full service mesh.
HAProxy Kubernetes Gateway: High-performance, low-latency, and natively aligned with the Gateway API. Ideal for latency-sensitive environments that need a fast, predictable data plane.
NGINX Gateway Fabric (NGF): The successor to the OSS NGINX Ingress Controller. Fully Gateway API–native and designed as NGINX’s long-term ingress/gateway strategy for Kubernetes.
Traefik v3: A simple, easy-to-operate controller with direct Gateway API support. A strong fit for small-to-medium on-prem clusters or developer-centric platforms.
Kong Kubernetes Gateway: A Gateway API implementation powered by Kong, with enterprise-grade capabilities such as JWT/OAuth2 authentication, OPA/WASM extensibility, and advanced rate limiting.
Istio Gateway: Istio’s stable Gateway API integration, used istio-ingressgateway as the data plane. Suited for organizations already adopting service mesh patterns.
Kuma / Kong Mesh: An Envoy-based mesh with built-in Gateway API integration via MeshGateway. Strong for zero-trust, mTLS-by-default, and unified mesh + gateway deployments.

6. Managed Cloud Kubernetes Services

For teams using managed Kubernetes in the cloud, the story is similar but with vendor-specific nuances.

EKS: Many clusters run Ingress NGINX manually. Post-2026, these become unmaintained and risky. Traefik or AWS Load Balancer Controller are viable paths forward.
GKE: Clusters with manual NGINX installs face the same exposure. Transitioning to GKE Gateway API or a supported ingress controller (GKE Ingress) is recommended.

Managed Kubernetes Platforms with Gateway API Support

For customers who need a fully supported, production-grade Kubernetes platform with modern Gateway API capabilities, we offer managed services across the leading enterprise and on-prem solutions:

Red Hat OpenShift
OpenShift 4.14+ provides native Gateway API support alongside traditional OpenShift Routes, combining HAProxy-based ingress with an Envoy-powered gateway layer. With its robust operator ecosystem and long maintenance cycles, OpenShift is an excellent fit for enterprise on-prem environments that prioritize stability, compliance, and vendor-backed support.

VMware Tanzu Kubernetes Grid with AVI (NSX ALB)
Tanzu Kubernetes Grid integrates seamlessly with NSX Advanced Load Balancer, offering Gateway API support and multi-cluster L7 traffic management. This platform is ideal for VMware-centric data centers looking for consistent networking, strong lifecycle automation, and unified control across clusters.

SUSE Rancher
Rancher provides centralized management for any Kubernetes distribution and supports installing a wide range of Gateway API controllers, including Envoy Gateway, NGINX, Traefik, HAProxy, and Kong.

Canonical MicroK8s
MicroK8s delivers a lightweight, production-ready Kubernetes distribution with optional Gateway API add-ons such as Traefik or Envoy Gateway. It is well-suited for edge deployments, small on-prem clusters.

7. Azure Kubernetes Services (AKS) — Ingress options

First, let’s clear a few terms and technologies in the Azure world:

Application Gateway

Azure’s fully managed Layer 7 load balancer. It handles TLS termination, path-based routing, and WAF rules.

By itself, it does not implement Gateway API or Kubernetes Ingress.

AGIC (Application Gateway Ingress Controller)

A Kubernetes controller that connects your cluster to Azure Application Gateway. It watches Ingress resources, converts them to AG configuration, and allows your services to use Application Gateway as the entry point.

Not a Gateway API controller.

Application Gateway for Containers (AG for Containers / AGC)

Azure’s modern solution that allows Application Gateway to work with Gateway API resources in Kubernetes.

Supports the newer Gateway API CRDs, enabling a more flexible, cloud-native ingress model than traditional AGIC.

NOTE: AGC can work only with Azure Application Gateway in front; no other Load Balancer is supported!

https://medium.com/media/009b7717c3ed613f5f2ef8f9b04e40f8

Managed NGINX ingress with the Application Routing add-on

Many AKS clusters use Microsoft’s Application Routing add-on as their default ingress solution.

Support timeline: NGINX in Application Routing will be supported for critical patches only until November 2026. After that, teams must migrate to stay secure.
Future direction: Microsoft is investing in Gateway API via Istio and also supports Application Gateway for Containers (AGC) as an alternative ingress solution (based on Gateway API Kubernetes resources).

Migration steps for AKS teams

Inventory clusters and ingress resources: Identify which workloads rely on NGINX.
Test Gateway API: Enable the Managed Gateway API CRDs in a dev cluster and provision Istio. Try routing a few test workloads.
Plan migration: Shift production workloads well before March 2026, using a phased approach.
Get familiar with Gateway API concepts and Istio’s gateway features, or AGC.

All AKS Ingress options with Gateway API

https://medium.com/media/f8197a7c6546dd435a1bcb6446e598e7

8. Key Takeaways

Ingress NGINX retirement is a defining moment for Kubernetes networking.
Teams have a choice: compatibility-first migration with a modern controller or full Gateway API adoption.
Managed cloud Kubernetes services are aligned but have nuances; AKS teams must plan for a transition to Gateway API/Istio or AGC.
Start now: inventory clusters, test new controllers, and build a phased migration plan.

The era of NGINX Ingress is ending. The next chapter — Gateway API and modern, actively maintained controllers — is already here. Kubernetes teams that act early will stay secure, maintainable, and ready for the future.