在 Kubernetes 中使用部署来隔离客户端是个好主意吗？

Question

我们正在将老化的单体架构迁移到更强大的解决方案，并将 Kubernetes 作为最合适的平台来实现我们的目标。同时，我们希望拆分和隔离我们的客户数据，以确保安全并改善隐私。

我们正在考虑最终让每个客户拥有一个数据库，并将这些连接详细信息嵌入到每个客户的部署中。然后，我们将构建某种路由服务，将客户端的请求链接到它们各自的部署/服务。

由于我们的各个客户端的规模差异很大（我们有一些每分钟产生数千个请求，而另一些则每天产生数百个请求），我们喜欢能够扩展它们的选项通过部署上的 ReplicaSet 独立进行。

但是，我对集群中可以存在/成功管理的部署数量上限有些担忧，因为我们可能会关注数百个不同的客户端，这些客户端将继续增长。我还担心成本，以及为我们的小客户提供专用资源（基本上是整个虚拟机）可能会如何影响我们的预算。

所以我的问题是：

• 这是个好主意吗？为什么或为什么不，如果没有，我们是否可以考虑使用替代架构来实现相同的目标？
• 这个解决方案是否比它需要的更昂贵？

如果您能提供任何见解，我将不胜感激，谢谢！

Answer 1

对于这种情况，我可以想到几个选项：

1. 为每个客户部署单独的集群。这还允许您为每个客户正确调整集群的大小，并为每个客户相应地配置自动缩放。缺点是每个集群的管理费为每小时 0.10 美元，但您可以完全保证一切都是隔离的，您可以使用cluster autoscaler 确保只有每个客户实际需要的 VM 正在运行.对于较小的客户，您可能希望将其用于小型（且便宜）的机器类型。

2. 如 cmets 中所述，另一种选择是使用命名空间。但是你必须configure the cluster properly，因为那里有exist ways of accessing services in different namespaces。

3. 在您自己在集群上运行的软件中实施客户隔离。这意味着强制您的软件仅访问给定客户的数据库，但我不建议采用这种方式。