Hacker Newsnew | past | comments | ask | show | jobs | submit | emilevauge's commentslogin

We have been building an ingress Nginx compatibility layer in Traefik that supports the most used ingress Nginx annotations. You should definitely give it a try as it makes Traefik a drop-in replacement to ingress Nginx, without touching your existing ingress resources. Your feedback will be super useful to make it better

https://traefik.io/blog/transition-from-ingress-nginx-to-tra...


We have been building an ingress Nginx compatibility layer in Traefik that supports the most used ingress Nginx annotations. You should definitely give it a try as it makes Traefik a drop-in replacement to ingress Nginx, without touching your existing ingress resources. Your feedback will be super useful to make it better

https://doc.traefik.io/traefik/master/reference/routing-conf...


This is pretty funny. The main reason I dislike Traefik is because you can get away with broken ingress objects (i.e. you put elements into the `tls` array that only have a cert or only have a hostname and traefik will do some fuzzy matching) and it was a huge pain to get our manifest rendering pipeline back to spec.


This whole discussion needs way more input - this has been posted three times (I was the last and it got flagged as "dupe") - the moderators are not allowing fair discussion here.

As an industry this has a huge impact.

Good to know re: Traefik - I wonder if K3s will continue to ship Traefik v2?


Case in point... front page 61 comments.. https://www.kubernetes.dev/blog/2025/11/12/ingress-nginx-ret...


this has been posted three times (I was the last and it got flagged as "dupe") - the moderators are not allowing fair discussion here.

this site is policed by vigilante bot-runners who seem to farm karma by flagging "dupe" everywhere but saying or contributing nothing


Indeed, go plugins were our initial choice (https://github.com/traefik/traefik/pull/1865). But you said everything about how bad/impossible the workflow would have been for users. Building from scratch a go interpreter was not the easiest way, but this was the best solution regarding the UX.


This security issue is not that simple to manage as you probably know. It's mainly due to the fact that there is now way to have authorization on the the docker API. This is not the case on Kubernetes for example where you have RBAC to prevent this kind of issue. We have described this in detail in our documentation, and you have many solutions/workarounds to address this: https://doc.traefik.io/traefik/providers/docker/#docker-api-...


Yeah, I'm surprised that this is such a sticking point. There's nothing that anyone who isn't Docker Inc. can do to fix the problem that, by default, Docker is all or nothing. It would be nice if Docker could expose a read-only endpoint but c'est la vie.

The only solution I've seen/used that wasn't convoluted or brittle is running a little daemon to just shovel container metadata into Consul and going from there.


> This security issue is not that simple to manage as you probably know.

I do think it's simple to manage: As I already mentioned elsewhere, it wouldn't be necessary for the network-facing part of Traefik to talk to the Docker API. There could be a second Traefik container (w/o network access) running a binary called, say, traefik-config-generator whose only task it is to talk to the Docker socket and generate a config and write that config to a shared volume.

EDIT: Oh, I just realized you're the founder of Traefik! Thank you so much for your work! I would really appreciate your opinion on my suggestion – even if you think it's complete BS. :)


We think that it is interesting to have an alternative with a simpler design bringing almost all features. So yes, mTLS between pods is not supported. But it's a decent tradeoff for many users. Finally, mTLS could be supported in the future between nodes :)


Whæt's wröng?


Thanks! We deeply believe that the best infrastructure products are open and free from vendor lock-in. Being compliant to SMI will make both Maesh and the specifications stronger.


Traefik creator here. Wow, that's harsh!

You may encountered issues while using Traefik so giving your opinion is totally fine, but I don't think that's fair to overreact.

Many users (and I mean big companies) have been using Traefik in production for years without issue. I'm not saying there is not bug, which software can claim this, I'm just saying that many users have a good opinion on Traefik stability.

We follow semver, there shouldn't be any breaking change between 2 minor versions. But, yes, it can happen, sometimes, we may have forgot to check a specific use case. But hey, again, let's be fair, we don't want it. We are just human. And no, this does not happen at every minor version and this is pretty uncommon...

Finally, on Traefik size. You are including Traefik dependencies, in vendor/, which is a bit weird. In go, the convention is to push the dependencies in your repository to get reproducible builds, so that's not a good way to count. If you exclude vendor/:

golocc --no-vendor ./...

Lines of Code: 58532 (2987 CLOC, 55545 NCLOC)

Which is rather tiny.

So all in all, I regret you had such a bad experience with Traefik, but I just wanted to express the fact that many users are using it without any issue :) I would be happy to discuss further on this.


Thanks for clearing all that up.


Could you elaborate? I would never say that the code is perfect, like any other "big" open source project, but we follow a pretty strict review process on each PR (3 LGTM from maintainers). I'm curious to know why you are so negative.


https://github.com/containous/traefik now has native Let's Encrypt support ;)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: