Skip to content
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

Closed
ltagliamonte-dd opened this issue May 1, 2020 · 8 comments · Fixed by #257
Closed

sync endpoints for serviceType=LoadBalancer #254

ltagliamonte-dd opened this issue May 1, 2020 · 8 comments · Fixed by #257
Labels
area/sync Related to catalog sync type/question Question about product, ideally should be pointed to discuss.hashicorp.com

Comments

@ltagliamonte-dd
Copy link
Contributor

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

@ishustava ishustava added area/sync Related to catalog sync type/question Question about product, ideally should be pointed to discuss.hashicorp.com labels May 1, 2020
@ishustava
Copy link
Contributor

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.

@ishustava ishustava added the waiting-reply Waiting on the issue creator for a response before taking further action label May 1, 2020
@ltagliamonte-dd
Copy link
Contributor Author

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.

@ishustava
Copy link
Contributor

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.

@ltagliamonte-dd
Copy link
Contributor Author

ltagliamonte-dd commented May 1, 2020

hello @ishustava thank you for the quick reply.

my use cases:
got a mixed env ECS and k8s, ECS services are calling into k8s via ELB.
services in k8s are on flat network and i want for those one to be able to reach directly service in other k8s clusters.

to maintain consul-k8s backward compatibility i propose to add an additional flag like sync-lb-endpoints set to false by default.
What do you think?

@ltagliamonte-dd
Copy link
Contributor Author

@ishustava i'm thinking of something like this:
master...ltagliamonte-dd:master

just did the make test and it seems that it doesn't break anything, i'm going to test it and if it does work will open a PR. What do you think?

@ltagliamonte-dd
Copy link
Contributor Author

@ishustava i tested my changes and it looks like it is working, what do you think?

@lkysow lkysow removed the waiting-reply Waiting on the issue creator for a response before taking further action label May 5, 2020
@lkysow
Copy link
Member

lkysow commented May 5, 2020

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.

@ltagliamonte-dd
Copy link
Contributor Author

@lkysow @ishustava PR opened here #257

ndhanushkodi pushed a commit to ndhanushkodi/consul-k8s that referenced this issue Jul 9, 2021
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/sync Related to catalog sync type/question Question about product, ideally should be pointed to discuss.hashicorp.com
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants