HomeArticle

With only 1 - 2 people struggling alone and being plagued by fatal bugs, Ingress NGINX announced its "retirement" in four months, leaving global users in a panic: There's too little time left.

CSDN2025-12-05 11:18
The simplest answer is to pay the maintainers.

After the recently concluded KubeCon North America conference, everyone has been discussing the future of eBPF, AI-native infrastructure, and cloud-native security. However, what really made the entire community nervous was a low-key announcement:

Kubernetes announced that Ingress NGINX will be officially retired in March 2026. By then, Ingress NGINX will completely stop being maintained, meaning "no more bug fixes, no more new versions, and the GitHub repository will be set to read-only."

In other words, this Ingress NGINX, which is widely deployed on various managed Kubernetes platforms and self-built clusters, and is used by thousands of clusters, will be completely "retired" in four months.

What is Ingress NGINX and why is it important?

Let's first briefly introduce Ingress NGINX.

Ingress is one of the earliest "user-friendly" ways to handle traffic ingress in Kubernetes, used to direct external network requests to applications within the cluster (the Gateway API is a newer alternative). For Ingress to work, an Ingress Controller must be running in your cluster.

Ingress NGINX is one of the most commonly used Ingress Controllers in Kubernetes clusters. It is responsible for routing external HTTP/HTTPS traffic to internal services according to various configurable Ingress rules. It acts like a reverse proxy, distributing requests to the correct backends based on path, domain name, TLS configuration, etc., performing load balancing, and managing edge traffic.

Due to its high flexibility, rich features, and independence from specific cloud platforms, Ingress NGINX has quickly gained popularity among many developers since its inception. Even when Kubernetes officially announced the retirement of Ingress NGINX, it mentioned:

"Ingress NGINX has handled billions of requests in data centers and homelabs around the world. In a sense, without Ingress NGINX, there would be no Kubernetes ecosystem today."

However, this once-popular project, known for its flexibility and rich features, is about to become "abandoned software."

You might think, "What's so strange about software retirement?" Indeed, this isn't the first time. Software like dBase, Lotus 1-2-3, VisiCalc... were all once very popular. But the problem is that Ingress NGINX is still being used by thousands of clusters around the world.

The maintenance nightmare of Ingress NGINX: Accumulated technical debt and "no one to maintain it"

Regarding the reason for the retirement of Ingress NGINX, the official statement is straightforward:

"The powerful functions and flexibility of Ingress NGINX have brought a huge burden to its later maintenance."

Take a typical example: Ingress NGINX allows users to directly add arbitrary NGINX configurations (snippets) through annotations. This was considered an advantage of flexibility in the past, but now it has become a security black hole. Such features fundamentally undermine the "configuration security boundary," making the NGINX runtime almost uncontrollable. In today's context of increasingly strict cloud-native security standards, this is already an "unacceptable level" of design.

And there are more than just one such feature. As the user base has grown, these historical burdens have gradually accumulated into technical debt that is difficult to fix.

Of course, if a project is complex but has a 20-person team to maintain it, it can still function. However, Ingress NGINX only has 1 - 2 maintainers, who can only spare time in their free time to do the maintenance.

Yes, you read that right. This component, which is a billion-level traffic entry, is very popular among users, and is relied on by countless production clusters, has only had 1 - 2 maintainers over the years. They have to fix bugs in their free time, evenings, and on weekends, while the project's complexity and security requirements continue to rise.

Actually, as early as last year, the maintainers of Ingress NGINX publicly stated their plan to gradually abandon Ingress NGINX and tried to cooperate with the Gateway API community to develop an alternative, InGate. But even after giving the retirement notice, it still failed to attract more contributors to join the maintenance. InGate didn't even reach the mature stage and will be retired along with Ingress NGINX.

The "last straw" that crushed Ingress NGINX: A fatal security bug

However, the signs of Ingress NGINX's maintenance fatigue have been apparent for many years. What really made Kubernetes finally decide to "press the retirement button" was a serious bug discovered by security company Wix in March this year.

How serious was it? In Wix's own words:

"Attackers can use this bug to execute arbitrary code and obtain all cluster keys in all namespaces, thus completely taking over the entire cluster."

Obviously, a bug of this level is enough to put all affected projects directly into a "high-risk state."

Community users are angry: There's too little time left!

Upon hearing this news, many users on Reddit, Slack, and GitHub expressed anger and even panic.

Some of them complained, "For such an important component, we should at least be given a one-year migration period. Just rewriting all the documentation would take more than four months."

In response, Tim Hockin, a core maintainer of Kubernetes, was also quite straightforward:

"Please don't take it for granted. The people maintaining Ingress NGINX are doing it for free, driven by a sense of responsibility. Almost no one has been willing to join the maintenance work in the past two years, so closing the project is inevitable."

This statement once again reveals the cruel truth in the entire open-source field: Many key open-source software projects are highly relied on by community users, but the maintainers receive no compensation.

Will Ingress NGINX not be the last one to fall?

To be honest, it's not uncommon for software to have major security bugs. For example, Windows almost has an "explosive patch day" every month. As mentioned above, the root cause of Ingress NGINX's retirement is not the bugs, but rather: it is a core infrastructure software, but there is no sustainable maintenance funding.

William Morgan, the CEO of Buoyant and the author of Linkerd, pointed out when discussing this matter on LinkedIn: "The CNCF ecosystem is not really suitable for volunteer maintenance. The attitude of this community towards open source is more like 'consumption' rather than 'contribution.'"

This statement hits the nail on the head. Whether it's FFmpeg, log4j, OpenSSL, SQLite, or cURL, these key projects that support the Internet are very similar: they have a huge influence, are highly relied on by enterprises, but are only maintained by a few people silently.

If we continue to "freely use open source" and are not willing to pay, support, or contribute to key infrastructure, then Ingress NGINX will surely not be the last key component to fall. And perhaps, as William Morgan said, "The simplest answer is to pay the maintainers."

This article is from the WeChat official account "CSDN", written by Zheng Liyuan, and published by 36Kr with permission.