We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.

Rethinking Autoscaling for Apache Solr using Kubernetes

Formal Metadata

Rethinking Autoscaling for Apache Solr using Kubernetes
Title of Series
Number of Parts
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Release Date2023

Content Metadata

Subject Area
SolrCloud clusters are often large and complex, with each organization using its own code to deploy and maintain these clusters. The Solr Operator was a first step in consolidating complexity through official deployment tooling to run Solr on Kubernetes. However the Operator does not address scaling up and down based on demand. Much like it provides generic deployments, Kubernetes provides generic ways of autoscaling applications, such as the HorizontalPodAutoscaler (HPA). This works especially well for stateless applications, much like deployments do. Solr is a stateful application that has specific state assigned to each pod (Solr node), therefore autoscaling SolrClouds with the HPA will not work by default. The Solr Operator has already been built to extend Kubernetes’ StatefulSets, Services and Ingresses to support Solr’s unique use-case. Therefore it is the prefect mechanism to also bridge the gap between the HorizontalPodAutoscaler and Solr. Through extending the functionality of the Solr Operator, and adding new APIs to Solr, we will show how autoscaling can be re-introduced to the Solr ecosystem.