Solr OperatorとPod Disruption Budget
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/f8jjssp4nfwr9rz8vks05pggdzpc7pcg into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
Solrオペレーターでは、管理されるSolrのアップグレードに対するupdateStrategyについての情報は見つかりますが、Pod Disruption Budgetsについては言及されていません。SolrオペレーターでデプロイされるZookeeperにはZookeeper Pod Disruption Budgetがインストールされていることが分かりましたが、Solrにはそのようなものは見当たりませんでした。
updateStrategyはPod Disruption Budgetsの代わりになるのでしょうか、それとも低レベル（OSなど）のPodの更新に対して個別に指定する必要があるのでしょうか？
Joel Bernstein
http://joelsolr.blogspot.com/
残念ながら、Pod Disruption BudgetはSolrアプリケーションにとってあまり有用ではありません。
ポッド仕様の再起動（Solrイメージで使用されるOSを含む）について話している場合、updateStrategyが非常にうまく処理します。Kubernetesノードのアップグレードについて話している場合、updateStrategyは全く関与しません。
Pod Disruption Budgetの問題は、すべてのポッドを同じように扱うという点です。これはZookeeperの場合にはうまく機能しますが、各ポッドが同じデータを含むSolrの場合は適していません。たとえば、12台のSolrノードがあり、3つのシャードがそれぞれ4つのノードに分割されている場合があります。その場合、各シャードグループのノードを1つだけ停止させるために、ポッドDisruption Budgetを3に含めたいかもしれません。しかし、Kubernetesはシャードグループが何であるかを知らないため、同じシャードグループの3つのポッドを含むノードを取り下げる可能性があり、私たちのポッドDisruption Budgetの目的を完全に無視します。
複数のStatefulSetを使用して手動でシャードグループを作成し、それぞれに個別のPod Disruption Budgetを使用することができます。これはおそらく、将来的にオペレーターが有効にするオプションですが、まだ計画されていません。
その間、SolrCloudオブジェクトと共にPod Disruption Budgetリソースを作成することができます。これは最終的にはZookeeperオペレーターが行うことと同じですが、自分で管理する必要があります。
Houston
ありがとう、Houston。その回答は完璧です。
Joel Bernstein
http://joelsolr.blogspot.com/
トピックへ返信するには、ログインが必要です。