# Elasticsearch 2.0 unicast discovery via load balancer

**URL:** <https://discuss.elastic.co/t/elasticsearch-2-0-unicast-discovery-via-load-balancer/35210>\
**Category:** Elasticsearch\
**Created:** [November 21, 2015, 7:55am UTC](https://discuss.elastic.co/t/elasticsearch-2-0-unicast-discovery-via-load-balancer/35210 "2015-11-21T07:55:09Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![jimmidyson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jimmidyson/32/6067_2.png) [@jimmidyson](https://discuss.elastic.co/u/jimmidyson)\
**Post date:** [November 21, 2015, 7:55am UTC](https://discuss.elastic.co/t/elasticsearch-2-0-unicast-discovery-via-load-balancer/35210/1 "2015-11-21T07:55:09Z")

</div>

If I have all my elasticsearch instances automatically joined to a load balancer pool (actually a kubernetes service) on start up, would it cause any problems to point the unicast discovery hosts to just the load balancer (kubernetes service) address? This seems to work fine, but I wanted to check that there wasn't something I'm missing.

Thanks  
Jimmi

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [November 21, 2015, 9:00am UTC](https://discuss.elastic.co/t/elasticsearch-2-0-unicast-discovery-via-load-balancer/35210/2 "2015-11-21T09:00:34Z")

</div>

Well it should work as long as the LB doesn't fall over 😛

---

<div class="post-metadata">

**Author:** ![ant31](https://avatars.discourse-cdn.com/v4/letter/a/b5a626/32.png) [@ant31](https://discuss.elastic.co/u/ant31)\
**Post date:** [November 21, 2015, 12:26pm UTC](https://discuss.elastic.co/t/elasticsearch-2-0-unicast-discovery-via-load-balancer/35210/3 "2015-11-21T12:26:00Z")

</div>

Hi,

It works yes but do you see any cons to do this instead to configure all available masters as unicast hosts ?

If the LB fall, will it affect only new nodes ? Already clustered nodes don't use discovery settings as soon as they joined the cluster?

Thanks,

Antoine

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [November 21, 2015, 11:04pm UTC](https://discuss.elastic.co/t/elasticsearch-2-0-unicast-discovery-via-load-balancer/35210/4 "2015-11-21T23:04:42Z")

</div>

> [@ant31](#):
>
> If the LB fall, will it affect only new nodes ? Already clustered nodes don't use discovery settings as soon as they joined the cluster?

Correct.

---

<div class="post-metadata">

**Author:** ![bleskes](https://avatars.discourse-cdn.com/v4/letter/b/71c47a/32.png) [@bleskes](https://discuss.elastic.co/u/bleskes)\
**Post date:** [November 22, 2015, 8:12pm UTC](https://discuss.elastic.co/t/elasticsearch-2-0-unicast-discovery-via-load-balancer/35210/5 "2015-11-22T20:12:04Z")

</div>

The unicast hosts used to exchange information between new nodes of the cluster. If the cluster is already formed, a new node can ping any node and ask it for the current master. However, if you have a full cluster restart, where all the new nodes are pinging and discovering each other, a LB can (in theory) lead them to miss nodes. For example, if consistently separates the nodes into two halves, those two halves will never discover each other. Since you have mentioned using dedicated master nodes, I would suggest just putting those in the list. Last, since you talk about kubernetes, maybe it has an API which can give the list of current container IPs? If so you can write a little discovery plugin to ingest that list as a unicast host seed (see how the GCE/EC2 plugins work now).

---

<div class="post-metadata">

**Author:** ![jimmidyson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jimmidyson/32/6067_2.png) [@jimmidyson](https://discuss.elastic.co/u/jimmidyson)\
**Post date:** [November 23, 2015, 11:20am UTC](https://discuss.elastic.co/t/elasticsearch-2-0-unicast-discovery-via-load-balancer/35210/6 "2015-11-23T11:20:26Z")

</div>

@bleskes Thanks for that info. I've written a plugin to do exactly as you said: discover cluster nodes from the kubernetes API ([https://github.com/fabric8io/elasticsearch-cloud-kubernetes](https://github.com/fabric8io/elasticsearch-cloud-kubernetes)). We were seeing if we could get rid of that & just point discovery to the service load balancer but as you've alluded too it is better to find individual masters.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 5, 2017, 11:36pm UTC](https://discuss.elastic.co/t/elasticsearch-2-0-unicast-discovery-via-load-balancer/35210/7 "2017-07-05T23:36:37Z")

</div>


