如何在Kubernetes上部署Kafka Stream应用程序？

我的应用程序具有一些聚合/窗口操作，因此它具有一些状态存储，这些状态存储在中state.dir。AFAIK，它还将状态存储的更改日志写入代理，因此可以将Kafka Stream应用程序视为无状态POD吗？

无状态Pod和数据安全性（=无数据丢失）：是的，就数据安全而言，您可以将应用程序视为无状态Pod 。也就是说，无论Pod发生什么变化，Kafka和Kafka Streams都可以确保您不会丢失数据（如果启用了一次处理，它们也将保证后者）。

这是因为，正如您已经说过的那样，应用程序中的状态更改总是通过相应状态存储的更改日志连续不断地备份到Kafka（经纪人）中-除非您明确禁用此更改日志功能（默认情况下已启用）。

注意：当您不使用Kafka的Streams默认存储引擎（RocksDB），而是使用内存中的替代存储引擎时，上述情况甚至适用。许多人没有意识到这一点，因为他们读到“内存中”并且（错误地）得出结论：“当计算机崩溃，重新启动等时，数据将丢失”。

无状态Pod和应用程序的恢复/恢复时间：上面已经说过，您应该了解在Pod重新启动后拥有本地状态与不拥有本地状态将如何影响应用程序（或应用程序实例）直到完全恢复/恢复的时间。再次运作。

想象一下，有状态应用程序的一个实例在计算机上运行。它将本地状态存储在下state.dir，并且还将对本地状态的任何更改连续备份到远程Kafka群集（代理）。

• 如果该应用程序实例正在重新启动并且无法访问其先前实例state.dir（可能是因为它是在其他计算机上重新启动），则它将通过从Kafka中的关联变更日志中还原来完全重建其状态。根据状态的大小，这可能需要毫秒，秒，分钟或更长的时间。只有状态完全恢复后，它才会开始处理新数据。
• 如果该应用程序实例正在重新启动并且确实可以访问其先前的实例state.dir（可能是因为它是在同一台原始计算机上重新启动的），则它可以更快地恢复，因为它可以重新使用全部或大部分现有本地状态，因此仅需要从关联的变更日志中还原一个小增量。只有状态完全恢复后，它才会开始处理新数据。

换句话说，如果您的应用程序能够重用现有的本地状态，那么这很好，因为它将使应用程序恢复时间最短。

备用副本可在无状态环境中进行救援：但是，即使您正在运行无状态Pod，也可以通过以下设置将应用程序配置为使用备用副本，从而最大程度地缩短应用程序恢复时间num.standby.replicas：

num.standby.replicas

备用副本的数量。备用副本是本地状态存储的卷影副本。只要有足够多的实例在运行，Kafka Streams就会尝试创建指定数量的副本并保持最新状态。备用副本用于最大程度地减少任务故障转移的延迟。最好先在发生故障的实例上运行任务，然后在具有备用副本的实例上重新启动，以便可以将其更改日志中的本地状态存储还原过程最小化。

另请参见文档部分工作负载重新平衡期间的状态恢复

更新2018-08-29：在Kubernetes上运行Kafka / Kafka Streams / KSQL的最方便的选择可能是使用Confluent Operator或Confluent提供的Helm Charts，请参阅https://www.confluent.io/confluent-operator/。（免责声明：我为Confluent工作。）

更新2019-01-10：还有一个Youtube视频，演示如何使用Kubernetes扩展Kafka流。