Closed pvlltvk closed 4 years ago
Hey @pvlltvk,
Thanks so much for this issue. I'm curious about your use-case. Currently, you could reach the clients via the HOST_IP
. For example, in the Helm chart that's how the sync catalog process talks to the client that's running on its host:
https://github.com/hashicorp/consul-helm/blob/74177c29f24903a53ae82eaac7e07f2198e113c4/templates/sync-catalog-deployment.yaml#L49-L79
Will this work as a solution to the problem you're facing?
@ishustava Thank you for your response!
Yes, your solution will work. I just think that service can be useful too as it provides some features.
I could make a PR, but if you think that service is unnecessary - it's ok.
Hey @pvlltvk,
Yeah, having a service doesn't fit the way clients are intended to be used. With a service, Kubernetes will load balance between client instances, but it's better if each pod talks to the client instance on its host. This is important from both security (limiting the network boundary) and performance standpoint. That's why we recommend using the Host IP.
In the future, when Kubernetes supports limiting networking to the host only, we might switch the daemon sets to use that to ensure that only the pods on its host can talk to it.
Hey @pvlltvk,
I'm going to close this issue for now. I hope the solution I mentioned worked for you.
If not, let us know by either commenting here or creating a new issue. Cheers!
Hi!
I think it would be reasonable to add an optional service resource for the Сlient. It could be use when a Consul Server Cluster is running outside a Kubernetes cluster and your apps need to do requests to this Server Cluster through Consul Agents.