シナリオ: SSL 暗号化と SASL/PLAIN 認証で保護された Kafka クラスターは、専用 VPC 内の AWS プライベートサブネットに存在します。プライベートサブネット内ではすべて問題ありません。通信を保護するために自己生成の CA とキーを使用し、ホスト ID は AWS 内部 DNS に基づいています。
達成したいこと：プロデューサーAPIにアクセスする可能性を持つこと（ない外部から REST API にアクセスします。
私は、キー、DNS、kafka リスナーの組み合わせと、プロデューサーからブローカーへの永続的な接続が、接続を開始するために使用したものではない可能性があるという事実に苦労しています。
リバース プロキシを使用したいくつかの試行は失敗しました。キーを解決できないため、SSH トンネルも機能しません。
このような場合の参照アーキテクチャのようなものを持っている人はいますか? さまざまな構成、キーなどに分散しているため、ここでは構成の詳細は省略しますが、必要に応じて設定を提供することができます。
答え1
解決策を見つけました。最も効率的ではないかもしれませんが、私にとっては問題ありません。3 つのブローカーの前に 3 つのレベル 4 ロード バランサーを実装し、各ブローカーの advanced_listener アドレスをロード バランサーのアドレスで構成しました。比較的高価で、トラフィック レートがいくらか制限されるとしても、うまく機能します。