docker - 将数据库和应用程序部署到同一容器中的单独容器中有什么好处/缺点？

Question

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

背景知识:该应用程序位于Nginx代理后面。所有请求都从代理流向Web服务器。 Web服务器是唯一有权访问(只读)数据库的设备。

体系结构1:

Pod＃1-仅数据库容器

Pod＃2-仅适用于应用程序容器

体系结构2:

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

到目前为止，从我的研究中，我发现出于扩展原因而推荐Architecture 1的评论。 https://linchpiner.github.io/k8s-multi-container-pods.html

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

Answer 1

能够独立扩展应用程序和数据库将是将它们分开的主要原因。高负载(或高可变负载)扩展需要强大的体系结构，什么才算是“高负载”将取决于您的应用程序。例如，如果数据库和应用程序位于不同的容器中，那么理论上您可以运行该应用程序的多个副本(即多个Pod)，并且(如果需要)运行该应用程序的所有实例都指向的数据库的一个副本。 。而且您可以让Nginx入口 Controller 路由到应用程序实例，并在它们之间进行负载平衡。

运行多个副本可以使您能够响应负载而上下缩放(例如，请参见Horizo​​ntalPodAutoscaler，但也可以手动缩放)。它提供了一定程度的容错能力，因为一个实例可能会变得不堪重负，变得无响应(或仅仅发生故障)，而不会影响其他实例(而且故障容器也可以由Kubernetes自动重新启动)。

在运行应用程序的多个副本时(至少是要移植到kubernetes的现有应用程序时)，可能需要注意的是，确实需要以无状态的方式编写应用程序来支持此操作。您的数据库可能是只读的，这意味着在数据层这不是问题。也许您也可以运行多个数据库副本，并使用服务，以便您的应用实例可以与它们对话。但您还需要考虑应用程序中的有状态性，例如是否基于身份验证 token ，并且不同实例可以在无需重新登录的情况下验证 token ？

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