Kubernetes:带有许多容器的单个POD,或带有单个容器的许多Pod

时间:2017-03-31 14:11:28

标签: kubernetes microservices

我更倾向于一个理论上的问题,我无法回答网上发现的问题。问题是:决定如何在POD中组合容器的规则是什么?。让我用一个例子来解释。

我有这些微服务:

  • 身份验证
  • 授权
  • 提供内容
  • (加上)OpenResty将呼叫从一个转发到另一个并且保持流程。 (有没有可能在K8本地这样做?它似乎有基于nginx + lua的服务,但不确定它是如何工作的)

为了示例我避免使用数据库和co,我认为它们是外部的,不受kubernetes管理

现在,这里 LEFT RIGHT 的正确方法是什么? enter image description here

LEFT :这似乎更容易使它工作,一切都在“localhost”上工作,缺点是它失去了一些微服务的好处。例如,如果auth变慢并且需要更多实例,我将复制整个pod而不仅仅是该服务。

RIGHT 似乎有点复杂,需要服务才能将每个POD暴露给其他POD。然而,在这里,我可以根据需要复制auth而不复制其他容器。另一方面,我会有很多豆荚,因为每个豆荚基本上都是一个容器。

5 个答案:

答案 0 :(得分:2)

通常建议将不同的服务保留在不同的pod或更好的部署中,这些服务将独立扩展。原因通常被讨论为微服务架构的好处。

  • 更松散的耦合,允许以他们自己的语言/技术独立开发不同的服务,

  • 独立部署和更新

  • 也可以独立扩展。

例外是被认为是" 帮助应用程序"协助"主要应用程序"。 k8s文档中给出的示例是数据提取器,数据推送器和代理。在这些情况下,通过环回网络接口的共享文件系统或交换可以帮助处理关键性能用例。数据提取器可以是用于nginx容器的侧车容器,例如,从GIT存储库拉取网站服务。

答案 1 :(得分:0)

右图,每个都在自己的pod中。实际上只有在高度耦合或需要支持主容器(如数据加载器)时才能使用容器中的多个容器。

使用单独的pod,它允许每个服务独立更新和部署。它还允许更有效的缩放。将来,您可能需要2个或3个内容容器,但仍然只需要一个授权。如果它们都在一起,那么你可以将它们全部缩放,因为你没有在同一个pod中选择它们。

答案 2 :(得分:0)

正确的形象是更好的选择。更轻松的管理,升级和扩展。

答案 3 :(得分:0)

应该选择结构的右侧,理由是左侧的架构模型的部署是紧耦合,不利于模块根据业务扩展能力的实际需要。

答案 4 :(得分:0)

正确的图像是更好的选择,易于扩展和管理