DODoublon·Mar 25, 2026Submission
Nginx ingress controller has been archived
3 points · Open discussionkubernetes
ingress-nginx
Go2016–2026
kubernetes / ingress-nginx · Archived
ingress-nginx
Ingress NGINX Controller for Kubernetes
29Distinct people
31Mentions
0Explicit recommenders
19.4KGitHub stars
What to know before exploring
What it is
Ingress NGINX Controller for Kubernetes
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year31 dated mentions
Observed mentions: 2016-12-13 11:42:55 UTC to 2026-03-25 02:38:31 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
31 sourcesTo be fair, this is not the first time we'e heard about this, https://github.com/kubernetes/ingress-nginx/issues/13002 exists since March. However I also thought that the timeline to a complete project halt would be much longer considering the prevalence of the nginx ingress controller. Might also mean that InGate is dead, since it's not mentioned in this post and doesn't seem to be close to any kind of stable release.
In Kubernetes Ingress Nginx is retiringStrict-validate-path-type does not allow period/dot/. in Exact or Prefix path
1 points · Open discussionI'm really missing HTTP/3 in ingress-nginx for Kubernetes. I guess most people use a CDN/Load Balancer in front of it. I didn't find a good general purpose alternative for ingress-nginx yet.
(https://github.com/kubernetes/ingress-nginx)
In Where Is HTTP/3? (2021)Nginx ingress, arguably the most popular reverse proxy for Kubernetes, is also lacking any HTTP3 support because of this slow progress. The related issue is 5y/o and the feature is now planned for its successor.
https://github.com/kubernetes/ingress-nginx/issues/4760
In Where Is HTTP/3?AFAIK the maintainers of ingress-nginx are investigating using the NGINX Javascript Module instead of lua/openresty in the future
https://github.com/kubernetes/ingress-nginx/issues/9950
In OpenResty: A High-Performance Web Platform Built on Nginx and LuaJITIt was the latest nginx at the time. I actually found a rather obscure issue on Github that touches on this problem, for those who are curious:
https://github.com/kubernetes/ingress-nginx/issues/1681#issu...
> We discovered a related issue where we have multiple ssl-passthrough upstreams that only use different hostnames. [...] nginx-ingress does not inspect the connection after the initial handshake - no matter if the HOST changes.
That was 5-ish years ago though. I hope there are better ways than the cert hack now.
In .INTERNAL is now reserved for private-use applicationsI find this syntax argument a bit strange nowadays.
There's this extremely popular Kubernetes tool called Helm, which uses go-templated YAML to generate Kubernetes resources.
The template syntax is nothing short of horrible. An endless maze of {{ ... }}s, where it's just too easy to shoot oneself in the foot by using {{- or -}} in wrong place, etc. And on top of that, you literally need to count spaces for nindent (mind you, you don't need to count parentheses while writing Lisp code).
I'd say Lisp syntax is clear as day when compared to your average Helm template.
An example is here:
https://github.com/kubernetes/ingress-nginx/blob/main/charts...
https://github.com/kubernetes/ingress-nginx/blob/main/charts...
And yet, all of this somehow doesn't prevent Helm from being popular...
In A brief interview with Common Lisp co-creator Dr. Scott Fahlmank8s has good, non-cloud based ingress controllers.
https://github.com/kubernetes/ingress-nginx
https://doc.traefik.io/traefik/providers/kubernetes-ingress/
In The container orchestrator landscapeIn most cases you can fix this with the service upstream annotation, which has existed since 2017: https://github.com/kubernetes/ingress-nginx/issues/257
In Ask HN: What is your Kubernetes nightmare?TLDR: Complexity.
The deprecation lifecycle, and running ingress controllers in an automatic scaling group.
The first isn't as much of an issue if you have a (partially) dedicated team for managing your clusters, but can be prohibitively expensive (effort / time-wise) for smaller organisations.
The second highlights a bigger problem in K8s in general. I'll have to give a little background first:
If you run an Nginx ingress controller on a node that's part of an ASG — i.e. a group where nodes can disappear, or increase in number — you will experience service disruption to a small percentage of your requests, every time a scaling event occurs. This is caused by a misalignment between timeout values for your load balancer and Nginx, which can not be fixed:
* https://github.com/kubernetes/ingress-nginx/issues/6281
* https://github.com/kuberne
Read the rest
tes/ingress-nginx/issues/6791
* https://github.com/kubernetes/ingress-nginx/issues/7175
The fix is to only run the controllers on nodes that reside in a separate statically sized group, and perform updates to them out of hours when necessary :|
I'll leave you to decide on whether that's a fix or not, but the larger point it highlights is how _theoretically_ everything's great in K8s, but the headaches introduced by the complexity often make it not worth it.
Another example is pod disruption budgets. These are needed because the behaviour of K8s when instructed to shutdown a node is, well, to shutdown the node. Seems reasonable, until you realise that it doesn't handle moving the workloads off that node _first_. No, at some point later, the scheduler realises the pods aren't running and schedules them somewhere else. So you use a combination of PDBs to tell K8s that it must keep n pods of this deployment running at all times, and distribution rules to tell it pods must run on different nodes. This solution falls apart when you have pods that should only have a single instance running.
If I'm not mistaken, the biggest user of openresty is the Kubernetes community-maintained nginx ingress controller [1].
[1]: https://github.com/kubernetes/ingress-nginx I took pains to say "community-maintained" because there's also an official nginx ingress controller from F5 (current corporate owner of nginx).
In Nginx Modern Reference ArchitecturesCan we fix the title to include ingress-nginx instead?
The upstream URL seems more clear as well: https://github.com/kubernetes/ingress-nginx/issues/7837
In Kubernetes ingress-nginx controller vulnerabilityIt is unclear whether this is a problem if you're running namespaced ingress-controllers though. This comment [0] in the bug report says:
there's definitely an attack path that gets the ingress-nginx service account token, which has list rights on secrets at a cluster level (so allowing for all secret values to be retrieved).
I can't see how list permissions would allow retrieval of the secret value though. You'd need get permissions for that.
[0] https://github.com/kubernetes/ingress-nginx/issues/7837#issu...
In Kubernetes ingress-nginx controller vulnerabilityAn issue with discussion: https://github.com/kubernetes/ingress-nginx/issues/7837
The only fix so far is removing the feature.
>According to the publication, multi-tenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.
Ouch! I guess this means lots of secret/password rotations for k8s admins coming soon. I've always wondered if there are public Kubernetes multi-tenant setups in the wild rather than just ones with admins and developer roles/namespaces.
In Kubernetes ingress-nginx controller vulnerabilityShowing the 15 most recent of 31 sources. Enable JavaScript to search and browse every indexed mention.