Replies: 1 comment
-
|
Thanks for your thought about this matter . Can you please give some more details about your thought on this ? After reading your suggestions I'm thinking about to somehow make service discovery not by service name,but by tag, if that is doable , not tried yet. So the idea is to pull Consul/Kubernetes api look for tags specified in upstreams.yml and build upstreams list s it it now . |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
First, I think this issue should be in discussion tab, but it is disabled, so I'm creating it here.
I'll get straight to the point, the "service discoverability" of aralez is kinda simple for modern traffic management... Surely, it auto discovers upstream endpoints based on dns, consul (which makes me happy) and kubernetes, but I really really think it can also do more than just that
When working with kubernetes or a nomad cluster (with consul), things can get very messy real quick, I'm talking about handling more than 200 different micro-services, each with its own name, pool of endpoints, ruleset, etc... and doing the discoverability for these services is kinda a pain when you have to do manually one by one in a yaml file...
To solve this problem, I think aralez should expand the discoverability system and actually discover services either by consul catalog (you can also filter by tags, like traefik do) or by kubernetes ingress-api
I'm very curious to know what the community thinks about this
Related: #7
Beta Was this translation helpful? Give feedback.
All reactions