kubernetes - 在节点上并置相关容器以避免网络访问成本

Question

我还是Kubernetes的新手，如果这是一个愚蠢的问题，请原谅。

我正在设计一个系统，其中包括:

MQTT经纪人

一组发布并订阅它的(容器化的)微服务

一个微服务读取和写入的Redis缓存。

在扩展规模时，我们当然需要所有这些组件的多重性。

这些事物的多样性具有自然的区别:它们各自与城市中的一组交叉路口有关。发布或订阅微服务将处理1个或多个路口。 MQTT代理实例和Redis实例可以分别设置为处理n个交集。

我想知道通过尝试按交叉点划分事物并将与给定交叉点集相关的所有容器放在一个节点上来尝试避免在Kubernetes中进行不必要的网络跳跃是否有意义。这是否意味着将它们全部放置在单个 pods 中，还是有另一种方法？

(顺便说一句，仍然会有其他发布者和订阅者需要访问不是特定于交叉点的MQTT代理。)

Answer 1

这更多是一个意见问题。

Would this mean putting them all on a single pod, or is there another way?

我当然会避免将它们全部放在一个Pod中。从理论上讲，您可以将任何东西放在单个 pods 中，但是通常的做法是添加能够处理非常特定功能的轻型侧车。

IMO，MQTT代理，Redis数据存储区和订阅/发布应用程序似乎很多都放在一个pod中。

可能的缺点:

难以调试，因为您可能不知道失败的根源。

发布/订阅者通常更多地是无状态的应用程序，MQTT＆Redis将会是有状态的。建议将Deployments用于无状态服务，建议将StatefulSets用于有状态服务。

可能是网络延迟。但是您可以使用Node Affinity and Pod Affinity减轻这种情况。

可能的优势:

所有服务共享相同的IP /上下文。

pod 里太杂乱了。

如果您有:

子/发布应用的

Deployment。

StatefulSet及其自己的Redis服务器存储空间。

Statefulset及其自己的MQTT存储空间。

这些工作负载资源中的每一个都会创建单独的Pod，您可以独立地向上/向下扩展。