Why Ingress NGINX Is Retiring and How to Choose Its Successor

Retirement Announcement and Immediate Impact

On 11 Nov 2025 the Kubernetes community announced that the Ingress NGINX controller will be retired. The Ingress API itself remains supported, but after March 2026 Ingress NGINX will receive no new releases, bug fixes, or security patches and its repository will be set to read‑only. Existing Helm charts and container images will continue to be usable, but production deployments will no longer have SLA guarantees or security updates.

Root Causes of the Retirement

High‑severity security vulnerabilities : CVE‑2025‑1974, CVE‑2025‑1097, CVE‑2025‑1098, CVE‑2025‑24513, CVE‑2025‑24514 expose TLS private keys and allow arbitrary code execution due to persistent input‑validation flaws (CWE‑20) and overly permissive configuration injection.

Monolithic architecture : The controller runs control‑plane and data‑plane in a single pod, forcing TLS secrets and other sensitive artifacts to be stored where many users can access them, dramatically expanding the attack surface.

Excessive configurability : Arbitrary NGINX snippet injection, while flexible, makes configuration management error‑prone and amplifies the impact of the architectural flaw.

Technical debt : The project tracks ~43 dependencies, 68 command‑line flags, 186 configuration options and a four‑hour compile time, indicating a high maintenance burden.

Insufficient maintainers : Only ~2.5 full‑time maintainers were available, limiting the ability to address bugs, security hardening, and feature development.

Strategic Migration Options

Continue using Ingress NGINX in isolated test clusters : Accept the loss of security updates and SLA; restrict usage to environments that do not rely on high‑risk annotations.

Adopt the Kubernetes Gateway API : The community‑endorsed successor for traffic management. Requires upgrading clusters to v1.28+ (v1.30+ recommended), deploying a separate Gateway implementation (e.g., Envoy Gateway), and handling behavioral differences such as header case handling, URL normalization, and host‑header semantics.

Switch to another actively maintained Ingress controller : Choose a mature controller (e.g., Kong, Traefik, HAProxy) to avoid the security cliff while keeping migration effort modest.

Use Alibaba Cloud ALB Ingress : A fully managed, cloud‑native solution that separates control‑plane (inside the cluster) from data‑plane (Alibaba Cloud Application Load Balancer). TLS secrets never leave the cluster, and the service provides built‑in DDoS protection, WAF, and rate‑limiting. It is compatible with most Ingress NGINX annotations and offers migration tooling.

Technical Comparison: Ingress NGINX vs. ALB Ingress

ALB Ingress runs the data‑plane on Alibaba Cloud’s Application Load Balancer while the control‑plane runs as a Kubernetes controller. This eliminates the need to store TLS secrets in the cluster and mitigates configuration‑injection risks inherent to Ingress NGINX. Both support HTTP/HTTPS/HTTP2/GRPC and a large set of annotations, but ALB Ingress adds native rate‑limiting, access‑control policies, and tight integration with other Alibaba Cloud services.

Key Differences When Migrating to a Gateway Implementation

Header case handling : NGINX forwards header names unchanged (e.g., X-Token), whereas Envoy normalises them to lower‑case (e.g., x-token).

URL path processing : NGINX forwards the raw path; Envoy performs canonicalisation (e.g., /a//b → /a/b).

Host header semantics : NGINX defaults the upstream Host header to the service name; Envoy forwards the client‑provided host value.

Resource model : Ingress API uses a single Ingress resource. Gateway API introduces role‑separated resources ( Gateway, HTTPRoute, ReferenceGrant), increasing configuration complexity but enabling finer‑grained traffic governance.

These differences can cause backend routing failures; thorough testing (traffic replay, canary deployments) is recommended before production cut‑over.

Recommendations

For new projects or workloads planning a cloud‑native evolution, pilot the Gateway API on a Kubernetes v1.30+ cluster and adopt a supported implementation such as Envoy Gateway.

For existing workloads that require minimal operational overhead, consider migrating to ALB Ingress (especially for clusters running on Alibaba Cloud ACK/ACS/ASK) or to another well‑maintained Ingress controller.

Maintain Ingress NGINX only in isolated test environments and monitor for critical security incidents.

Reference Links

Ingress NGINX retirement announcement: https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/

High‑risk annotation list: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations-risk/

ALB Ingress migration guide (Chinese): https://help.aliyun.com/zh/ack/serverless-kubernetes/user-guide/best-practice-for-migrating-from-a-self-managed-nginx-ingress-to-an-alb-ingress