docker - 将我的数据库和应用程序部署到同一个 pod 中的不同容器中的优点/缺点是什么？

Question

在使用 kubernetes 部署我的应用程序和数据库容器时，我试图了解以下架构的优缺点。

一点背景：该应用程序位于 Nginx 代理后面。所有请求都从代理流向 Web 服务器。Web 服务器是唯一可以访问（只读）数据库的东西。

架构一：

Pod#1 - 仅数据库容器

Pod#2 - 仅限应用程序容器

架构二：

Pod#1 - 数据库容器和应用程序容器

根据我目前的研究，我发现出于扩展原因推荐架构 1 的评论。https://linchpiner.github.io/k8s-multi-container-pods.html

有谁知道这些方法中哪种更适合我的情况？

标签： dockerarchitecturekubernetesdocker-containerkubernetes-pod

Answer 1

能够独立扩展应用程序和数据库将是将它们分开的关键原因。使用高负载（或高度可变负载）进行扩展需要强大的架构，而“高负载”的定义取决于您的应用。例如，如果数据库和应用程序位于不同的 pod 中，那么理论上您可以运行应用程序的多个副本（即多个 Pod）并且（如果您愿意）只运行一个应用程序的所有实例指向的数据库副本. 你可以有一个 nginx 入口控制器路由到应用程序实例并在它们之间进行负载平衡。

运行多个副本可以使您能够根据负载进行扩展和缩减（例如，请参阅 Horizo​​ntalPodAutoscaler，但您也可以手动扩展）。它提供了一定程度的容错，因为一个实例可能会变得不堪重负并变得无响应（或只是失败）而不影响其他实例（并且失败的 Pod 也可以由 Kubernetes 自动重新启动）。

在运行应用程序的多个副本时需要注意的一个潜在问题是，至少如果它是您要移植到 kubernetes 的现有应用程序，那么您的应用程序确实需要以无状态方式编写以支持这一点。您的数据库是只读的大概意味着这在数据层不是问题。也许您也可以运行多个数据库副本并使用服务，以便您的应用程序实例可以与它们通信。但是您还需要考虑应用程序中的状态性，例如身份验证是否基于令牌，不同的实例是否可以在不需要新登录的情况下验证令牌？

将两个容器放在同一个 pod 中不一定是错的。在您的情况下，您可能仍会获得一些扩展优势，就好像您的数据库是只读的，那么大概实例不会不同步。但是你只能将它们一起缩放，同样每一对都会一起失败。