在kubernetes的上下文中，每个应用程序有一个KSQL SERVER是否有意义？当我阅读KSQL Server的容量规划时，似乎基本设置是在一台服务器上运行多个查询。
但是我觉得可以更好地控制使用Kubernetes进行向上和向下扩展，更合理的方法是按每个查询固定Thread的数量，并启动一个在kube中配置的服务器，比如说1个cpu，其中只有一个应用程序可以跑。但是我不确定KSQL Server有多沉重，以及这是否有意义。
任何建议。
最佳答案
首先，您提到的显然是可行的。您可以run KSQL Server with Docker，这样就可以拥有一个容器编排器，例如kubernetes或群集来维护和调度那些KSQL Server实例。
因此，您知道如何进行:
使用
KSQL_SERVICE_ID定义的相同Kafka群集的相同KSQL_KSQL_STREAMS_BOOTSTRAP_SERVERS 应用程序，只需在使用时使用不同的
KSQL_SERVICE_ID相同的Kafka群集。 结果，您现在拥有:
诸如Kubernetes的协调器。
KSQL_SERVICE_ID，您也可以具有不同的Kafka集群)(不同的
KSQL_SERVICE_ID)以实现分离问题，以便可以扩展性，安全性和可用性
维护得更好。
关于同一台服务器上的多个KSQL Server实例(可能具有不同的
KSQL_SERVICE_ID)的共存，您应该知道贪婪实例会垄断可用的机器资源，从而导致贪婪程度较低的实例出现问题。使用Kubernetes，您可以在Pod上设置资源限制来避免这种情况，但是贪婪的实例将受到限制并减慢速度。融合advice regarding multi-tenancy:
一个可能的缺点是，如果在同一个池中运行多个KSQL Server实例(Java应用程序占用空间)而又没有任何工作要做(即:由于主题上没有分区，则没有可计划的任务)，则会产生开销))或仅仅是因为您的工作量很少。您可能用更少的实例来完成相同的工作，从而避免了空闲或接近空闲的实例。
当然，将所有流处理(可能是针对完全不同的用例或项目)填充在单个KSQL Server或KSQL Server池上，可能会带来自身的内部并发问题，开发周期复杂性，管理等。
我猜中间的东西会很好用。对单个项目或用例使用KSQL Server实例池，这反过来可能会转换成由多个源，进程和接收器的拓扑组成的管道，并由多个KSQL查询实现。
另外，请不要忘记previous question you've posted中讨论的Kafka，Kafka Streams和KSQL(在Kafka Streams之上构建)的伸缩机制。
所有这些机制都可以在这里找到:
https://docs.confluent.io/current/ksql/docs/capacity-planning.html
https://docs.confluent.io/current/ksql/docs/concepts/ksql-architecture.html
https://docs.confluent.io/current/ksql/docs/installation/install-ksql-with-docker.html
关于kubernetes - Kubernetes中的KSQL Server弹性扩展，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/56926837/