At present embedded zookeeper is "supported" only for initial testing, basically to ease the running of tutorials. It's not designed to form clusters that provide redundancy, nor is there much thought put into facilitating management of its data store or securing it from unwanted access.
There are some folks who would like to move it to a more scalable level of support, but that has not come to pass yet. (see https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper) The strong recommendation is that you use an external zookeeper in production. In a kubernetes context, this should mean maintaining a stateful set for a Zk cluster, and maintaining a separate stateful set for the Solr cluster. The Solr nodes should be provisioned with the current zookeeper string on start. How to communicate that string is a concern dictated by how you manage your systems, and ideally for ease of management it will be similar to the way you communicate the location of solr (or your database) to your user facing applications or other downstream systems. The good news is that you can usually provision smaller, cheaper instances for your zookeeper cluster, so the cost of doing this is not high (relative to the cost of hardware/disk for Solr), just don't completely ignore the zookeeper docs regarding performance, and of course monitor it like any other system. There certainly are folks who've run small single node systems using embedded zk successfully, but usually not in mission critical or near zero down time scenarios. In a non-kubernetes environment I've also known folks less concerned about uptime, and not facing strong performance requirements to put Zk on some of the machines used by solr, but this is not a high performance, highly available configuration. Neither Zk nor Solr like competition from other services for disk or memory. I definately wouldn't try this in kubernetes. Some places who use zookeeper for other things (i.e kafka) have larger beefier existing zookeeper clusters that just get a Solr zk root added to them, usual caveats about system interdependence and making sure competing apps can't stomp on each other apply of course. -Gus -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
