Unfortunately the podDisruptionBudget isn't so useful for Solr applications.
If we are merely talking about doing restarts of the Pod Spec (which could include the OS that the Solr image uses), then the updateStrategy takes care of that very well. If you are talking about doing upgrades of the Kubernetes Nodes, then the updateStrategy doesn't come into play at all. The issue with PodDisruptionBudget is that it treats all pods the same. This works well for Zookeeper, where each pod does contain the same data. For Solr however, we can have 12 Solr nodes, 3 shards split across 4 nodes each. We might then want to include a podDisruptionBudget of 3, so that we only take down one node of each shard-group. However Kubernetes doesn't know what our shard-groups are, so it could take down node(s) that contain 3 pods of the same shard-group, completely ignoring the point of our podDisruptionBudget. We could manually create shard-groups by using multiple statefulSets, at which point you can use a separate podDisruptionBudget for each. And this is probably a future option that the operator will enable, but hasn't been planned for yet. In the meantime, you are able to create PodDisruptionBudget resources in conjunction with your SolrCloud object. This is no different in the end to what the Zookeeper Operator does, you just have to manage it yourself. - Houston On Fri, Jul 9, 2021 at 11:52 AM Joel Bernstein <[email protected]> wrote: > WIth the Solr operator I see there is an updateStrategy for the managed > Solr upgrades. But I don't see anything mentioned about pod disruption > budgets. I saw that a Zookeeper pod disruption budget is installed with the > Zookeeper that deploys with the Solr operator but I didn't see one for > Solr. > > Does the updateStrategy take the place of the pod disruption budgets or do > we need to specify one for the lower level (OS etc...) pod updates? > > > Joel Bernstein > http://joelsolr.blogspot.com/ >
