こんにちは、
ロードバランサーの後ろにあるweb_onlyコンテナを使用したマルチノード構成で、設定を変更した際に、その設定が単一ノード（おそらく変更を行った際にロードバランサー経由で接続していたノード）にのみ適用されることに気づきました。
具体的には、Global notice（グローバル通知）、Globally pinned posts（グローバルにピン留めされた投稿）、そして最近ではカスタムテーマへの変更といったものが該当します。
結果として、変更はロードバランサーがユーザーをその変更が行われたノードと同じノードに接続した場合にのみユーザーに表示されます。これにより、場合によっては混在したページ読み込みやサイトのレンダリングが乱れる原因となります。
そこで質問です。このような変更を行った後、すべてのノードでrakeを使って何らかの設定リロードコマンドを実行する必要があるのでしょうか？それとも、設定が自動的に他のノードに伝播されるように、コンテナ実行時に特定の環境変数を追加する必要があるのでしょうか（自動リロード/クラスターモードのため）？
はい、以下を試すことができます。
su discourse -c 'bundle exec rake cache:clear'
あるいは、railsコンソールに入りたい場合は、SiteSetting.refresh! がおそらく同じことをします。
ありがとうございます！何か見落としている点があるような気がしていました。設定変更の後にどのような操作が必要になるかについて言及しているドキュメント記事はありますでしょうか？ドキュメント記事をいくつか確認しましたが、特にその件やHAセットアップに関するものは見当たりませんでした。
確認ですが、全てのノード間で共有されたRedisデータベースをお持ちですか？ Discourseが動作するためにはそれが不可欠です。（他のアプリケーションではノードごとに1つのRedisで動作するものもありますが、Discourseでそれを試みると、あなたが説明しているような問題が発生します）
はい。Redisは、すべてのDiscourseノードインスタンスで共有されます。HA（高可用性）になるようにセットアップを作成しましたので、S3/Redis/PostgreSQLはそれぞれ個別に存在します。
/logs 内で Global messages on xx timed out, message bus is no longer functioning correctly のようなエラーメッセージを確認しましたか？
以前、Redis とメッセージバスが別々のホストで実行されている場合にタイムアウトが発生し、異なる Unicorn ワーカー間での同期に失敗することを発見しました。
私の回避策は、ユニコーンサーバー全体を定期的にリロードすることでした。
すべてのノードのログをgrepしましたが、そのようなログエントリは見つかりませんでした。
ああ。やはり Global messages on xx timed out, message bus is no longer functioning correctly というメッセージがありました。しかし、誤って実際のログディレクトリを見ていました。今、ウェブインターフェースのログのエラーセクションを見たところ、あなたが言及していたエントリに実際に気づきました。Discourse では異なるエラーが異なる場所に表示されるという事実に慣れる必要があります。それでも、Discourse のウェブ側には機能があるのは良いことです。