Jan Høydahl commented on SOLR-6734:
I'm arguing back and forth with myself on this. While it gives easier cluster setups since we ship ZK, it also re-invents some of the orchestration tasks that frameworks like Kubernetes, Swarm & Mesos were built to handle. Like "Where do my zookeepers run?" and "Node A with ZK died, should we start it on node B?".
I also realise that most people will not consider K8s for small clusters due to the (current) complexity of installing and overhead, but looking 3-5 years into the crystal ball I can see more and more users wanting to run their search cluster containerized and freely choose whether to deploy in a public cloud, a private cloud or on-premise. Also in that time frame K8s will probably be mature for small local DC installs, and your average hosting provider will offer container services.
So my question is whether it makes sense to instead focus our efforts into lowering the bar for running Solr on Kubernetes, and aim to promote that as an officially supported environment and later perhaps the recommended one? This could translate into developing a high-quality and feature rich [Kubernetes Operator|https://coreos.com/operators/] for Solr. An Operator is a program that knows the application well and can support high-level cluster operations such as "install a 3x2 node cluster with 3 ZKs", or "do a rolling upgrade from SolrX to SolrY", or "Spin up more nodes / containers / pods if Solr' Metric X is above threshold Y for more than Z minutes".