在使用kubernetes部署我的应用程序和数据库容器时，我试图了解以下体系结构的优缺点。
一些背景知识：该应用程序位于Nginx代理后面。所有请求都从代理流向Web服务器。 Web服务器是唯一有权访问（只读）数据库的东西。
体系结构1：
Pod＃1-仅数据库容器
Pod＃2-仅适用于容器
体系结构2：
Pod＃1-数据库容器和应用程序容器
到目前为止，从我的研究中，我发现了出于扩展原因而推荐架构1的注释。 https://linchpiner.github.io/k8s-multi-container-pods.html
有人知道这些方法中哪种更适合我的情况吗？
答案 0 :(得分：3)
能够独立扩展应用程序和数据库将是将它们分开的主要原因。高负载（或高可变负载）扩展需要强大的体系结构，什么才算是“高负载”将取决于您的应用程序。例如，如果数据库和应用程序位于不同的Pod中，则理论上您可以运行该应用程序的多个副本（即多个Pod），并且（如果需要）运行该应用程序的所有实例都指向的数据库的一个副本。 。而且，您可以将Nginx入口控制器路由到应用程序实例，并在它们之间进行负载平衡。
运行多个副本可以使您能够响应负载而上下缩放（例如，请参见HorizontalPodAutoscaler，但也可以手动缩放）。它提供了一定程度的容错能力，因为一个实例可能会变得不堪重负，变得无响应（或仅仅发生故障）而不会影响其他实例（而且故障容器也可以由Kubernetes自动重新启动）。
一个潜在的障碍是，当您运行应用程序的多个副本时（至少是要移植到kubernetes的现有应用程序时），需要注意的是，您的应用程序确实需要以无状态方式编写才能支持此操作。您的数据库可能是只读的，这意味着在数据层这不是问题。也许您也可以运行多个数据库副本，并使用服务，以便您的应用实例可以与它们对话。但您还需要考虑应用程序中的有状态性，例如身份验证是否基于令牌，并且不同实例可以在无需重新登录的情况下验证令牌吗？
将两个容器放在同一个容器中不一定是错误的。在这种情况下，您可能仍会获得一些扩展优势，就像您的数据库是只读的那样，则推测实例无法同步。但是，您只能将它们缩放在一起，同样，每对也会失败。
答案 1 :(得分：1)
出于相同的原因，您不能将Web服务器和数据库放在同一台计算机或VM上。
两个关键原因是安全性和性能方面。
您的网站可能面向公众，但您的数据库不能。您应该努力减少攻击面。
此外，您可以独立地调整每个层的性能，例如根据一些指标扩展应用层。
最后，如果您不关心这些注意事项，则将它们放在同一容器/容器中更容易维护。
HTH