Kubernetes：单 POD 多容器，或多 Pod 单容器答案

【问题标题】：Kubernetes: single POD with many container, or many Pod with single containerKubernetes：单 POD 多容器，或多 Pod 单容器
【发布时间】：2017-08-25 20:26:35
【问题描述】：

我有一个理论性的问题，我无法通过网上找到的资源来回答。问题是：决定如何在 POD 中组合容器的规则是什么？。让我用一个例子来解释。

我有这些微服务：

身份验证
授权
服务内容
（加）OpenResty 将呼叫从一个转移到另一个并orhcestarate 流。（是否有可能在 K8 中原生地这样做？它似乎有基于 nginx+lua 的服务，但不确定它是如何工作的）

为了这个例子，我避免使用数据库和 co，我假设它们是外部的，而不是由 kubernetes 管理的

现在，图像的 LEFT 或 RIGHT 的正确方式是什么？

LEFT ：这似乎更容易让它工作，一切都在 "localhost" 上工作，缺点是它失去了微服务的好处。例如，如果身份验证变慢并且需要更多实例，我必须复制整个 pod 而不仅仅是那个服务。

RIGHT 似乎有点复杂，需要服务将每个 POD 暴露给其他 POD。然而，在这里，我可以根据需要复制身份验证，而无需复制其他容器。另一方面，我会有很多 pod，因为每个 pod 基本上都是一个容器。

【问题讨论】：

标签： kubernetes microservices

【解决方案1】：

正确的图像，每个都在自己的 pod 中。 pod 中的多个容器实际上应该仅在它们高度耦合或需要支持主容器（如数据加载器）时使用。

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

【讨论】：

【解决方案2】：

正确的图像是更好的选择。更轻松的管理、升级和扩展。

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

通常建议将不同的服务保留在不同的 pod 中或更好的部署中，以独立扩展。原因就是通常讨论的微服务架构的好处。

更松散的耦合允许不同的服务以自己的语言/技术独立开发，
独立部署和更新
也可以独立缩放。

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

【讨论】：