Thanks @dduportal for the very detailed answer
~2/3 of my customers have 2 or more ingress controllers installed. Neither your case nor mine are representative, truth is somewhere on the middle.
Switching an Ingress controller is also upgrading to a new major version, which breaks things (Nginx 2.x will surely break annotations, HAPRoxy 2 did, Contour as well: it's a common pattern).
I do not see an upgrade as a switch, but we might disagree on that.
However: is there a particular reason to NOT stay with Traefik v1.7 if it fits your needs? This version is maintained for at least 1 year (as you can see on the recent releases of 1.7.x we do not let this version rot), and I'm sure the "ingress v2 problem" will be solved until then?
The reason is in your words. 1.7.x will be maintained for at least 1 year. After that we may or may not have to switch the controller or upgrade to Traefik 2.0 if the way it works does not change. I would rather act now and get things straight before 1.7.x is out-of-support and we suddenly use unmaintained software in production.
I feel like this stance is a threat to stop using Traefik, and might not be the most kindest way to advocate for your need on a community (explaining your use case as you did later is waaaaay better). I'm not here to say you have to stay on Traefik, but to explain why, and how to fix. Traefik is a tool with its pro and cons, and it cannot answer to everyone's contexts. If you feel that it's better for you to not switch to Traefik v2, please consider another ingress controller more suited to your need: again it's engineering and there is no absolute golden bullet for everyone.
I am sorry if you took this as a threat, it was not meant that way. It just is a thing that crossed my mind as a possible solution if things do not work out.
You cannot and do not have to answer everyones contexts. And I did not ask for that.
Traefik 1.7.x fits our use-case just fine and for us it is a great piece of software that just works perfect. But v2 is something else for us, as you can see.
I hear you, and I would even advocate for you doing this if it is the simplest way, and easiest way to manage your infra. But binding ingress rules to a specific exposed port of an ingress controller is not a feature in the Kubernetes Ingress spec, unless I missed a recent change. If this is the case, I would be interested to learn how to do it with other ingress controller?
If what I'm saying is right, then it means that you hit a limitation of the ingress v1 definition.
Maybe I was not clear enough on our use-case. So, I will try to clarify how we use Traefik and Ingress in k8s-clusters.
Traefik is setup as a ingress-controller in the cluster, running as a daemonset. It has entrypoints for http, https, ping and metrics. So, the containerports are 443 and 80 and something else for the other two.
We now build a service of type NodePort that forwards external traffic to ports 80 and 443 of Traefik.
These NodePorts are loadbalanced by HAProxy-VM's.
If I now deploy an ingress-object for www.example.com and point the DNS to the IP of HAProxy, the request will be forwarded to the NodePort of Traefik and finally to the pods of the app.
This should work with almost any ingress-controller.
For this reason, I'm not sure (but I cannot confirm or deny as I'm not part of the team) if the issue #5624 will be implemented or not, because it would mean adding an annotation for this, right?
And this use-case I described, is why our problems would be solved if Traefik 2.0 would have the default-entrypoints option Traefik 1.7.x has. We could just set this option and everything should just work as before.
This should not need any annotations, because it is an option in the config of Traefik.
Should we need more features, like ingress for tcp-services we can still use IngressRoutes for that.
I don't understand the issue? If Traefik exposes its public ports 80 and 443, and is configured with 2 entrypoints (web -> 80 and websecure -> 443 ), then the ingress rules will be matching requests incoming on both port, that is all. These concepts are Layer-4 (TCP) related, where there is NO routing. This is why you're using Ingress at Layer-7 with routing based on the HTTP protocol right?
The "ingress" from Harbor's official helm chart provides a set of rules for different HTTP: a request for the webapi of Harbor will be sent to the webapi's (Kubernetes) service as expected because the match is done with hostname AND/or URL's path, right?
Of course I might misunderstand something here, but please help me by defining exactly the challenge.
We have four entrypoints configured. Web, websecure, ping and metrics. And if Traefik uses all of them a http-request will most likely end up entering the wrong one.
But maybe I misunderstood the docs and I do not need entrypoints for ping and metrics to still be able to scrape metrics and use readiness-probes.
If we do not need those, Traefik 2.0 could potentially still work for us.