我试图绕过kubernetes。
据我所知，pod是组织相关容器的好方法。我知道复制控制器是确保它们正常运行的好方法。
但是，我不知道如何在现实生活中这样做。
给一个webapp，比如在独角兽上使用rails app，在nginx后面有一个postgres数据库。
nginx和rails app可以水平自动缩放（如果它们没有任何共享），但是postgres可以开箱即用。
这是否意味着当我想在负载均衡器后面安装两台服务器时，我无法在与nginx和rails相同的pod中组织postgres数据库？ postgres是否需要自己的复制控制器，并且只是群集中的服务？
关于这一点的一般问题是：在常见的网站场景中，哪种容器进入一个容器？我知道这不能得到普遍的回答，所以背后的想法很有意思。
答案 0 :(得分：2)
这个问题的答案实际上取决于你想要走多久。您真的在描述应用程序的3个独立部分 - ngingx，rails，postgres。在监控，扩展和更新方面，每个部分都有不同的需求。
您可以将所有3个放入一个吊舱中。这复制了VM的体验，但具有可管理性，部署等方面的一些优势。但是您已经在调出一个主要缺点 - 您希望扩展（例如）rails应用程序而不是postgres实例。是时候分解了。
如果您改为制作2个pod--一个用于rails + nginx，另一个用于postgres，该怎么办？现在，您可以扩展前端，而不会弄乱数据库部署。如果有意义的话，您可以更进一步将rails app和nginx拆分为不同的pod。或者将您的rails应用程序拆分为5个较小的应用程序。
这是微服务背后的整个想法（我知道这是一个非常大肆宣传的词）。将问题分解为更小且更易于管理的块。这就是为什么kubernetes存在 - 帮助您管理由此产生的微服务海洋。
要回答你的上一个问题 - 没有单一的食谱。这完全取决于您的应用程序的结构以及对您有何意义。也许您希望沿着团队边界，或者沿着公司的部门或管理员角色进行分解。要问自己的问题是“如果我更新或扩展此pod，是否有任何部分我不想同时更新/ sclaed？”
在某种意义上，这是一个数据规范化问题。 pod应该是一个概念或所有者或范围的模型。我希望这有点帮助。
答案 1 :(得分：1)
如果要同时部署和更新容器，或者需要共享本地状态（磁盘，网络等），则应将容器放入同一个容器中。在某些边缘情况下，出于性能原因，您可能还希望将它们放在一起。
在您的方案中，由于nginx和rails应用程序可以水平扩展，因此它们应该位于自己的pod中，以便您可以为应用程序的每个层配置正确数量的副本（除非您始终在同一个位置扩展它们）时间）。 postgres数据库将位于一个单独的pod中，可通过服务访问。
这使您可以更新到较新版本的nginx，而无需更改有关您服务的任何其他内容。对于rails应用程序也是如此。他们可以各自独立扩展。