私の理解する限り、組み込み ZooKeeper はシングルノードの SolrCloud 用に意図されています。

私はコンテナ化した SolrCloud を実行しており、3 台の専用ホストで ZooKeeper と Solr を起動する際に docker run --network host を使用しています。

現在、組み込み ZooKeeper は「サポートされている」とはいえ、基本的には最初のテストやチュートリアルを簡単に実行するためのものです。冗長性を提供するクラスタを構築することは想定されておらず、データストアの管理や不要なアクセスからの保護についてもあまり考慮されていません。

これをよりスケーラブルなレベルのサポートに引き上げたいと考えている人たちもいますが、まだ実現していません。
（参照: https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper）

本番環境では外部 ZooKeeper を使用することが強く推奨されます。

Kubernetes の文脈では、ZooKeeper クラスタ用に StatefulSet を維持し、Solr クラスタ用に別の StatefulSet を維持することを意味します。Solr ノードは起動時に現在の ZooKeeper 接続文字列を設定しておく必要があります。その文字列をどのように伝達するかは、システム管理方法によって決まりますが、理想的には、Solr（またはデータベース）の場所をユーザー向けアプリケーションや他の下流システムに伝えるのと同じように扱えると管理が容易になります。良い点として、通常 ZooKeeper クラスタ用には小規模で安価なインスタンスを用意できるため、これを実施するコストは（Solr 用のハードウェア／ディスクコストに比べれば）高くありません。ただし ZooKeeper のドキュメントにあるパフォーマンス関連の注意事項は無視しないようにし、もちろん他のシステムと同様に監視してください。

組み込み ZooKeeper を使って小規模なシングルノードシステムを運用している人たちも確かにいますが、通常はミッションクリティカルや無停止運用が求められるシナリオではありません。

Kubernetes 以外の環境では、稼働時間をあまり重視せず、強いパフォーマンス要件にも直面していない人たちが、Solr が動作するマシンの一部に ZooKeeper を配置するケースもありますが、これは高性能でも高可用でもありません。ZooKeeper も Solr も、ディスクやメモリを他のサービスと取り合うことを嫌います。私は Kubernetes では絶対にこの構成は試さないでしょう。

また、Kafka など他の用途で ZooKeeper を利用している組織では、既存の大規模で強力な ZooKeeper クラスタに Solr 用のルートを追加することもあります。ただし、その場合もシステム間の依存関係や、アプリケーション同士が互いに影響を及ぼさないようにする注意が必要です。

— Gus

http://www.needhamsoftware.com （仕事用）
https://a.co/d/b2sZLD9 （私のファンタジー小説）

コンテナ化された SolrCloud を組み込み ZooKeeper で動かすのは不可能に思えます。

それは決して正しくありません。ただし、確かにいくらかのエンジニアリング努力は必要です。私たち（Autotrader UK）は Kubernetes 上で Solr と ZooKeeper を実行しており、かれこれ 7 年ほど大きな問題なく運用しています。私たちの環境は読み込み・書き込みともに多いチャレンジングな構成ですが、やり抜いてきました。ちなみに私たちは GCP 上で運用しており、Hyperdisks を利用してディスクの容量とは独立に IOPS とスループットをスケールさせています。また、ARM ノード（C4A）上で動かしています。

Helm チャートは自分たちで作成し、市販のチャートやオペレーターは使っていません。これによりデプロイのあらゆる側面を完全に制御できます。各クラスタごとに Solr レプリカを 9、ZooKeeper レプリカを 5 実行しています。Pod が同じノードで動作しないように anti-affinity ルールを設定し、利用可能なゾーン全体に分散するよう Pod のトポロジ制約を活用してください。また、他の方も言っているように、ZooKeeper は Solr とは異なるノードで動作させるべきです。さらに、PodDisruptionBudget（PDB）を設定し、Solr と ZooKeeper の両方について同時にオフラインになる Pod が 1 つだけになるよう制御しています。これによりロールアウトは遅くなりますが、安全になります。また、私たちの CI/CD パイプラインでは、必ず ZooKeeper を先にデプロイし、その後に Solr をデプロイしています。

ZooKeeper のホスト名と IP に関しては、IP が変わらないようにする必要があります。そのために各 Pod ごとに Service を作成します（例えば ZooKeeper ノードが 5 つある場合）。そして StatefulSet のセレクタ statefulset.kubernetes.io/pod-name: zookeeper-X を利用します。これにより、常に zookeeper-X.namespace.svc.cluster.local というアドレスを利用でき、それが固定の IP（Service）に解決され、その IP が Pod（動的）にルーティングされます。これで予測可能に ZK_HOSTS をテンプレート化することができます。

お役に立てば幸いです。これは完全に実現可能です。

すみません、埋め込み部分を読み違えていましたので、最初の一文は無視してください。――ただ、それ以外の部分はおそらくまだ役に立つと思います。

ご支援いただき、本当にありがとうございます。

その間に自分で解決策を見つけることができました。
ある問題についての議論の中で、ZK コンテナ（0.0.0.0 ハックを使ったもの）がリーダー選出に問題を抱える可能性があることが挙げられていました。その際に、ZK には 「quorumListenOnAllIPs」 というパラメータがあることが言及されていました。
このパラメータを true に設定すると、「0.0.0.0」を使った回避策ではなく、実際のホスト IP で ZK アンサンブルを構成することができます。
その結果、Solr ノードが到達不能な zkHosts の参照を扱う必要がなくなり、問題は解決しました。

より詳しい説明に興味がある方のために、こちらに追記しました：
https://stackoverflow.com/questions/64351894/solr-cloud-cannot-connect-to-random-zookeeper-node-full-docker-set-up

追伸：
最初の投稿がリストに表示されるまで 6 日かかってしまいました。そのため、もっと早く撤回することができませんでした。申し訳ありません。この返信はもう少し早く反映されることを願っています。