嗨，马库斯，

我们需要在这里改进一些错误处理。 抱歉。 在管道的日志中，您会发现一个错误"无法发布消息...已超过最大有效负载"。

目前，跨管道的不同容器进行数据交换的最大大小为10 MB。 那是一个限制。 将来我们可能会增加该限制，但目前是这样。

我将尝试解释一些情况：

• 在运行管道时，这种简单的说法会导致Kubernetes上出现N个pod。
• 如果您的管道很简单，那就是一个吊舱。 如果您在管道中使用组，则每个组都是一个Pod，其余的运算符（组之外的那些运算符）也都是一个Pod。
• 如果您有一个具有多个M的组， 然后导致该组的M个广告连播。
• 我们试图优化不同操作员之间的通信，以避免仅仅因为价格昂贵而就将数据复制到内存中。 假设您链接了三个运算符，我们将尝试确保这三个运算符都可以访问"相同"数据（我简化了一点……对不起）。
• 现在让我们回顾一下我说的内容 关于团体。 不同的组是不同的豆荚。 并且不同的Pod可能在不同的群集节点上运行。 因此，当三个操作员各自具有自己的组时，我们需要以不同的方式进行通信。 我们要做的是：发送操作员将数据放入消息传递系统中（当前我们使用NATS），接收操作员从消息传递系统中提取数据。

上述不同Pod和介于两者之间的消息传递系统的机制也是优化数据处理，以不同方式缩放管道的不同部分等的好方法。

同时，这也意味着：尽量避免在不必要的组/对数据处理没有价值的组，因为（不考虑当前的限制）通过消息传递系统发送数据会对性能产生负面影响，而不是 正在做。 当您通过消息传递时，两个运营商之间的数据交换越大，获取的成本就越高。

这一切都与操作员的端口是"消息"类型还是其他类型无关。 所有端口类型的机制都相同。

我希望能有所帮助。 如果有理由将Python运算符放在一个组中，那么让我们检查一下原因或考虑将读取文件运算符与Python运算符放在同一个组中。

干杯
Thorsten