通常、メッセージパッシングを使用して、分離されたサービスにメッセージを送信します。これにより、(たとえば RabbitMQ の AMQP を使用して) ブローカーのルーティング機能を使用して、正しいサービスにフィードする正しいキューにメッセージをディスパッチできるため、サービス検出は問題になりません。負荷分散もメッセージ ブローカによって処理されます。
Kubernetes に入ります。
サービスのレプリケーションと失敗したサービスの再生成について話すときに通常提示される使用例は、クライアントが http などのアクティブなプロトコルを使用してサービスに接続する場合です (このサービスがリクエストを非同期的に処理する場合でも)。このコンテキストでは、サービスのグループとそれらの間の負荷を分散するための単一のエントリ ポイントを管理するレプリケーション コントローラーを用意するのが自然に適しています。
ローリング デプロイなど、kubernetes の直感的なコンセプトは気に入っていますが、http インターフェースを持たないこの野獣をどのように制御すればよいのでしょうか。
更新: メッセージ ブローカーのクラスターをセットアップしようとしていません。メッセージコンシューマをサービスとして見ています。サービス クライアントはサービスに直接接続せず、メッセージ ブローカーにメッセージを送信します。メッセージ ブローカは、ある意味でロード バランサとして機能し、サブスクライブされたキュー コンシューマにメッセージをディスパッチします。これらのコンシューマーがサービスを実装します。
私の質問は、デモのほとんどの使用パターンが http 経由で呼び出されるサービスを処理し、kubernetes がこれらのサービスのサービス プロキシとレプリケーション コントローラーを作成するためにうまく機能しているという事実に引き寄せられます。HTTP インターフェイス自体を持たず、ローリング アップデートのすべての利点と最小限のインスタンスを備えた、私の種類のサービス用のレプリケーション コントローラーを作成することは可能ですか?