我目前拥有一个 Kafka-Connect 集群，由部署在 2 个 EC2 实例上的两个工作线程组成。我通过依赖 kafka-connect API 的客户端层创建连接器 - 我也以这种方式对它们进行版本控制，也就是说，我将配置存储在 json 文件中，并通过在 API 请求中使用它们来部署它们。
目前我正在尝试解决两个问题：
可扩展性：随着我的用户创建的连接器数量的增加以及吞吐量和记录大小的变化，我需要不断地在他们后面监视堆大小，从而导致新连接器的添加等等。
UX：另一个团队使用 Strimzi Operator 让用户通过简单地在自己的存储库中添加清单来创建主题。我想将我的 KC 客户端加入到这种做事方式中，以便用户可以在同一位置创建主题和连接器，并且无需重写连接器配置所需的所有样板。
我正在考虑迁移到 Kubernetes，但是，将服务器迁移到 Pod 甚至添加自动缩放器并不能解决太多问题。我想考虑一种架构，其中对连接器的请求意味着部署具有不同组 ID 的专用、隔离的 Kafka Connect 工作线程。这样，连接器就不会共享 JVM 资源。
我没有在其他地方找到这样的架构，说实话，我很怀疑，尤其是这违背了 kafka 连接概念本身的定义。
在 Kubernetes 中部署 Kafka Connect 连接器
连接器将始终共享集群的 JVM 资源，除非您形成一个模型，其中每个连接器都是专用的连接“集群”。
Strimzi 可以做到这一点，但扩展是一个独特的问题，您无法扩展超出接收器消费者的主题分区计数，而源消费者有时根本无法扩展太多（Debezium 或 JDBC 源应该始终为每个表有一个任务）
Strimzi 中的 Kafka Connect CRD 允许您跳过 JSON 文件，因为它将自行部署和管理连接器任务