**NOW** In a k8s setting, ZK will have separate PODs (with both the suggested helm charts), and a POD hooks into the linux kernel to guarantee some resources so it is not starvated by hot Solr PODs on the same k8s node. So no need for separate machine, separate POD is ok.
**FUTURE, NOT EXISTING**: With SIP-14 Solr may get a new "zookeeper" node-role that lets you spin up a solr Pod just for hosting an embedded ZK. > 23. nov. 2023 kl. 09:02 skrev ufuk yılmaz <uyil...@vivaldi.net.INVALID>: > > There’s a fundamental downside of embedded zk or putting zk on the same node > as Solr. When there are many queries running, a Solr replica gets overloaded > and it starts to affect the node itself (sometimes you can’t even ssh into > the node when Solr is too busy), it also affects the Zk on the same node, > which can cause a chain of downed solr replicas and zk nodes, reducing the > overall availability of the cluster. > > When you need a high read high write cluster, it’s better to put zookeeper on > its own machines I think. > > -ufuk yilmaz > >> On 23 Nov 2023, at 00:25, Jan Høydahl <jan....@cominvent.com> wrote: >> >> I think there is a product that speaks ZK api but stores everything in etcd >> :) >> >> Also, you may want to check out >> https://cwiki.apache.org/confluence/display/SOLR/SIP-18%3A+A+Solr+Kubernetes+Module+for+native+integration >> , an initiative that will let you use ConfigMaps for configSet files etc. >> I.e. somewhat more cloud native. And >> https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper, >> if it gains traction, will embed ZK in Solr processes, making it an >> implementation detail that the users dont need to manage separately. >> >> Jan >> >>> 22. nov. 2023 kl. 14:30 skrev matthew sporleder <msporle...@gmail.com>: >>> >>> It's annoying that zookeeper is a hard dependency when etcd is just >>> sitting there and all of the stuff in zk could easily fit into >>> ConfigMaps. >> >
