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

Question

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

我正在设计一个包含以下内容的系统：

• MQTT经纪人
• 一组发布并订阅的（容器化）微服务
微服务读取和写入的
• Redis缓存。

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

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

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

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

Answer 1

这更多是一个意见问题。

  

这是否意味着将它们全部放在一个吊舱中，还是有另一种方法？

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

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

可能的缺点：

• 调试困难，因为您可能不知道故障来自何处。
• 发布/订阅者通常更像是一个无状态应用程序，MQTT＆Redis将会是有状态的。对于无状态服务，更推荐使用Deployments，对于有状态服务，更推荐使用StatefulSets。
• 也许是网络延迟。但是您可以使用Node Affinity and Pod Affinity减轻这种情况。

可能的优势：

• 所有服务共享相同的IP /上下文。
• 豆荚里的杂物太多。

如果您这样做，那会更干净

• Deployment for your sub / pub app。
• StatefulSet及其自己的Redis服务器存储空间。
• Statefulset及其自己的MQTT存储空间。

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