KafkaストリームアプリケーションをKubernetesにデプロイする方法は？
私のアプリケーションにはいくつかの集約/ウィンドウ操作があるので、state.dirに格納するいくつかの状態ストアがあります。 AFAIK、ステートストアの変更ログもブローカーに書き込むので、KafkaストリームアプリケーションをステートレスPODと見なしても大丈夫ですか？
私のアプリケーションにはいくつかの集約/ウィンドウ操作があるので、
state.dirに格納するいくつかの状態ストアがあります。 AFAIK、ステートストアの変更ログもブローカーに書き込むので、KafkaストリームアプリケーションをステートレスPODと見なしても大丈夫ですか？
ステートレスポッドとデータの安全性（=データ損失なし）：はい、データの安全性に関する限り、アプリケーションをステートレスポッドと見なすことができます懸念;つまり、ポッドに何が起こっても、KafkaおよびKafkaストリームは、データが失われないことを保証します（また、正確に1回の処理を有効にした場合は、後者も保証します）。
これは、すでに述べたように、アプリケーションの状態変更は、この変更ログ機能を明示的に無効にしない限り、常にそれぞれの状態ストアの変更ログを介してKafka（ブローカー）に継続的にバックアップされるためです（デフォルトで有効になっています）。
注：上記は、KafkaのStreamsデフォルトストレージエンジン（RocksDB）ではなく、代替のインメモリストレージエンジンを使用している場合にも当てはまります。多くの人は、「メモリ内」を読んで、（誤って）「マシンがクラッシュしたり、再起動したりするとデータが失われる」と結論付けているため、これに気づいていません。
ステートレスポッドとアプリケーションの復元/回復時間：上記のように、ポッドの再起動後にローカル状態を使用できる場合と使用しない場合がどのように影響するかを理解する必要がありますアプリケーション（またはアプリケーションインスタンス）が完全に機能するようになるまでの復元/回復時間。
ステートフルアプリケーションの1つのインスタンスがマシン上で実行されていると想像してください。ローカル状態をstate.dirの下に保存し、ローカル状態への変更をリモートKafkaクラスター（ブローカー）に継続的にバックアップします。
- アプリインスタンスが再起動されていて、しない以前の
state.dirにアクセスできる場合（おそらく別のマシンで再起動されたため）、関連付けられたから復元することで、状態を完全に再構築します。 Kafkaの変更ログ。状態のサイズによっては、ミリ秒、秒、分、またはそれ以上かかる場合があります。状態が完全に復元されると、新しいデータの処理が開始されます。 - アプリインスタンスが再起動されていて、does以前の
state.dirにアクセスできる場合（おそらく同じ元のマシンで再起動されたため）、再起動できるため、はるかに迅速に回復できます。 -既存のローカル状態のすべてまたはほとんどを使用するため、関連する変更ログから復元する必要があるのは小さなデルタのみです。状態が完全に復元されると、新しいデータの処理が開始されます。
つまり、アプリケーションが既存のローカル状態を再利用できる場合は、アプリケーションの回復時間が最小限に抑えられるため、これは適切です。
ステートレス環境での救済のためのスタンバイレプリカ：ただし、ステートレスポッドを実行している場合でも、使用するようにアプリケーションを構成することで、アプリケーションの回復時間を最小限に抑えるオプションがあります- スタンバイレプリカnum.standby.replicas設定経由：
num.standby.replicas
スタンバイレプリカの数。スタンバイレプリカは、ローカルステートストアのシャドウコピーです。 Kafka Streamsは、指定された数のレプリカを作成し、実行中のインスタンスが十分にある限り、それらを最新の状態に保とうとします。スタンバイレプリカは、タスクのフェイルオーバーの待ち時間を最小限に抑えるために使用されます。変更ログからのローカル状態ストアの復元プロセスを最小限に抑えることができるように、スタンバイレプリカがあるインスタンスで再起動するよりも、障害が発生したインスタンスで以前に実行した方が望ましいです。
ドキュメントセクションも参照してください ワークロードリバランス中の状態の復元
更新2018-08-29：KubernetesでKafka/Kafka Streams/KSQLを実行するためのおそらく最も便利なオプションは、ConfluentOperatorまたは提供されているHelmChartsを使用することですConfluentによる、 https://www.confluent.io/confluent-operator/ を参照してください。 （免責事項：私はConfluentで働いています。）
更新2019-01-10：方法をデモするYoutubeビデオもあります スケールKafkaストリームKubernetesを使用 。
私はそう思う。 RocksDBは、状態自体を必要とする操作の実行を高速化するために、状態を保存するためにあります。すでに述べたように、状態変化はKafkaトピックにも保存されるため、現在のストリームアプリケーションインスタンスに障害が発生した場合、（別のノード上の）別のインスタンスがトピックを使用して再実行できます。ローカル状態を構築し、前の状態と同じようにストリームの処理を続行します。
KStreamsは、基盤となるstate.dirをローカルストレージに使用します。ポッドが同じマシンで再起動され、ボリュームがマウントされている場合、ポッドは元の場所からすぐに取得されます。
ローカル状態が利用できない別のマシンでポッドが起動した場合、KStreamsはバッキングKafkaトピックを再読み取りして状態を再構築します
https://www.youtube.com/watch?v=oikZg7_vy6A の短いビデオはLenses-for Apache = Kafka-KubernetesでのKStreamアプリケーションのデプロイとスケーリング