The SolrCloud CRD allows users to spin up a Solr cloud in a very configurable way. Those configuration options are layed out on this page.
The SolrCloud CRD provides users the ability to define how it is addressed, through SolrCloud.spec.solrAddressability. This provides the following options:
podPort - The port on which the pod is listening. This is also that the port that the Solr Jetty service will listen on. (Defaults to 8983)commonServicePort - The port on which the common service is exposed. (Defaults to 80)kubeDomain - Specifies an override of the default Kubernetes cluster domain name, cluster.local. This option should only be used if the Kubernetes cluster has been setup with a custom domain name.external - Expose the cloud externally, outside of the kubernetes cluster in which it is running.method - (Required) The method by which your cloud will be exposed externally. Currently available options are Ingress and ExternalDNS. The goal is to support more methods in the future, such as LoadBalanced Services.domainName - (Required) The primary domain name to open your cloud endpoints on. If useExternalAddress is set to true, then this is the domain that will be used in Solr Node names.additionalDomainNames - You can choose to listen on additional domains for each endpoint, however Solr will not register itself under these names.useExternalAddress - Use the external address to advertise the SolrNode. If a domain name is required for the chosen external method, then the one provided in domainName will be used.hideCommon - Do not externally expose the common service (one endpoint for all solr nodes).hideNodes - Do not externally expose each node. (This cannot be set to true if the cloud is running across multiple kubernetes clusters)nodePortOverride - Make the Node Service(s) override the podPort. This is only available for the Ingress external method. If hideNodes is set to true, then this option is ignored. If provided, his port will be used to advertise the Solr Node. method: Ingress and hideNodes: false, then this value defaults to 80 since that is the default port that ingress controllers listen on.Note: Unless both external.method=Ingress and external.hideNodes=false, a headless service will be used to make each Solr Node in the statefulSet addressable. If both of those criteria are met, then an individual ClusterIP Service will be created for each Solr Node/Pod.
Solr Clouds require an Apache Zookeeper to connect to.
The Solr operator gives a few options.
Note - Both options below come with options to specify a chroot, or a ZNode path for solr to use as it‘s base “directory” in Zookeeper. Before the operator creates or updates a StatefulSet with a given chroot, it will first ensure that the given ZNode path exists and if it doesn’t the operator will create all necessary ZNodes in the path. If no chroot is given, a default of / will be used, which doesn't require the existence check previously mentioned. If a chroot is provided without a prefix of /, the operator will add the prefix, as it is required by Zookeeper.
This is an external/internal connection string as well as an optional chRoot to an already running Zookeeeper ensemble. If you provide an external connection string, you do not have to provide an internal one as well.
If you do not require the Solr cloud to run cross-kube cluster, and do not want to manage your own Zookeeper ensemble, the solr-operator can manage Zookeeper ensemble(s) for you.
Using the zookeeper-operator, a new Zookeeper ensemble can be spun up for each solrCloud that has this option specified.
The startup parameter zookeeper-operator must be provided on startup of the solr-operator for this parameter to be available.
Using etcd-operator, a new Etcd ensemble can be spun up for each solrCloud that has this option specified. A Zetcd deployment is also created so that Solr can interact with Etcd as if it were a Zookeeper ensemble.
The startup parameter etcd-operator must be provided on startup of the solr-operator for this parameter to be available.