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

Multi-Cluster Deploy #42

Closed
Ginja opened this issue Dec 7, 2018 · 3 comments
Closed

Multi-Cluster Deploy #42

Ginja opened this issue Dec 7, 2018 · 3 comments

Comments

@Ginja
Copy link

Ginja commented Dec 7, 2018

This may be a duplicate of #6, if so please feel free to close this, but currently running more than one consul-k8s deployment across different clusters results in the deployments fighting one another:

2018-12-07T05:39:41.560Z [INFO ] to-consul/sink: invalid service found, scheduling for delete: service-name=SERVICE_NAME

I'd ideally like to be able to run multiple deployments across clusters, and have a particular deployment only manage what it synced. Would adding a -svc-tag option solve this I wonder? I'm thinking if set consul-k8s would only manage the services, and more specifically the nodes, with said tag value? Something like this would solve our use case as we do have multiple clusters with the same service defined in both.

@Ginja
Copy link
Author

Ginja commented Dec 7, 2018

Looks like this would be resolved with #39

@adilyse
Copy link
Contributor

adilyse commented Jan 8, 2019

Merged a configurable tag that should allow each Kubernetes cluster's services to be independently identified, which should solve this conflict. It will be included in the next released version, which should happen soon.

Please feel free to reopen if this doesn't fix your issue.

@adilyse adilyse closed this as completed Jan 8, 2019
@jacksontj
Copy link

@adilyse is there an ETA for a release that would include this fix?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants