-
Notifications
You must be signed in to change notification settings - Fork 317
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sync endpoints for serviceType=LoadBalancer #254
Comments
Hey @ltagliamonte-dd, The main issue I see with that is that it's not clear which address we should register with Consul when we see a service of type LoadBalancer: the ingress IP/Hostname or the endpoints. Right now, the catalog sync assumes you want a routable address to be in Consul, and so if you have a load balancer service, we think that the Load Balancer address should be registered rather than the load balancer endpoints. If you are switching to a flat network, then all the registered load balancer addresses would still work, so you can switch them eventually by changing a service type to NodePort or ClusterIP over time. Hope this makes sense. |
thank you for the reply @ishustava but my situation is a bit more complicated and i need to maintain backward compatibility i need to gradually migrate clients to the new consul domain so i need new client address a service via routable IPs and old services still use the load balancer endpoint. |
Got it, thanks for a quick reply! Do you maybe have an example that you could share with us showing the use-case? Or maybe you could outline what you're proposing a bit more? I'm mainly confused about how would the sync process decide which address to register when it sees a load balancer service. |
hello @ishustava thank you for the quick reply. my use cases: to maintain consul-k8s backward compatibility i propose to add an additional flag like |
@ishustava i'm thinking of something like this: just did the |
@ishustava i tested my changes and it looks like it is working, what do you think? |
Hi @ltagliamonte-dd it's a valid use-case so please go ahead and submit a PR but just a warning that we're really backed up on PR reviews so it likely won't get reviewed for a while. |
@lkysow @ishustava PR opened here #257 |
* Upgrade to terraform 0.12 * Add terraform to the Test.dockerfile * Add CircleCI config * Rename .circleci/config.yaml to .circleci/config.yml * Use env variable for the terraform version * Switch to hashicorpdev/consul-helm-test Docker image * Specify directory for terraform commands Also, add a clarifying comment describing which image is being used * Update .circleci/config.yml Co-Authored-By: Luke Kysow <[email protected]> * Only run acceptance tests on the changes to master Plus, minor changes to terraform commands. * Split out acceptance tests into multiple steps for clarity * use multiple steps rather than a single step * 'terraform destroy' step runs always, even if previous steps fail * decrease GKE cluster node pool from 5 to 3 to make spin ups faster * wait for Helm to initialize to make sure tiller is ready * use the latest consul-helm-test docker image
We are moving to a flat network using awscni and we will would like to sync in Consul all pods endpoints also the one that atm are type=LoadBalancer.
is there any issue of doing that?
if you are ok i can open a PR for enhance this:
https://github.com/hashicorp/consul-k8s/blob/master/catalog/to-consul/resource.go#L298
The text was updated successfully, but these errors were encountered: