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