hashicorp / consul-helm

Helm chart to install Consul and other associated components.
Mozilla Public License 2.0
419 stars 386 forks source link

Add optional service resource for client #385

Closed pvlltvk closed 4 years ago

pvlltvk commented 4 years ago

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.

ishustava commented 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?

pvlltvk commented 4 years ago

@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.

ishustava commented 4 years ago

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.

ishustava commented 4 years ago

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!